shopify

When Checkout Extensibility meets analytics: migrating from checkout.liquid to Web Pixels without losing conversion data

Thu Apr 09 2026 • Nigel Abramow

After the first deploy of Checkout Extensibility, the orders kept coming in but Meta Events Manager went quiet. GA4 showed a handful of purchase events. TikTok still saw activity, but conversions had halved. Nothing about the products or traffic had changed. The only variable was the move away from checkout.liquid.

This is the common aftertaste of a checkout migration on Shopify right now. Analytics that once lived in Additional Scripts or checkout.liquid no longer have a home. Web Pixels and Customer Events are the new route, but they don’t behave like hand-injected scripts. If the migration is treated as a copy‑paste exercise, you either lose conversions or count them twice.

The goal of this piece is to lay out why that happens, what it costs, and what to check first so you can move to Checkout Extensibility without losing tracking confidence.

The problem

Once checkout.liquid is removed, you can’t run arbitrary JavaScript in the checkout or thank you page. That means GTM snippets, dataLayer pushes and ad pixel code that relied on the checkout DOM no longer run. The replacement is Shopify’s Web Pixels and Customer Events framework, which fires structured events to your pixels under consent controls. If you don’t remap your tracking to those events, or you leave channel apps running server-side alongside legacy browser pixels, purchase reporting breaks.

Why it happens

Migrating to Checkout Extensibility changes how and where tracking can run. The browser still sees events, but the path is different and more constrained. Several patterns tend to create gaps or duplicates.

The checkout is now event‑driven and sandboxed

It’s tempting to think you can move the same scripts to a different slot. In practice, checkout is now a sandbox with a defined event stream and no access to the checkout DOM.

• Legacy GTM snippets, inline scripts and DOM queries in checkout.liquid or Additional Scripts stop running

• Web Pixels receive Shopify-authored event payloads instead of scraping data from the page

• Only the events Shopify exposes at each milestone can be used, such as checkout_started or checkout_completed

The immediate effect is that anything depending on document selectors or window variables from the old checkout won’t work. The solution is to bind to Shopify’s event topics and read the structured payloads they provide.

Consent gating changed the firing rules

Shopify’s pixel runtime is consent‑aware by default. This is good for compliance, but it changes when and how your tags fire.

• Pixels run under Shopify’s customer privacy and Google Consent Mode v2 signals

• If you previously ignored consent or used your own CMP logic, events may be held or modeled instead of fired

• Debugging looks different because suppressed events don’t appear in network logs in the same way

If GA4 setup assumed unrestricted gtag on the thank you page, purchase might not fire until consent is granted, and modeled conversions can diverge from platform counts. You need to align your CMP with Shopify’s consent APIs, or your pixel won’t behave like it used to.

Server and browser now collide more easily

Most merchants run at least one sales channel app (Google, Meta, TikTok) that sends server‑side conversions. When you add custom Web Pixels that also send purchases, you create a duplication risk.

• Channel apps often send server events for purchase with their own event_id

• Custom pixels may send browser events with a different event_id and slightly different item payloads

• Without explicit deduplication, platforms count both, or discard one inconsistently

To avoid this, choose whether a platform should rely on Shopify’s channel app, your custom pixel, or both with matching event_name and event_id for proper dedupe.

The data shape is not a 1:1 with your old dataLayer

Shopify’s event payloads use Shopify-centric formats. They don’t always match the schemas your pixels were built around.

• Variant and product identifiers use GIDs (for example, gid://shopify/ProductVariant/12345)

• Line items, discounts, taxes and shipping appear with specific fields and currency precision

• Subscriptions, bundles and custom attributes require careful mapping to the receiving platform

If you previously posted a tidy dataLayer with numeric IDs and custom item params, a direct send from the raw Web Pixel payload may reduce event match quality or break platform catalog matching.

Cross‑domain and attribution behave differently

Purchase now happens on Shopify’s checkout domain with stricter controls, and Chrome’s cookie changes have narrowed old workarounds.

• Old UA/gtag linker hacks in checkout.liquid are gone, so session linking relies on your GA4 setup and eligible Shopify integrations

• If you moved GA4 fully into a custom pixel without proper cross‑domain config, sessions split at checkout

• UTM and referrer data carried by Shopify’s event payloads may not mirror your prior dataLayer fields

This shows up as lower “purchase per session” in GA4, even while order counts in Shopify are fine. The fix is to implement GA4 through either Shopify’s Google channel with Web Pixels or a custom pixel with cross‑domain support, then verify DebugView end‑to‑end.

What it means commercially

This isn’t a cosmetics issue. It hits budgets and decisions quickly.

• Underreported purchases depress signal quality in Meta and TikTok, so delivery shifts to broader, less efficient audiences

• Double counting inflates ROAS, masking weak creative or poor targeting and pushing spend into the wrong campaigns

• GA4 gaps make cohort and LTV analysis less trustworthy, so merchandising and retention bets get fuzzier

• Finance and performance teams lose confidence in the uplift from checkout changes, slowing further optimisation

When you migrate tracking cleanly, ad platforms relearn faster, modeled conversions line up with reality, and the team can trust the numbers enough to keep making changes.

What to check first

Before writing a line of new pixel code, build a small inventory of what is truly in use.

• Export checkout.liquid, Additional Scripts and GTM tags that target the thank you page

• List every platform that expects a purchase event and the payload it expects

• Note whether the platform is also connected via a Shopify channel app that sends server events

• Identify any custom event names, properties or catalog ID formats in your old dataLayer

• Capture your consent setup and whether it currently triggers Google Consent Mode v2 signals

With that in hand, plan the move in four passes.

• Pick a source of truth per platform: channel app only, custom Web Pixel only, or both with dedupe

• Map Shopify’s checkout_completed payload to each platform’s schema, including ID formats and currency rules

• Implement consent alignment so pixels respect Shopify’s gating and still produce acceptable modeled conversions

• Prove the path in a development theme or test checkout profile using Shopify’s Pixel testing tools and platform debuggers

A few specific gotchas are worth flagging early.

• Event IDs for dedupe must be identical between browser and server for the same purchase

• GA4 ecommerce requires the correct event names (purchase) and item array structure, not just a value and currency

• Subscription line items may need special handling to report initial purchase versus recurring events

• Bundling apps can flatten or split items differently than your catalog, affecting match rates in Meta and Google

Once these are handled, run a side‑by‑side for a week. Compare Shopify orders to platform purchase counts by day, not hour, to absorb modeling delays. Look for stable ratios rather than exact matches.

Final thought

A checkout migration isn’t just a UI change. It’s a data migration with stricter interfaces. The fastest path is rarely to recreate the old dataLayer. It’s to adopt Shopify’s event topics, choose a single authority for each ad platform, and shape the payloads carefully. That takes a little more planning, but it avoids the long tail of misattribution and bad optimisation.

If you are about to switch off checkout.liquid or you’ve already moved and the numbers don’t line up, start with the inventory and ownership decisions above. The rest becomes implementation work rather than guesswork.