My numbers look wrong: a checklist

"The revenue on my dashboard doesn't match Shopify" or "Meta says one number, nod. says another" is the most common support question we get. Most of the time nothing is broken — you're comparing two things that were never meant to match. Work through this list in order; each step tells you what to check, where to check it, and what to do about it.

1. Are you comparing the right thing?

Check: the attribution model, the date window, and the timezone on both sides of the comparison.

Where: the model switcher and date picker on the attribution dashboard.

What you'll see: the picker holds six entries: First Click, Last Click, U-Shape, nod. Mix, Data-Driven and Unique. The same period can show different revenue under the first five, which is expected, since each of them splits one purchase's credit differently across the touches that led to it. Unique is the odd one out: it credits the whole conversion to every entity on the path, so it counts participation and can total more than the conversions behind it, and it carries no revenue at all. Note that Data-Driven currently shows the same numbers as U-Shape; the real model isn't live yet, so don't expect it to differ.

Fix: confirm you're on the same model, the same date range, and pick a consistent shop-timezone lens. nod. buckets every day using your Shopify store's timezone (captured when you connected Shopify, falling back to Europe/Berlin if it was never captured), the same way Shopify admin does. If you're comparing against a report that buckets in UTC, orders near midnight can shift to the adjacent day and throw off a same-day comparison.

2. Check nod.'s conventions before assuming a bug

Check: whether the discrepancy is explained by how nod. counts, not a tracking gap.

Where: the attribution matrix and deep dive.

What you'll see:

• Cancelled orders never count — no revenue, no order, on any surface.
• The matrix shows gross credited revenue; refunds are summed in their own column, attributed by the same per-touch split, but never subtracted from that revenue column. Deep dive and cross-channel show both gross and net (gross minus the credited refund share) — pick the one you meant to read.
• Test orders never become a conversion.
• POS (in-person) orders do count as a conversion, but a lead is not an order — leads are tracked as their own metric, separate from revenue and order counts.

Fix: if a number looks low, check whether cancelled or test orders explain the gap before digging further. If it looks high, check whether you're reading gross where you expected net.

3. Is coverage low?

Check: what share of your sessions and orders are actually stitched to a touch path.

Where: the coverage view (tagged-session rate and order-stitch rate).

What you'll see: a low tagged-session percentage usually means your ads aren't carrying nod.'s URL parameters. A low order-stitch rate means orders are landing in the honest unattributed bucket. By default nod. doesn't redistribute that revenue to other channels, so a real coverage gap shows up as unattributed rather than as a wrong number somewhere else. The redistribution lens is optional and labeled wherever it's on, so if a channel looks bigger than you expected, check whether you're reading the lens or the default.

Fix: see the coverage article linked below for what each number means and how to raise it.

4. Give it time, then recompute

Check: how recently the order or pixel event came in.

Where: the timestamp of the order versus now.

What you'll see: Shopify orders derive quickly — the webhook triggers a derivation right after Shopify delivers it. Pixel-only purchases and CRM leads wait for the next scheduled derive, which runs every 30 minutes, so they can lag by up to that long.

Fix: if the order is recent, wait for the next cycle. If it's been longer than that and the number still looks wrong, an admin can trigger a manual recompute from the dashboard.

5. Does Meta look doubled?

Check: whether the same purchase is being counted by more than one source on the Meta side — nod.'s server-side send-back (CAPI) and the shop's own browser pixel.

Where: Meta Events Manager, and your Shopify custom pixel setup under Settings → Customer events.

What you'll see: if your store also fires its own Meta pixel and it isn't deduplicated against nod.'s send-back, the same order can show as two Purchase events in Meta.

Fix: see the double-counting article for how to set this up correctly — it comes down to making sure only one browser-side Purchase carries the same event id nod. sends server-side.

6. Platform-reported vs. nod.-attributed — know which one you're looking at

Check: whether the dashboard is showing nod.'s own multi-touch attribution or a platform's self-reported numbers.

Where: the basis indicator on the dashboard.

What you'll see: nod. shows its first-party, multi-touch numbers whenever the pixel has captured touches in the window. If it hasn't — for example, before the pixel was installed — nod. falls back to showing the platform's own reported numbers (Meta's reported revenue and ROAS, Klaviyo's email-attributed revenue, and so on) and labels this plainly. Platform-reported numbers are last-touch by nature, so they won't match a multi-touch model even when both are "correct" for what they measure.

Fix: check which basis you're on before comparing to nod.'s own attribution. If you're stuck on platform-reported numbers longer than expected, confirm the pixel is installed and firing.

Still stuck?

If you've worked through all six and the number still doesn't add up, contact support with the workspace, the date range, and the model you're comparing — that's enough for us to look at the same numbers you're seeing.