Where do purchase events die?
Work the chain in order; each step has a distinct test, and the first failing test is your break.
| Stage | The break | The test |
|---|---|---|
| 1. The trigger | The thank-you or confirmation context never fires your tag - template changed, checkout type differs, consent state blocks it | Place a test order per payment method with an instrumented browser; watch the network layer |
| 2. The payload | Event fires but malformed - missing transaction id, value, currency, or items array | Inspect the actual request parameters, not the tag config |
| 3. Consent and blockers | Event fires only for consenting, unblocked visitors - a population, not a bug | Compare consent-accept rate to the measurement gap; they should be the same size |
| 4. Property processing | Events arrive but land wrong - filters, unwanted-event marking, mis-mapped parameters, wrong property id on one template | Realtime and raw event views against a known test order |
| 5. The report | Data is present but the report hides it - date lag, attribution settings, comparing mismatched scopes | Query the event count directly before trusting any built report |
Why do Shopify analytics and GA4 disagree?
Because they are different instruments. The platform counts orders server-side at the moment of transaction - no consent gate, no blockers, no client to crash. GA4 counts a browser event that must survive the client, the consent state, and processing. The platform's number approximates the orders table; GA4's number is the orders table as seen through measurable web conditions. A stable, explained gap is a healthy system. The defects worth hunting are changes in the gap and unexplained components of it.
Refunds are the classic false alarm. The platform nets them; a purchase event does not un-fire. A store with meaningful refund volume will always show GA4 revenue above platform net revenue unless refunds are handled explicitly.
What about ad platforms not tracking conversions?
The same chain applies with one addition: identity. Ad platforms count a conversion only when they can match the purchase to a click or a user - so beyond firing and payload, the diagnosis includes the click id surviving the journey and customer identifiers being present for matching. A conversion pixel can fire perfectly and still record nothing the platform can attribute, which reads as "not tracking" but is actually "not matching" - a different fix entirely.
How do you verify a fix honestly?
The same way the defect was found: a test order per payment method with the network layer recorded, then a closed date-range reconciliation against the orders table after the fix has run long enough to measure. A fix verified by looking at a dashboard the day after deployment is a hypothesis wearing a suit.