Shopify Tracking Checklist: 42 Checks Before You Call It Done

A green tag is not an acceptance test

Most broken Shopify setups were not built carelessly. They were built, checked once in preview mode and never verified against a real order. Preview mode tells you a tag fired. It does not tell you whether the value was right, whether a second path fired the same purchase or whether the consent state that reached Google matched what the visitor actually clicked.

On top of that, between August 2025 and September 2026 Shopify switched off several things older setups were built on: additional scripts and script tags on the order confirmation, several tracking cookies and the flow of customer data to app pixels without approval. A setup signed off in spring 2025 can be silently losing data today without anything having changed in Tag Manager.

This is the checklist we work through before a Shopify measurement setup is declared finished. Work through it in order. Each block assumes the previous one is clean. The central checks carry the official source inline.

If you would rather have this done as a fixed-price project, that is the Shopify tracking service.

---

Block 1: Accounts and ownership

Before touching a single tag, write down who owns what. Almost every inherited mess starts here.

1. GTM account and container ID are documented and the merchant is an account owner, not just a user.
2. GA4 property and measurement ID are documented, including which data stream belongs to the shop.
3. Google Ads account and customer ID are documented and the conversion actions live in that account rather than in an agency account.
4. Merchant Center connection is documented separately from the measurement connection.
5. Shopify app inventory: every installed app that touches tracking, pixels or the product feed is listed.
6. User permissions are reviewed. Former agencies and departed staff are removed.
7. A baseline export of the GTM container exists before any change.

The seventh point is the one people skip and regret. Without a baseline export there is no rollback, only a rebuild.

---

Block 2: Active measurement paths

The single most common Shopify defect is not a missing path. It is two paths sending the same event.

8. Google & YouTube app: is it installed? Which conversion actions did it create in the Ads account and is a GA4 property linked? When you link the Ads account, the app suggests purchase, add to cart and checkout started as the default actions. Google’s own guide explicitly warns about duplicate tags when conversions are measured both in the app and in the storefront or a custom pixel (Google Ads Help).
9. Theme scripts: check theme.liquid and any header or footer injection for a hard-coded gtag or GTM snippet.
10. Custom pixels: list every custom pixel under Settings, Customer events and note whether each is app-managed or merchant-managed. Record the permissions per pixel. New custom pixels require Marketing and Analytics by default and qualify as data sale by default (Shopify Help).
11. Legacy checkout scripts and script tags are gone. checkout.liquid and additional scripts were switched off on the Thank you and Order status pages for Plus shops on 28 August 2025 and script tags on those pages for all other shops on 26 August 2026 (checkout.liquid, script tags on the Order status page). A purchase tag that still sent from there has been reporting nothing since the cutoff. The ScriptTag API on the storefront is being phased out too: from 1 October 2026 scriptTagCreate and scriptTagUpdate return an error and from 1 March 2027 Shopify no longer injects script tags into storefronts (changelog). Check the app inventory for any app still measuring this way and whether the vendor has migrated to a web pixel or an app embed block.
12. Third-party apps that add their own analytics, upsell or review pixels. For the Facebook & Instagram app, record the data sharing level: Standard sets only the Meta pixel, Enhanced and Maximum additionally send through the Conversions API (Shopify Help). A second Meta pixel in the theme or in GTM then doubles the events.
13. Duplicate GA4 measurement IDs on the same page. Search the rendered page source for G-.
14. Only one owner per event: for every event in your measurement plan, exactly one path is responsible for sending it.

Point 14 is the acceptance criterion. Everything else in this block is evidence gathering.

---

Block 3: Customer events and the data layer

Web pixels run in a sandbox. App pixels run in the strict sandbox, custom pixels in the lax sandbox (Web Pixels API). Neither can render UI elements or read data from the DOM (Shopify Help). Pixels load on the storefront, checkout, Thank you page and Order status page. On customer account pages they have loaded since July 2025, only with a custom subdomain and only with the page_viewed event (changelog).

15. Subscribers are registered at the top level of the pixel, before any fetch or script load is awaited. In consent regions Shopify executes the callbacks only after consent and then replays events that already occurred (Shopify docs). Do not rely on that replay. Verify in the test purchase that the first page_viewed of a session arrives.
16. page_view fires with the real page address and the real referrer, not the sandbox URL. In the lax sandbox the automatically detected URL includes a sandbox version and does not exactly reflect the main window’s address (Shopify Help). Read event.context.document.location.href and event.context.document.referrer and verify page_location and page_referrer on a live product page, so internal referral inflation does not appear.
17. No code reads switched-off Shopify cookies any more. Shopify stopped setting _tracking_consent, _landing_page and _orig_referrer on 15 September 2025 (changelog) and _shopify_y and _shopify_s on 1 January 2026 (changelog). For the visitor identifier the replacement is event.clientId from the event, for the session there is none. This affects custom pixels, GTM variables and apps that read the landing page, referrer or identifier from them and passed it on to a server-side setup.
18. view_item fires on product pages with item ID, name, price and currency.
19. add_to_cart fires with quantity and value.
20. view_cart fires on the cart page.
21. begin_checkout fires at checkout start, on the checkout version that is actually live. checkout_started fires every time a customer enters checkout on shops with checkout extensibility and only the first time on older shops (standard events). Decide whether you count every entry or only the first.
22. purchase fires exactly once on order completion. checkout_completed is triggered once per checkout, normally on the Thank you page. With a post-purchase upsell it fires on the first upsell page. If that page fails to load, it does not fire at all (standard events). Since July 2025 web pixels also load on the Order status page. Reopening the order there yields page_viewed, not a second checkout_completed. Confirm no custom pixel hangs the purchase on page_viewed for an order URL.
23. Item arrays are normalised: the same field names, the same types, on every event.

