On 26 August a Script Stops Running That Has Reported Your Purchases for Years. The Orders Keep Coming. The Numbers Do Not.

What exactly ends on 26 August

The Shopify documentation on checkout.liquid is more precise here than most of the coverage about it, and the precision matters, because otherwise the wrong stores panic and the right ones feel safe.

For the thank-you and order status pages: checkout.liquid and additional scripts were already sunset on 28 August 2025. Script tags were sunset on those pages for Plus stores on 28 August 2025 and are sunset for non-Plus stores on 26 August 2026.

For the information, shipping and payment checkout steps, customisation via checkout.liquid already counts as unsupported.

So 26 August 2026 concerns a clearly bounded case: script tags on the thank-you and order status pages in non-Plus stores. That sounds narrow. It is far-reaching because in exactly that case, a great many stores hang their purchase event.

What actually breaks

The purchase event is the one event in the measurement chain that genuinely counts, and in many Shopify setups it is the only one fired by a script tag on the thank-you page.

When it stops, the consequences land in several places at once and do not initially look connected.

Google Ads sees no conversions. That breaks not just reporting but bid management. Smart bidding optimises against a signal that no longer arrives.

GA4 shows sessions without completion. The conversion rate drops to a value that looks like a problem in the store, although the store is selling exactly as before.

Meta receives no purchase events. In a pixel-only setup with no server-side complement, the signal is missing entirely, and audience building continues on stale data.

Affiliate and voucher logic stops reporting. Anyone settling with partners based on reported completions has a commercial problem from that day, not a technical one.

The unpleasant part is the delay. Campaign metrics fluctuate anyway, and a decline gets attributed first to the market, the competition or the season. Weeks can pass before somebody thinks to check the measurement chain, weeks in which bids were set on incomplete signals.

The failure mode behind it

This case is not a one-off but a textbook example of a specific class of measurement failure: the business event happens, but the measurement record does not.

Our report on measurement reliability separates exactly these layers. It distinguishes whether an event is created at all, whether it is technically transmitted, whether the target platform accepts it, whether it can be attributed, and whether a missing record may and can be reconstructed later from an authoritative source.

26 August hits the first layer. And that is the one layer where no later modelling helps: a platform can estimate an aggregate gap, but it cannot manufacture a record that never existed.

The transaction stays reconstructable nonetheless, from a source entirely unaffected by any of this. The order exists in the shop. It has a number, an amount, a timestamp. Anyone drawing on that source instead of relying on a script in a browser does not have this problem.

What actually replaces it

There are two paths here, and they differ less in effort than in what they survive over time.

Path one: Shopify pixels in the customer events area. This is Shopify’s intended replacement and sufficient for many stores. Events continue to run in the browser, in a sandbox, with the familiar constraints from blockers and browser rules. The advantage is quick implementation, the drawback is that the dependency on a platform decision remains. The next boundary change will come, and the same question reopens.

Path two: send the purchase event from the order source. A webhook on the order, your own endpoint, from there server-side to the target platforms, with a deterministic order number as the event ID for deduplication. The advantage is that this event does not depend on whether a page loaded, whether a script was allowed to run, or whether Shopify still supports the format next year. The drawback is the higher initial effort.

In practice the answer that holds is usually both: the pixel for events during the purchase journey, the order source for the purchase event itself. How that interacts with deduplication and event quality for Meta is covered in our Conversions API guide, and the architecture behind it on the server-side tracking page.

The two weeks that remain

The date cannot be moved, but the migration is manageable if it happens in the right order.

1. Establish whether you are affected at all. Non-Plus store, and any script tag on the thank-you or order status page. Plus stores went through this in August 2025.
2. List what hangs there. Not just GA4 and Meta. Also affiliate scripts, review services, subscription tools, secondary analytics. Everything ever fired from the thank-you page.
3. Record a reference figure before the migration. Orders and revenue per day from the shop report, for two to four weeks. Without that baseline you cannot judge afterwards whether the migration was complete.
4. Migrate and verify with a real test order. Not in preview mode, but an actual order that you cancel afterwards. Anything else tests intent, not outcome.
5. Reconcile after 26 August. Measured purchases against orders from the shop, for the same days. A residual difference is normal. A halving is a finding.

Step three is the one nearly everyone skips and the one worth the most. Spotting a discrepancy after the migration is easy. Knowing whether it is new requires a number from before.

For the reconciliation itself and a realistic expectation of the residual gap, we published a tracking coverage calculator and a 42-point checklist. Both are usable without engaging anyone.

What this date actually shows

This is not about Shopify having made a bad decision. The old approach of injecting arbitrary JavaScript into a checkout page was never a good design for security or load time, and replacing it was overdue.

It is about the fact that the most important number in your business hung on a mechanism whose continued existence you never decided. The date was announced, with long lead time and good documentation. What could not be announced is whether anyone in your organisation knows where that event is actually created.

That is the recurring part. 26 August 2026 will pass, and after it comes the next boundary change from a platform whose decisions you do not make. A purchase event drawn from your own order source survives those dates, because it does not hang on them. That is not an argument against Shopify. It is an argument for creating the one number all your decisions rest on where it already exists anyway.