Skip to content

TroubleshootingGA4Shopify

GA4 Not Tracking Purchases on Shopify: Diagnosis

GA4 showing zero or missing purchases on Shopify? Diagnose checkout extensibility gaps, sandboxed pixels, express checkout, and consent causes.

Published
Reviewed

Diagnosis

  1. Platform GA4 · Shopify
  2. Usual cause The Shopify purchase event stopped firing or fires without transaction_id.
  3. Causes, ranked 4
  4. How to diagnose it 8
Go to the checks

First answer free, within one working day. Describe your case

Sounds familiar?

The symptom

Symptom report GA4 · Shopify

Real orders are coming in. GA4’s purchase report is empty, or shows a fraction of what it should. This is usually the first thing a merchant notices when tracking is broken, because it’s visible without any reconciliation work — the ecommerce report just doesn’t move, even while the order list in Shopify Admin keeps growing.

It’s worth ruling out the mundane explanation before assuming the pixel is broken: test from a browser without an ad blocker or tracking-prevention extension active, since a blocked request looks identical to a missing one from inside GA4’s reports. Once that’s ruled out, the cause is almost always one of a small set of Shopify-specific issues.

A checkout path where the final purchase signal never leaves
Tick what you see

Tick the lines that match your store.

Describe my case

The short version

Direct answer

GA4 purchase events on Shopify go missing for a small, recurring set of reasons: no Customer Events pixel installed after a checkout extensibility migration, a pixel installed but sandboxed away from the data it needs, an express checkout path (Shop Pay, Apple Pay, Google Pay) the pixel was never tested against, or consent blocking the event before it fires.

Running a real test order through GA4’s DebugView isolates which of these you have faster than reading through pixel code.

Where to look

Causes, ranked

GA4 shows no purchases4 causes

  1. Checkout extensibility gap

    If your only purchase tracking lived in the legacy “Additional Scripts” box and nothing was migrated, there may be no pixel firing on the checkout or thank-you page at all, on any path.

  2. Customer Events pixel missing or sandboxed

    Web Pixels run in a sandboxed context with no direct access to the page’s DOM or a global dataLayer. A pixel written to read window.dataLayer the old way will see nothing — it needs to use Shopify’s analytics.subscribe('checkout_completed', ...) API instead.

  3. Payment-method bypass

    Purchases that go through Shop Pay, Apple Pay, or PayPal Express can behave differently from a standard card checkout. If the pixel was only ever tested against the standard path, express checkouts are a common blind spot.

  4. Consent blocking

    If analytics consent defaults to denied and the CMP never sends an update signal before the purchase fires, the event either doesn’t leave the browser or arrives without the data GA4 needs to count it.

8 steps

How to diagnose it

Work through them in this order.

  1. In Shopify Admin, go to Settings → Customer events and confirm a GA4 pixel is listed and shows as connected — not just added.
  2. If the store still has access to legacy Additional Scripts (Settings → Checkout → Order status page), check whether tracking code still lives there and whether Shopify shows any migration notice on that screen.
  3. Place a real or test order, then open GA4 → Admin → DebugView with your debug parameter active, and walk the checkout through to confirm a purchase event appears with transaction_id, value, and an items array populated.
  4. Repeat the same test using at least one express checkout path (Shop Pay or Apple Pay) separately — don’t assume a passing standard-checkout test covers it.
  5. Open the browser’s Network tab on the thank-you page and look for the actual collect request to Google’s analytics endpoint. This confirms the event fired client-side even if DebugView is lagging.
  6. Check whether the pixel is reading a dataLayer object versus subscribing to Shopify’s checkout_completed event — the former breaks under sandboxing even if the pixel “looks” installed.
  7. In DebugView, check the consent state attached to the purchase event to see whether analytics_storage was granted before it fired.
  8. Confirm the GA4 property and data stream ID configured in the pixel match your live property — a stale ID pointing at an old or test property is a common, silent cause.

Signal and fix

Decision table

