Mtrix report · 01
Your Shopify tracking breaks on 26 August. The 12-point audit.
Twelve checks on your own store, five minutes each. Built from Shopify's Help Center, developer docs and changelog, all read 1 August 2026. Not a migration guide — there is a free one of those. This is the inspection you run after.
What actually happens on 26 August
The Additional Scripts box stops executing. That is the event, in one sentence.
Your Thank you page and your Order status page — the two pages a customer sees after paying — are replaced by new ones, and neither new page reads that box. The new Order status page isn't even part of your online store any more; it moves into Shopify's customer accounts, which is check 2. Shopify's sentence for non-Plus stores:
If you're on a non-Plus plan, then you have until August 26, 2026 to upgrade and replace your Thank you and Order status pages.
Nothing is deleted. On the 27th your code is still sitting in that box, still readable, doing nothing. It has been view-only on every plan since August 2025, so you can't even edit it to test. No error, no console warning, no email, no red banner in your admin. The box simply stops being a place where code runs.
The same date turns off app ScriptTags on the Order status page. shopify.dev:
ScriptTags on the Order Status page have been deprecated and will be turned off on August 28, 2025, for Plus merchants and on August 26, 2026, for non-Plus merchants.
Those are the tags apps injected on your behalf — review requests, loyalty enrolment, post-purchase upsells. They were never in the box you copied out, and they stop on the same morning.
What replaces all of it is a web pixel. Not a script on your page. A piece of JavaScript Shopify runs for you inside a sandboxed iframe, on its own origin, subscribed to a fixed list of fifteen events it is allowed to hear. That sandbox is not a smaller version of the old box. It is a different place with different rules.
Two ways this breaks. Only one of them is the deadline.
A — it stops running. Additional Scripts and Order-status ScriptTags stop executing on 26 August, and whatever they fed — Meta, Google, your affiliate network — receives nothing from that morning. Loud in principle. Silent in practice, because nothing errors. Three of the twelve checks below are family A.
B — it runs, but it lies. Nine of the twelve, and almost nobody is writing about them. You migrate correctly. The pixel installs, reads Connected, fires a green dot in Shopify's own tester — and it is running on a different origin from your store, inside a sandbox that cannot read your page's URL, with consent it never heard about, with the customer's email stripped out of the purchase event, and with Shopify holding a switch that pauses it for going quiet. Same green dot, wrong data.
Family A you find by looking. Family B is the silent pass — a check that reports success while the thing it checked is broken — and it survives every test you already know how to run. None of the nine waits for the deadline either: check 9 has already happened to anyone who never moved their Google tag.
If you think you only have family A, you will migrate correctly and stay broken. Every check below is labelled A or B.
Why none of it surfaces where you'd look — Shopify, on ad blockers:
In both cases, your Shopify reports and order records aren't affected, because Shopify records order and analytics data when the order is processed. What's reduced or lost is third-party attribution, such as matching a conversion back to an ad click.
Your admin is fed by the order record. Your ad platforms are fed by the pixel. Only one of those breaks in August, and it is not the one you open every morning. Shopify's upgrade report is built on the same split — it inventories your scripts and never tests your data.
Three of the twelve stop running. Nine report success and send the wrong data.
It stops running
Three checks. The deadline.
It runs, but it lies
Nine checks. Survives a correct migration.
- 02 Order status page off-domain Blind spot
- 03 Consent never reaches Shopify Blackout
- 04 Shopify pauses your pixel Blackout
- 05 Every order counted twice Distortion
- 06 Tags fire, values empty Distortion
- 07 Click IDs read empty Distortion
- 08 Purchase arrives without identifier Blind spot
- 09 Google tag already converted Distortion
- 12 Refunds never reported back Blind spot
- Blackout
- a channel receives nothing
- Distortion
- a channel receives a wrong number
- Blind spot
- a channel never sees the event at all
Block B is three times the size of block A, and every row in it passes the tests you already run.
Source Mtrix classification. The two families and the three cost words are ours, not a measurement — this report audited no population of stores and claims no frequency for any check.
Two browser tabs, one real order, about forty minutes. Start here.
Check 1 Does anything, anywhere, actually fire on purchase?
A
it stops running
Ninety seconds, and the most expensive line in the report. This is family
A's entire cost in one check: the box stops on 26 August, and the only question that matters is
whether anything took its place. A pixel with no purchase subscription looks identical to one that
has it. It loads. It connects. It fires page_viewed all day.
SettingsCustomer events. Open every custom pixel and search
the code for checkout_completed.
analytics.subscribe("checkout_completed", …) is present, and the callback
sends the order to the destination you care about — not into a dataLayer no tag
reads.
The string is absent. Or it is there, pushing to a GTM variable that no longer exists (that is check 6, and the two travel together).
What it costs. All of it. Not a degraded signal — no signal, while Meta and Google keep spending against a model that now believes nobody buys. On the store below that is roughly $870 a day running blind, and because conversion reports get read monthly rather than hourly, the realistic detection lag is two to four weeks. Four weeks is the whole $26,000.
What this is built on
No survey, no crawl, no sample. Twelve documented failure modes, taken from Shopify's own documentation and from the mechanics of the pixel sandbox — not twelve measured ones. We have not audited a population of stores and do not know what share of them fail check 6, or any other check. Where a number carries a dollar sign it is arithmetic on the six inputs above, and those are hypotheses you should replace with your own. Full method, exclusions and every source at the end.
The free guide answers what happens on 26 August and how do I upgrade. Thousands of pages answer that now. This one answers the question you actually have at 9pm on a Tuesday: what is already broken on my store, and what will break without telling me?
Check 2 Your new Order status page is on a different domain, and your pixels know it
B it runs, but it lies On by default, one glance to check, and nobody is writing about it.
Your new Order status page does not live on your store's domain. By default Shopify serves
customer account pages — sign-in, orders, profile — from a shopify.com URL in the
shape shopify.com/1234567890/account. One line, easy to miss, adds the Order
status page to that list.
Shopify's app-pixel troubleshooting spells out the consequence. If your online store uses a
custom domain, you have to point your customer account domain at a subdomain of it, such as
account.example.com. Otherwise pixels and cookie consent do not work on the new
Order status page, because consent only carries where the domain matches the one that collected
it.
Consent is obtained on yourstore.com. The page is served from
shopify.com. Different origin, no consent, no pixel — on the page your customer
returns to three or four times per order.
SettingsCustomer accounts → the URL field.
account.yourstore.com, or any subdomain of your primary domain.
shopify.com/1234567890/account — the default, so if you have never touched this
setting, you fail.
What it costs. Everything you measure or sell after the order: repeat-purchase prompts, review requests, loyalty enrolment, subscription management, referral widgets. It is the quietest of the twelve, because none of it appears in your upgrade report. A domain setting, filed under Customers, silently governing marketing.
And it is not a Friday job. Subdomain propagation and verification can take up to 48 hours. If you run social sign-in or an identity provider, add the new domain there first — Shopify's own warning is that customers cannot sign in until you finish that update.
By default, your new Order status page is on a different domain from your store — so your pixels never load on it.
You have never touched this setting
yourstore.com
Storefront · consent granted here
- Cookie consent
- Your pixels
Origin boundary
shopify.com/
Order status page · a different origin
Consent does not carry. Pixels do not load.
Customer accounts on a subdomain of your domain
yourstore.com
Storefront · consent granted here
- Cookie consent
- Your pixels
Same origin
account.yourstore.com
Order status page · same origin
Consent carries. Pixels load.
Settings → Customer accounts → URL. If it reads shopify.com, this is your store. Allow 48 hours, and update your sign-in provider first.
Source help.shopify.com — customer account subdomains, and app pixel troubleshooting.
Check 3 The consent your shopper gave that Shopify never heard about
B it runs, but it lies If you run a third-party cookie banner — and most stores selling into the EEA or UK do — there is a handshake between it and Shopify that has to exist. There is no error when it doesn't.
Shopify's rule is plain. A third-party consent tool has to sync consent to Shopify through the Customer Privacy API, and if it doesn't, your pixels may not fire even after the customer has clicked Accept.
The banner appears. The shopper accepts. The banner records consent. Shopify never receives it, every pixel stays silent for that shopper, and your consent dashboard reports a healthy accept rate throughout. Two systems both reporting success, nothing passing between them. Shopify also requires the two region lists to agree, so a banner set for the EU while Shopify's list carries the UK leaves a gap in one market only.
SettingsCustomer privacyCookie bannerMore actions → Set custom banner regions. Write the list down, then compare it to your consent app's own.
The lists match, and your app's documentation names Shopify's Customer Privacy API.
Any region in one list and not the other, or an app whose docs never mention the API — which means it almost certainly isn't calling it.
What it costs. Your entire EEA and UK measurement, with a banner on screen throughout telling you it works. If a fifth of the illustrative store's revenue is European, that is $20,000 a month arriving with no attributable source, and European campaigns you will eventually switch off for underperforming.
Check 4 Shopify can pause a pixel it decides isn't working, and the setting is on by default
B it runs, but it lies The newest item here, and the nastiest shape, because it can punish you for migrating correctly.
Shopify's changelog, 13 January 2026:
When we see zero signals coming from a pixel over days or weeks, we will pause data sharing until we see new signals, at which point data sharing turns back on.
The setting that does this is called Optimized, and it is the default on every app pixel.
The intent is sound — Shopify is cutting off dead apps that still drain your customer data, and its worked example is a tool you stopped using two years ago. The trap is timing. A pixel you install in August to replace a script has, by definition, no history of driving results. It is exactly the profile the system switches off, at exactly the moment you need it. And the recovery is circular: sharing resumes automatically when relevant activity returns — activity measured through the channel that just went quiet.
SettingsCustomer events → the pixel's name → its data access setting. Then ⋯ → View details → the activity log.
The pixel reads Always on, or the log shows no Data access paused entries.
Data access paused, or Optimized on a pixel carrying your purchase event that you installed in the last few weeks.
What it costs. The same as check 1 — a channel receiving nothing — with one extra cruelty. Your pixel is installed, connected, correctly written, and passes every test you can run on it. You will spend a week in the app developer's support queue before anyone thinks to look at a Shopify setting.
Check 5 You are almost certainly double-counting right now
B it runs, but it lies This one is running on your store today, weeks before the deadline.
Shopify says it outright, filed under a step rather than a warning: while you install, connect and test pixels to replace your additional scripts, the third-party platform counts each event twice — once from the script and once from the app pixel. If you connected the app pixel and have not clicked Disable script, you are in that window today.
Your upgrade guide → Additional scripts → Tracking and analytics. For every script whose replacement is connected, look for the Disabled label.
Every replaced script shows Disabled.
A connected app pixel sitting alongside a live script for the same platform.
What it costs, in your own arithmetic. The platform receiving both counts each order twice. On the store above, 1,100 real orders report as 2,200, and a paid ROAS of 2.31 reports as 4.62. One unclicked button buys two wrong decisions for the price of one: you scale spend against a number exactly double the truth, then on 27 August you watch it halve overnight and conclude the migration broke your tracking. It didn't. It stopped lying.
Shopify offers the choice and names both costs. Connect the new custom pixel before you remove the old one and you minimise missing events but duplicate them. Connect it after and you avoid the duplicates but lose whatever happens in the gap. There is no third option. Pick deliberately and write down the date — you will be reading a step change either way.
The migration inflates your reported ROAS before it deletes it.
- A Script only Reported = actual
- B Script + connected app pixel Today, for most stores
- C Script off From 26 August
Vertical: reported paid ROAS. Horizontal: migration phase — ordered, not to scale. Phase B lasts as long as you leave the old script running, so it has no duration to draw.
Arithmetic on one illustrative store — 1,100 orders, $60,000 of paid revenue, $26,000 of spend. Run it on yours; the shape is the same.
Source The duplication behaviour is Shopify's, from its Additional scripts page; the figures are arithmetic on this report's stated inputs. Axes are schematic.
Check 6 Your GTM container still fires. It just can't see the page any more.
B it runs, but it lies A custom pixel is not a script on your page. It is an iframe with a sandbox attribute, and code written for a page behaves differently inside one. Three documented ways, none of which errors.
It cannot reach the page it is measuring. Traditional JavaScript pixels
placed in the lax sandbox cannot access the top frame. Shopify's own example:
window.href returns the sandbox's URL instead of your page's.
The stateful dataLayer is gone. GTM's stateful dataLayer — where
one push sets a variable a later tag reads — has no equivalent in Shopify's pixel sandbox. Shopify's
advice is to build your own data object and pass it into each custom event. Every tag written
to read a variable set by an earlier push now reads undefined.
GA4's automatic events stop being automatic. Some events GA4 normally infers for you have to be set up by hand. Shopify's example is outbound link clicks under Enhanced measurement, which cannot be triggered automatically inside a custom pixel for security reasons.
Open your container and list every tag whose value comes from a variable set by a different push than the one that triggers it.
Every tag reads only from the event object handed to it in the same push.
Any tag reading a dataLayer variable it did not receive in that push, or depending
on GA4 enhanced measurement.
What it costs. The worst class in the audit, because the tag does fire. GTM logs a fire. Your platform receives an event. The value is empty — revenue reports as 0, or the event arrives with no currency and is discarded downstream with nothing sent back. A missing event you can find. An event that arrives empty looks like a business problem, and you will go looking for it in your pricing long before you look in your tag manager.
Check 7 Your click IDs and UTMs read empty inside the pixel
B it runs, but it lies Same sandbox, separate failure, and this one attacks the number your whole media budget is judged on.
Automatic page-URL detection inside the lax sandbox returns a sandbox URL rather than the main
window's. Shopify's remedy is one line: take the main window's URL out of the
page_viewed event.
Any code in your pixel that reads the URL for fbclid, gclid,
gbraid, wbraid, ttclid or utm_source is reading
the sandbox's URL. Those parameters are not in it. They do not error — they come back empty, and
every attribution model on earth reads empty as direct.
Search your pixel for window.location, document.referrer,
URLSearchParams and the string utm_. Every hit is a bug.
Every URL your pixel uses comes out of the page_viewed event payload.
Any URL read from window or document.
What it costs. On the store above, $60,000 a month of paid revenue reports as direct. Blended numbers hold steady, which is why this survives so long — total revenue is fine, so nothing alarms. Meanwhile every paid channel shows a collapsing ROAS, and the obvious, rational, badly wrong response is to cut the channel paying for the store.
Shopify names the GA4 version and its remedy: turn off GA4's automatic page tracking and
implement your own from the standard page_viewed event. Landing-page reports full
of URLs you don't recognise are this.
Check 8 Advanced matching and enhanced conversions lost their identifier
B it runs, but it lies Meta's Advanced Matching and Google's Enhanced Conversions both work by attaching a hashed email or phone to the purchase. Most implementations got that by reading it off the page. That route is closed: Shopify states that features which automatically scrape forms for email addresses or phone numbers might not work in the sandbox, and that most pixel providers support passing the data manually instead.
The manual route has its own gate. In the checkout_completed event, the email
field requires the read_customer_email access scope and the phone field requires
read_customer_phone. Both sit inside Shopify's protected customer data regime,
where name, address, phone and email are Level 2 — and a public app has to pass Shopify's
review to get them. An app not approved for those fields receives a purchase with no
identifier on it. Installed, connected, green dot, no match key.
Meta Events Manager → Events → Purchase → Event Match Quality. Google Ads → Conversions → your purchase action → Enhanced conversions diagnostics. Compare the seven days after you connected the app pixel against the seven before.
Match quality flat across the change.
A step down dated to the day you connected the pixel.
What it costs. Not a uniform percentage — a specific population. The conversions that only ever matched on email are the cross-device ones: clicked on a phone at lunchtime, bought on a laptop that evening. Pull that share out of your own data before you assume it is small; it decides whether prospecting looks profitable.
Shopify names the honest upgrade. Server pixels don't depend on browser cookies and can match events on first-party data such as an email address or phone number. Availability is not universal — Shopify's own wording is that certain app owners have access, and it publishes no list.
Check 9 Your Google tag may already have been converted, and one settings box was quietly dropped
B it runs, but it lies Every other check here is about the future. This one has already happened. If you never moved your Google tag to the Google & YouTube channel app, Shopify has already converted it into a custom pixel for you, to keep some continuity in your measurement.
Shopify then lists what got worse. Five of the six are the kind of degradation you can go and find:
- Data reported in Google Analytics might change, or in some cases be lost.
- Core GA features such as enhanced measurement and cross-domain measurement might not work correctly.
- Tag Assistant might not work, or might report on your GA4 tag incorrectly.
- Tag Diagnostics might not identify your GA4 tag correctly.
- Consent treatment of your Google Analytics tag might change.
The sixth is the one to read twice, and it is worth Shopify's exact words:
Settings you've previously added to the Additional Google Analytics Javascript section will be dropped.
Whatever you or an agency put in that box is gone, and the deletion was silent. Additional
Scripts was never the only paste target either. Shopify names four places old pixels live:
theme.liquid, checkout.liquid (Plus only), Additional scripts in your
checkout settings, and the Preferences page. Your upgrade report reads one of them.
SettingsCustomer events: is there a Google custom pixel you did not write? Then Online StorePreferences → the Google Analytics section.
The Google & YouTube channel app is installed, connected, and your GA4 property is receiving purchases from it.
A converted custom pixel you never created, or an Additional Google Analytics JavaScript box you were still relying on.
What it costs. Cross-domain measurement is the expensive one if your checkout, blog or subscription portal sits on a different hostname — one visit splits into two sessions and your conversion rate looks worse on both. And Tag Assistant not working is the silent pass again: a verification tool returning a false negative on a tag that is fine.
Check 10 The tags you never wrote, and never inventoried
A it stops running Everyone tells you to copy your Additional Scripts box into a document before you touch anything. Good advice, half an inventory. The tags an app injected are not in that box, and the ScriptTag sentence at the top of this report is the one that kills them — it names non-Plus merchants and 26 August 2026 explicitly.
Two screens, and the first is new. Since 1 April 2026, SettingsApps shows, for every installed app, whether it collects customer data through pixels, with its connection status and data access mode, alongside its Extensions and Functions. Walk the list one app at a time. Then open your upgrade guide → Incompatible apps → Apps that require update from a developer.
Every app that touches your order status page appears with an active extension or pixel.
An app under Apps that require update from a developer, or an app with nothing active and a feature you can still see on the page.
What it costs. Post-purchase upsells, review requests, loyalty enrolment, shipment-tracking widgets, subscription management, referral capture. The order status page is where a real share of DTC repeat revenue is earned, and none of it is in the box you copied out.
Shopify has told app developers what merchants do about this. In its partner guidance it says it has observed merchants uninstalling apps to unblock their upgrade, and that it expects those uninstalls to keep increasing as the deadlines approach. If you are waiting on a developer, so is everybody else, and their queue is about to get much longer than yours.
Check 11 The affiliate and referral tags that stop attributing, and nobody tells you
A it stops running An affiliate network gave you a conversion tag. Somebody pasted it into Additional Scripts, probably years ago, probably not you. It fires on the Thank you page, records the sale against a partner cookie, triggers the commission. On 26 August it stops, and nothing errors on either side. The network simply records no conversions.
Your upgrade guide → Additional scripts → Tracking and analytics. Read every entry you don't immediately recognise as Meta, Google, TikTok or your email platform. Those are your affiliate, referral, influencer, cashback and comparison-shopping tags.
Every network has a named replacement, installed, tested with a real paid order.
A network with a live tag in the box, no app on Shopify's list, and a support address you have never used.
What it costs, and this one compounds in a direction the others don't. Your affiliate CPA appears to improve, because the denominator vanished while the fee did not — for a fortnight it will look like the best channel you have ever run. Then your partners see their commissions hit zero. They don't email you. They move your placement to a competitor who is still paying, and placements are far harder to win back than to lose. Attribution loss first, distribution loss second, and the second one outlasts the deadline by a year.
Check 12 Refunds were never in there, and the rebuild does not add them
B it runs, but it lies The oldest one on the list, and it predates the deadline by years. The Web Pixels API publishes fifteen standard events:
alert_displayedcart_viewedcheckout_address_info_submittedcheckout_completedcheckout_contact_info_submittedcheckout_shipping_info_submittedcheckout_startedcollection_viewedpage_viewedpayment_info_submittedproduct_added_to_cartproduct_removed_from_cartproduct_viewedsearch_submittedui_extension_errored
None of them is a refund. That is not an oversight. A pixel runs in a browser; a refund happens in your admin three weeks later, with no browser attached and no customer present. There has never been an event to fire. So this was never your script's fault and the app pixel doesn't fix it — it belongs here because the migration is the only week this year you will have the file open.
Your returns report, last 90 days, by value rather than order count. Then your ad platform's reported purchase value for the same window.
The two reconcile, because something server-side writes refunds back against the order.
They don't, and nothing in a browser-pixel stack can make them.
What it costs, in one line of arithmetic to run on your own numbers. Take $60,000 of paid revenue against $26,000 of spend: a reported ROAS of 2.31. Now take 20% back as returns. Net revenue is $48,000 and the ROAS you banked is 1.85. Reported sits 25% above earned, permanently, on every campaign you have ever judged. Invert it and it becomes actionable: your true break-even ROAS is not 1.0, it is 1.25 — and every campaign you kept alive between those two numbers has been losing money the whole time it looked fine.
Your ad platform has never seen a refund, so your break-even ROAS is 1.25, not 1.0.
What the platform reports
It has never seen a refund
What you banked
After returns
Paid revenue
20% back as returns
ROAS
against $26,000 of spend
Break-even ROAS
the number you have to beat
Reported sits 25% above earned, permanently, on every campaign you have ever judged.
Arithmetic on this report's illustrative store. Swap in your own return rate: reported ROAS divided by (1 − return rate) is the number you actually have to beat.
Source The absence of a refund event is from Shopify's Web Pixels API standard events reference; the figures are arithmetic on this report's stated inputs.
The door you're standing in
One piece of arithmetic nothing else on this subject seems to do. It changes when you act, not what you do.
Shopify allows a revert, and all three of its conditions have to be true at once: your store was created before 6 January 2025; it has pre-existing Thank you and Order status page customisations using additional scripts or apps with script tags; and you upgraded manually less than 30 days ago. Then the hard stop — the revert itself has to happen before 26 August 2026.
Both clocks run at once and the calendar wins. Upgrade today and you hold 25 days of undo. Upgrade on 22 August and you hold four. Upgrade on the 26th and you hold none.
Your undo window shrinks by one full day for every day you wait. It is the only part of this deadline that rewards moving early, and the part nobody mentions.
There is a second door behind it and it does not reopen. You can only reactivate an additional script while your Thank you and Order status pages have not completed their upgrade; once they are upgraded, that route is closed. Shopify has not published whether reverting the pages restores a script you deactivated. Do not build a plan on the assumption that it does.
Your undo window shrinks by a day for every day you wait.
0 days of undo. The window has closed.
Upgrade date — August 2026
Upgrade on the 1st and you hold 25 days of undo. Upgrade on the 22nd and you hold four. Upgrade on the 26th and you hold none.
The 30-day revert condition and the 26 August cut-off run together. After 27 July the calendar is the binding one.
Source help.shopify.com, non-Plus upgrade guide, revert conditions. The day count is computed from 26 August 2026, not typed.
Fix this → Monday
Twelve checks, one week, ordered to put the waiting first. Nothing needs a developer except 6 and 7. Three of them — 1, 10 and 11 — close out family A. The other nine are the ones you would otherwise ship broken and never hear about.
Monday morning, 40 minutes — checks 1, 5, 9. Search every custom pixel for
checkout_completed. Disable every replaced script still showing live. Find out whether
your Google tag was already converted.
Monday afternoon, 10 minutes of work and 48 hours of waiting — check 2. Update your sign-in provider first, then move your customer accounts domain to a subdomain. The one item that cannot be done late.
Tuesday, the emails — checks 3, 8, 10, 11. Your consent app. Each ad platform's app. Every app developer without a replacement. Every affiliate network. Send them before you do any more work; from here you are waiting on other people, and their queues lengthen every day this month.
Wednesday, the code — checks 6 and 7. Rebuild the data object. Replace every
window.location read. Then place
one real order, at a real price, arriving on a URL carrying a ?gclid=, in a clean browser, and confirm it in the Shopify Pixel Helper.
Thursday, the numbers — check 4, and check 8's before-and-after. Set your purchase pixels to Always on, read the activity log, and compare seven days after each connection against the seven before.
Friday, the baseline — check 12. Recalculate your true break-even ROAS from your own return rate, and rebaseline EEA and UK separately. Then stop: do not upgrade on a Friday, and do not upgrade in the week your biggest campaign launches.
The following week, upgrade — with as much of your undo window still in hand as you can manage.
Where Mtrix fits — and where it doesn't
Twelve checks, one week, and most of you should close this and go and run them. Mtrix does not shorten that list by a single item.
This is for the smaller group who finished the audit holding a different question. Not how do I rebuild this, but why was the record of my own revenue living in a script box I wasn't allowed to edit?
What we do about exactly that. Purchase attribution in Mtrix runs on an
HMAC-verified Shopify Admin orders/paid webhook — server-side, no checkout
script, no ScriptTag, no pixel in the path. Nothing on 26 August touches it. A
refunds/create webhook writes the refund back against the same session — check
12's answer, and the thing fifteen browser events structurally cannot give you; orders, line
items and refunds land together in Purchases. Ad attribution doesn't
ride on a vendor pixel either: Mtrix captures fbclid, gclid,
gbraid, wbraid and ttclid on first touch for 90 days and
reads the platforms' own cookies on every event, with no vendor SDK loaded. And Mtrix sets no third-party
cookies — identity travels in the request body.
The concessions, which matter more than the pitch:
-
That webhook needs a
_mtrixSessionnote attribute on the cart. Without it the order arrives and is dropped as unattributed. A wiring step, on you, and the honest condition on everything above. - Mtrix is not a Shopify app. No App Store listing, no app pixel, no custom pixel. It will not appear in your upgrade report, it is not one of the replacements that report recommends, and it will not do the upgrade.
- Mtrix does not run inside Shopify's hosted checkout. Third-party code gets in there only through Shopify's own extension points and we ship none of them. Session replay covers your storefront, not Shopify's checkout steps.
- Mtrix does not replace your pixels. Meta and Google still need their own conversion events, and all twelve checks above still apply to you.
- Web only. No native iOS or Android SDK. Replay and errors kept one month; events and purchases three years.
If your problem is the deadline, Mtrix is not the answer to it. But the usual reason to file this under later doesn't apply: a switch runs in under a week, not a quarter, so it fits inside the twenty-five days you have left with room to spare. Fix what breaks on the 26th. Then decide whether the record of your own revenue should keep living somewhere a script box can take it down. Four tools hold four definitions of a conversion, and 26 August is only the first of them to arrive with a date attached.
Methodology (in full)
What was measured: nothing. No first-party data, no crawl, no survey, no sample. This is a method document, and the twelve checks come from documented behaviour rather than observed frequency. We do not know what proportion of Shopify stores fail any individual check and do not claim to. No benchmark here and no distribution.
Sources and dates. Every Shopify statement in this report was read on
1 August 2026 from help.shopify.com, shopify.dev or
changelog.shopify.com, and every URL is listed below. Five statements are quoted
verbatim, because in those five the exact wording is the argument: the two dated deadline
sentences, Shopify's description of what ad blockers do and don't affect, the pixel-pausing
sentence in check 4, and the dropped-settings line in check 9. Everything else is stated in our
own words with the source below. Mtrix statements were read from shipped source:
mtrix-js_o/src/modules/match/ for click-ID capture,
mtrix-js_o/src/core/api.ts for request construction, and
nova-middleware/routes/webhooks/shopify-orders.js and
shopify-refund.js for the two webhooks.
Exclusions. Shopify Plus, whose deadline was 28 August 2025 and has passed, and
the checkout.liquid questions that go with it. Shopify Scripts, which stopped executing
on 30 June 2026 — a separate deprecation with a separate fix. Headless storefronts, where several
checks assume a Pixel Helper that Shopify states is incompatible with them.
The arithmetic. Every dollar figure derives from one illustrative store, stated in full in the box inside check 1: 1,100 orders and about $100,000 a month at a $91 average order value, $26,000 of monthly ad spend, 60% of revenue from paid, 20% returned by value. Those six inputs are declared hypotheses, not measurements. They exist so the method is visible; substitute your own and the conclusions move with them.
Which plans this covers. Shopify's wording is "non-Plus plan" and it enumerates no individual plans. Its live plan list runs Starter, Lite, Retail, Basic, Grow, Advanced, Plus, Shopify for enterprise and Agentic, and its checkout-apps page gates checkout-customising apps at the Basic plan or higher — so sub-Basic stores may never have had these customisations to replace. On Starter, Lite, Retail or Agentic, ask your account team rather than assuming this applies to you.
Use this report
Share it, quote it, put the charts in your deck. Attribute to Mtrix with a link to this page. Want the underlying working — the arithmetic, the verbatim quote set, the read dates? Ask us and we'll send the raw cuts.
Sources
Everything above was read on 1 August 2026.
Shopify Help Center
- Upgrading and replacing your Thank you and Order status pages — the 26 August 2026 non-Plus deadline sentence, quoted verbatim in What actually happens on 26 August
- Non-Plus upgrade guide — the five steps, "view-only since August 28, 2025", the three revert conditions, the Incompatible apps section, and the position of the auto-upgrade sentence under the Revert heading
- Reviewing and replacing additional scripts — duplicate events during migration (check 5), the deactivation order, and that an additional script can't be reactivated once the pages are upgraded
- Pixels overview — the sandbox limitation list, the lax-sandbox URL behaviour (check 7), the EEA/UK consent gate (check 3), the form-scraping limitation (check 8)
- App pixels — Optimized as the default and the pause behaviour (check 4), the activity log's 3 June 2026 cut-off, server pixels and their limited availability (check 8), the "reports aren't affected / third-party attribution is lost" passage quoted verbatim, and the customer-account-domain troubleshooting entry (check 2)
- Testing custom pixels — Connected status, the Shopify Pixel Helper, the one-pixel-at-a-time limit, the headless and password-protected incompatibility (check 6)
-
Create a Google Tag Manager custom pixel — the Tag Assistant incompatibility, the stateful
dataLayer, GA4 enhanced measurement, sandbox URLs (check 6) - Migrating pixels — the already-converted Google tag, the six degradations, the dropped Additional Google Analytics JavaScript settings quoted verbatim, the four paste locations (check 9), the connect-before / connect-after trade (check 5)
-
Connecting a custom subdomain for your customer account pages — the default
shopify.combase domain, that it also includes the Order status page, the 48-hour propagation window, the sign-in provider ordering (check 2) - Customer privacy settings — the Customer Privacy API consent sync, third-party banner regions needing to match (check 3)
- Replacing Google Tag Manager scripts on the Thank you page · Checkout apps · Plans and features
shopify.dev
- ScriptTag functionality to be blocked as of February 1, 2025 — the ScriptTag turn-off sentence quoted verbatim in What actually happens on 26 August, and the two merchant-uninstall sentences paraphrased in check 10
-
Web pixels — strict versus lax sandbox,
window.hrefreturning the sandbox URL (check 6) - Web Pixels API standard events — the complete list of fifteen, none of which is a refund (check 12)
-
checkout_completed— theread_customer_emailandread_customer_phonescope requirements (check 8) - Work with protected customer data — the Level 2 table and the review requirement for public apps (check 8)
changelog.shopify.com
- New default setting for marketing pixel data sharing, 13 January 2026 — the pixel-pausing sentence quoted verbatim in check 4
- See which apps use Extensions and Functions, 1 April 2026 — the SettingsApps view in check 10
- View data access changes with the new app pixel activity log, 29 June 2026 — the activity log and its 3 June 2026 cut-off in check 4
Mtrix source, read 1 August 2026
-
mtrix-js_o/src/modules/match/index.ts— first-touch click-ID capture, 90-day TTL, Meta-specfbcconstruction, vendor cookie reads, no vendor SDK loaded mtrix-js_o/src/core/api.ts— no request setscredentials-
nova-middleware/routes/webhooks/shopify-orders.jswithutils/webhooks/shopify.js— HMAC verification, the_mtrixSessionnote attribute, unattributed orders skipped -
nova-middleware/routes/webhooks/shopify-refund.js— HMAC-verified refund webhook
Nothing about the deadline changed in the week to 1 August 2026. The newest changelog posts are dated 29 July and cover analytics annotations, WhatsApp marketing and UPS return labels. The two posts that matter most to this report are older and quieter — 13 January 2026 and 29 June 2026 — and both land on check 4.