Why is my Shopify conversion tracking not working?

When a Shopify store owner tells me conversion tracking is broken, they mean one of two things. Either the numbers in Meta and GA4 don’t match Shopify, or the numbers are missing entirely. Both trace back to a short list of failure points. I check them in order.

Broken, or just different?

Before you call it broken, put a number on the gap between what the ad platforms report and what Shopify recorded.

Gap, platform purchases against Shopify paid orders, 30 days	What it usually means	What I check
Inside 10 percent	Reconciled. The rest is click date against order date	Nothing, move on
10 to 25 percent	Something specific, still unnamed	Attribution window, counting setting, refunds
Above 25 percent, platform lower	An event is missing or blocked	The Customer Events pixel, first-party loading, consent
Above 25 percent, platform higher	Purchases are counted twice	Duplicate installs, missing event_id dedup

Start with funnel event volumes, not the purchase

The fastest tell isn’t the purchase event. It’s everything before it.

Pull event volumes for the last 10 days, from GA4 or your server container, and put view_item, add_to_cart, and begin_checkout beside PageView and purchase. You’re looking for an event that sits at a tiny fraction of page views while purchases look normal.

On one store I audited, ten days of server logs showed thousands of page views and a steady run of purchases, but only a handful of product views and add-to-carts. Its custom pixel listened for the completed checkout and nothing else. Once the pixel subscribed to the full funnel, the ad account’s add-to-cart action went from almost nothing the month before to hundreds in the first full month.

An event that low is broken, not underperforming. No amount of bid tuning fixes it, because the platforms have nothing to optimize toward. That’s the problem to fix first.

The four causes I check

1. The Customer Events pixel is missing or incomplete

Shopify moved checkout to a sandboxed environment. The old approach of dropping pixel snippets into theme.liquid doesn’t capture checkout anymore. Tracking now lives under Settings, then Customer events. Pixels installed by a channel app show up there on their own, and your own code goes in as a custom pixel on the same screen.

The common breakage: the pixel exists but subscribes only to checkout_completed. That gives you a purchase number and nothing else. View item, add to cart, and begin checkout never fire, so your funnel goes dark before checkout. Subscribe to the full event set, not just the purchase.

2. Event names don’t match your GTM triggers

This one is quiet and expensive. The Customer Events pixel emits an event, but the event name doesn’t match what your GTM Web Container trigger is listening for. The trigger never fires. The event never reaches GA4 or your server container.

The harsher version is a published event with no subscriber at all. A theme file can call Shopify.analytics.publish() and Shopify accepts it whether or not any pixel is listening, so the producer looks finished while nothing consumes it. I walk through finding that one in my own build, including why the fix was to take the conversion out of the sandbox rather than write a subscriber for it.

Open your GTM Web Container, list your triggers, and compare each trigger name against the exact strings your pixel pushes to the dataLayer. A mismatch as small as add_to_cart versus addToCart kills the whole chain silently. Nothing errors. The event just disappears.

Case counts too. On Emma Grace Home, a furniture store I built, the purchase tag sent Purchase with a capital P. GA4 ecommerce binds to lowercase purchase, so that one character kept purchases out of GA4’s ecommerce reports even when the event fired.

3. Purchases are sent twice

The break I find most often on Shopify is a duplicate install: the Shopify Google & YouTube channel plus GTM, or two GA4 installs, firing the same event twice. On one store I audited, the Google & YouTube channel had injected a second copy of the GTM container, so every dataLayer event fired into two instances.

Meta has its own version. If you run a Meta browser pixel and a server-side CAPI feed at the same time without a shared dedup key, Meta counts each purchase twice. On that same store, a legacy CAPI auto-setup and a later server-side build both sent every purchase, with event IDs that didn’t match, for six months. The store owner sees great ROAS in Meta, terrible reconciliation against Shopify, and can’t trust either number.

The fix is a stable key shared between the browser event and the server event. Meta deduplicates when the event name matches and the pixel’s eventID equals the server’s event_id. Without a matching ID, Meta falls back to fbp or external_id, which generally only works when the browser event arrives before the server one. Set event_id explicitly (the order ID works for Purchase) and pass the identical value from both the browser pixel and the server tag. For duplicate installs, the fix is to remove one delivery route, not to dedupe two.

4. Pixels load third-party and get blocked

If your Meta Pixel still loads from connect.facebook.net and your GA4 still loads from Google’s domains, ad blockers and browser privacy defaults drop part of your traffic before any event fires. On the store with the duplicate container, the server path was recovering 45% of events and 51% of purchases from Safari’s tracking prevention, and adblock recovery read 0% because the theme still loaded GTM from googletagmanager.com instead of the paid first-party loader.

Check what’s loading on your storefront. GTM and GA4 should come from a first-party subdomain like load.gtm.yourbrand.com. If they’re still loading third-party, you’re leaving recoverable conversions on the table. First-party loading for GTM and GA4 is the higher-priority fix here. Routing the Meta Pixel server-side is a separate, paid step and I only recommend it when Meta is a large line item.

Consent can also zero out your data

Before you tear apart the pixel, check consent. Pull your GA4 requests by consent choice. If a large share reads “Not set,” Consent Mode may be failing at the source. The direct test is to accept your own banner, reload as a returning visitor, and read the gcs parameter on an outbound Google request. On one store I audited, visitors had said yes and the beacons still carried gcs=G1--.

One caution. A high “Not set” share can be old data from before a consent platform was installed, not proof that consent is broken now. Verify what’s actually deployed before you call it missing. Look in the storefront for an active consent platform and confirm it fires before GTM, not after.

The diagnosis order I follow

1. Funnel event volumes against PageView. This tells you if the problem is broken events or just attribution noise.
2. The Customer Events pixel. Confirm it exists and subscribes to the full funnel, not only checkout_completed.
3. Event name matching between the pixel and your GTM triggers.
4. Deduplication keys between browser and server.
5. First-party versus third-party script loading.
6. Consent Mode coverage.

I start at steps 1 and 2 because a broken event looks like a quiet one. Across 33 Google Ads accounts I manage, in the 30 days to October 21, 2026, 16 had at least one biddable website conversion action that recorded zero conversions. Some of those are low-volume, and some are broken without anyone knowing. A broken action rarely announces itself: on one contractor account, renaming a form button from Send to Submit broke the click-text trigger behind the only website conversion, and it sat Inactive with nobody told. In the funnel case above, the owner would have looked at the purchase pixel, and the purchase was the one event still firing. The damage is upstream, in the events the ad platforms need to find buyers in the first place.

One more check belongs on that list, and it sits above all six: confirm the actions your account counts as conversions are purchases. In my Ecommerce Tracking Accuracy Benchmark, covering May to August 2026, two of three accounts counted add-to-cart events inside the Conversions column, at 16.6% to 17.2% of the total, and one campaign had no purchase goal on it at all. Tracking that fires correctly into the wrong definition still reads as broken from the outside.

If you have run through this list and the numbers still don’t reconcile, the next layer is server-side observability. Turn on outgoing request logging in your server container so you can see exactly what’s being forwarded to Meta, Google Ads, and GA4. You can’t fix what you can’t watch. The full architecture is in my Tracking Stack reference.

When to bring me in

Bring me in when Google Ads, Meta and your store report different numbers for the same sales, when a purchase or lead event stopped firing after a site change, or when you can’t say which number to trust.

I'm Conner Crowe, and I write every audit myself. Send the free audit request and add me as a read-only user, and within 24 hours of access you'll have a written read on which numbers to trust and what to fix first. No call needed, and nothing in your account or store changes.

Request a free Google Ads audit →

See how I fix conversion tracking.