CauseSignal you’ll seeFix
Checkout extensibility gapNo purchase events on any path, ever; Additional Scripts is empty or shows a migration noticeInstall a Customer Events pixel that reads Shopify’s checkout_completed event
Pixel missing/sandboxedPixel shows “connected” in Shopify but DebugView shows nothing; no collect request in the network tabRewrite the pixel to use analytics.subscribe('checkout_completed', ...) instead of reading a dataLayer
Payment-method bypassStandard checkout tracks fine; Shop Pay/Apple Pay/PayPal orders never appearConfirm the pixel subscribes to the same checkout_completed event regardless of payment method and test each path independently
Consent blockingPurchase event exists in DebugView but is flagged denied, or arrives without ecommerce parametersFix the CMP’s default/update consent signals so analytics_storage is granted before the purchase tag fires

A note from Daniilbefore you decide

Should you fix it yourself or bring in help?

Confirming pixel status in Customer Events, running a DebugView test, and checking the network tab are things any merchant comfortable in the Shopify and GA4 admin can do in under an hour.

What usually needs a developer or specialist is rewriting a pixel to work inside the Web Pixels sandbox, debugging why one specific express-checkout path doesn’t fire, or wiring consent state correctly through to the purchase event.

If DebugView confirms the event simply never fires — on any path — that’s a build task, not a settings fix, and worth scoping through GA4 consulting rather than trial and error against a live checkout.

One more thing worth checking before escalating: if a GTM web container sits between the pixel and GA4, confirm the container is actually publishing a live version, not just saved in a draft workspace — a surprisingly common reason a “correctly configured” tag never fires in production.

— Daniil

Next

If the self-check does not settle it.

The checks above find the cause in most stores. When two or more overlap, an order-level reconciliation is faster than another afternoon spent comparing dashboards.

Tracking Health Check

Price
USD 395
Access
Read-only
Timeline
verdict two working days after the kickoff

What the reconciliation shows for this symptom.

A Health Check reconciles this symptom order by order against your Shopify orders, so the cause is a fact from your own data, not a guess from a dashboard. Real numbers for this symptom are not published yet — ask for the sample report.

Request a Health Check · USD 395

Follow the order. Then compare the evidence.

  1. Real orderOrder ID, amount, currency
  2. Browser / server eventsConsent, event ID, delivery
  3. GA4 / advertising platformsReceived events and reporting
  4. Reconcile the recordsMatch IDs, time windows and definitions
A completed order and a reported conversion are different records. Check the path and compare like-for-like before treating a difference as missing data.

Questions

Questions this symptom raises

I installed a GA4 pixel through an app, why is nothing showing up?

An installed pixel and a working pixel aren't the same thing. Many app-installed pixels are configured against the wrong GA4 property or data stream, or subscribe to the wrong Shopify checkout event. Confirm the property/stream ID matches your live GA4 property, then verify with a real test order in DebugView rather than trusting the app's own 'connected' status.

Does DebugView show everything, or can an event fire and still not show there?

DebugView only shows events tagged with your debug parameter or sent from a device running the GA4 Debug extension. If you're testing without either active, a working purchase event can fire and never appear there. Check the browser's network tab for the actual collect request as a second, independent confirmation.

Is checkout extensibility the same thing as Customer Events?

They're related but not identical. Checkout extensibility is the broader framework replacing checkout.liquid customization. Customer Events (the Web Pixels API) is the specific mechanism within it for adding tracking pixels — it's what a GA4 pixel needs to use to keep working under the new checkout.

Will Shopify's own GA4 integration work without GTM?

Yes, for standard ecommerce events — Shopify's native or custom Customer Events pixel can send purchase data directly to GA4 without a GTM container in between. GTM adds flexibility for custom parameters and multi-tag management, but it isn't required for basic purchase tracking to work.

Read more, or check a neighbouring symptom.

All symptoms

If purchases fire but the revenue totals still don’t line up with Shopify, see GA4 revenue doesn’t match Shopify. If the checkout itself just changed and tracking broke afterward, see Shopify checkout tracking broken. For how a pixel and dataLayer relate in general, see dataLayer. If purchases arrive more than once per order, see GA4 purchase fires twice.

Daniil Maximkin

Hi, I’m Daniil.

I work with you from defining the problem to implementation and handover. You talk to the person who does the work. I work in English and Russian.

My story My work

Tried it and still stuck?

Describe your task

The first answer is free, within one working day. Or write directly: next@taskfordaniel.com