On 26 August Shopify stops the script that reports your orders to Google and Meta.

What exactly ends on 26 August

The Shopify documentation on checkout.liquid is more precise here than most of the coverage about it. 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, for all stores. Script tags on those pages were also sunset for Plus stores on 28 August 2025. Non-Plus stores follow on 26 August 2026.

A script tag is a piece of JavaScript that an app or an agency hooked into your thank-you page. Usually it reports the order to Google Analytics, Google Ads or Meta.

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

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 still far-reaching, because in exactly that case a great many stores have their order report hanging.

What actually breaks

The order is the one event in the measurement chain that genuinely counts. In many Shopify setups it is the only one reported by a script tag on the thank-you page.

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

Google Ads sees no orders any more. That breaks not just the reporting but the bidding. Automated bids optimise against a signal that no longer arrives.

Google Analytics shows visits without a purchase. The purchase rate drops to a value that looks like a problem in the store, although the store is selling exactly as before.

Meta receives no orders. If you only use the pixel in the browser and no report from your own server, there is no signal left at all. Audiences keep running on old data.

Partner and voucher programmes stop reporting. Anyone paying partners based on reported orders has a commercial problem from that day, not a technical one.

The unpleasant part is the delay. Campaign figures fluctuate anyway. A decline gets attributed first to the market, the competition or the season. Weeks can pass before somebody thinks to check the measurement chain. In those weeks, bids were set on incomplete numbers.

The failure behind it

This case is a textbook example of a specific kind of measurement failure: the order 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 sent, whether the target platform accepts it, whether it can be assigned to a campaign and whether a missing record may and can be rebuilt later from a reliable source.

26 August hits the first layer. That is the one layer where no later estimate helps. A platform can estimate a gap in the total. It cannot manufacture a record that never existed.

The transaction can still be rebuilt, from a source the change does not touch at all. The order exists in the shop. It has a number, an amount, a time. Anyone using 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. They differ less in effort than in what they survive over time.

Path one: Shopify pixels under customer events. This is Shopify’s intended replacement and sufficient for many stores. The report still runs in the browser, in a sealed-off area, with the familiar limits from ad 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 then the same question reopens.

Path two: report the order from the order source. Shopify can send a message to an address of your choice for every new order. That is called a webhook. From there your own server reports the order to Google and Meta, with the order number as the identifier. The advantage: this report 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 the steps in the purchase journey, the order source for the order itself. How that works with Meta is covered in our Conversions API guide. The architecture behind it is on the page about tracking through your own server.

The two weeks that remain

The date cannot be moved. The migration is manageable, though, 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 Google Analytics and Meta. Also partner programmes, review services, subscription tools, secondary analytics tools. 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 orders against orders from the shop, for the same days. A residual difference is normal. A halving is a finding.

Nearly everyone skips step three. It is 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, there is our tracking coverage calculator and a 42-point checklist. Both are usable without engaging anyone. If you would rather hand the check over, that is what the tracking check is for.

What this date actually shows

This is not about Shopify having made a bad decision. The old approach of hooking arbitrary JavaScript into a checkout page was never a good design for security or load time. 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 report is actually created.

That is the recurring part. 26 August 2026 will pass. After it comes the next boundary change from a platform whose decisions you do not make. An order report 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.