Data and tracking

Tracking audit: a checklist for finding broken signals

A practical checklist for inventorying tags, testing user journeys, isolating failures, and documenting tracking fixes clearly.

By Anderson, who leads Natander. Editorial reading, with no promise of results

Define the scope before opening any tools

A tracking audit is not a generic hunt for tags. It determines whether specific signals move through a defined journey and can support a decision. List pages, forms, buttons, phones, campaigns, domains and destinations involved. For each path, record the expected event, purpose, confirmation source, and risk if it fails. This scope prevents the team from declaring tracking “complete” after testing only the homepage or a single browser. The scope should also state what will not be examined so the conclusion is not treated as a guarantee for the entire digital operation.

Keep the audit separate from optimization work. The audit describes the observed state, evidence, and gaps; a remediation proposal can follow with the appropriate approval and priority. If the team changes tags during the inspection, record the change and rerun the affected test. Without a baseline, it is impossible to know whether the problem already existed or whether it was introduced by the investigation itself. The recorded sequence allows repeating the case after a change and comparing the behavior before and after, keeping the investigation verifiable.

  1. List critical journeys, pages and integrations in the scope.
  2. Set expected event and operational source for each step.
  3. Separate diagnosis from production changes.
  4. Register baseline before fixing any item.

Inventory the actual implementation

Inventory containers, properties, data streams, conversions, pixels, embedded scripts, consent settings, and server-side integrations. The inventory should identify the owner, environment, purpose, status, and most recent known revision. Don't just trust the old documentation: themes, plugins, agencies, and platforms can add code through different paths. Check the HTML delivered, active settings and permissions that allow you to publish changes. The scope should also state what will not be examined so the conclusion is not treated as a guarantee for the entire digital operation.

Then compare the inventory with the measurement plan. Tags without associated questions deserve investigation, but should not be removed without knowing dependencies. Duplicate events, similar names, and conversions imported more than once can produce contradictory numbers. Mark each divergence as confirmed, probable or not yet verified. This classification prevents a hypothesis from being reported as a proven defect. The recorded sequence allows repeating the case after a change and comparing the behavior before and after, keeping the investigation verifiable.

  1. Catalog tags, events, conversions, scripts and integrations.
  2. Register owner, environment, purpose and publication access.
  3. Compare active implementation with measurement plan.
  4. Classify each discrepancy by its level of evidence.

Test the journey and observe each layer

Run controlled tests for page load, consent, clicks, submissions, redirects, and confirmation. Observe the data layer, debug modes, network requests, and receipt in the destination tool. Use test identifiers and write down time, URL, device, and consent status. An isolated screenshot does not replace the sequence: the same event can appear in the interface and fail in later processing. The scope should also state what will not be examined so the conclusion is not treated as a guarantee for the entire digital operation.

Repeat cases that may expose duplication or data loss: reloads, browser back navigation, invalid submissions, blocked scripts, network delays, and handoffs to external domains. Do not use real personal data unnecessarily to validate a configuration. If validation depends on customer service or a sale, use an authorized test flow and preserve the distinction between technical evidence and a business outcome. The recorded sequence allows repeating the case after a change and comparing the behavior before and after, keeping the investigation verifiable.

  1. Test loading, consent, action and destination confirmation.
  2. Log the time, URL, device, and test identifier.
  3. Repeat reload, delay, error and external domain when applicable.
  4. Use controlled and authorized data during validation.

Turn findings into a verifiable plan

Each finding should state what was observed, its potential impact, the evidence supporting the conclusion, and who needs to decide. “Low conversions” is not a root cause: it may reflect a missing event, a consent rule, a broken destination, low volume, or unrecorded customer-service activity. Write down the affected layer and the minimum correction that can be tested. Prioritize by risk, dependencies, and effort—not simply by the number of tags involved. The scope should also state what will not be examined so the conclusion is not treated as a guarantee for the entire digital operation.

After the correction, repeat the original test and record the result. Update inventory, documentation, access and revision date. If the failure cannot be reproduced, keep the item as unconfirmed and follow additional evidence. A properly closed audit makes the system more observable; it does not promise perfection. The next cycle must begin with critical points and recent changes. The recorded sequence allows repeating the case after a change and comparing the behavior before and after, keeping the investigation verifiable.

  1. Describe evidence, impact, layer, responsibility and priority.
  2. Set a minimum correction with acceptance criteria.
  3. Rerun the original test after publishing the change.
  4. Update the inventory and record unconfirmed findings.

Reference sources

Want to identify the bottleneck before investing?

Natander connects your website, media, content, and data in a focused diagnostic, with documented priorities and clear limits.

Request a diagnosis
Menu
Request a diagnosis