Auditing Your Shopify Tracking in 30 Minutes: A Repeatable Checklist

Why a scheduled audit beats reactive troubleshooting

Most merchants only discover broken tracking when a number looks obviously wrong — ROAS suddenly at 40x, or conversions at zero for three days. By then, decisions have already been made on bad data, sometimes for weeks, because gradual tracking degradation (not a sharp break) is easy to miss in daily glancing. A scheduled 30-minute audit, run monthly at minimum and after any theme, app, or checkout change, catches degradation before it compounds into meaningfully wrong budget decisions.

Minute 0-5: Confirm the Web Pixel is installed and active

In Shopify admin, go to Settings > Customer events. This page lists all active pixels — both Shopify's app-managed pixels (installed automatically by apps like the Meta and Google & YouTube channels) and any custom pixels you've added manually. Confirm the pixels you expect are listed as Connected, not Disconnected or showing an error state. This single screen catches the single most common tracking failure: an app being uninstalled or disconnected weeks ago without anyone noticing, silently ending event delivery from that point forward.

Minute 5-10: Run a real test purchase

Use Shopify's test order capability (Settings > Payments > deactivate live payment temporarily, or use a Bogus Gateway on a development store, or simply use a real low-value product with a discount code for 100% off in a pinch) to walk through a full checkout. While doing this, open your browser's developer tools Network tab and filter for requests to facebook.com, google-analytics.com, or googleadservices.com to visually confirm pixel-fire requests are actually leaving the browser at the page_viewed, add_to_cart, and checkout_completed stages, not just present in the page's code.

Minute 10-15: Verify events arrive server-side

In Meta Events Manager (Meta Business Suite > Events Manager > your pixel/dataset > Test Events tab), confirm the test purchase appears within a minute or two, and check whether it's flagged as coming from Browser, Server, or both. If Conversions API is configured, you should see matching browser and server events with the same event ID, confirming deduplication is working. In Google Ads, check Tools > Conversions > your conversion action > recent conversions, which can lag by up to an hour, so this step may need a follow-up check rather than an instant confirmation.

Minute 15-20: Cross-check GA4 real-time report

Open GA4's Reports > Realtime view during or immediately after the test purchase and confirm the purchase event appears with the correct event parameters — item value, currency, transaction ID. This catches a specific, common failure mode: a purchase event that fires but with a missing or zero value, which won't show as 'no tracking' anywhere but will quietly corrupt every revenue-based report downstream. Check the event's parameters by clicking into it in the realtime report, not just confirming the event name appears.

Minute 20-23: Check for duplicate event firing

A less obvious but common issue is a purchase event firing twice from the same page load — often caused by a theme customization or a second marketing app both implementing their own tracking calls redundantly. In the GA4 DebugView (Admin > DebugView, with the GA4 Debugger Chrome extension enabled during your test purchase) you can see every event fired, in sequence, including duplicates that wouldn't be obvious from aggregate reports alone. If checkout_completed or purchase fires twice, identify which app or script is double-firing and disable the redundant one.

Minute 23-26: Verify UTM parameters survive to purchase

Load your store with a test URL containing UTM parameters (e.g., ?utm_source=test&utm_medium=audit&utm_campaign=trackingcheck), browse to a product, and complete a test purchase without closing the tab. Then check that order's attributes in Shopify admin (Orders > the specific order > scroll to see referring site/UTM data if displayed, or check via the Shopify Order API/admin GraphQL if not visible in the UI) and confirm the campaign parameters made it through the full session rather than being dropped by a redirect, an app's checkout modification, or a multi-domain checkout flow.

Minute 26-28: Reconcile a real week's numbers

Pull last week's purchase count from Shopify Analytics, GA4's Ecommerce purchases report, and your primary ad platform's reported conversions for campaigns you know drove traffic that week. They won't match exactly — expect GA4 within a few percent of Shopify's true order count, and platform-reported conversions to vary more due to attribution windows — but a gap wider than roughly 15-20% between GA4 and Shopify's actual order count specifically warrants investigation rather than being written off as normal attribution variance.

Minute 28-30: Check consent banner behavior

If you serve EEA, UK, or other consent-regulated traffic, load the storefront in a fresh incognito window from a VPN or browser location set to a relevant region, decline all optional cookies in the consent banner, and confirm (via the Network tab again) that marketing pixel requests are actually suppressed or reduced as expected, not firing regardless of the consent choice. A consent banner that visually shows a decline option but doesn't actually gate the underlying tracking calls is both a compliance risk and, ironically, a sign your 'consented' analytics numbers might be inflated by users who never truly opted in.

What to do when the audit finds a problem

Document exactly what broke, when it likely started (check GA4's historical trend for the specific event to estimate the onset date), and what data range is now unreliable. Don't try to retroactively 'fix' the historical data — instead, note the affected date range clearly in whatever reporting or decision-making process relies on it, so past comparisons don't silently assume broken-period data is trustworthy. Then fix the root cause (reconnect the app, remove the duplicate script, correct the consent gating) and re-run the relevant portion of this checklist to confirm the fix worked before considering the audit closed.

Building this into a recurring calendar habit

The most effective version of this checklist is the one that actually gets run. Put a recurring monthly calendar reminder tied to a specific day (like the first Monday of the month) rather than an open-ended 'do this sometime' intention, and additionally trigger an ad-hoc run any time you install a new app, change your theme, or modify checkout customization — these are the events most likely to silently break something in the customer events pipeline. Keeping the audit to a strict 30 minutes, using this same fixed sequence each time, is what makes it sustainable to actually repeat monthly rather than skipped when things feel busy.

For merchants using Adsify, a working, verified tracking setup is the precondition for everything the app does downstream — the optimizer's six-hour adjustment cycle and profit/POAS calculations are only as good as the conversion events feeding them, so running this audit before trusting a sudden change in reported performance (good or bad) is worth the 30 minutes every time, not just when something already looks broken.