Checkout Extensibility Broke Your Tracking

What Actually Changed

For years, Shopify Plus stores could edit checkout.liquid, the template behind the checkout, and any store could paste "additional scripts" into the order status page. That's where a decade of tracking accumulated: Google Ads conversion snippets, GA4 code, affiliate network pixels, survey tags, the lot.

Checkout Extensibility replaces all of that with a locked-down checkout you customise through apps and sandboxed extension points instead of raw code. More secure, upgrade-safe, and considerably less forgiving of the tracking habits everyone had built up.

The timeline, for the record:

• August 2024 — checkout.liquid stopped working on the checkout steps themselves (information, shipping, payment) for Plus stores.
• August 2025 — the Plus deadline for the thank you and order status pages. After this, legacy additional scripts couldn't be edited and customer details were withheld from the old pages.
• January 2026 — Shopify began automatically upgrading Plus stores that hadn't migrated, and legacy scripts on those pages were dropped in the process.
• 26 August 2026 — the deadline for everyone else: non-Plus stores lose additional scripts on the thank you and order status pages.

What Broke

• Additional scripts on the thank you and order status pages. The classic home of conversion tags. Google Ads snippets, Meta pixel purchase events, GA4 purchase code, all of it stops firing when the pages upgrade. If reported conversions dipped the day your checkout changed, this is why.
• Script-tag apps in checkout. Apps that injected their code into checkout via script tags lost that ability. Some vendors rebuilt as proper checkout apps or pixels, some didn't. An app can look installed and healthy while its checkout script silently no longer runs.
• Affiliate network pixels. Awin, Rakuten and friends traditionally lived in additional scripts. Networks have published migration paths, but nothing migrates itself, and unrecorded affiliate sales have a way of turning into awkward conversations about commission. More on that in affiliate tracking not recording.
• Custom conversion scripts and hacks. Anything bespoke, custom deduplication logic, enriched data layers, third-party survey or review triggers, needs rebuilding in the new model. The old code isn't sitting there disabled, on upgraded stores it's simply gone.

What Didn't Break

Worth being clear about, because the panic tends to overshoot:

• Tracking in your theme. Everything before the checkout, product views, add to carts, tags in theme.liquid or GTM on the storefront, is untouched. Checkout Extensibility only changed checkout and the post-purchase pages.
• Shopify's native integrations. The Google & YouTube channel app and the Facebook & Instagram app report conversions through Shopify's own pipes, not your scripts, and carried on working. If those are your only tracking, you may have sailed through unscathed.
• Server-side tracking. Anything driven by Shopify webhooks, order notifications sent server to server, never depended on checkout pages in the first place. It didn't even notice the migration.
• Your actual orders. Obviously. Shopify's own numbers are the ground truth while you rebuild, same principle as in GA4 not matching Shopify: when reports disagree with the till, believe the till.

What Replaced It: Customer Events and Custom Pixels

The official successor is Customer Events, found in Settings under Customer events, where you install custom pixels: JavaScript snippets that subscribe to Shopify's standard events (page_viewed, product_added_to_cart, checkout_completed and so on) and forward them to your tools. This is now the supported way to run GA4, Google Ads or Meta code through the checkout without an app.

The catch, and it's a significant one: custom pixels run inside a sandbox, an isolated container walled off from the actual page. Your code no longer sees the real URL, can't read other scripts' cookies, and behaves differently enough from on-page tags that naive copy-paste migrations produce subtly wrong data, missing ad click IDs, broken sessions, attribution quietly going sideways. It's a big enough topic that I've given it its own guide, read that before you paste your old GTM snippet into a pixel and call it migrated.

The Server-Side Alternative

The other route skips the browser entirely. Shopify fires a webhook, a server-to-server notification, the moment an order is created, containing everything a conversion tag would want. Feed that into a server-side tag manager (server-side GTM, or a managed equivalent) and your purchase tracking no longer cares what the checkout pages do, this week or next redesign.

It's more setup than a custom pixel, and there's a small monthly running cost for the server, but it's immune to sandbox quirks, ad blockers and future checkout changes, and it typically records more of your real conversions than browser tags ever did. For purchase events specifically, it's the most durable answer available, the full case for and against is on my server-side tracking page.

The Migration Checklist

In order:

• Inventory the old scripts. Dig out what was in checkout.liquid and additional scripts (from the legacy settings if still visible, or from whoever built them). List every tag and what it fed.
• Decide each tag's fate. For each one: replaced by a native integration already? Rebuild as a custom pixel? Move server-side? Or, be honest, nobody's looked at its data since 2021 and it can die here.
• Rebuild in the right place. Native apps for the standard platforms where they suffice, custom pixels for the rest, webhooks or server-side for purchase events you can't afford to lose.
• Kill the duplicates. The most common post-migration fault I see is the opposite of missing data: the old tag still firing somewhere alongside the new one, and every sale counting twice. If your numbers went up after migrating, that's not a win, see Google Ads counting conversions twice.
• Test with real orders. Place a test order and follow it through every tool, Google Ads, GA4, Meta Events Manager, affiliate dashboards. An event arriving is not the same as an event arriving with the right value, currency and IDs attached. For Meta specifically, check the match quality hasn't cratered: event match quality explained.
• Compare against Shopify for a fortnight. Daily orders versus reported conversions in each platform. Steady, explainable gaps are fine, growing or erratic ones mean something in the rebuild is off.

Why This Is Actually an Opportunity

Nobody enjoys a forced migration, but here's the quiet upside. Most stores' checkout tracking was sediment, layers of snippets from successive agencies, apps and late-night fixes, nobody sure what half of it did, plenty of it double counting or dead. Checkout Extensibility burns that down whether you like it or not.

Rebuilding from a clean slate means one deliberate tag per platform, transaction IDs done properly, purchase events somewhere durable, and a written record of what runs where. Stores that treat this as a rebuild rather than a patch usually end up with more accurate numbers than they had before the migration, sometimes revealingly so, I've seen what happens when the old sediment was quietly lying.

If you'd rather someone else did the digging, my tracking health check covers exactly this: what your checkout is actually sending now, what it should be sending, and a written plan to close the gap.