Shopify Tracking Migration: Pixels, GA4 and Meta CAPI
How to move Shopify tracking from old checkout scripts and theme-code pixels to customer events, GA4 and Meta Conversions API, with a full test checklist.
Quick answer: Migrate Shopify tracking in this order: list every pixel and script on the store, move each one to its supported home (the Facebook & Instagram app for Meta, the Google & YouTube app for GA4, a custom pixel only where no app covers the need), remove the old code, then test. For Meta, the browser event and the Conversions API event should share an event name and an event ID, which is the main way Meta recognises them as one order. Finish by placing test orders with consent accepted and declined, and check that each order is counted once in Shopify, GA4 and Meta Events Manager.
If you spend money on Meta or Google, you rely on numbers you did not build yourself: purchases in Meta, purchases in GA4, orders in your email platform. Each comes from a small piece of tracking code that someone installed at some point, often a developer, a freelancer or an app. Shopify has been retiring the places where that code used to live, so on some stores it is gone, running twice, or running half-blind.
This guide is a practical sequence for fixing that, ending in a test checklist you can run with a phone and a test order. You may want to hand parts of it to a developer.
Two things up front. Prism3 does not run ads or email; we work on Shopify SEO, GEO and CRO. Every ad and email number is only as good as the tracking underneath it. And I am not promising that fixing tracking recovers any amount of lost or “attributed” revenue. It makes the numbers more honest.
What changed, and why old tracking goes wrong quietly
Every date below is as at 30 October 2026, with the page it comes from named.
- Checkout and order pages. Shopify’s help centre says that as of 28 August 2025 the Additional scripts section in checkout settings is view-only, and that 26 August 2026 was the deadline for non-Plus stores to upgrade their Thank you and Order status pages. Shopify’s developer documentation words it a little differently: checkout.liquid and Additional scripts were sunset for those pages on 28 August 2025, and script tags on those pages were sunset for non-Plus stores on 26 August 2026. Because the two pages do not read identically, I would not guess what an old script does on your store. Test it. Shopify’s upgrade guide points to app pixels and web pixels as the replacement for tracking.
- Storefront script tags. A Shopify developer changelog post dated 24 August 2026 says creating or updating script tags returns an error from 1 October 2026, and Shopify stops injecting script tags into storefronts on 1 March 2027. It recommends web pixels for scripts that only collect analytics or conversion data. If an app on your store tracks through a script tag, ask the vendor whether it has moved to a web pixel.
- Pixels in Preferences. Shopify’s migration page says that as of February 2025, Meta pixels and Google Universal Analytics tags not set up through their respective apps were removed from the Preferences page and converted to custom pixels, which “might result in a reduction in measurement performance and features.”
A tracking script that stops running does not break the page; it shows up as a number that quietly falls. That is my observation, not a Shopify statement. There are three ways it goes wrong:
- A gap. Old code stopped and nothing replaced it.
- A double count. Old and new code both run, so one order is counted twice.
- A blind spot. New code runs, but consent settings or the sandbox stop it firing for some visitors.
How Shopify tracking works now
Shopify’s help centre describes pixels as JavaScript snippets that run on your store, customer accounts or checkout and listen to customer events: actions customers take in the browser, such as adding a product to the cart. You manage them under Customer events in the Shopify admin.
| Option | Use it when | Watch for |
|---|---|---|
| App pixel | A marketing app already covers the platform (Meta, Google, your email tool) | Shopify recommends it where possible, citing higher security and automatic updates. You depend on the app’s event mapping, so test it |
| Custom pixel | No app pixel meets your need | Needs JavaScript. Shopify says custom pixels are unsupported and compliance, consents, code security and updates are your responsibility |
| Theme code or Additional scripts | Not for new work | Additional scripts are view-only; script tags are being retired (dates above) |
Three details change how you plan:
- Standard events. Shopify’s Web Pixels documentation lists 15 standard events, including page_viewed, product_viewed, product_added_to_cart, checkout_started and checkout_completed. Merchants cannot publish standard events, only custom ones through Shopify.analytics.publish().
- The sandbox. Shopify’s pixels overview says sandboxed pixels cannot automatically detect DOM-scraped events, outbound link clicks, page scrolling or heatmap clicks. If your old setup tracked scroll depth by reading the page, rethink it rather than pasting it across.
- The purchase event. Shopify’s reference says checkout_completed fires once for each checkout, typically on the Thank you page. With an upsell or post-purchase flow it fires on the first upsell page instead. If the page it should fire on fails to load, it does not fire.
Step 1: Find every tracker, and write down your baseline
Shopify’s migration page says most old pixels have two parts: a base JavaScript SDK (often in the header of theme.liquid or in Additional scripts) and the code that collects events (usually in theme liquid files or Additional scripts). Plus stores should also check checkout.liquid. Shopify’s examples of what to search for: Meta’s fbq(), and Google’s gtag() or dataLayer.push().
| Where to look | What to check | Note |
|---|---|---|
| Theme files, especially theme.liquid | fbq(, gtag(, dataLayer.push(, any Tag Manager snippet, other SDKs | Check every theme you keep, not only the live one |
| Checkout settings, Additional scripts | Any code at all | View-only now, but readable, so you can see what used to run |
| Settings > Customer events | Every pixel already connected | Includes pixels converted from Preferences |
| Installed apps | How each adds tracking | Ask whether it uses a script tag or a web pixel |
| Ad platform dashboards | How many pixels your Meta account has | Shopify warns that more than one pixel on the store can cause duplicate or incorrect data |
| Email and SMS platform | Its onsite tracking settings | See Step 7 |
Write down a baseline before you touch anything. For the last 14 days (30 is better) record orders in Shopify admin, purchases in GA4 and purchase events in Meta Events Manager. Do not compare them to each other yet. You are recording what each tool says today so you can ask afterwards whether each moved in a way you can explain. Our guide to GA4 versus Shopify Analytics explains why they differ even when everything works.
Pick a quiet week. Shopify advises migrating during a less busy period to avoid duplicating or missing events. Change tracking mid-sale and you cannot tell whether a number moved because of the sale or the change. Our Black Friday checklist covers tracking before a sale.
Step 2: Decide where each tracker should live
Choose one home for each item. My decision rules:
- If an app pixel exists, use it. Shopify’s migration page says that if you installed an app pixel and added no extra code, you need no migration, and recommends moving the Meta pixel to the Facebook & Instagram channel and the Google Analytics pixel to the Google & YouTube channel for the most accurate tracking.
- If you added code on top of an app, follow the app developer’s migration instructions, per Shopify.
- Use a custom pixel only for what no app covers. Shopify’s steps: create a custom pixel that subscribes to the events you need, remove or replace the old code, add the pixel, connect it. Shopify’s custom pixels page says you can hire a Shopify Partner if you need help.
- Replace custom event code with Shopify.analytics.publish(). Shopify’s example swaps a theme-code
fbq("trackCustom", ...)call forShopify.analytics.publish("my_custom_event"), with the custom pixel subscribing and calling the Meta function. - Remove the old SDK, and for standard events remove the old code if your new pixel supports that event.
Google Tag Manager. Shopify’s custom pixels page lists a tutorial for a Tag Manager custom pixel, but says not all functionality works in the sandbox. If your container only fires GA4 and Meta tags, the two apps may remove the need for it. If it does more, treat it as a developer job.
Step 3: Cut over without a gap or a double count
Shopify’s migration page states the trade-off: connect the new pixel before removing the old one to minimise missed events, or after removing it to avoid duplicates. It does not say which to choose.
My rule, which is my reasoning and not a Shopify rule: an old hand-coded pixel will not know the event ID a new app generates, so overlapping them risks counting an order twice with nothing linking the copies. For most stores I would remove the old code and connect the new one in the same sitting, in a quiet window, then write down the exact time. A short, known gap is easier to explain than weeks of inflated numbers. Test the purchase straight away.
Keep a change log: what was removed, what was added, who did it, when.
Step 4: Meta pixel, Conversions API and event IDs
What the data-sharing levels mean
Shopify’s Facebook data sharing page says the Facebook & Instagram app offers Standard, Enhanced and Maximum, and that the levels offer different privacy settings depending on when you installed the app. In Shopify’s words:
- Standard uses the Meta pixel to collect browsing behaviour, and a browser-based ad blocker can stop it sharing data.
- Enhanced uses Meta’s Conversions API as well as the pixel. The API sends the purchase event server to server, which browser-based ad blockers cannot block. Shopify says it shares customer name, location, email address and phone number to match users on Facebook’s network.
- Maximum uses the Conversions API, the pixel and Facebook’s latest advertising technology, and shares the same kinds of customer information.
Meta’s Business Help Centre page on connecting Shopify says to enable the pixel and Conversions API and select Enhanced or Maximum. Shopify’s page says data sharing is a choice and your privacy policy should tell customers how you share data.
How Meta decides two events are the same order
Meta’s developer documentation sets the rules. A browser event and a server event are treated as one when the pixel’s event name matches the Conversions API’s event_name (for example Purchase on both) and the pixel’s eventID matches the API’s event_id. Meta also describes a fallback using event name plus fbp or external_id, but says it generally works only for events sent first from the browser and then the server, so event name plus event ID is the method to build for. Also:
- Events are only deduplicated if received within 48 hours of the first event with that event_id.
- If the two copies do not differ meaningfully, Meta generally prefers the one received first.
- If you send an event from only one source, there is nothing to deduplicate. Meta’s Help Centre notes that sending different events from each source needs no deduplication.
Meta’s browser example passes the ID as a fourth argument, {eventID: ‘EVENT_ID’}, and the server event carries the same value as event_id.
What this means on Shopify
Meta’s Help Centre says that with partner integrations, many platforms (Shopify and WooCommerce are named) automatically handle the deduplication parameters. Shopify’s page does not say how the app builds its IDs, so do not assume: run the test in the checklist and read what Meta’s Test Events tool says.
If you build your own custom pixel and server-side sending, the ID is your job. Shopify describes an event’s id as “the ID of the customer event”, but I found no documentation saying your server would see the same value. For a purchase, my suggestion is a value both sides can compute independently, such as the order identifier from the checkout_completed data. That is not a Meta or Shopify instruction, so confirm it in Test Events. Shopify’s custom pixel page also says Meta’s pixel SDK does not automatically transmit data from a custom pixel: you map each Shopify event to the Meta call yourself.
How to see it in Meta
Meta’s developer documentation points to Events Manager > Data Sources > your pixel > Test Events. It generates a test ID that you send as test_event_code, and you must remove that code from your production payload. Meta says you should be able to verify events within about 20 minutes, and its Help Centre says the tool shows which events were received, deduplicated or dropped.
One more thing. Shopify says events that track an order value use the order’s total price, the sum of all item prices in the checkout including duties, taxes and discounts. If your sales report defines revenue differently, the two will not match to the dollar, and that is not a tracking fault.
Step 5: GA4
Google’s help page recommends connecting GA4 through the Google & YouTube app: open the Overview page, start the “Just want to set up Google Analytics 4” section, then connect and confirm your property. It says this option is strongly preferred over adding the tag by hand, and lists access problems or sending data to multiple properties as reasons for the manual route. It also says the app adds events such as view_item_list, remove_from_cart, view_cart and add_shipping_info, and that the shopify_event_name parameter can filter some of this out of reports.
Check four things after connecting:
- No second GA4 tag. Google’s Ads help for the app says that if you track conversions in both the app and a storefront or custom pixel, check for duplicate tags. A leftover gtag snippet in theme.liquid is the classic cause.
- If your GA4 tag was converted to a custom pixel. Shopify lists the expected effects: data might change or be lost; enhanced measurement and cross-domain measurement might not work correctly; Tag Assistant and Tag Diagnostics might misreport; settings in Additional Google Analytics JavaScript are dropped; consent treatment might change. This is the strongest reason to move to the app.
- Purchase deduplication. Google says GA4 deduplicates purchase events with the same transaction ID, on web streams only. The ID must be unique per order, should not be reused across users, and must not be an empty string, because GA4 will deduplicate all purchases with transaction_id of "". In DebugView, open a real purchase and confirm the ID is the order identifier.
- DebugView limits. Google says events will not appear if client-side privacy controls are in place or if consent mode is used and the visitor has not consented to Analytics cookies. If your test shows nothing, check consent before concluding the tag is broken.
Google also says that turning off conversion tracking in the app switches off tracking for ads and free listings. If someone runs Google Ads for you, check with them before removing anything: a change that looks tidy from the store side can change what their campaigns optimise to.
Step 6: Consent, in general terms
The law differs by country and, in the United States, by state. I am not a lawyer and this is not legal advice. Here is what Shopify and the Australian regulator say, and what to test.
Shopify. Its migration page says web pixels always respect your store’s privacy settings and that a third-party consent tool must sync consent to Shopify through the Customer Privacy API. Its pixels overview says that in markets that require consent, such as the EEA and the UK, pixels run only after visitors grant the permissions set on the pixel, and that new pixels require Marketing and Analytics permissions by default. Its custom pixel page adds that new custom pixels qualify as data sale by default. Shopify’s privacy settings page says automated settings configure a cookie banner for UK and EEA visitors when you have active markets there, that it is not active by default elsewhere, and that a third-party banner should use the same regions as Shopify’s. The page I read does not mention Australia.
The OAIC. The Office of the Australian Information Commissioner published guidance on tracking pixels on 4 November 2024. It says the Privacy Act does not prohibit tracking pixels; that collection should be limited to the minimum reasonably necessary; that sensitive information should only be collected through a pixel with express consent; that you should clearly disclose third-party pixels in your privacy policy; and that due diligence should not be “set and forget”. Whether your store needs a banner depends on what you collect, from whom and where they are, so have a professional check it.
In the migration:
- Whatever Meta level you choose, check your privacy policy describes it. Enhanced and Maximum share name, location, email and phone, per Shopify.
- If you use a cookie banner app, confirm it uses the Customer Privacy API and the same regions as Shopify.
- Test with consent accepted and declined, so you know what each looks like.
Shopify’s migration page says single-digit percentage dips in event counts are expected after moving to web pixels, because some bots do not trigger the pixel sandbox. For larger gaps it points you to a list of possible causes, so investigate them.
Step 7: The email side
Email numbers rest on tracking too. Klaviyo’s help article on its Shopify Added to Cart event (last updated 27 August 2025) says Klaviyo added an event that syncs through Shopify pixels and that its older snippet was not being deprecated then. Its order of work suits any email platform: turn on behavioural tracking, confirm the new event appears on a test profile before changing anything else, clone and update the flows that depend on the old event, send test emails, and only then remove the old snippet. It also warns that Shopify’s privacy settings may stop tracking for visitors in the EU, EEA, UK and Switzerland unless they have consented.
Other platforms have their own rules, so read their documentation. The point: an abandoned-cart trigger is a tracking event, and it can change when your tracking does.
The test checklist
Run this after the cutover and again a week later, on a phone as well as a desktop.
| Test | How | A pass looks like |
|---|---|---|
| Old code is gone | Search theme files and Additional scripts for fbq(, gtag(, dataLayer.push(, old SDK names | No live copy outside the app or pixel you chose |
| Events fire | Shopify’s Pixel Helper shows a custom pixel’s events in real time | Each expected event appears. The helper tests one custom pixel at a time and does not work with headless stores or stores in private mode. For app pixels, use the platform’s own debugging tool |
| Each event fires once | Browser network tab on one page load; look for repeat requests to the same endpoint | One request per event |
| Purchase fires once | Place a test order, watch the Thank you page, then reload it | One purchase for one order. Shopify’s docs do not say how a refresh is handled, so check |
| Post-purchase upsell | If you use one, order through it | One purchase event, on the first upsell page per Shopify’s reference |
| Value and currency | Compare the event to the order | Matches the order total as Shopify defines it, in the right currency |
| Meta deduplication | Test Events: do the browser and server copies share event name and ID | One counted event, marked deduplicated |
| GA4 purchase | DebugView: open the purchase event | transaction_id is the order identifier, not empty, not repeated |
| Consent accepted | Accept the banner, repeat the order | Events fire as above |
| Consent declined | Decline, repeat the order | Permission-gated events do not fire and nothing breaks |
| Next-day reconciliation | Compare the same order across Shopify, GA4 and Meta | Each tool saw the order once, even if totals differ by definition |
Repeat for each payment method your customers use, such as Shop Pay, Apple Pay or buy-now-pay-later. Our checkout leakage audit covers what else to look for in those flows.
Reading the numbers afterwards
After 7 to 14 days, line up your baseline against the new numbers. Shopify’s troubleshooting list gives the order of questions: are all expected events firing, is the logic the same as before, is each event tracked once, are you comparing numbers from the same service, do privacy settings match the old setup, and are you collecting consent where required? Shopify also says not to compare event counts across different services, and lists theme code, apps, the Customer events section and leftover Additional scripts or checkout.liquid code as sources of duplicates.
The arithmetic below is illustrative, not from a real store:
| What you see | Most likely cause | First check |
|---|---|---|
| Shopify shows 120 orders; Meta shows about 240 purchases | Same order counted twice, probably with no shared event ID | Test Events pair; any leftover pixel |
| Shopify shows 120 orders; Meta shows about 96 | Missing events, well beyond the single-digit dip Shopify calls expected | Was the old pixel removed first? Consent? |
| GA4 purchases collapse | Empty or repeated transaction_id, or a GA4 tag converted to a custom pixel | DebugView on a real purchase |
| Everything fell on cutover day | A gap, not a trend | Your change log, then Pixel Helper |
| Meta and Shopify revenue differ by a steady percentage | Different definitions of revenue | Order total definition and currency |
Do not expect the tools to agree. Meta has a help article on why event counts differ between Ads Manager, Ads Reporting and Events Manager, and our guide to why Meta shows more sales than Shopify covers attribution. The aim here is narrower: each order counted once, with the right value.
When to get help
You can do Steps 1 to 3 and most of Step 5 yourself. Get a developer for a custom pixel, server-side sending you write yourself, or a busy Tag Manager container.
Prism3 does not run ads, email or SMS and does not manage ad accounts or Meta settings. Our CRO service starts with a tracking audit and repair (GA4, GTM and ecommerce events) before any optimisation, because you cannot improve a conversion rate you cannot measure. For how the pieces fit, see the DTC growth system, and three numbers Shopify founders watch for what to track once the data is trustworthy.
Key takeaways
- As at 30 October 2026, Additional scripts have been view-only since 28 August 2025, 26 August 2026 was the non-Plus upgrade deadline and storefront script tags stop being injected on 1 March 2027 (Shopify). Test your own store.
- Find every tracker first, and write down a baseline before changing anything.
- Use the supported app where one exists. Use a custom pixel only for gaps, and treat it as your responsibility.
- Cut over in one sitting during a quiet window and log the time. Overlapping an old hand-coded pixel with a new one risks double counting.
- For Meta, browser and server events need the same event name and event ID, within 48 hours. Verify in Test Events.
- For GA4, check there is one tag and transaction_id is filled and unique.
- Test with consent accepted and declined. Single-digit dips are expected; larger gaps need investigating.
- Do not expect Meta, GA4 and Shopify to agree. Aim for each order counted once, with the right value.
FAQs
What are Shopify customer events and web pixels?
Customer events are actions customers take in the browser, such as adding a product to the cart. Pixels are JavaScript snippets that listen to those events and pass them to a service such as Meta or GA4. Shopify manages them under Customer events in the admin, as app pixels from marketing apps or custom pixels written by a developer.
Do I need to remove my old Meta pixel code before using the Facebook & Instagram app?
Yes. Shopify’s Meta pixel help says to remove a pixel added in your theme code before adding a pixel ID through the app, and that if you do not, your store will have more than one pixel, which can result in duplicate or incorrect data in your reports.
Do I need Meta’s Conversions API on Shopify?
It is a choice. Meta’s Help Centre recommends enabling it with the pixel for reliable data sharing, and Shopify’s Enhanced and Maximum levels use it. Those levels share customer details such as name, location, email and phone, so decide with your privacy policy in mind. I do not manage ad accounts, so I cannot say what your campaigns will do with the extra data.
How does Meta deduplicate browser and server events?
Mainly by matching event name and event ID on both copies. Meta says the pixel’s eventID must match the API’s event_id, and events are only deduplicated if they arrive within 48 hours of the first. Meta also describes a fallback using event name plus fbp or external_id, but the event ID method is the main one. Without a working match you can see artificially high counts, which Meta warns about.
Why do my GA4 purchases not match Shopify orders after migrating?
Some gap is normal because the tools count differently. A big or sudden gap usually means a missing event, a second GA4 tag, an empty or repeated transaction_id, or consent blocking events. Check the transaction ID first.
Do I need a cookie banner for tracking in Australia?
I cannot answer that for your store, and this is not legal advice. The OAIC says the Privacy Act does not prohibit tracking pixels but expects minimal collection, a clear privacy policy and express consent for sensitive information. Shopify’s automated banner covers the UK and EEA by default, and the page I read does not mention Australia. US state laws vary. Ask a professional.
Can I keep using Google Tag Manager on Shopify?
You can run one through a custom pixel, and Shopify lists a tutorial, but custom pixels are unsupported by Shopify and run in a sandbox where not all functionality works. If your container only fires GA4 and Meta tags, the two apps may do that job with less to maintain.
Keep reading
- Why Meta shows more sales than Shopify
- GA4 vs Shopify Analytics: why the numbers differ
- Why attribution is broken on Shopify in 2026
Is the tracking under your numbers telling the truth?
Moving the pixels is the easy part; knowing each order is counted once, everywhere, is the hard part. Book a free 30-minute diagnostic: we look at where your store loses buyers after the click, using your own numbers, and tell you what to fix first. We do not run ads or email. No pitch. No email gate.
A tracking check comes first in our Shopify CRO service, before any optimisation work, and it includes tracking audit and repair.
Free 30-min diagnostic
Seen enough?
Book a free diagnostic.
We'll look at where your store loses buyers after the click and what to fix first. No pitch. No email gate. 30 minutes.
More from Prism3
Afterpay vs Zip vs Shop Pay Instalments: Shopify AU
Afterpay, Zip and Shop Pay Instalments compared for Australian Shopify stores: merchant fees, payouts, approval, checkout placement and a worked margin example.
AI-Referred Orders on Shopify: What Is Real and What Is Hype
What Shopify has disclosed about AI-referred orders, why the 13x headline needs context, how to find AI traffic in GA4 and Shopify, and what to do now.
AI Visibility Tools for Shopify: What They Measure and Miss
What AI visibility tools for Shopify stores really count: mentions, share of voice and citations, where the data is sampled or unstable, and how to use them.