Shopify Tracking Audit Checklist: What Each Check Proves

Merchants running paid traffic on Shopify keep asking the same question: what should a tracking audit actually check? Most answers list tools — install this pixel, glance at that dashboard — without saying what checking it actually proves, or what it leaves unanswered once you’re done.

A checklist worth using is organized around checks, not tools: a question worth asking, the source you’d look at to answer it, how you’d verify that source, and — the part usually missing — what you still don’t know afterward. That fourth column is the reason a checklist like this is worth having at all: passing a row narrows a problem, it does not close it.

Read the columns like this: the first two say what you’re checking and where; the third is the concrete action — a report to pull, a tool to open, a field to inspect; the fourth is the actual finding. A three-column checklist lets you tick boxes without knowing what a green tick still leaves open. Everything below is read-only, in the same order I use in the methodology: review existing records and retained test evidence. If a row needs new evidence, mark it unverified. A new checkout or consent-interaction test is a separate, explicitly authorised step outside this checklist.

What scope and access does a Shopify tracking audit actually need?

Before any platform is compared against any other, the audit needs to know what it’s allowed to look at, and for how long. Skipping this step is how a verdict ends up covering a system nobody agreed was in scope.

Question	Source checked	How it is verified	What stays unknown after this check
Is the scope actually one store, one problem, and an agreed set of systems?	The written scope note agreed before access is granted	The systems named in the note are compared against what’s actually being checked	Whether the real cause sits in a system outside the agreed scope — this check only confirms what’s in view
Is the access read-only and does it cover what’s needed?	GA4 viewer role, Google Ads read-only, Meta Events Manager, Shopify staff account	Log in with the granted role and read the permission level the platform itself shows	Whether the access turns out to be insufficient once the reconciliation is under way
What order window is actually available to check?	Shopify order export (Admin or Orders API) for the agreed period	The order count and date range in the export are checked against Shopify admin directly	Whether the same pattern held before the export window — a 30-day baseline is not a promise of full history
Which pixels and tags are actually installed, not just remembered?	Shopify admin → Settings → Customer events, plus any GTM container in use	Each entry in Customer events is opened and checked against what the merchant described	Why each entry is there and who owns it — this confirms what’s present, not who added it or whether it’s still needed

Is the purchase event coming from a source that still works?

Shopify has changed, more than once, where a purchase tag may run, so an audit that checks the old location finds nothing wrong: there is nothing left there to find. The sandboxed pixel, the retired Additional Scripts field and untested express-checkout paths are catalogued on the Shopify tracking pillar page; the rows below say which applies.

Question	Source checked	How it is verified	What stays unknown after this check
Does the purchase event reach GA4 from a real order?	Existing GA4 DebugView evidence from a previously authorised test order	Review the saved purchase-event parameters and match them to that test order; if the evidence was not retained, mark this check unverified	Whether every payment path — Shop Pay, other express checkouts — fires the same event; the evidence covers only the order tested
Is the purchase tag running where Shopify actually lets it run?	Shopify admin → Settings → Customer events (app pixels and custom pixels)	Each active pixel is opened and its subscribed events are checked against what Shopify’s Web Pixels API exposes	Whether a listed pixel is also configured correctly — being present is not being correct
Is a purchase tag still sitting in a retired field?	Checkout settings → Additional Scripts	The field is opened directly; Shopify made it view-only for non-Plus stores, and scripts there are not carried over to the upgraded Thank you and Order status pages, so anything still in it is not running on a store that has upgraded	How long the tag had already been silent before the check — nothing alerts a merchant when a script in that field stops firing
Does a server-side copy of the same order exist?	Server container or Conversions API delivery log, matched by order	The server event’s order reference is compared to the browser event for the same order	Whether the server path also covers orders the browser path misses, without checking a wider sample

Is one purchase counted once, on every platform?

A platform reporting more orders than Shopify shipped is a deduplication question before it is a volume question — and each platform deduplicates on its own identifier, so this has to be checked per platform, not assumed from a total that happens to look plausible.

