Shopify controls the code where your purchase fires — and it keeps changing it. I rescue the tracking when it breaks, rebuild it on Customer Events and server-side, and prove it against your real orders. GA4, Meta CAPI, Google Ads, and consent, reconciled end to end.
If you are in this column, say so on the call and I will point you somewhere better. It costs you nothing.
Most of these are not bugs in your setup — they are consequences of how Shopify’s checkout works today. Each one needs a different fix. Shopify’s own documentation on checkout extensibility, the Web Pixels API, and the order status page carries the authoritative, current timeline.
Shopify fires the purchase from Customer Events (the Web Pixels API), which run in a sandbox isolated from your theme and any global dataLayer. A pixel written the old way sees nothing — it has to subscribe to Shopify’s checkout_completed event instead.
Checkout extensibility replaced direct checkout.liquid edits. Tracking that lived in theme files or the checkout no longer runs, and a half-finished migration can leave two pixels firing on the thank-you page at once.
Shopify has announced it is retiring the legacy Additional Scripts box for non-Plus stores, with a stated deadline of August 2026. Any purchase tag still living there goes silent on that date — and nothing alerts you when it does.
Shop Pay, Apple Pay, and Google Pay take shoppers down purchase paths a pixel was often never tested against. Orders through those paths quietly go untracked while the standard checkout still works fine.
A CAPI app plus a theme or Customer Events pixel can send the same purchase twice with different ids the other side never sees — so Meta counts winners that never existed unless event_id deduplication is enforced.
Diagnose cheaply, then fix only what the evidence justifies. Every rung ends with a reconciliation against your Shopify orders.
I do not hand over a report that says “fixed.” The evidence pack lines every platform up against your actual Shopify orders, so the result is provable rather than asserted.
One row per source — GA4, Meta CAPI, Google Ads — with order count and revenue against Shopify as ground truth, and the delta per row.
Proof that the browser and server events for one purchase share a single event_id and are counted once, checked in Events Manager.
Which events fired, on which platform and which checkout path, before the work versus after — legible to your whole team.
Each guide starts with what you can see, gives a direct answer, then walks the real diagnostic — where to click and what the signal means.
For the Health Check, read-only access to GA4, Google Ads, Meta Business, and your Shopify admin. Nothing changes during a diagnosis — you get a verdict first, and nothing goes live without your approval.
No. Customer Events pixels and server changes are built in a separate workspace, previewed, and validated on a real test order before publishing. Every change has a rollback path, and the old path is switched off only once the new one is proven.
Urgent. Shopify has announced it will retire that field for non-Plus stores, with a stated deadline of August 2026. Any tag still there stops firing on that date and your GA4 revenue falls off a cliff, so migrating to a Customer Events pixel is a hard deadline, not optional maintenance.
All three. Stape or self-hosted server-side GTM for most brands; my own platform, Fixel Pixel, when volume, cost, or data control call for it. I recommend whichever is cheapest to run for your case — I am not tied to selling my own product.
Then I tell you that, in writing, and you have bought certainty before scaling spend — which is worth more than a fix you did not need.
Send me your store URL and one sentence about what looks wrong. You will get an honest read: what is likely broken, whether it is worth fixing, and what step one costs.
Daniil Maximkin · Valencia, Spain · working worldwide