The 10-Minute Shopify Additional Scripts Fix Misses Three Things

The shape of the panic reply has stayed the same since late August. A merchant posts on r/shopify or in the Shopify Community that their Meta purchase count fell off a cliff on August 26 or 27. Someone links the "10-minute fix" post. The merchant goes into Settings > Checkout > Customize, switches the page selector to Thank you, clicks Add app block, saves. The reply thread goes quiet. Two weeks later a new post appears from the same merchant, saying tracking is still off. That is the thing I want to argue about.

The 10-minute fix is not wrong. It is what you should do first. But it covers one of three breakages, and the other two are the ones that make merchants spend a second month wondering why their Google Ads CPAs keep climbing. If you did the Add app block step and moved on, the odds are decent that your store is one of the ones with the next two problems live right now.

What the 10-minute fix actually does

Credit where it's due. The guide circulating since late August - add the app block on the new Thank you and Order status pages in the checkout editor - handles the most visible breakage. Order confirmation widgets, upsell blocks, order-note displays, survey apps: anything that lived inside the Additional Scripts field disappeared on August 26 because the pages holding it were replaced wholesale. Re-adding them as app blocks puts the visible pieces back.

The 10-minute fix also carries one quiet assumption, and it is where the guide starts to leak. The assumption is that if an app shows up in the Add app block menu, you are done. "Compatible" on the new pages is not the same as "working." It only means the block exists and can be placed. Each app still needs its pixel configuration done separately in Settings > Customer events, and the guide does not say that out loud. BTWigley made the point on r/shopify in early August, and I have watched merchants read that same thread, nod along, and still miss what it meant. The app block is the furniture. The tracking is the wiring, and the wiring is a separate job.

That is the counterargument I want to give fair weight to: for merchants who only used the Additional Scripts field for visible widgets, the 10-minute fix really is enough. If you did not have ad pixels or GTM pasted in there, you can stop reading. Everyone else, keep going.

What it misses: Optimized mode is still silently throttling your pixels

This is the part of the guide that does not exist at all, and it is the one I think catches the most stores two months later. On January 13, 2026 - more than six months before the August 26 deadline - Shopify changed the default data-sharing mode on every app pixel from Always on to Optimized. Under Optimized, Shopify watches each pixel's attribution signals and, if it decides the pixel is not producing useful results, restricts or pauses what it sends. There is no banner. There is no email. The pixel does not throw an error, because from its own perspective it is working fine.

Here is what that looks like after a correct August 26 migration. You moved your Meta and Google channel pixels to the new pages. You placed a test order. The order went through, you saw the event fire in the preview tool, you declared the migration done. Four weeks later your Shopify order count for the week is tracking normally, but Meta is reporting roughly 60% of those as purchases. You open Events Manager, see nothing wrong, open Shopify's pixel detail page, see nothing wrong. The Optimized mode throttle does not surface in either place as an error. Shopify only started showing per-pixel pause activity on the detail page on June 29, 2026, which means the first five and a half months of this throttle were invisible even to merchants who thought to look.

I wrote a longer piece on this specific setting and when it hurts you in September. The short version: go to Settings > Customer events, open the App pixels tab, and for each pixel click the Data column and set the mode to Always on. Custom pixels are not affected. The Optimized default was documented by Analyzify and WelTpixel's vendor blogs before Shopify's own help content caught up, which tells you how much emphasis Shopify's own migration path puts on this. If you do no other post-fix step, do this one.

What it misses: your Order Status page can swallow 30% of your events

The second miss is architectural, not configurational, and that makes it harder to catch. Customer Events has a checkout_completed event. It fires on the Thank you page. It does not fire on the Order status page. These are two different pages in Shopify's post-purchase flow, and whether a given order triggers the event depends on where the customer ends up.

For a long time most stores never had to think about this because the Thank you page was where everyone landed. New customer accounts change that. Stores that enabled new customer accounts route logged-in buyers to the Order status page after purchase, not the Thank you page. The pixel is correctly installed. The migration is clean. The event simply does not fire for that segment of customers. CMunro answered this in the Checkout Extensibility AMA last year, and ns_6, a developer auditing stores, reported in the same thread that one recent store they looked at was missing roughly 30% of its orders from this single cause.

