GA4 traffic dropped or spiked sharply after launch.
GA4 and GTM launch QA checklist
Protect your tracking when a website launches or migrates
A practical checklist for web developers, studios, ecommerce teams and in-house launch teams. Use it to reduce the risk of missing events, duplicated tags, broken journeys, lost campaign context and unreliable reporting when a site changes.
The checklist is free and ungated. MeasureNest can also provide independent pre-launch or post-launch GA4 and GTM QA where specialist validation is needed.
A working site does not guarantee working measurement
Tracking can break even when the launch appears successful
A new site can look correct, accept enquiries and process purchases while GA4 quietly loses important data. Templates change, selectors move, domains and checkout flows differ, consent behaviour is rebuilt, old tags remain active and new events are implemented without matching the reporting definitions people already use.
The safest approach is to treat analytics QA as a distinct launch workstream: define what must remain measurable, test it before launch where possible, validate it again in the live environment and record any limitations or follow-up actions.
Use this checklist when the change could affect how GA4 data is collected or interpreted
- New website launch or major redesign.
- CMS, ecommerce platform, theme or checkout migration.
- Domain, subdomain or cross-domain journey change.
- GTM container rebuild, tag migration or agency handover.
- Cookie banner or consent-management change.
- Form, booking, call, login, subscription or payment-flow change.
- New event names, key-event definitions or ecommerce implementation.
- Reporting or campaign-tagging changes introduced alongside the launch.
Free, ungated launch resource
GA4 Tracking QA Checklist for Website Launches and Migrations
Work through the risk scan, status guide and checklist categories before and after a new website launch, rebuild or migration. The objective is to identify whether GA4 and GTM still capture the journeys, outcomes and reporting context that matter.
Quick risk scan: signs launch tracking needs checking
These are not proof that tracking is broken, but they are strong signals that GA4/GTM should be checked after launch.
Leads, enquiries or purchases no longer broadly match the CRM, inbox or ecommerce platform.
Key events stopped firing after new templates, forms or checkout steps went live.
The GTM container was re-added, duplicated or moved during the build.
Thank-you pages, confirmation pages or form behaviour changed.
Payment providers, booking tools or third-party domains appear as referrals.
Google Ads conversions changed unexpectedly after launch.
UTMs or campaign landing URLs were changed, redirected or stripped.
Cookie banner or consent settings changed during the launch.
Nobody has tested GA4 after the launch using DebugView, Tag Assistant or GTM Preview.
How to use the checklist
Nothing obvious to investigate.
Evidence is incomplete or unclear.
Something appears missing, duplicated or implausible.
The item does not apply to this website.
Interpretation guide
- 0–2 issues: GA4 may be broadly usable, but still review after major launch, form, checkout or consent changes.
- 3–5 issues: launch tracking confidence is moderate. Prioritise checks linked to leads, purchases, paid media or client reporting.
- 6+ issues: GA4 should not be treated as launch-ready without a structured review.
- Any issue affecting leads, purchases, revenue or Google Ads conversions should be prioritised.
This guide is educational prioritisation, not a guarantee or formal scoring system.
The launch tracking QA checklist
Work through each section after a new website launch, rebuild or migration. The aim is to identify whether GA4 and GTM are still capturing the actions that matter.
What to check first after launch
Prioritise the checks that affect business outcomes, paid media and client reporting first.
Highest priority
Leads, purchases, revenue, key events, Google Ads conversions, form submissions, checkout journeys, consent behaviour and campaign attribution.
Medium priority
Event naming, landing page reporting, secondary enquiries, internal traffic, GTM documentation, dashboard fields and handover notes.
Lower priority
Minor naming inconsistencies, legacy events, low-value engagement tracking and historic issues that do not affect current launch reporting.
Do not wait for reporting problems to appear weeks later
Escalate these findings before the launch is treated as complete
MeasureNest can independently test the agreed journeys, document what appears to work, identify material gaps and define the next action before unreliable data becomes embedded in reporting.
Request launch tracking QA- The new site sends data to a different or unintended GA4 property.
- Important forms, bookings, purchases or lead actions no longer generate the expected events.
- Events fire more than once for a single action.
- Revenue, currency, transaction IDs or item data are incomplete or inconsistent.
- Consent choices produce unexpected collection behaviour.
- Cross-domain or payment journeys create unwanted referrals or broken sessions.
- Campaign parameters disappear or channel attribution changes unexpectedly.
- No one owns the final live-environment validation and handover.
Independent specialist validation
Need MeasureNest to QA the tracking rather than use the checklist alone?
Launch tracking QA is a scoped GA4 and GTM validation engagement for teams that need independent evidence around the measurement affected by a website launch or migration.
The work is shaped around the launch risk, the important journeys, the systems involved and the stage of the project. It can support a developer or studio before handover, an in-house team preparing for go-live, or a business that has already launched and now suspects that tracking continuity has been lost.
QA can be scoped before launch, after launch or across both stages
Before launch
Review the measurement plan, implementation readiness, test environment and agreed priority journeys before go-live. Pre-launch access and testability depend on the environment and project setup.
After launch
Validate the live site, real consent behaviour, production domains, real referrals and the end-to-end journeys that cannot be confirmed fully in staging.
Combined launch QA
Use pre-launch checks to reduce preventable risk, then complete a defined post-launch validation once the production environment is live.
Do not promise that every launch can be fully validated before go-live. Production-only behaviour, third-party payment journeys, live consent conditions and platform restrictions may require post-launch testing.
Focused on the measurement that matters to the launch
The final scope is agreed before work begins. Depending on the launch and available access, the QA may include:
- GA4 property, data-stream and domain continuity.
- GTM container deployment and relevant tag, trigger or variable behaviour.
- Base-page collection and duplicate-tag checks.
- Consent-banner and consent-related measurement behaviour.
- Forms, enquiries, bookings, calls, downloads, registrations or other priority lead actions.
- Events and key events used in operational or stakeholder reporting.
- Ecommerce product, cart, checkout, purchase, revenue, currency, transaction and item data where relevant.
- Cross-domain, payment-provider and unwanted-referral behaviour.
- Campaign parameters, source/medium continuity and obvious channel-reporting changes.
- Single-page application, route-change or template-specific behaviour where relevant.
- Debug and live-environment validation of the agreed journeys.
- Clear handover of findings, limitations, dependencies and required next actions.
The engagement does not attempt to test every page, every event or every possible user path unless that breadth is explicitly included in the agreed scope.
A usable QA record, not an unexplained list of tag observations
Typical output
- Confirmed scope and priority journeys tested.
- Summary of what appears to be working as expected.
- Material issues, inconsistencies and unresolved risks.
- Evidence appropriate to the finding, such as screenshots, debug observations or event examples.
- Severity or priority so the launch team can distinguish blockers from lower-risk follow-up work.
- Dependencies involving the developer, platform, consent setup or another supplier.
- Recommended next action and ownership.
- A concise handover suitable for the business, developer, studio or agency involved.
Implementation boundary
Launch tracking QA identifies and validates the agreed measurement. Hands-on fixes may be included only where they are explicitly scoped, access is appropriate and the required change sits within MeasureNest’s GA4/GTM capability. Developer, platform, data-layer, consent or third-party changes may remain with the relevant supplier.
Public scope boundaries
- It does not include website design or development.
- It does not include SEO migration management.
- It does not include accessibility, security, performance or general functional testing.
- It does not include legal advice on privacy, consent or compliance.
- It does not guarantee that every defect or future platform change will be identified.
- It does not recreate historic GA4 data that was not collected.
- Ongoing monitoring or post-launch support is not included unless separately scoped.
How launch tracking QA is scoped and delivered
Describe the launch
Share the website, expected launch or migration timing, platforms involved, priority journeys and who owns the website and analytics implementation. No passwords or platform access are required at enquiry stage.
MeasureNest confirms fit and timing
The requirement is reviewed to determine whether pre-launch, post-launch or combined QA is feasible and whether the issue is better handled as implementation support or a wider audit.
Scope, access and responsibilities are agreed
The included environments, journeys, systems, deliverables, timing, dependencies, access and price are confirmed before work begins.
The agreed QA is completed
MeasureNest tests the defined measurement in the available environment, records evidence and separates confirmed issues from limitations or items that cannot yet be assessed.
Findings and next actions are handed over
The launch team receives the agreed QA output, including blockers, lower-priority issues, dependencies and ownership. Any implementation or retesting beyond the agreed QA is separately confirmed.
For client launches and migrations
Add specialist analytics QA without taking on the measurement risk internally
MeasureNest can support agencies, developers, ecommerce specialists and studios where the client needs independent GA4 and GTM validation around a launch, but specialist analytics QA is not part of the core delivery team.
The scope, client relationship, access, communication route, responsibilities and handover are agreed before work begins. Support may be referral-based or delivered behind the scenes where appropriate; no white-label promise is assumed without explicit agreement.
Launch QA, implementation support, free review or wider audit?
Launch tracking QA
Use it when:
A website launch or migration creates a defined need to validate GA4/GTM continuity and priority journeys.
What it produces:
A scoped QA record, evidence, priorities, dependencies and handover.
Tracking & Implementation Support
Use it when:
A specific event, form, purchase journey, tag or implementation is already known to be broken or missing.
What it produces:
Agreed implementation changes, appropriate QA and handover.
Free GA4 Tracking Confidence Review
Use it when:
The concern is broader and you are unsure whether the current setup can be trusted.
What it produces:
A limited confidence assessment and concise written next step.
GA4 Clarity Audit
Use it when:
You need deeper evidence and prioritisation across the wider GA4 and relevant GTM setup.
What it produces:
A documented diagnostic, action plan and video walkthrough.
GA4 Tracking Confidence Checklist
Use it when:
You want a wider self-service assessment that is not tied specifically to a launch.
What it produces:
An ungated checklist covering broader tracking and reporting confidence.
Not dealing with a defined launch?
Use the broader GA4 confidence route instead
If the site is already established and the concern is simply that the GA4 data may be incomplete, duplicated or difficult to trust, start with the Free GA4 Tracking Confidence Review. For a self-service assessment, use the broader GA4 Tracking Confidence Checklist.
Frequently asked questions
Can MeasureNest check tracking before the site launches?
Potentially. Pre-launch QA depends on the availability and quality of the test environment, whether relevant journeys can be completed and whether consent, payment or third-party behaviour can be represented accurately. Some checks may still require post-launch validation.
Can you check the site after launch?
Yes. Post-launch QA is often necessary because production domains, live consent behaviour, real referrals, payment journeys and final deployment conditions may differ from staging.
Does launch tracking QA include fixing every issue?
No. The QA and any hands-on implementation are separately defined. MeasureNest may be able to complete agreed GA4/GTM fixes, while developer, data-layer, platform, consent or third-party changes may remain with another supplier.
Is this a full GA4 or GTM audit?
No. Launch tracking QA is bounded around the launch, migration and agreed priority journeys. Use the GA4 Clarity Audit where deeper evidence is required across the wider setup.
Can you work with our developer or agency?
Yes. The communication route, responsibilities, evidence and handover can be agreed around the project structure. MeasureNest does not assume control of the website build or the client relationship.
Do you need access when we first enquire?
No. Describe the launch, timing, systems and priority journeys first. Do not send passwords. The minimum appropriate access is agreed only after fit and scope are understood.
Is there a fixed price?
No universal price is published. A small post-launch check of defined lead journeys and a complex ecommerce migration across multiple domains require materially different preparation, access and testing. MeasureNest confirms the scope and quote before work begins.
Can launch QA recover data that was missed after go-live?
No. Tracking can be corrected for future collection, but GA4 data that was never collected cannot normally be recreated retrospectively.
Does this include general website QA?
No. MeasureNest focuses on GA4, GTM and related measurement. Functional, visual, accessibility, SEO, performance, security and broader website testing remain with the appropriate project specialists unless a specific analytics dependency is agreed.
Protect the measurement before handover
Request independent GA4 and GTM QA for your launch or migration
Share the site, expected timing, platforms involved and the journeys that must remain measurable. MeasureNest will review the requirement and respond with the appropriate pre-launch, post-launch or combined QA scope.