A conversion pixel installed there today does not fire. It returns zero.

That is the deadline for non-Plus merchants to replace the Thank you and Order status pages. Plus merchants passed theirs on 28 August 2025: additional scripts and checkout.liquid frozen, PII cut off from legacy pages.

I keep seeing that pixel scoped, quoted and invoiced — plus a retainer to maintain the tag manager, the feed exports, and the flat-file integrations carrying the same data to four other systems. You are paying to keep a measurement layer alive that has already stopped reporting.

Most SEO and agency reporting runs on page metrics — position, visibility score, estimated traffic, keyword movement, backlinks, Core Web Vitals. Those are upstream proxies. Not one of them reads whether a conversion fired, so none of them change on 26 August. The monthly deck keeps improving while the thing it is a proxy for reports zero.

That is why this fails quietly. The measurement that broke and the measurement being reported on are two different systems, and only one of them is on the invoice.

Campaigns don’t stop. Budget paces exactly as before. Bidding models don’t reset — they decay. Smart Bidding needs conversion volume to optimise, and below that threshold delivery degrades toward unoptimised. Spend continues at full rate with the targeting intelligence switched off, and the drop surfaces weeks after the cause. Then someone reads collapsed ROAS as a channel failure and cuts the budget — a measurement problem, paid for by defunding a channel that was working.

And it was understating you before the deadline. A conversion that fires at order reports gross; returns never come back to correct it. At a thousand orders that is absorbed. At a million, twelve months of bidding against a gross label buys more of the cohorts that return — so the return rate drifts up and the model grows confident about customers who send the product back.

Most of these stacks run one global instance with a US-shaped banner: notice, then tags fire, opt out afterwards. That is correct for the US. In the EU and UK nothing non-essential may be stored or read before consent — and a single instance means one residency, one lawful basis and one retention policy applied to everyone.

Serve EU visitors from that instance, or pass their data to partners on it, and there is no record of which regime applied, which purposes were consented, or when. Third-party pixels firing on your own domain without consent is currently one of the most active class-action theories in privacy — statutory damages per violation, every visitor a class member.

The exposure is not a future deadline. It is on every page load, in every market, today. And because jurisdiction was never recorded at capture, validity cannot be reconstructed afterwards — no forward fix cures the back catalogue.

Horizon, Catalog, GraphQL, and Web Pixels or a server-side event bus. It runs alongside business as usual — no replatform, nothing your ERP or warehouse reads has to change.

If you operate globally, this is where the number stops being small. At a thousand orders a mislabelled conversion and a US-shaped banner are rounding errors. At a million, across seven markets, they are the budget. The fix does not get harder at that scale — same theme, same Catalog, same GraphQL calls. The implementation is fixed cost; the benefit is per order, in every market. The multiple is not in the work. It is in the volume you apply it to.

Catalog is the piece multi-market orgs underrate: one product record, published per market with its own price, currency, availability and language — in place of the per-market feed exports and flat files carrying the same product to four other systems. That maintenance line is the fee you are already paying.

A thank-you pixel can only ever report one number: gross order value, at order, client-side, with no identity past the session. That is the ceiling of the thing you are paying to maintain.

Once events are server-side, consent-stamped and joined per market, the label you send back becomes a choice. Order value is the easy one. Predicted lifetime value is the one that changes the arithmetic — a model over recency, frequency, average order value and channel breadth, trained on your own history and returned as the conversion value the bidder optimises against. Google’s own guidance is that Smart Bidding does better with a value that reflects what a customer is worth than with a flat one, and returns stop being invisible because the label can be net.

The pieces are ordinary and documented: BigQuery ML to train it (a boosted-tree regressor is enough), the GA4 Measurement Protocol to send it, and Consent Mode v2 deciding whether it may be sent at all.

And the reporting layer moves off the IT queue. The GA4 → BigQuery export is free, and once the events land there the analysis is SQL — a business analyst writes the query, defines the metric, and edits the event definitions in the GA4 admin rather than filing a ticket for a release. You pay for what you query beyond the free tier, not for the pipe, and not for a developer sprint per report. That is a different operating model from a tag manager an agency holds the keys to.

None of this replaces what you have. You will need to supplement your REST data and apps with AI-shaped, real-time functions on Shopify-enabled server-side data. The flat file keeps flowing to every system that reads it. What gets added beside it is an event that fires when the thing happens, in a shape a model can consume — and that is additive, not a migration.

What changes is the shape of time. The flat CSV is now on a timeline, and the timeline is JSON. A CSV row is a state; an event is a state change with a timestamp on it. The same order becomes two points — the purchase when it is paid, the refund when it comes back, both carrying the same transaction id so they net against each other. In the flat-file version that order was one row that got overwritten, and the fact that it returned left no trace anywhere.

The mechanism is one rule: the idempotency key is the change, not the object. order:<id>:<status>, never order:<id>. A redelivered webhook carries a key that has already been seen and does nothing; a genuine state change mints a new key and becomes the next point on the line. Safe redelivery and a real timeline are the same property, and they fall out of the same choice.

