Home›Blog›GA4 purchase event not firing

GA4 purchase event not firing on Shopify: the 5 usual causes

By Sam Parkinson18 September 20267 min read

You can see the orders in your Shopify admin. GA4 shows fewer, or none, or a suspiciously round £0 in revenue. Your ad platforms are optimising on that same broken number. Here is why the GA4 purchase event fails on Shopify, and how to work out which of the five it is in about ten minutes, without guessing.

The short answer, before the detail: a GA4 purchase either never fires (the tag isn't running where the sale completes), or it fires without the parts that count (no transaction_id, no value), or it's blocked (consent), or it was quietly changed (a theme or app update), or it's firing twice. Each looks different in the data, so start by reading the symptom.

First, confirm it's actually broken

Before you change anything, prove the gap is real and not just reporting lag:

1. In Shopify, count orders for a fixed window, say yesterday, in your store's timezone.
2. In GA4, open Reports › Monetization › Ecommerce purchases (or Realtime for a live test) for the same window.
3. Allow for GA4's 24–48 hour processing delay and check both are in the same timezone. A small gap is normal. A large gap, or zero, is a fault.

If the gap is real, complete one test order on your own store with GA4 DebugView open (or the Google Analytics Debugger browser extension). What you see, or don't, tells you which cause you have.

Cause 1 — the purchase isn't connected to Shopify's checkout event (the Shopify classic)

This is the most common one, and it's specific to Shopify. Tracking code installed only in your storefront theme does not automatically give you a reliable purchase event from Shopify's checkout. Checkout runs on Shopify's own pipeline, so a GA4 snippet in theme.liquid loads on your product and collection pages but isn't guaranteed to fire at the moment the sale completes. You see page_view and maybe add_to_cart, then nothing at the finish line.

The fix: connect the purchase to Shopify's own checkout event rather than tracking it from the theme. Modern Shopify implementations do this through the Google & YouTube integration, app or custom pixels, and customer events, depending on the setup, so pick the route that matches yours:

• Connect the Google & YouTube sales channel, which wires GA4 purchase tracking through Shopify's own pipeline, or
• Add a Custom Pixel under Settings › Customer events that listens for the checkout_completed event and sends the GA4 purchase. Customer events is the sanctioned way to run tracking on checkout without a theme hack.

In DebugView, the tell is clean: events up to begin_checkout, then no purchase at all.

Cause 2 — it fires, but the payload is incomplete

The event arrives, so DebugView shows a purchase, but revenue in GA4 stays at £0 or item data is missing. That means the event is firing without its required parameters:

• value and currency — without these there is no revenue to report.
• transaction_id — without it, GA4 can't de-duplicate, so refreshes and back-button revisits either double-count or get dropped.
• items — missing this leaves product-level reports empty even when totals look fine.

The fix: make sure whatever sends the purchase reads the real order total, currency and order name into those exact fields. In DebugView, click the purchase event and read its parameters, a blank value is the whole story.

Cause 3 — consent mode or a cookie banner is blocking it

If you run a consent banner (you likely should, for UK/EU visitors), GA4 respects it. When analytics consent is denied by default and the shopper checks out before accepting, the purchase is either withheld or sent without identifiers, and never lands as revenue. The trap is testing it yourself after clicking accept, which hides the problem.

The fix: test checkout with the banner in its default, pre-consent state. Decide deliberately whether you use Consent Mode v2 (which sends cookieless pings that GA4 models) and confirm your banner and GA4 agree on what "denied" does.

Cause 4 — a theme or app update quietly changed it

Tracking that worked last month can stop the day you switch theme, update it, or install an app that manages its own tags. A theme update can overwrite a customised theme.liquid; a new app can inject a second GA4 or strip an old one. Nothing looks broken on the storefront, and the alert you get is a quiet dip in reported sales two weeks later.

The fix now: re-run your test order after any theme change or app install. The fix for good: this is exactly the failure that continuous monitoring exists to catch, the reason Guardrails re-checks your tags after every deploy rather than trusting that a green tick from launch day still holds.

Cause 5 — it's firing twice

The opposite problem: GA4 shows more revenue than Shopify. The most common version is worth calling out plainly: Shopify itself warns that adding GA4 through Google Tag Manager on top of its built-in Google & YouTube integration can produce duplicate tracking. Two installs both fire purchase on the same order. If they share a transaction_id, GA4 de-dupes some of it; if they don't, you double-count and make every ROAS number optimistic, which is arguably worse than under-counting because it flatters the exact metric you scale spend on.

The fix: pick one method and remove the others, don't run the Google & YouTube integration and a GTM/hardcoded GA4 in parallel. In DebugView, two purchase events on a single order is the fingerprint.

The 60-second check on your own store

Before you dig into checkout code, rule out the simplest thing: are the tags even installed and detectable on your public pages? A lot of "not firing" turns out to be "not present", or a legacy Universal Analytics tag still sitting there doing nothing.