Question	Source checked	How it is verified	What stays unknown after this check
Does GA4 count one purchase per order?	The transaction_id parameter on the purchase event	The value is compared against the real order id, in DebugView and in a next-day export	Whether a specific payment path produces a blank or repeated value that one test order didn’t hit
Do the browser and server Meta events for one purchase collapse into one conversion?	Meta Events Manager’s Test Events tool and Diagnostics tab	The same event_id and event name are confirmed on both the browser and server copy of one purchase, received inside Meta’s stated deduplication window	Whether the same event_id discipline holds across every order, not only the sample checked
Is only one purchase path active per order?	Shopify sales channels plus the custom pixel or GTM configuration	Confirm by inspection that the native Shopify sales channel and any custom pixel aren’t both sending the same purchase	If both are found active, whether GA4’s own transaction_id dedup is absorbing the overlap cleanly or missing some of it
Does the reconciled order count match Shopify’s ledger?	Shopify’s order export joined to GA4’s purchase export on transaction_id; Meta and Google Ads expose no per-order feed, so they are compared in aggregate	Orders are matched row by row on a shared identifier, not compared as totals	Why a given order is missing or repeated — the join shows which rows don’t match, not the mechanism behind them

What do consent and reporting explain, and what do they not?

Not every gap between a platform and Shopify’s orders is a defect. Consent choices, modeled traffic, and platforms that only report in aggregate all produce differences that look identical to a bug from inside a dashboard. This covers technical implementation, not legal advice.

Question	Source checked	How it is verified	What stays unknown after this check
Does the consent banner actually block or allow tags the way it’s configured to?	Consent Mode v2 signals (ad_storage, analytics_storage)	Review existing request captures for each consent choice, checking cookieless versus full payload; mark unverified if those captures are unavailable	Whether Google’s own modeling recovers denied traffic accurately — that happens inside Google’s systems, not in anything visible here
Is Unassigned traffic in a range consistent with this store’s consent setup?	GA4 Traffic acquisition report, Unassigned row	The percentage is read directly from the report for the checked period	There’s no fixed figure that marks Unassigned as “too high” for every store — this check reports the number, not a verdict on it
Does Meta’s Event Match Quality reflect what this store is actually sending?	Meta Events Manager Overview, EMQ score and parameter breakdown	The score and any listed missing or malformed parameters are read for the checked pixel or dataset	EMQ is a data-completeness score, not a measure of ad performance — a low score doesn’t mean the campaign itself is failing
Does Google Ads report conversions for the same window Shopify shows the orders in?	Google Ads conversion report versus Shopify orders, same date range	Aggregate conversion counts are compared for the window, since Google Ads exposes no per-order feed to read	Which specific orders sit behind any gap — an aggregate comparison can say a difference exists, not which orders it is

Conclusion and next step

Two honest answers come out of a checklist like this, and both are legitimate.

No defect found in the checked scope. The completed checks found no failure in the systems, orders and period reviewed. Record any unverified rows and remaining limits alongside that result. It does not certify all payment paths, historical coverage or attribution, and it does not establish that every reported number is correct.

Investigate further. One or more rows land in the fourth column with a gap that isn’t explained by consent, modeling, or aggregate reporting — a repeated transaction_id, a pixel that went silent, a server event with no matching browser event. That is a signal a specific cause is findable, not a verdict that it has been found yet.

Either way, the write-up I’d keep looks like the one in the worked example of this diagnostic method: what was checked, what it proved, and what it didn’t — on a fictional store, in the same format a real one would use.

Before a seasonal peak, my BFCM 2026 tracking readiness checklist puts these checks on a schedule, with a tag freeze and a review after the peak.

If a row here turns up something you can’t explain, the next step is to describe it, not to buy anything: get in touch with the store URL, which row failed, and what you saw. If the cause or scope genuinely needs a closer, read-only look beyond what you can check yourself with the access above, that is what the Health Check is for — not the default next step, only the one for when self-checking has reached its limit.