A Google Tag Manager audit, from tag to recorded event
A useful audit follows a real action all the way into the reporting platform. This checklist covers the container, the data behind each event and the evidence needed to sign off a fix.
Decide what the numbers should represent
A container can fire every tag successfully and still count the wrong thing. Before opening Google Tag Manager, write down the business action being measured: a completed order, a submitted enquiry or a booked appointment. A click on a submit button is a different event from an accepted form submission.
List the domains, destination accounts and journeys in scope. Record the published container version and any unpublished changes. Test the live version first; a workspace draft may contain fixes that visitors have never received.
- Get read access to the relevant containers and reporting properties.
- Agree test data and a safe test journey with the site owner.
- Record the expected event name, destination and key parameters.
- Keep a container export or version reference before changing anything.
Download the GTM audit worksheetCSV · opens in a spreadsheet · no sign-up
A checklist for the complete event journey
Work through each important journey with GTM Preview and Tag Assistant. Keep the browser Network panel open alongside it. Tag Assistant explains the container's decisions; a network request shows what the browser actually attempted to send.
Inventory every installation
Record container IDs and destination IDs. Look for tracking added by a site plugin, theme or embedded form as well as GTM. Two installations are not automatically wrong, but two copies of the same event need an explanation.
Check the trigger against the outcome
Complete the successful journey, then try its failure case. A form with missing required fields should not count as a submitted enquiry. Check a second interaction without reloading, and browser back navigation where relevant.
Read the values at the event
Inspect the data layer at the exact event that fires the tag. Check field names, types and whether a value arrives too late. Google's data layer documentation explains event ordering and why resetting the data layer can remove earlier information.
Inspect the outgoing payload
Match the destination and event name to the measurement plan. For an order, check the transaction identifier, value and currency against the test order. Search URLs and event parameters for email addresses, names and other unintended personal data; Google's PII guidance describes common leaks.
Trace server-side forwarding where present
Use the server container's preview to follow the incoming request, the client that claims it and the outgoing tags. Compare the browser event with the forwarded payload. A request reaching a first-party endpoint does not prove a destination accepted it.
Check receipt in the destination
For GA4, use DebugView with debug mode enabled and suitable consent. Confirm the expected parameters as well as the name. Consent and privacy controls can prevent debug events appearing, so an empty view alone does not identify the fault.
Look for repeat sends
Compare requests from GTM, site plugins and direct platform integrations. If browser and server both send to the same platform, inspect that platform's deduplication mechanism. Do not apply Meta's event identifiers as a universal rule for every destination.
Check reporting definitions
Verify which actions count as key events or conversions in each destination. A clean transport path cannot resolve two reports using different definitions, attribution settings, time zones or reporting delays. Record those differences before calling the remaining gap a tagging error.
The server-side tracking guide explains the extra processing stage. For customer-data matching, use the separate enhanced conversions reference.
Test decisions, not just the banner
Use a clean browser context for each starting state. Record all four Google consent signals before relevant tags run and after each choice. The expected behaviour depends on whether the implementation uses basic or advanced mode; a denied state does not always mean zero network requests.
| Visit | Check |
|---|---|
| No saved choice | Defaults arrive before the tags they govern. Behaviour matches the agreed mode. |
| Reject | The choice reaches the tags. Inspect storage and requests, including non-Google tags. |
| Accept | Only the selected categories are granted. The intended journey still records correctly. |
| Return visit | The saved choice is restored before collection begins. |
| Change a choice | The updated decision reaches the relevant tags without requiring a new visit. |
Google's consent implementation reference covers defaults and updates. The Consent Mode guide on this site goes into the signals and verification steps. This checklist tests implementation; the site's consent requirements must be established separately.
Write findings that another person can act on
For each finding, record the URL, browser, consent state, container version and steps to reproduce. Attach a redacted payload or screenshot, the expected result and the observed result. Assign an owner and a retest condition.
| Priority | Observation | Retest condition |
|---|---|---|
| High | A failed form validation sends a lead event. | Only an accepted submission creates the agreed event. |
| High | The same purchase is sent by a plugin and a GTM tag. | One intended event path remains, or documented deduplication is verified. |
| Medium | A report's event parameter is missing on one page template. | Both templates populate the agreed value at send time. |
Priorities depend on the business impact. Unintended disclosure of personal data or collection outside the agreed consent behaviour needs immediate attention. A naming inconsistency can wait behind a broken primary conversion.
Retest the published version
Keep audit findings separate from proposed changes. Test fixes in a workspace, publish through the agreed approval process, then repeat the important journeys without preview mode. Record the version deployed and any remaining limitations.
The completed worksheet should distinguish passed checks, failed checks and checks that could not be completed. Missing access is an open question, not a pass. Include enough evidence that someone else can repeat the result after the next site release.
I offer written tracking audits and implementation work. The guide index covers individual parts of the setup in more detail.
Questions about running the audit
Can a GTM audit be completed with read-only access?
Read access supports an inventory and review of the published configuration. Testing workspace drafts and validating destination data may need additional permissions. Record any access limit in the findings so the report does not imply that an untested path passed.
Does a tag firing successfully prove the conversion was recorded?
No. It shows that the tag executed in the container. The outgoing request, its payload and receipt in the intended platform still need checking. Reporting configuration can introduce another difference after collection.
Should unused tags be deleted during the initial audit?
Document them first and check their purpose with the owner. A tag that did not fire during one test may serve another journey or a seasonal campaign. Any removal needs a recorded version and a way to restore it.