Checklist: verify a tracking setup before you trust it

Use this checklist after any tracking setup or change, and again every month. Each item is a statement you can prove true or false. The principle behind all of it: a tag that fires, a green check in a tool, or a server that answers with a 200 proves nothing on its own. A setup works when the data has landed where it was supposed to go, and you have looked at it there.

Keep these open while you work: Tag Assistant, GA4 Realtime and DebugView for the intended property, the CRM, the ad accounts, the browser's developer tools, and a real phone. Record the date and the result of every pass, so the next person knows what working looked like.

Phase 1: Tags are on every page

• The container ID appears twice in the source of every page (script and noscript), including landing pages, the thank-you page, and pages added since launch.
• The ID is the real container ID, not a placeholder such as GTM-XXXXXXX.
• Only one Tag Manager container loads, and no hard-coded Google tag or plugin sends data to the same measurement ID.
• The measurement ID in the container matches the data stream of the property the business actually uses.
• The container ID, measurement ID, property, and data stream are written down in a document the business keeps.
• A fresh visit from a phone shows up in GA4 Realtime in that property.

For a large site built from flat HTML files, a script that fetches every URL in the sitemap and counts the snippets is faster than checking pages by hand.

Phase 2: Each event fires once

• In Tag Assistant preview, each page load sends one GA4 page view.
• A successful form submission fires generate_lead exactly once.
• A submission that fails validation fires no lead event.
• If the lead event fires on a thank-you page, that page cannot be reached without submitting, and it is excluded from navigation and search results.
• A click on the phone link fires phone_click once, and a click on the email link fires email_click once.
• GA4's enhanced measurement form interactions option is off, or its events are kept out of the lead count.
• In DebugView, the same actions show the same single events with the expected parameters.

Phase 3: Key events are marked

• generate_lead and phone_click are marked as key events in GA4, and email_click is marked if email is a real lead channel.
• No page view, scroll, or engagement event is marked as a key event.
• The date the key events were marked is recorded, since marking does not apply to earlier data.
• In Google Ads, every conversion action has the intended primary or secondary status, and lead actions count one conversion per click.

Phase 4: A real lead goes through end to end

• A test form submission, made on a phone from a page other than the landing page, arrives wherever the business receives leads: the inbox, the CRM, or both.
• If the business gets text alerts for new leads, the test lead triggers one.
• The form handler keeps a copy of every submission, so a lead survives even if the notification email bounces.
• The test submission shows as generate_lead in GA4 Realtime.
• A real tap on the phone link, made on a phone outside preview mode, shows in Realtime as phone_click.
• The office knew the test was coming, and the test lead is marked or deleted so it never reaches a report or an upload.

Phase 5: The source reaches the lead record

• Landing with test values in the address (?gclid=TEST123&utm_source=test&utm_medium=cpc), clicking to a second page, and then submitting puts those exact values on the lead record.
• The landing page and referrer fields are filled in on the record.
• Closing the browser, returning later without the test values, and submitting again still carries the original source.
• The values land in fields on the CRM record, not only in the notification email.
• Phone leads get a source too, from a tracking number or a required lead source field in the CRM.

Phase 6: Consent behaves as designed

• Before any choice, Tag Assistant's Consent tab shows the intended default for every signal.
• After a rejection, no GA4 cookie and no click ID cookie is written, and tags gated on consent do not fire.
• After acceptance, the update shows as granted, and the gated tags and cookies appear.
• The choice persists across pages and visits, and the visitor can reopen it.
• Cookies written by a tagging server follow the same consent state as the browser.

The setup behind these checks is in Consent Mode and deletion requests.

Phase 7: The server-side container is healthy

• The tagging server's health endpoint returns 200, and an uptime monitor alerts when it stops.
• The HTTPS certificate on the tagging subdomain is valid and set to renew.
• In the browser's network panel, GA4 requests go to the tagging subdomain rather than directly to Google, and they return 200.
• Loading a page with a test click ID gets a response from the tagging subdomain that sets the click ID cookie.
• In Safari, that cookie's expiry date matches what the server set, not seven days.
• Events sent through the tagging server show up in GA4 Realtime.

The health check and the Realtime check answer different questions. The first proves the server is running. Only the second proves it is doing its job. Background on both is in server-side tagging.

Phase 8: Ad platforms are recording conversions

• Every Google Ads conversion action the business relies on is recording recent conversions and shows no warning in its status or diagnostics.
• Auto-tagging is on in Google Ads, and recent Google Ads visits show in GA4 under a paid channel, not as organic or direct.
• The latest offline conversion upload has no rejected rows, or every rejected row has a known cause that is being fixed in the CRM.
• For Meta, Events Manager shows the expected events arriving, and events sent from both the browser and the server share an event ID so each is counted once.

Phase 9: Monthly re-check

• A fresh test lead and a phone tap, run end to end, still reach Realtime and the CRM with the source attached.
• GA4 lead events, CRM leads, and ad platform conversions for the month are in the same range, and any large gap has an explanation.
• The container's version history shows no changes that nobody can account for.
• Pages added or rebuilt during the month carry the container snippets and the hidden form fields.
• The tagging server's uptime monitor shows no unexplained outages, and the cookie expiry in Safari still checks out.
• Offline conversion uploads ran on schedule, and their rejected rows were reviewed.
• The date and result of this pass are recorded.

Site edits, plugin updates, rebuilt forms, and browser changes break tracking without any warning. A monthly pass finds the break within weeks, instead of months later when someone asks why the leads dried up. The quickstart and the offline conversions guide cover how to fix what this checklist turns up.