Why is my Shopify conversion tracking not working?

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

Start with funnel event volumes, not the purchase

The fastest tell is not the purchase event. It is everything before it.

Pull your GA4 request volumes for the last 10 days and use PageView as the denominator. Then look at the ratios:

• view_item should land around 30 to 60 percent of PageView
• add_to_cart should land around 5 to 15 percent
• begin_checkout should land around 2 to 7 percent

If any of these sits below 1 percent of PageView, that event is broken, not underperforming. When add_to_cart fires a handful of times in ten days against tens of thousands of pageviews, a small fraction of one percent, the mid-funnel is dark. No amount of bid tuning fixes it, because the platforms have nothing to optimize toward.

When two or more of those events are below 1 percent, your mid-funnel is invisible. That is the problem to fix first.

The four causes I see most

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 does not capture checkout anymore. You need a Customer Events pixel under Settings, Customer events, App pixels.

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 do not match your GTM triggers

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

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.

3. Browser and server purchases are not deduplicated

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. I have seen Purchase inflated by 30 to 100 percent from this alone. The store owner sees great ROAS in Meta, terrible reconciliation against Shopify, and cannot trust either number.

The fix is a stable key shared between the browser event and the server event. Most server-side setups built on Stape map order_id from transaction_id and use that as the implicit dedup key. That works for Purchase. If you want explicit control, set an event_id and pass the identical value from both the browser pixel and the server tag.

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 a meaningful slice of your traffic before any event fires. Roughly a third of an audience runs some form of blocking.

Check what is loading on your storefront. GTM and GA4 should come from a first-party subdomain like load.gtm.yourbrand.com. If they are still loading third-party, you are 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 “Not set” is above 50 percent of events, Consent Mode is failing at the source and the platforms are discarding data that should be modeled.

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 is 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.

Most “tracking is broken” reports resolve at step 1 or step 2. The owner thinks the purchase pixel is the issue, but the purchase is usually the one event still firing. The damage is upstream, in the events the ad platforms need to find buyers in the first place.

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