Home›Tracking audit

How to audit your marketing tracking: the complete checklist

By Sam ParkinsonUpdated 18 September 202611 min read

A website can look completely healthy while the data underneath it is wrong. The ads keep running, the dashboards keep loading, and a conversion quietly stops being counted. This is the audit we run, written down so you can run it yourself.

Before you start: write down what "right" means

You cannot audit tracking against nothing. Spend ten minutes writing a one-page tracking plan, even a rough one:

• Which platforms should receive data: GA4, Google Ads, Meta, TikTok, a CRM, anything else.
• Which events matter for each: usually purchase first, then begin_checkout, add_to_cart, view_item, and any lead events.
• How each is installed: hardcoded, Google Tag Manager, a platform integration (for example Shopify's Google & YouTube channel), a server-side container.
• Your source of truth for orders: the store admin, the payment processor, the back office.

If you find you cannot answer the third point, that is already your first finding. Tracking that nobody can describe is tracking that nobody will notice breaking.

Step 1: inventory every tag on the site

Open the site in a clean browser profile with no extensions that block scripts, and list every marketing and analytics tag you can find:

1. View the page source and search for G- (GA4), GTM- (Tag Manager), AW- (Google Ads), fbq( or fbevents.js (Meta), and UA- (the retired Universal Analytics).
2. Open developer tools, go to the Network tab, reload, and filter for collect, google, facebook, tiktok. This catches tags that load dynamically and never appear in the source.
3. If you use Tag Manager, open the container and list every tag and its trigger. Paused and forgotten tags are common.
4. Check the platform's own integrations (Shopify's apps and sales channels, a WordPress plugin) which often install tags without anyone touching code.

You are looking for three failure patterns: the same platform installed twice (a hardcoded GA4 plus a GA4 in Tag Manager plus a platform integration), a platform you pay for with no tag at all, and dead tags such as Universal Analytics, which Google stopped processing in 2023.

Step 2: complete one real test purchase per platform

Presence is not proof. The only way to know the purchase event works is to buy something and watch it arrive. Use a discount code or a low-value product and refund it afterwards. With the order in progress, have these open:

• GA4 DebugView (Admin › DebugView), or Google's Tag Assistant in debug mode. See the GA4 audit guide.
• Meta Events Manager › Test events, or the Meta Pixel Helper browser extension. See the Meta Pixel audit guide.
• Google Ads conversion diagnostics, plus Tag Assistant for the AW- tag. See the Google Ads conversion guide.

Walk the whole path: product page, add to cart, checkout, payment, confirmation. For each platform, write down which events arrived and which did not. A path that goes view_item, add_to_cart, begin_checkout and then nothing is the single most common result, and it means the purchase is not connected to the checkout.

Step 3: check the payload, not just the event name

An event that arrives empty is almost as bad as one that never arrives. Click into the purchase event on each platform and check:

The classic silent bug is a price or value sent as a string, "49.99" instead of 49.99. It looks right to a human and is wrong to the platform. dataLayer testing covers how to catch this systematically.

Step 4: look for duplicates

Double counting is worse than under-counting, because it flatters the exact metric you scale spend on. Signs of duplication:

• Two purchase events for one order in DebugView or Test events.
• A platform reporting more purchases or revenue than the store actually took.
• Refreshing the order confirmation page sends the purchase again.
• Google Ads counting the same sale from both its own tag and an imported GA4 key event, with both set as primary.

Step 5: test with consent in its default state

If the site shows a cookie banner, run the test purchase again in a private window without accepting, and once more after rejecting. Record what each platform receives. Two things can be wrong: tags firing before consent when they should not, or nothing at all being sent when your setup (for example Google Consent Mode) is meant to send cookieless signals. Testing only after clicking "accept" hides both.

Step 6: reconcile against real orders

Pick a closed window, such as last week, and compare the order count and revenue in your store against GA4, Google Ads and Meta for the same dates and timezone. Expect differences, and know why each exists:

• GA4 loses some purchases to ad blockers and refused consent, and takes up to 48 hours to finish processing.
• Google Ads reports conversions against the date of the ad click by default, not the date of the sale, and only counts ad-driven conversions.
• Meta includes view-through conversions in its default attribution setting, so it can legitimately claim sales that other tools do not.

A stable gap you can explain is fine. A gap that changed suddenly, or a platform that shows more sales than you made, is a fault. Note the date it changed and check what was deployed that day.

Step 7: check what happens after a change

Almost every tracking failure has the same origin: something else changed. A theme update, a new app, a rebuilt checkout, a consent banner update, a Tag Manager publish. Finish the audit by writing down how you will know next time. At minimum, repeat step 2 after every change to the purchase path. Conversion tracking QA turns this into a repeatable test plan, and tracking monitoring covers automating it.

The checklist in one place

1. Tracking plan written: platforms, events, install method, source of truth.
2. Every tag inventoried; no duplicate installs; no dead Universal Analytics.
3. Every platform you pay for has a tag.
4. Test purchase: purchase arrives in GA4, Meta and Google Ads.
5. Payload: value, currency, transaction_id and items present and correctly typed.
6. Exactly one purchase per order on every platform; confirmation-page refresh does not re-send.
7. Consent: default, accepted and rejected states each behave as designed.
8. Reconciliation: gaps against real orders are stable and explained.
9. A named trigger for re-testing after every change.

How AuditTag handles it

Doing this by hand once is manageable. Doing it after every deploy, across every template, is where it stops happening. AuditTag automates the parts that can be automated honestly, and is explicit about the parts that cannot.