---

Block 4: Purchase parameters

This block decides whether Google Ads bids on real numbers.

24. transaction_id is present and unique per order. Not the cart token, not a timestamp, not a static string.
25. value matches the shop system for the same order. Record which field you use: since 24 April 2025 checkout.subtotalPrice.amount is calculated after product and order-level discounts on the new Thank you page and in the checkout events, whereas previously order-level discounts were missing (changelog). checkout.totalPrice.amount includes tax and shipping.
26. currency is set explicitly, even in a single-currency shop.
27. tax and shipping follow the same convention as the shop reporting. Decide whether value includes them and document the decision.
28. coupon is present when a discount was applied and correct with two stacked codes. The source is checkout.discountApplications.
29. Item-level price and quantity sum to the order value within rounding.
30. Multi-currency: the currency actually charged is reported from checkout.currencyCode, not the store default.

---

Block 5: Consent

31. The Shopify Customer Privacy API is read, not assumed. On the storefront that means analyticsProcessingAllowed(), marketingAllowed(), preferencesProcessingAllowed() and saleOfDataAllowed() and inside a pixel the same state lives in init.customerPrivacy (Customer Privacy API, pixel privacy). The _tracking_consent cookie has not been a substitute since 15 September 2025, see point 17.
32. A consent change listener is registered, so a visitor who accepts later is handled correctly. The event is visitorConsentCollected, as a document event on the storefront and through customerPrivacy.subscribe inside a pixel.
33. Analytics and marketing consent are handled separately. A pixel that only loads when both are granted silently loses analytics data. That is exactly the default for new pixels: they require Marketing and Analytics. Set the permission per pixel deliberately and check what still loads with analytics-only consent.
34. Default state is set before any tag executes.
35. The update state reaches Google after the decision, verified in the network request rather than in the banner UI. Since 15 June 2026 the Google Signals setting in GA4 only controls the association of Analytics data with signed-in users for behavioural reporting. For Google Ads, the decisions passed through Consent Mode govern exclusively (Google Analytics Help). So verify that ad_storage, ad_user_data and ad_personalization are set correctly by the banner and that nothing relies on a GA4 setting. How the common banners connect to Consent Mode v2 is covered in Connect your cookie banner to Consent Mode v2.
36. No retroactive replay happens in basic mode.
37. If a WordPress main site exists, its CMP is checked separately and the two systems are reconciled or the difference is documented.

For the difference between the two consent modes and what each one actually changes, see the Consent Mode basic vs advanced guide.

---

Block 6: Google Ads

38. The conversion action lives in the merchant Ads account, with the value, currency and transaction ID passed through. The setup from scratch is covered in Google Ads conversion tracking setup.
39. The counting method is a deliberate choice, not the default.
40. A GA4 import, a native action and the Google & YouTube app action are not all primary at the same time. Google recommends setting the app conversion as primary and removing legacy tags if you use the app (Google Ads Help). The reverse applies too: if you measure through GTM, set the app action to secondary.
41. Enhanced conversions are only enabled where the user-provided data variable is populated correctly and marketing consent is present. Verify the hashed payload in the network request. For app pixels there is one more condition: since 10 December 2025 Shopify sets email, name, phone and address to null in events sent to app pixels whose app has no protected customer data approval. Custom pixels are not affected (changelog). If an app populates enhanced conversions or a Conversions API, verify in the network request that the fields are actually filled.

---

Block 7: The test purchase

Nothing above counts until an order goes through end to end.

42. Run a real test purchase and verify, in this order:

• the item view, cart, checkout start and purchase all appear in GA4 DebugView
• the purchase value, currency, tax, shipping and coupon match the Shopify order
• the transaction ID in GA4 matches the Shopify order number convention
• the Google Ads conversion request fires with the same value and ID
• reloading the order confirmation does not create a second purchase
• opening the Order status page from the confirmation email produces page_viewed and likewise no second purchase
• the purchase comes from exactly one path, verified in the network tab and not only in the tag preview
• the same run repeated with consent rejected produces no measurement events
• the same run repeated with analytics only produces analytics events and no ad events
• entering the shop from the main site preserves the campaign source
• Merchant Center and the product feed are unaffected

Cancel or refund the test order once the evidence is captured.

---

What still will not match

Even a clean setup will not reconcile exactly with the shop backend. Rejected consent, ad blockers, browser restrictions, order confirmations that never finish loading, cancellations and the processing logic of each platform all leave a residual difference.

The goal is not a perfect match. The goal is a difference you can explain. If you want to put a number on yours, the tracking coverage calculator compares orders and revenue against what Analytics actually measured.

---

When to escalate

If working through this checklist surfaces more than two structural defects, stop patching and audit properly. A setup with duplicate purchase paths, a broken consent chain and an inherited app nobody documented is not a fix, it is a rebuild with a controlled cutover.

That is what the Web Tracking Foundation is for: baseline export, rollback point, new path in the workspace, parallel operation, test purchase, then disabling the old path.

Technical guidance, not legal advice. Whether a specific setup meets your legal obligations depends on the data processed, the recipients and the legal basis.