A CSV cannot be keyed this way — not for want of discipline, but because a row identifies an object and never a transition. There is nowhere to put a change id, since the change is the row being overwritten. Import the same file twice and nothing inside it can tell you whether that was a duplicate delivery or a genuine restatement. The consumer has to diff whole files against retained copies to guess, and even then cannot distinguish a value that changed back from one that never moved.

That is not a nicer format. It is the only shape that can answer what was true when — which is the same question a restated conversion asks, and the same one a regulator asks about consent. Neither has an answer in a file that only holds the current value.

Shopify Catalog plus the GraphQL Admin API and Markets is the right data shape for agentic and cross-surface commerce: one product record, published per market with its own price, currency, availability and language, carrying stable identifiers (GTIN, MPN) all the way through to the event. That identifier is what lets a scan, a session, an order and a return be the same object in BigQuery — which is the precondition for a per-market predicted-value label, and for a return that resolves without a human reconciling three systems.

The organisations that cannot adopt it are the ones it was designed for: global, multi-market, and assembled from CSV feeds, per-market flat files and single-tenant plugins. The blocker is never the protocol. It is that the product record does not exist in one place, so there is nothing for the protocol to bind to. Catalog and GraphQL are how you get there, and both are in the platform already.

Identifiers are only half of it. The same record carries the content — description, media, localized ALT text, structured data — as metaobjects bound to the product rather than as copy pasted into a theme. Enrich it once and every surface that reads the record inherits it: the PDP, the JSON-LD a crawler and an answer engine read, the feed, the agent. That is the difference between a catalogue that identifies a product and one that can actually describe it to a machine.

And because the content lives in the record rather than in the template, design and copy publish in real time — edited in the design plane, live on the storefront, with no theme release and no developer in the path. The same non-developer who owns the metric in BigQuery owns the words on the page. This page is one of them.

Related: the product-record layer · the entitlement layer · REST is not GraphQL, and the user-data audit

These are two planes that are routinely assumed to be one. hreflang is an annotation in a page’s header telling a search engine that a German version of that page exists. The product feed is a separate thing entirely, and it carries its own language and country as typed fields on the product record. Marking up hreflang does not populate them, because nothing that reads the feed ever loads the page.

So a store can have perfect hreflang and still be invisible in a market, because eligibility was never a question the page could answer. It works the other way too: the feed can be right while the page markup is missing entirely. Fixing one does nothing for the other.

The second change is the transport. XML is gone from the API in favour of JSON, and on 18 August the Content API itself is replaced by the Merchant API — also JSON. Feed files are not being banned; what is disappearing is every programmatic path that is not JSON.

Which is why the ISO codes have to live in the feed rather than in the theme. Language, country and product identity are fields on a record that an API delivers — readable by Merchant Center, by a marketplace, by a scanner at a till, and by an assistant buying on someone’s behalf. None of those loads your page. A code in the markup reaches exactly one consumer: a crawler.

Open the product resource and read it as what it is: a list of the things somebody was compelled to declare. Almost none of it is there because a merchant wanted it.

Each of those is a settlement, a penalty or a directive that arrived after somebody got it wrong. The schema is the accumulated case law of selling things, written down as fields. Nobody designed it. It accreted.

And this is precisely where a flat file stops being a stylistic preference and becomes unable to do the job. These fields are nested and typed because the obligations are conditional. salePriceEffectiveDate is a time range. shipping is an array keyed by country. certifications points at an external registry. taxes is nested per jurisdiction. A spreadsheet cell cannot hold this price, in this country, between these dates, under this certification — and flattening it discards exactly the qualifier the regulation was written to require.

Which reframes the migration. It is not a transport upgrade. The obligations were always conditional; the flat file was always lossy; the API is simply the first interface that admits it. And the reference page linked above is the v2.1 one — the version being switched off on 18 August. Even the fossil record is moving.

Server-side conversions need a consent signal per purpose, per event, at the moment it fired. One marketing opt-in boolean cannot populate that. That is the real work; the rest is configuration.

This page is a working example of the shape it describes — the banner you were shown is Consent Mode v2 with four purposes, and nothing non-essential read anything before you answered it.

Two of these are already decided elsewhere. Amazon stopped accepting XML and flat-file listings feeds in July 2025 — they return a fatal status, and the replacement is JSON. Google’s Merchant API replaces the Content API for Shopping on 18 August, after which those calls return HTTP 410. Both of the largest demand channels have now stopped accepting flat file. That is not a direction of travel to plan around; it is two dates, one of which has already passed.

For anyone running feeds on a client’s behalf, 18 August is the one to raise this week. A store still publishing product data through the Content API loses its Merchant sync on the 18th and its conversion measurement on the 26th — two failures in nine days, from the same cause, mid-quarter.

None of this needs a decision today. It needs the conversation to happen before the date rather than after it — the difference between choosing when to spend a week on it and finding out on a Tuesday that listings stopped syncing. Have the conversation, or be surprised. Those are the two options, and only one of them is scheduled.

Check whether your thank-you page pixel fired yesterday. Check what you were invoiced last month to maintain it. Then check which jurisdiction your consent record says applied to your last German order.