Why your numbers differ from Meta, Shopify, and GA4

Open nod. next to Meta Ads Manager, your Shopify admin, and GA4, and you will see three different revenue numbers for the same day. None of them is broken. Each tool answers a different question with a different method. This article walks through each comparison so you know which gap is expected and which one means something is actually wrong.

vs. Meta Ads Manager

Meta's reported revenue and nod.'s reported revenue rarely match, by design.

Meta models its own credit. Ads Manager attributes conversions using Meta's own attribution window and its own modeling, including conversions it estimates rather than directly observes (to cover iOS and blocked pixels). nod. attributes from your own first-party pixel and Shopify order data, credited across the nod. models, with nod. Mix as the recommended read. Two different attribution engines, looking at overlapping but not identical evidence, will not agree to the cent.

A Meta number inside nod. is a Platform Claim, not nod. credit. Synced conversion and value aggregates keep Meta's attribution window, identity graph and model. They sit beside nod. Mix V3 for comparison and never enter its Journey or allocation math.

Verified view credit needs a different contract. Meta Insights exposes aggregate 1-day-view reporting and video-watch metrics, but not a documented public order-level read that tells nod. which impression belongs to one Shopify order. CAPI sends conversions to Meta; it does not read impressions back. Unless an eligible provider supplies conversion-linked evidence under a permitted contract, Mix V3 labels verified exposure unavailable and remains observed-only. nod. does not manufacture the missing link from aggregate watch time.

Meta counts some conversions Shopify never sees as "orders" the same way. Meta's number can include view-through and modeled conversions that never show up as a distinct, stitched order in nod. nod. only counts a conversion once Shopify (or the pixel) has recorded an actual order.

Double counting is a separate, fixable problem. If your own Meta browser pixel fires a Purchase event alongside nod.'s server-side send-back (CAPI), Meta can see the same order twice and inflate its own reported revenue further. This is the most common reason the gap is larger than it should be — see Avoid double counting with your own Meta pixel to fix it.

Because of this, use Meta's own numbers to judge Meta's own modeling, and use nod. to see how Meta spend fits into your full picture across channels.

vs. Shopify admin

nod. is built to reconcile with Shopify admin as closely as any external system can, but a few conventions still create visible gaps.

• Timezone: nod. buckets every day using your store's own IANA timezone (the same one Shopify uses), not UTC — including on DST transition days. If your numbers ever looked shifted by a few hours, that's fixed; day totals should now line up with what you see in Shopify admin.
• Cancelled orders: nod. excludes cancelled orders everywhere — revenue, order counts, every report. Shopify's own analytics may present cancelled orders differently depending on the view you're looking at.
• Refunds: nod.'s matrix view (the main channel table) shows gross revenue — refunds are reported in their own column, never subtracted. Other views — deep dive, cross-channel, and the browser extension overlay — show net revenue (gross minus the refunded amount). If you're comparing to Shopify's net sales, use deep dive or cross-channel, not the matrix.
• Test orders: Shopify test orders never become a conversion in nod. at all — no revenue, no order count, nowhere.
• POS (in-person) orders: these ARE recorded as conversions in nod. — they count toward revenue and orders — but they never trigger a Meta CAPI Purchase send-back, since an in-store sale isn't a website event.

vs. GA4

GA4 is a different measurement system entirely — its own session definition, its own attribution model, and its own view of your traffic. It is not reading the same pixel or the same order data nod. reads, so treat a gap here as expected rather than a bug. If the difference looks extreme (order-of-magnitude, not a few percent), check My numbers look wrong: a checklist for setup issues on the nod. side before assuming GA4 is right.

vs. Google Search Console

Search Console reports aggregate organic search demand, not customer journeys. Its site totals include clicks and impressions whose individual queries Google does not expose. Query and page tables return top rows, and Google may suppress anonymized queries. nod. also applies privacy filters and removes defined high-risk query and page patterns before storage. The visible query table will therefore be smaller than the authoritative site total. The Coverage and Unknown values make that gap explicit.

Search Console dates use Pacific Time (America/Los_Angeles), while attribution uses the shop timezone. Do not expect daily rows to line up across those two source calendars.

There is no visitor, session, order or conversion ID in Search Console's Search Analytics data. nod. does not join a query or page row to a journey, and rising Brand Search does not prove that a specific ad caused it. Read Search Demand as aggregate context. Read nod. Mix for conversion credit.

Conventions at a glance

Which number to steer by

Steer by nod. for the same reason nod. exists: it's first-party. It reads your own pixel and your own Shopify orders — not a platform grading its own homework, and not a third-party analytics tool with a different session model. Meta's number tells you how Meta sees its own performance. Shopify's number is your ledger. GA4's number is its own model of your traffic. nod. is the one place built specifically to tie ad spend to real, stitched revenue across every channel at once — so when you need to decide where the next dollar goes, that's the number to use.

Inside nod., read nod. Mix V3 first: Created shows eligible demand creation, Intent Captured shows an explicit linked milestone, and Final Closed shows the observed closing role. Read the evidence and health state with the number. If you want to know how much a channel's result depends on the model, the corridor between observed-only comparison models is the honest answer. When that corridor straddles break-even, no model settles the question; only a controlled test does.