There is a Safari-specific variant of the same problem that affects repeat buyers across every store, not just new-accounts stores: Shopify sets a loggedConversion2 cookie after the first checkout_completed fires, and Safari's cookie behavior means the event is suppressed on subsequent purchases from the same browser until you clear it on checkout_started. If you have a lot of returning customers and your Meta numbers quietly skew low week over week, this is one place to look.

The fix is not one click. Confirm which page your post-purchase flow actually terminates on. Open an incognito tab, place a real order through the storefront with the same account state your customers use, note whether the final URL is /thank-you or /orders/ or the order status URL. If it lands on the Order status page, your conversion pixel is sampling, not measuring. The fallback paths - a server-side webhook sending the purchase event, or an Order Status app block that triggers a pixel event - need a developer. There is no admin toggle for this one.

What it misses: pasted legacy code into a Custom pixel does nothing

The third thing the guide skips is the one that catches the most self-service migrations. If you had raw JavaScript in Additional Scripts - a GTM container snippet, a Microsoft Bing conversion tag, a Pinterest script, something an agency pasted in two years ago and nobody has touched - the intuitive move is to copy that code into a Custom pixel in Settings > Customer events. That looks like a one-to-one swap. It is not.

Custom pixels run in a sandboxed iframe. The old code assumed it had access to Shopify.checkout.order_id and friends, and that window.location would return the actual Thank you URL. Inside the sandbox, window.location returns the sandbox frame's own URL, and the Shopify Liquid objects are not available. Pasted code silently does nothing. The order completes, Shopify records it, your test looks fine. The pixel never fired. If you want this working you have to rewrite against the Customer Events API: subscribe to checkout_completed, pull the order fields from the event payload, call whatever tracker you were using. GTM has its own version of this - the recommended path is a Custom pixel that pushes a dataLayer event rather than pasting a full container.

This is also why Microsoft Bing Ads conversions tend to be broken on migrated stores even when Meta and Google look fine. Bing goals were often configured against the URL path /thank_you. The new system uses /thank-you. The hyphen is not a typo. Any goal configured against the old pattern silently stops matching, with or without the sandbox issue.

Thread 652934 on the Shopify Community has the best description of why your test orders are not telling you the truth: the checkout completes successfully whether or not the pixel fires, so a successful test is only evidence that checkout works, not that tracking does. If your migration process was "I pasted the code, placed a test order, saw the order in Shopify, moved on," your tracking is probably off. I would like to tell you I have never done this myself, but I spent a Thursday afternoon doing exactly it in September before I remembered to compare the pixel's event count against the admin's order count. Nothing in the admin asks you to.

How to actually validate the migration

Place real orders over three days with the budget you normally spend. At the end of the three days, open two tabs. Tab one: Shopify admin orders filtered to that window. Tab two: Meta Events Manager purchase events for the same window, then Google Ads conversions for the same window, then GA4 purchases. Compare the counts. A gap is the only reliable signal. If every platform matches your Shopify order count within a reasonable margin, your Additional Scripts migration is actually done. If one is off, the one that is off is the one to chase. If you want a second pair of eyes on which gap goes with which cause before you spend another month troubleshooting, that is exactly what help1's expert chat is for and the first fifteen minutes are free.

The three things above are the ones I keep finding. There is a fourth coming in March 2027 when the storefront script tags deprecation lands - that one will take out a different set of apps than Additional Scripts did - but you have five months on that and it is not urgent today. The urgent part is that if you migrated in September and have not checked Optimized mode, verified your terminal page, and rewritten any pasted legacy code, your tracking is almost certainly still off, and the only person telling you is a growing gap between dashboards nobody opens on the same day.

The take, after six weeks of audits: a successful test order is the migration's most expensive false positive. Treat the dashboards as the test, not the checkout.