Back to blog

Development CRO

Your Thank-You Page Tracking Dies on 26 August: The Web Pixels Migration

July 21, 2026 · 10 min read

On 26 August 2026, Shopify auto-upgrades the Thank-you and Order status pages on every remaining non-Plus store to the new versions. Plus merchants were moved earlier, which means this lands on the majority of stores on the platform, and most of the merchants it lands on have never once opened the settings page it affects.

When it happens, anything sitting in the Additional Scripts field on those pages stops running. Conversion pixels, tracking snippets, affiliate postbacks, survey snippets, custom messaging, any app that was never rebuilt for the new checkout. It fails without an error message. Nothing throws. The data just stops arriving, and the first person to notice is usually whoever runs the Wednesday ad spend review three weeks later, wondering why last month's numbers don't add up.

This is not a checkout redesign. It is an analytics outage with a scheduled start date, and we're publishing this five weeks out because five weeks is roughly what the inventory and rebuild takes when nobody has looked at that field since it was set up, sometimes literally in 2021.

---

There is no opt-out and no extension request. The upgrade runs on the account, not on a per-merchant schedule you can push back.

---

What actually breaks, and why nobody tells you

The Additional Scripts field lives on the Thank-you and Order status pages settings, and for years it was the only way to get custom code to run after a purchase. Merchants pasted a Meta Pixel snippet, a Google Ads conversion tag, an affiliate network's postback call, a survey widget, sometimes a hand-written script that fired a Slack webhook when a VIP customer bought. It worked because that page was, technically, just HTML you could inject arbitrary JavaScript into.

The new Thank-you and Order status pages don't work that way. They are built on the same extensible checkout architecture as the rest of checkout, which means no arbitrary script injection point. On 26 August that field goes from "running your tracking" to "sitting there, ignored, forever." Nothing in the merchant's inbox says this happened. There's no admin banner, no deprecation email with your store name on it, no red exclamation mark next to the setting. The field simply stops being read.

Compare that to a typical outage. A pixel misfiring, an app crashing, a webhook timing out — those tend to announce themselves, in Sentry, in a dashboard going to zero, in a support ticket. This doesn't. Conversion numbers don't crash to zero, because most brands run more than one tracking source and the others keep reporting. What actually happens is quieter and worse: attribution gets noisier, ROAS on paid channels looks subtly wrong, an affiliate partner's dashboard stops matching yours, and everyone assumes the ad platform's own tracking has drifted again, because that happens too and it's a familiar shape of problem. The Additional Scripts field is never the first suspect, because most of the people debugging attribution have never opened it.

"It fails without an error message. Nothing throws. The data just stops arriving, and the graph keeps looking plausible enough that nobody checks."

The stores most exposed are exactly the ones you'd expect: mature brands with a long tail of legacy tracking, where the person who set up the affiliate postback in 2021 left the company in 2023, and the current marketing team inherited a checkout settings page nobody's had reason to reopen since.

---

Additional Scripts vs Web Pixels, side by side

The replacement path is Shopify's checkout blocks and the Web Pixels API — app pixels and custom pixels, configured under Customer events. It is a genuinely different model, not a like-for-like swap, and understanding the shape of the difference is most of the migration work.

The sandbox is the trade-off worth understanding early: you get isolation and a real settings page, and you give up the free-for-all DOM access Additional Scripts always had.

That sandbox point deserves its own section, because it's the part that catches teams out mid-rebuild rather than before it. We'll come back to it after the inventory, since the inventory determines whether the sandbox limits even apply to what you're rebuilding.

---

The inventory: find everything in that field first

Do not start by rebuilding pixels. Start by reading, in full, whatever is currently pasted into Settings → Checkout → Additional Scripts (it may be split across the order status page and the separate "Thank you page" field, depending on how old the store is — check both). Copy the entire contents into a document before you do anything else. That field can disappear from view the moment the pages are upgraded, and it is the only written record most stores have of what's supposed to be running there.

In the audits we've run this year across older Shopify stores, the field is rarely one clean snippet. It's usually four to eight blocks of script mashed together, added at different times by different people, some commented out and left in, some duplicated because two agencies both installed the same pixel a year apart without checking. Untangling that is the actual work. Once it's untangled, sort each block into one of four bins, then work through who owns each one.

---

Classify every snippet before you touch code

Every block you find will fall into one of these four categories. Get the classification right and the rebuild is mostly mechanical; get it wrong and you'll spend week three rebuilding something that should have been deleted in week one.

In the checks we've run on older stores this year, roughly a third of what's sitting in that field falls into the last bin. It's the cheapest win in the whole migration: find it, delete it, move on.

---

The sandbox is the catch: what custom pixels can't do

