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.

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.

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 channel: is it installed, and is it sending analytics events, feed data, or both?
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.
11. Legacy checkout scripts: confirm nothing is left over from checkout.liquid after a Checkout Extensibility migration.
12. Third-party apps that add their own analytics, upsell or review pixels.
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

15. Subscribers are registered before any async work. If your custom pixel awaits a fetch before calling analytics.subscribe, early events are gone.
16. page_view fires with the real page address, not the sandbox URL. Verify page_location on a live product page.
17. page_referrer reflects the real referrer, so internal referral inflation does not appear.
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.
22. purchase fires exactly once on order completion.
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.
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.
29. Item-level price and quantity sum to the order value within rounding.
30. Multi-currency: the currency actually charged is reported, not the store default.

---

Block 5: Consent

31. The Shopify Customer Privacy API is read, not assumed. Check analyticsProcessingAllowed, marketingAllowed and visitorConsentCollected.
32. A consent change listener is registered, so a visitor who accepts later is handled correctly.
33. Analytics and marketing consent are handled separately. A pixel that only loads when both are granted silently loses analytics data.
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.
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.
39. The counting method is a deliberate choice, not the default.
40. A GA4 import and a native action are not both primary at the same time.
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.

---

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
• 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.