Skip to content
Tracking SOP

Testing & Debugging Methodology

The exact sequence used to verify every single tag in this build — the default procedure for anything new built from this reference.

General Testing Sequence

  1. 1.Always start with a genuinely fresh session — fully close any existing Tag Assistant connection, use a fresh Incognito/private window for the site itself. Stale sessions produced several false-negative dead-ends throughout this build.
  2. 2.Connect Tag Assistant (tagassistant.google.com) to the live site.
  3. 3.Test the pre-consent state first: before accepting the cookie banner, check which tags fire — only Google’s own tags (GA4, Google Ads base) should fire; every non-Google tag (Clarity, LinkedIn, Meta) should NOT.
  4. 4.Accept the cookie consent banner.
  5. 5.Re-check: every consent-gated tag should now also appear in "Tags Fired."
  6. 6.Perform the actual action being tested (submit the form, click the call/WhatsApp link, etc.).
  7. 7.In Tag Assistant, click into the specific fired event, then the specific tag — check its "Tag Details" panel.
  8. 8.Critical: confirm the "Display Variables as" toggle is set to "Values," not "Names," before concluding any data field is empty or broken.
  9. 9.Cross-check in the destination platform’s own tools where possible: GA4 Realtime/DebugView, Meta’s Test Events tool, LinkedIn’s own campaign reporting, Google Ads’ Diagnostics tab — a tag showing "Fired" in GTM is necessary but not sufficient proof; confirming the data actually landed on the platform’s own side is the real test.
  10. 10.One documented, known exception: the native Google Ads Conversion Tracking tag type has a confirmed tendency to show "Failed" in GTM Preview even when it genuinely succeeds — don’t chase this specific tag type’s "Failed" status without corroborating evidence from Google Ads’ own side first.
  11. 11.If a screenshot-based comparison across multiple page loads gets ambiguous, request/export Tag Assistant’s raw JSON and parse it directly (group by groupId, extract exact eventName per message) rather than continuing to compare dense screenshots.

Debugging Technique — the "Names vs Values" toggle

  1. 1.A fired tag’s Advanced Matching data appeared completely empty when checked in Tag Assistant — looked like a genuine data-population bug. Actual cause: Tag Assistant’s tag-detail panel has a "Display Variables as: Names / Values" toggle — "Names" mode shows the variable reference (e.g., DLV - user_email), not the actual resolved data. Always confirm this is set to "Values" before concluding data isn’t populating correctly.

Debugging Technique — parse raw Tag Assistant JSON exports directly

  1. 1.When comparing multiple page loads/events precisely (did event A fire before or after event B, across which page groups), Tag Assistant’s own JSON export can be parsed programmatically far more reliably than reading dense, easy-to-misread screenshots. Group messages by their groupId to reconstruct actual page-visit timelines, and extract exact eventName/parameter values per message.

Testing Discipline — always remove Test Event Codes before considering a build production-ready

  1. 1.Meta’s Test Event Code mechanism (used to verify CAPI events in the Test Events tool) deliberately excludes every event carrying that code from real reporting and ad optimization.
  2. 2.A tag can be technically "working" and firing correctly while still silently contributing zero real data, simply because a test code was left in place after testing concluded.
  3. 3.Always explicitly clear this field and republish before considering any CAPI or Pixel tag genuinely production-ready — caught and fixed more than once across this build’s history, an easy step to forget precisely because the tag looks and behaves correctly while the code is still in place.