Custom pixels run inside a sandboxed iframe, and that single fact is the reason this migration is a rebuild rather than a copy-paste. A script in Additional Scripts had the run of the page: it could read and write cookies directly, reach into the DOM to grab an element's text, redirect the browser, inject a visible banner, poll for something to finish loading. Custom pixels can't do any of that. They receive structured event data about what happened at checkout — a purchase completing, a checkout step being viewed — and they can send that data onward. They cannot reach out and touch the page around them the way a page script could.

In plain terms: if your old snippet worked by reading a value straight off the confirmation page's HTML, or by setting a first-party cookie the way a normal script would, that approach is gone. The pixel has to work from the event data it's handed, not from crawling the page itself. Most standard tracking calls — "a purchase happened, here's the order value and the items" — map across cleanly, because that's exactly the kind of structured data the Web Pixels API hands you. It's the unusual, page-reaching hacks that need a genuine rethink rather than a straight port.

The other change worth flagging to whoever owns cookie consent on your store: because custom pixels don't get free-form cookie access the way inline scripts did, any snippet that was quietly setting its own tracking cookie needs to go through Shopify's supported mechanisms instead, which tend to be more consent-aware by default. That's very likely a net improvement for your privacy posture, but it means the old snippet's exact behavior is not guaranteed to reproduce, and you should treat "does this still fire under the same consent conditions" as a test case, not an assumption.

If you went through checkout extensibility already for the buying experience itself, this will feel familiar: it's the same trade Shopify made with UI extensions, isolation and stability in exchange for giving up unrestricted DOM access. We covered that shift in more depth in our guide to checkout UI extensions, and the underlying philosophy carries straight over to pixels.

---

Rebuilding affiliate postbacks specifically

Affiliate and partner postbacks are the snippet type most likely to get missed, because they're rarely thought of as "tracking" by whoever inherits the checkout settings — they're thought of as a finance or partnerships integration, which means marketing doesn't know it's there and the partnerships team doesn't know it lives in a script tag. It's usually a small block of code firing a request to a network's endpoint with the order value and a click ID pulled from a cookie or URL parameter.

The rebuild as a custom pixel follows the same shape, adapted to the sandbox: the pixel subscribes to the purchase event, reads the order total and identifiers from the event payload rather than scraping the page, and sends the postback onward. Where the old snippet read a click ID out of a cookie it had set itself earlier in the funnel, you need to check how that identifier is actually getting to the thank-you page now — via a cart or checkout attribute captured earlier in the flow is the more durable route, since it travels with the order rather than depending on a cookie surviving to the confirmation page.

Two things worth doing before you write a line of the replacement. First, get the exact postback format from the affiliate network in writing — parameter names, required fields, whether they expect the call fired once per order or tolerate duplicates — because most of these integrations were set up years ago from a forwarded email nobody kept. Second, tell the affiliate manager or partnerships contact this is happening, with the date, before you cut over. Their dashboard going quiet without warning is the fastest way to get an anxious phone call about "did you stop paying us commission," when the honest answer is "no, but the plumbing changed."

If the network already has a documented Shopify Web Pixels integration or app, use it rather than hand-rolling the postback — that's an app pixel by the earlier classification, and it's their job to keep it working against future Shopify changes, not yours.

---

The five-week schedule

Five weeks is enough if you start the inventory this week rather than the week the upgrade actually lands. Here's how we'd sequence it, treating 26 August as the hard stop it is.

Five weeks, five stages, each one blocking the next. The inventory in week one is the step every rushed migration we've seen skip, and it's the one that decides how much week three actually costs.

---

Verify before, and verify again after

The failure mode here is silent, so verification isn't optional polish, it's the entire point. Nobody is going to alert you that this went wrong. You have to go and check.

Before 26 August

After 26 August

---

Treat this as an outage you can schedule around

Most outages arrive without warning and get fixed under pressure. This one comes with a published date, five weeks out from today, which makes it one of the rare cases where you get to choose whether the fix happens calmly in week two or frantically in week five. The inventory step is unglamorous and takes an afternoon, and it is also the entire difference between those two outcomes.

If your Additional Scripts field has been untouched since it was set up, that isn't a sign it's safe. It's a sign nobody has been asked to look at it in years, which is precisely the condition under which a silent failure goes unnoticed the longest. We've written before about what else changed in the checkout stack this cycle in our rundown of the Summer 2026 Editions, and for the pricing-logic side of this same generation of changes, our Scripts-to-Functions migration guide covers the equivalent deadline that already passed for discount and shipping logic.

If you want a second pair of eyes on your Additional Scripts field, or on the wider state of your analytics and tracking setup, that's a fast thing for us to check against a live store — get in touch and we'll tell you honestly whether five weeks is enough for what you're carrying.

Twenty-six weeks felt like a long way off in February. Five weeks does not feel like a long way off now.