Tracking QA checklist: what to test before you launch a site or campaign

Most tracking failures do not start in the analytics tool. They start on launch day, when a new template moves the element a tag was reading, a new form replaces the one with working hooks, or a redirect quietly strips the campaign parameters. A short QA pass before traffic arrives is far cheaper than explaining a broken month of reporting.

Why launches break tracking

Launches change the parts of a site that tracking depends on. New templates rename or move the elements that tags read. New forms may not carry the hidden fields that hold UTMs and click IDs. Redirects can drop query parameters on the way to the landing page. Consent banners can block tags that load too late, or never load for a visitor who rejects. New domains split sessions and break the handoff to a booking or checkout tool. Each of these is testable before launch, so test them.

1. Plan: name the key events and owners

Write the measurement plan first. A test with no expected destination cannot fail, so every key event needs a name, an owner, and a list of the places it should be counted.

1. 1Each key event has a name, a plain-language trigger (for example, a demo form submit), and one owner.
2. 2For every event, list where it is counted: GA4, Google Ads, Meta, LinkedIn, the CRM, or a combination.
3. 3Mark one primary conversion and label the rest as secondary or diagnostic.
4. 4Write the expected count for one test action of each event.
5. 5Record the launch date and the person who can approve a rollback.

2. Tag configuration: one tag of each kind

Confirm the container and the IDs before testing any event. Most duplicate-count problems start here, with two copies of the same tag firing on the same page.

1. 1Record the live Google Tag Manager container version, with its version name and publish date, in the QA log.
2. 2Confirm the production GA4 measurement ID matches the production property, and that staging environments send to a separate property or do not send at all.
3. 3Check for a hard-coded gtag snippet loaded alongside GTM. If both load the same Google tag, pageviews and events can count twice.
4. 4Confirm each ad pixel (Google Ads tag, Meta Pixel, LinkedIn Insight Tag) loads once per page, whether from GTM or from the site code, not both.
5. 5View the page source and the network requests on a key page to confirm the tags you expect are present and the ones you do not expect are absent.

3. Consent: test both answers

Consent decides what fires for a visitor who says no. Test the reject path as carefully as the accept path, in a fresh browser session with storage cleared, so that earlier choices do not affect the result.

1. 1The consent management platform loads before any tag that depends on consent.
2. 2Before the visitor makes a choice, no non-essential tag fires.
3. 3The Consent Mode v2 signals ad_storage, analytics_storage, ad_user_data, and ad_personalization update to match the visitor’s choice.
4. 4On accept, the signals update and the dependent tags fire as designed.
5. 5On reject, nothing that needs consent fires. Check the network requests, not only the tag list.
6. 6Document the default consent state applied before a choice is made, and confirm it matches your policy decision.

4. Events and parameters: fire each one and watch it arrive

Perform each key action yourself and follow it through Google Tag Manager Preview mode, which shows the tag and trigger firing, and GA4 DebugView, which shows the event and its parameters arriving.

1. 1Each key event fires once per action. Submit the form once, load the confirmation page once, and count the events.
2. 2Parameters such as value, currency, form_id, and lead type carry the values you expect, not blanks, undefined, or placeholder text.
3. 3Purchase and transaction events carry a transaction_id that is unique per order.
4. 4A failed or invalid submission does not fire the success event.
5. 5Each event appears in GTM Preview with the trigger you planned, and in GA4 DebugView with the same parameters.

5. Attribution inputs: keep the source through the journey

Attribution starts at the landing page. If a redirect or a form drops the UTMs or click IDs, the lead reaches the CRM with no source, and the report falls back to direct or unassigned. Check the path from the ad to the CRM record, not only the landing page.

1. 1Click a tagged test link through every redirect and confirm the UTM parameters arrive on the landing page.
2. 2Confirm gclid, fbclid, and msclkid from a test click are present on the landing page and persist through the session.
3. 3Check the hidden form fields on each form. They should capture the UTM and click ID values into the form submission.
4. 4Submit a test form and confirm the CRM record stores those values in the source fields defined in the plan.
5. 5Visit directly with no parameters and confirm the source fields are blank or set to your documented default, not carried over from an earlier session.

6. Cross-domain and thank-you pages

Checkout and booking flows on a separate domain break sessions unless the cross-domain linker is configured on both sides. Thank-you pages are the other common source of inflated numbers: if search engines index them or anyone can load them directly, they can be counted as conversions that never happened.

1. 1Every domain in the flow (the marketing site, the booking tool, the checkout) appears in the cross-domain configuration.
2. 2Move from the site to the booking or checkout domain and confirm the session continues rather than starting over with a referral source.
3. 3Thank-you pages are not indexable: they carry a noindex directive and are not linked from public navigation or the sitemap.
4. 4Load a thank-you URL directly in a new browser session and confirm the conversion tag does not fire on a bare page load.
5. 5Confirm each conversion tag fires once, on the page the platform expects, and not on every page of the flow.

7. Ad platforms: set conversions on purpose

Each ad platform counts conversions by its own rules. Set the primary and secondary actions deliberately, and when a pixel and a server-side connection both send the same event, make sure the platform can deduplicate them. Check the current platform documentation for the exact setup steps, since interfaces change.

1. 1Google Ads conversion actions are marked primary or secondary on purpose, and the primary actions match the plan.
2. 2Meta events are tested in Events Manager’s test view, with the expected event names and parameters showing.
3. 3When the Meta Pixel and the Conversions API both send an event, both carry the same event_id so Meta can deduplicate them.
4. 4Each other platform that accepts both browser and server events has a matching identifier on both sides.
5. 5A test conversion appears in each platform’s diagnostic or test view. Standard reporting can lag, so do not rely on it for the launch-day check.

8. CRM and offline: follow a test lead to the end

The last hop is the CRM. A test lead should arrive with its source fields, and every stage change should be timestamped so that time-to-stage can be measured later. Use a test address you control, and mark the record so it stays out of sales queues and reporting.

1. 1Submit a test lead with a clearly marked test name and an address you control. Confirm it appears in the CRM.
2. 2The CRM record stores the source, medium, campaign, and click ID fields defined in the plan.
3. 3Move the test lead through one stage change and confirm the change is recorded with a timestamp.
4. 4Test records are tagged or excluded so they do not reach pipeline reporting or a sales team queue.
5. 5If conversions are uploaded back to an ad platform, send one test conversion and confirm it matches the expected click ID.

9. After launch: the first 72 hours and the first week

The windows below are our recommendations for how to run a launch review, not platform requirements. Adjust them to your traffic volume and sales cycle. The goal is to find breakage while it is small.

1. 1In the first 72 hours, compare GA4 key events, CRM leads, and ad platform conversions for the same days. Some mismatch is expected; zeros and sudden spikes are not.
2. 2Check every key event daily for a zero, which usually means a broken tag or a changed form, and for a spike, which often means duplicate firing.
3. 3In the first week, reconcile the counts against the expected source mapping and log every gap with a reason.
4. 4Annotate the launch date in GA4 and in the change history of each ad platform, so the step change is explainable in later reports.
5. 5Name an owner to review the QA log at the end of week one, and close or escalate each open item.

Keep a QA log for every launch

One row per check is enough. Fill in the actual result when the check runs, not from memory afterward. A log like this turns a launch into evidence the next person can read.

To see why counts drift after launch, read the common tracking mistakes guide, the server-side tag management primer, and the dynamic UTM parameters guide. For the cross-platform side, see why your numbers never match between platforms and, for ongoing measurement support, our digital analytics service. If you want a launch reviewed before traffic arrives, book a tracking audit and we will walk the plan, the tags, and the CRM handoff with you.