By the Digital Empire Regulatory Research Team (PixelProof Analysis Team) · Reviewed by Andy Gaber, Founder, Digital Empire Holdings LLC · Published August 30, 2026 · Last updated August 30, 2026
On August 26, 2026, Shopify made Checkout Extensibility mandatory for every non-Plus store and simultaneously removed the last three surfaces that ever accepted inline tracking scripts: the Additional Scripts field in checkout settings, the order-status page scripts field, and the legacy checkout.liquid template. Meta Pixel snippets, Klaviyo hooks, Google Ads tags, and every hand-rolled analytics script that lived on those surfaces stopped executing at 00:00 UTC on Aug 26. This guide is the end-to-end migration walkthrough for the replacement: the Customer Events API, the web-pixel-manifest.json extension contract, the sandboxed Web Worker execution model, consent gating through the Customer Privacy API, the Meta Pixel + Conversions API dual-fire on the new surface, common breakage patterns after migration, and how PixelProof monitors the whole stack continuously. If you want the free scan on your own store right now, start with the PixelProof free scan.
The Aug 26, 2026 checkout upgrade is the terminal step in a multi-year Shopify migration that started with Checkout Extensibility going generally available in 2023 and continued through the mandatory-for-Plus deadline in August 2024. On Aug 26, 2026, the deprecation extended to every non-Plus store on the platform, per Shopify's official checkout upgrade documentation. Three specific fields disappeared from Shopify Admin the same morning: Settings then Checkout then Additional Scripts, Settings then Checkout then Order status page scripts, and the ability to save changes to checkout.liquid in the theme code editor. Any script pasted into those fields as recently as Aug 25 stopped executing on Aug 26 at 00:00 UTC.
The removal is silent from the operator's side. Shopify does not send an email listing every script that was disabled. Meta Events Manager does not alert on Pixel volume collapsing. Google Ads does not alert on conversion volume collapsing. Klaviyo does not alert on Started Checkout volume falling. The first symptom a founder typically sees is Advantage+ Shopping cost-per-purchase drifting upward two or three days later, or an internal weekly report showing lower attributed revenue than the prior week. By the time the drift is loud enough to trigger investigation, the store has typically lost a week of clean signal.
Shopify replaced the three deprecated fields with three distinct surfaces, one for each install pattern. The first is the Web Pixel Extension shipped by a Shopify app, declared in the app's manifest as a pixel extension with a web-pixel-manifest.json and an ES module entry point. This is how the Facebook and Instagram sales channel, the Google and YouTube sales channel, the official Klaviyo app, the TikTok sales channel, and Microsoft's UET Tag Helper install their pixels going forward. The extension runs inside a sandbox, has a declared permissions block, and can be enabled or disabled per shop from Shopify Admin. Full spec at Shopify's web pixel extension documentation.
The second surface is the Customer Events custom pixel, created inside Shopify Admin at Settings then Customer events then Add custom pixel. A custom pixel is a merchant-owned script (not an app extension) with the same sandbox contract as an app-installed web pixel. It is intended for merchants who need a small custom tag — a first-party warehouse tap, a private analytics vendor without a Shopify app, an internal debugging fire — without shipping and installing a full Shopify app. Custom pixels also declare permissions and consent behavior through the same UI. Reference at Shopify's Pixels admin documentation.
The third surface is the Customer Events API in theme, which is the same event stream a pixel subscribes to, but consumed directly from theme JavaScript on the storefront (not the checkout, which is out of theme scope). This is how a theme developer can wire product-page interactions, a custom cart drawer, a search-results feed, or any other on-store analytics need to the same standardized event names a pixel would receive. The theme-side API is the drop-in replacement for the old pattern of DOM-scraping product IDs from a Liquid template; instead the theme reads the canonical Shopify event payload. Reference at Shopify's Web Pixels API documentation.
The Customer Events surface emits a fixed set of standardized events with typed payloads. Every pixel subscribes to the same event stream regardless of vendor, which means Meta, Klaviyo, Google Ads, and a custom pixel are all reading from an identical source of truth about what the shopper did. The full standardized event list, as of the Aug 26, 2026 upgrade:
page_viewed — fired on every storefront and checkout page load. Payload includes context.document.location, context.document.referrer, and context.navigator.product_viewed — fired on a product detail page. Payload includes productVariant (id, title, price, sku, product.id, product.title, product.type, product.vendor).collection_viewed — fired on a collection page. Payload includes collection.id, collection.title, and the paginated productVariants.search_submitted — fired when a shopper submits a search. Payload includes searchResult.query and the resulting productVariants.cart_viewed — fired on a cart page load. Payload includes the full cart with line items, totals, and currency.product_added_to_cart — fired on add-to-cart. Payload includes the cartLine (merchandise, quantity, cost).product_removed_from_cart — fired on remove-from-cart. Same payload shape as add.checkout_started — fired on the first step of checkout. Payload includes the full checkout object with line items, cost, currency, and a stable checkout.token.checkout_contact_info_submitted — fired after the shopper submits contact information (email or phone).checkout_address_info_submitted — fired after the shopper submits a shipping address.checkout_shipping_info_submitted — fired after the shopper selects a shipping method.payment_info_submitted — fired after the shopper submits payment information, before authorization.checkout_completed — fired after order authorization succeeds. Payload includes the full checkout with the assigned order.id, totals, discounts, and customer identity where available. This is the event Meta Purchase, Google Ads Purchase, and Klaviyo Placed Order all key off.Every event carries a shared context block with document, navigator, window, and cart at the moment of the event, and a top-level id, name, timestamp, clientId, and seq. The id field is the deduplication key vendors are expected to pass through as their own event_id when firing to a server-side conversions API in parallel.
A Shopify app that ships a web pixel extension declares it in an extension manifest, and Shopify uses the manifest to bootstrap the pixel into the sandbox, register its permission requirements, and offer it to merchants for install. The essential manifest shape is a top-level extension type of web_pixel_extension, a version, a runtime_context of strict for the sandbox model, and a customer_privacy block declaring which consent categories the pixel needs (typically marketing_consent for a Meta or Google Ads pixel, analytics_consent for a first-party analytics tap). The manifest also declares browser_features the pixel needs access to (typically window, cookie, local_storage), and any fields the merchant configures when installing (an API key, an account ID, an environment toggle).
The extension ES module is loaded by Shopify at pixel activation with a register function that receives an analytics, browser, init, and settings object. The pixel subscribes to standardized events with analytics.subscribe('checkout_completed', event => { /* fire */ }), reads consent state through analytics.subscribe('consent_updated', ...), uses browser.cookie and browser.localStorage for state, and can call fetch against the vendor endpoint for server-side transmission. The pixel never has access to the storefront window or DOM directly; it can only observe what the standardized event stream carries.
For 90 percent of merchants, the Meta migration is invisible. The Facebook and Instagram sales channel updates itself in the background, its bundled web pixel extension activates automatically, and the Aug 26 morning shows continuous Pixel + CAPI volume in Meta Events Manager. Confirm this by (1) opening Shopify Admin, Settings, Customer events, and verifying "Facebook & Instagram" appears in the pixels list as Connected, (2) opening Meta Events Manager, selecting the pixel, and confirming event volume did not drop across Aug 25 and Aug 26, and (3) using Meta's Events Manager Test Events tab to fire a live test purchase from a private-window browser session.
The 10 percent of merchants with a non-invisible migration fall into three groups. Group A is stores that installed Meta Pixel by pasting the base code into Additional Scripts or checkout.liquid, never used the Facebook sales channel, and now have zero Meta tracking. Fix: install the Facebook and Instagram sales channel, connect to the same Meta Business Manager and pixel ID, enable Conversions API with data-sharing set to Maximum, verify the domain-verification meta tag lands on the theme, and confirm test events fire. Group B is stores that ran a hand-rolled CAPI middleware (a serverless function or a third-party server-side tracking vendor) alongside a Meta Pixel snippet, generating their own event_id for deduplication. Fix: rewrite the middleware to read event.id from the Customer Events payload as delivered to a custom pixel, and pass that value as event_id on both the browser Pixel fire and the CAPI request. Group C is stores with a bespoke agency install that used both Additional Scripts and a custom app for CAPI, often years old. Fix: audit the whole stack, deprecate the agency scripts, migrate to the official channel plus a single documented custom pixel where the agency logic is genuinely needed.
Meta's Conversions API documentation and deduplication spec are the source of truth for the event_id, event_name, and fbp/fbc matching that Meta uses at ingest. The new Shopify surface changes the delivery mechanism, not the deduplication contract.
Inside a web pixel extension or a custom pixel, consent state is read through the pixel-sandbox mirror of the storefront's window.Shopify.customerPrivacy object, per Shopify's Customer Privacy API documentation. The object exposes flags for marketing, analytics, preferences, and sale_of_data, and a helper currentVisitorConsent() that returns the composite state. A well-behaved marketing pixel gates the fire on marketing, subscribes to consent_updated to catch retroactive opt-ins, and does not fall back to firing when the flag is not set. A well-behaved analytics-only pixel gates on analytics.
The failure mode we observe most often after migration is a pixel that reads consent from window.Shopify.customerPrivacy at pixel-registration time (which is before the shopper has seen the CMP banner) and never re-reads it after the shopper accepts. The pixel effectively treats the initial no-consent default as permanent, silently underreporting the fraction of shoppers who did in fact opt in. The correct pattern is to read consent inside the analytics.subscribe callback for each event, or to maintain internal state that a consent_updated subscription keeps current.
1. event_id drift between browser Pixel and CAPI. Symptom: Meta Events Manager shows the browser Pixel event count and CAPI event count both healthy, but the deduplication rate (visible in Events Manager, Overview) has dropped from near-100 percent to near-zero. Cause: a custom pixel or a middleware is generating its own UUID for event_id instead of reading event.id from the Customer Events payload. Fix: change the code to read event.id and pass it as event_id on both legs of the dual-fire.
2. Missing checkout_completed on 3DS flows. Symptom: a subset of orders in Shopify Admin never fired Purchase in Meta. Cause: on 3D Secure authorization flows (common in EU and India traffic), the shopper is redirected to the card issuer's page and back, and older pixel implementations lost the pixel context across the redirect. In the new sandbox, the Customer Events runtime correctly fires checkout_completed after the return, but a custom pixel that stored state in sessionStorage outside the browser.localStorage API can lose that state. Fix: use only the sandbox-provided browser.localStorage for pixel state, not raw sessionStorage.
3. Order-status page double-fires. Symptom: after migration, some vendors report double Purchase events on a fraction of orders. Cause: a merchant left both the legacy Order status page script (now inert) AND installed a custom pixel firing checkout_completed, and a caching layer or an old preview link served the legacy page for a few days. The legacy inline script is inert as of Aug 26, but if there is a second custom pixel doing the same fire, the sandbox pixel fires normally. Fix: delete all inert legacy references so future audits are not confused, verify only one Meta-firing pixel is active in Settings then Customer events.
4. Klaviyo Started Checkout drop after migration. Symptom: Klaviyo Started Checkout volume drops 20 to 40 percent starting Aug 26, and abandoned-checkout flow entry drops with it. Cause: Klaviyo's new web pixel extension gates Started Checkout on marketing consent (correctly), and the store's CMP defaults to no-consent for new visitors. Prior to migration, the legacy checkout.liquid hook ignored consent. Fix: this is not a bug — the pre-migration Klaviyo integration was firing without consent and is now correctly gated. Confirm CMP configuration and expected opt-in rate for your traffic mix.
5. AEM domain verification stale. Symptom: iOS-opted-out attribution silently drops after migration. Cause: the domain listed in Meta Business Manager, Brand Safety, Domains is a legacy myshopify.com subdomain or an old vanity domain that no longer serves the live storefront. Meta's AEM verification does not follow redirects. Fix: verify the current live storefront domain and re-prioritize the 8 events under it.
PixelProof scans a storefront and its checkout flow continuously against the Customer Events API and Meta's Pixel + CAPI ingest, and alerts when any of the following conditions trip. First, the presence check: at least one pixel subscribing to checkout_completed is active in Settings then Customer events, and the pixel is enabled for the store. Second, the fire check: a synthetic checkout run against a private-window session emits page_viewed, product_viewed, product_added_to_cart, checkout_started, and checkout_completed in sequence, and each is observed reaching Meta's Test Events endpoint. Third, the deduplication check: for the observed checkout_completed, the browser Pixel and CAPI events share an event_id and Meta collapses them at ingest. Fourth, the consent check: the CMP is present, gates fires correctly on marketing consent, and the pixel is subscribing to consent_updated. Fifth, the AEM check: the domain verified in Meta Business Manager matches the live storefront domain and is not a redirected legacy.
The full scan runs in the background against the storefront and reports through the merchant's existing alert channels (email, Slack, or a Klaviyo flow for merchants who connected the Klaviyo integration). The free scan tier runs a single-shot version of the checkout events audit and produces a paste-ready fix list; the paid tiers run it continuously and include synthetic-checkout monitoring against the new surface.
For the 60-day window before Aug 26, Shopify allowed merchants to opt back into the legacy checkout for testing purposes. That window is closed as of Aug 26 — there is no rollback to checkout.liquid or Additional Scripts. What is still supported is running two pixels in parallel for validation: keep the old vendor integration active (if it still runs on the new surface via the vendor app) and add a custom pixel firing to a staging endpoint for A/B validation, then remove the custom pixel once you are confident the vendor app is correctly configured. Two pixels firing the same Meta Purchase with the same event_id will deduplicate at Meta ingest; two pixels firing with different event_id values will double-count. During any dual-run, verify event_id alignment or accept the double-count for the validation window.
The Aug 26, 2026 hard cutover is the beginning of the migration audit, not the end. Meta, Google, and Microsoft rolled ad optimization models that adapt to the new event delivery over the four weeks following the cutover; unusual campaign performance in September 2026 is common and expected while the models re-baseline. Aggregated Event Measurement domain re-verification for merchants who migrated storefront domains during 2026 is a separate task with its own 72-hour propagation delay. And any vendor that never shipped a web pixel extension for their tracking is effectively dead on the new surface until they do; the merchant should plan for a possible vendor swap on any low-priority analytics tool that shows no post-Aug-26 activity.
For the Klaviyo + Meta Pixel dual-fire integration walkthrough on Shopify 2026, see Klaviyo + Meta Pixel Integration Guide 2026. For the iOS 14.5+ App Tracking Transparency deep dive with the aggregate impact numbers Meta itself published, see iOS 14.5 ATT Impact on Shopify Tracking (2026). For the CAPI setup deep dive including the server-side deduplication contract, see Meta Conversions API Setup for Shopify (2026). The PixelProof product hub is at /meta-monitor.
Shopify made Checkout Extensibility mandatory for all non-Plus stores on Aug 26, 2026, and removed the ability to inject inline tracking scripts through the Additional Scripts field in checkout settings, the order-status page settings, and the legacy checkout.liquid template. Any Meta Pixel snippet, Klaviyo hook, Google Ads tag, TikTok Pixel, or custom analytics script that was installed through those surfaces stopped executing at 00:00 UTC on Aug 26. The replacement is the Customer Events API surface, driven by pixel apps declared through web-pixel-manifest.json (for app-installed pixels) or by admin-created custom pixels attached in Settings then Customer events (for merchant-owned scripts). Stores that installed Meta and Klaviyo through their official Shopify apps migrated invisibly. Stores running hand-rolled or agency-installed scripts on checkout.liquid did not, and lost tracking on the same morning.
No, the Facebook and Instagram sales channel handles the migration for you. The channel now ships a Shopify-approved web pixel extension that subscribes to the Customer Events API and emits both browser Pixel and Conversions API events with a consistent event_id for deduplication. You should still confirm the pixel is active by opening Settings then Customer events in Shopify Admin and verifying the Meta pixel appears as Connected, and by checking Meta Events Manager for continuous event volume across Aug 25 and Aug 26. If the Facebook channel app was ever uninstalled and reinstalled, or if the store was migrated between Meta business assets, the channel may not have applied the auto-migration and a manual reconnect is required.
No. Checkout HTML editing was disabled at the same time Additional Scripts was removed. The only supported ways to run code during a Shopify checkout in 2026 are a web pixel extension declared in a Shopify app (web-pixel-manifest.json), a custom pixel pasted into Settings then Customer events by the merchant, or a Shopify Functions extension for order composition logic that is not tracking. All three run inside a sandboxed Web Worker with no direct DOM access, no access to the checkout iframe, and only the parameters explicitly passed through the Customer Events payload. If a vendor documentation page still tells you to paste a script into Additional Scripts, that documentation predates Aug 26, 2026 and is stale.
The Web Pixels sandbox is a Web Worker with a strict Content Security Policy that isolates pixel code from the storefront page. It has no window.document, no direct DOM access, no ability to attach event listeners to page elements, and no access to browser storage outside a scoped API Shopify provides (browser.localStorage and browser.cookie). This isolation is deliberate. Meta, Klaviyo, and other vendors used to compete for DOM access on checkout.liquid and one poorly written snippet could break the whole checkout. The sandbox forbids that by construction. All data a pixel needs arrives through the analytics.subscribe callback in the standardized Customer Events payload, and any storage or navigation activity has to go through the browser API.
Deduplication continues to rely on a consistent event_id passed to both the browser Pixel fbq call and the server-side Conversions API request within Meta 48-hour deduplication window. In the new surface, the Customer Events payload includes a stable event_id on every checkout_completed and checkout_started event, and the Facebook channel uses it for both legs of the dual-fire. If you run a custom pixel that forwards events to your own CAPI endpoint, you must read event.id from the payload and pass it as event_id in the CAPI request; do not generate a new UUID inside the pixel because the browser Pixel will already have used the Shopify-supplied one. Meta will collapse the two events at ingest if the event_name, event_id, and fbp or fbc cookies match.
The order-status Additional Scripts field was removed on Aug 26, 2026 alongside checkout.liquid Additional Scripts. Google Ads conversion tracking and Microsoft Advertising UET pixels that were installed on the order-status page have to migrate to the Customer Events checkout_completed event through either the vendor official Shopify app (Google recommends the Google and YouTube sales channel; Microsoft recommends its UET Tag Helper Shopify app) or through a custom pixel that calls the vendor global (window.gtag or window.uetq) from inside the sandbox. Because the sandbox runs in a Web Worker, the vendor script itself has to be loaded through the pixel bootstrapping code rather than expected to be present on the page.
The Customer Events runtime exposes window.Shopify.customerPrivacy inside the sandbox with the same marketing, analytics, and preferences flags the Customer Privacy API surfaces on the storefront. Read it inside the analytics.subscribe callback and gate the fire on the marketing flag for a marketing pixel like Meta, Google Ads, or TikTok; gate on the analytics flag for a pure-analytics vendor like a first-party warehouse tap. Do not fire on load and hope consent is present later. The sandbox also emits a consent_updated event you can subscribe to for retroactive filling once the shopper interacts with the CMP banner, which most vendors do not implement and end up systematically underreporting the fraction of shoppers who accept consent after arriving.
No. This is a technical migration guide for the Shopify checkout upgrade and the Customer Events surface, not legal advice. Consent obligations under GDPR, CCPA, CPRA, Colorado Privacy Act, Connecticut Data Privacy Act, Utah Consumer Privacy Act, Virginia Consumer Data Protection Act, and Quebec Law 25 depend on jurisdiction, sector, and data type, and a store operating across regulated jurisdictions should confirm its consent management platform is configured correctly with counsel qualified in that jurisdiction. Digital Empire Holdings LLC is a data and monitoring vendor, not a law firm, and nothing in this article should be interpreted as regulatory guidance.
Migrated on Aug 26 but not sure everything actually fires? PixelProof runs a synthetic checkout against the new Customer Events surface and returns a paste-ready fix list.