Already launched and something looks wrong?
Start with what changed.
| After-launch symptom | First area to investigate |
|---|---|
| GA4 traffic suddenly fell or increased | Base tracking, consent, template coverage and whether real traffic changed |
| Leads stopped appearing | Form success behaviour, events and GTM implementation |
| Purchases or revenue fell | Ecommerce purchase events, checkout measurement and consent |
| Conversions suddenly increased | Duplicate tags, events or parallel implementations |
| Traffic sources changed unexpectedly | Redirects, UTMs, referrals and cross-domain measurement |
| Data changed after the cookie banner changed | CMP and Consent Mode behaviour |
| One template or page type has little data | Tag deployment across templates |
| Dashboards still run but the numbers changed | Event names, URLs, definitions and reporting dependencies |
These symptoms are not proof that tracking is broken.
They are signals that the change should be investigated rather than assumed to represent genuine business performance.
A website launch is especially useful diagnostically because it gives you a known change point:
before launch -> deployment -> after launch
If the measurement changes sharply at the same point, the implementation deserves attention.
Treat analytics as its own launch workstream
Tracking QA should not be an afterthought to functional website testing.
A sensible launch process is:
Define what must remain measurable
↓
Test what can be tested before launch
↓
Verify the production deployment
↓
Test real journeys after launch
↓
Compare GA4 with actual business outcomes
↓
Document what is reliable, unresolved or needs fixing
Some measurement can be tested effectively in staging.
Some cannot.
Production-only domains, live consent conditions, payment providers, third-party forms and real referral behaviour may only be fully testable after go-live.
The aim should therefore be continuity and evidence, not a false promise that every measurement risk can be eliminated before launch.
What to check before launch
Before go-live, establish what the business needs to preserve.
That normally means prioritising the outcomes that affect decisions, rather than trying to test every analytics event equally.
Define the priority journeys
Identify the most important actions on the existing and new website.
Examples include:
- enquiries;
- quote requests;
- bookings;
- registrations;
- ecommerce purchases;
- subscriptions;
- downloads where commercially meaningful;
- important cross-domain journeys.
Document how those outcomes are currently measured and whether the new site changes any dependency they rely on.
Identify tracking dependencies that are changing
A redesign or migration may alter:
- URLs;
- page templates;
- DOM elements and selectors;
- form technology;
- confirmation pages;
- checkout platform;
- data-layer events;
- domains and subdomains;
- cookie banner or CMP;
- GTM container;
- CMS plugins or native integrations.
The tracking risk is usually concentrated where the underlying implementation changes.
Confirm the intended GA4 and GTM setup
Before launch, establish:
- which GA4 property and web stream should receive data;
- which Measurement ID is correct;
- which GTM container should be deployed;
- whether any old tags or integrations are being retired;
- which events should remain stable;
- which definitions intentionally change.
Google recommends checking existing Google tag implementations before adding new ones because redundant configurations can cause conflicting settings or duplicate data.
Test the priority journeys where the environment allows it
A staging site may allow useful checks of:
- form success events;
- key events;
- ecommerce data-layer structure;
- purchase event configuration;
- GTM trigger behaviour;
- basic consent behaviour;
- event names and parameters.
But record what cannot yet be established.
A successful staging test is not evidence that production will behave identically.
What to check immediately after launch
The first post-launch checks should focus on material measurement risk.
1. GA4 and GTM foundations
Check whether:
- GA4 is collecting on the live domain;
- the correct property, stream and Measurement ID are being used;
- the intended GTM container is present;
- old and new implementations are not both active;
- important templates actually contain the intended tracking;
- Realtime, DebugView, Tag Assistant or GTM Preview behave as expected;
- launch testing and internal traffic are understood.
Warning signs
- page views are dramatically higher or lower than expected;
- particular templates have little or no data;
- multiple GA4 configurations appear on the same page;
- nobody can confirm which container or implementation is authoritative.
2. Leads, forms and other key outcomes
The new website may visually submit a form correctly while the associated analytics event has stopped working.
Check whether:
- commercially important forms have been tested;
- successful submissions are distinguished from form starts or button clicks;
- event names still represent the intended outcome;
- the same lead is not measured more than once;
- thank-you pages or success messages still behave as expected;
- embedded and third-party forms still expose the required success signal;
- GA4 lead volumes broadly reconcile with the operational source.
Google's Enhanced Measurement can collect form interaction events, but the implementation still needs to be validated against the actual business outcome being measured.
If real submissions are reaching the business but GA4 is missing them, use the dedicated GA4 form submissions not tracking diagnostic rather than treating the launch page as a complete form-tracking tutorial.
3. Ecommerce measurement
For ecommerce websites, post-launch QA should confirm that purchases and revenue still make commercial sense.
Google Analytics ecommerce reporting depends on ecommerce events being sent with the relevant transaction and item information. These events are not simply inferred because an order exists in the ecommerce platform.
Check:
- purchase events;
- transaction IDs;
- purchase values;
- currency;
- item data where required;
- duplicate purchases;
- checkout-stage events where they are actually used;
- payment-provider referrals;
- tax, shipping and discount treatment;
- the effect of any checkout/platform migration.
The useful validation is not merely:
Did a
purchaseevent fire?
It is:
Does GA4 contain the correct transaction, once, with commercially sensible values?
Compare GA4 directionally against Shopify, WooCommerce or the relevant ecommerce platform.
If the platforms diverge materially, move into transaction-level reconciliation rather than assuming GA4 or the commerce platform is automatically wrong.
5. URLs, UTMs and campaign continuity
Website launches often change URLs.
That can affect analytics even where the redirect plan works from an SEO or user perspective.
Check whether:
- important campaign landing pages still resolve correctly;
- redirects retain useful campaign parameters where appropriate;
- paid search, paid social and email destinations still work;
- landing-page paths in GA4 make sense;
- source/medium patterns remain plausible;
- Direct traffic has not increased unexpectedly because campaign context is being lost.
This is analytics QA, not SEO migration management.
The purpose is to establish whether the new URL structure or redirect behaviour has changed the information available to GA4.
6. Cross-domain and third-party journeys
Some conversions do not take place entirely on the main website.
Examples include:
- external booking engines;
- separate checkout domains;
- payment providers;
- portals;
- subdomains;
- third-party registration systems.
Google's cross-domain measurement is designed to preserve user/session continuity where journeys genuinely span separate domains. Without appropriate cross-domain measurement, a user can be identified separately when moving between root domains.
After launch, check:
- whether cross-domain configuration still covers the required domains;
- whether booking or checkout platforms changed;
- whether unwanted self-referrals or payment referrals appear;
- whether sessions seem to restart mid-journey;
- whether final confirmation steps remain measurable.
A change in domain architecture can make a previously sound tracking setup incorrect without anybody changing GA4 itself.
7. Reporting and Data Studio continuity
A launch can break reporting even when GA4 continues collecting data.
Check whether:
- event names changed;
- page paths changed;
- key-event definitions changed;
- Data Studio reports still use valid fields and filters;
- dashboard logic still reflects the new website structure;
- stakeholders understand intentional differences between the old and new setup;
- launch-related changes have been documented;
- somebody owns future measurement changes.
One of the more subtle launch risks is:
The dashboard still loads, so everybody assumes the measurement is unchanged.
A working report does not prove that the definitions behind it are still comparable.
Use severity, not issue count
Do not judge launch-readiness by simply counting how many checklist items look questionable.
One broken purchase event can matter far more than six minor naming inconsistencies.
Use three practical states instead.
| Status | Meaning |
|---|---|
| Looks OK | No obvious problem found in the priority journeys tested |
| Needs investigation | Evidence is incomplete, inconsistent or changed after launch |
| High priority | Leads, purchases, revenue or another material business outcome is missing, duplicated or implausible |
Prioritise commercial impact and data reliability, not the raw number of observations.
For example:
- one missing low-value engagement event may have little practical consequence;
- one broken enquiry form conversion can invalidate lead reporting;
- one duplicated purchase implementation can materially inflate revenue reporting.
Quick post-launch diagnostic
If something looks wrong, use the symptom to choose the next investigation.
| Symptom | Next step |
|---|---|
| Real forms submit but GA4 misses them | Investigate form tracking |
| GA4 shows more conversions than actually happened | Investigate duplicate measurement |
| Shopify and GA4 revenue disagree materially | Reconcile transactions and ecommerce definitions |
| GA4 changed sharply after cookie-banner deployment | Investigate consent/CMP measurement |
| GA4 leads disagree with the CRM | Map the lead journey and find the first divergence |
| Payment/booking providers appear as conversion sources | Check cross-domain and referral behaviour |
| Traffic changes only on particular page types | Check template/tag deployment |
| Everything changed on the launch date | Start with the implementation timeline and base tracking |
This resource identifies which category of problem deserves attention.
The more specific diagnostic guides should then handle the detailed investigation.
What I would check first after a launch
If time is limited, prioritise the measurement that affects business decisions.
Highest priority
Check:
- genuine enquiries;
- purchases;
- revenue;
- key events;
- critical booking or registration journeys;
- consent behaviour;
- obvious duplicate measurement;
- campaign/source continuity.
Next
Check:
- event naming;
- landing-page reporting;
- secondary conversions;
- dashboard dependencies;
- internal/staging traffic;
- documentation and handover.
Lower priority
Deal later with:
- cosmetic naming inconsistencies;
- low-value engagement events;
- legacy measurement that does not affect current decision-making;
- documentation improvements that do not block interpretation.
This prioritisation should be adapted to the organisation.
For a lead-generation website, the primary form may matter more than ecommerce checks that are irrelevant.
For an online retailer, purchase and revenue integrity normally take precedence.
What cannot be fully tested before launch
Do not treat pre-launch QA as proof that the production implementation is correct.
Some risks may only become visible with:
- the production domain;
- real consent behaviour;
- real payment providers;
- third-party redirects;
- live ecommerce transactions;
- final CDN/template deployment;
- production-only integrations.
A practical launch QA process should therefore record three states:
Confirmed before launch
Requires production validation
Could not be assessed with the available environment
That is more useful than declaring the tracking "passed" before conditions exist to test it properly.
Data that was never collected usually cannot be recreated
This is worth making explicit before launch.
If an important GA4 event is missing for the first three weeks after a website goes live, correcting the implementation improves future collection.
It does not normally recreate the historical GA4 events that were never sent.
That makes early validation particularly important for:
- leads;
- purchases;
- revenue;
- key events;
- campaign measurement used in reporting.
The purpose of launch QA is therefore partly preventative:
find material problems before unreliable data becomes embedded in weeks of reporting.
When the launch needs specialist tracking QA
A structured review is worth considering when:
- GA4 or GTM has been rebuilt;
- the website changes CMS or ecommerce platform;
- important forms or checkout journeys changed;
- a domain or cross-domain journey changed;
- a new CMP or consent model was introduced;
- different agencies or developers have owned parts of the tracking;
- launch reporting is commercially important;
- nobody internally owns final analytics QA;
- the website has already launched and measurement continuity is now uncertain.
MeasureNest can provide independent pre-launch, post-launch or combined GA4/GTM QA around an agreed set of priority journeys.
Launch tracking QA
Launch Tracking QA is a scoped validation engagement for organisations that need independent evidence that important measurement survived a website launch, redesign or migration.
The work is shaped around:
- the launch risk;
- the website and systems involved;
- the journeys that matter;
- the available environment;
- what can reasonably be tested before and after go-live.
Before launch
Review the measurement plan, implementation readiness and priority journeys that can be tested reliably before production.
After launch
Validate the live implementation, including production domains, real consent behaviour, referrals and journeys that could not be fully confirmed in staging.
Combined launch QA
Use pre-launch testing to reduce preventable risk, then complete a defined post-launch validation once the production environment is live.
A complex ecommerce migration and a small lead-generation redesign do not require the same scope.
The engagement should be defined around material measurement risk, not an arbitrary promise to test every event on every page.
Typical areas that can be included
Depending on the project, Launch Tracking QA may cover:
- GA4 property, data-stream and domain continuity;
- GTM deployment and relevant trigger behaviour;
- duplicate-tag checks;
- forms and lead journeys;
- ecommerce events and transaction data;
- consent-related measurement;
- cross-domain and third-party journeys;
- source/medium and campaign continuity;
- route or template-specific tracking;
- live-environment validation;
- reporting dependencies;
- handover of findings and next actions.
The output should distinguish:
working as expected
confirmed issue
unresolved risk or dependency
recommended next action
rather than simply producing a list of tag observations.
Implementation boundaries
Launch Tracking QA focuses on GA4, GTM and associated measurement behaviour.
It does not include:
- website design or development;
- SEO migration management;
- accessibility, security or performance testing;
- general functional website QA;
- legal advice on privacy or consent;
- a guarantee that every possible defect will be identified;
- recreation of GA4 data that was never collected.
Hands-on GA4/GTM fixes can be handled through Tracking & Implementation Support where appropriate.
Developer, platform, data-layer, CMP or third-party changes may remain with the supplier responsible for that system.
Which MeasureNest route should you use?
| Situation | Best route |
|---|---|
| A launch or migration creates a defined need to validate measurement continuity | Launch Tracking QA |
| A specific event, form, purchase journey or tag is already known to be broken | Tracking & Implementation Support |
| The site is already live and the concern is broader - you are not sure whether the data can be trusted | Free GA4 Tracking Confidence Review |
| You want a broader self-service check rather than launch-specific QA | GA4 Tracking Confidence Checklist |
Not dealing with a defined website launch?
If the website is already established and the concern is simply that GA4 may be incomplete, duplicated or difficult to trust, start with the Free GA4 Tracking Confidence Review.
If you already know the implementation needs changing, use Tracking & Implementation Support instead.
Frequently asked questions
Can MeasureNest check tracking before the website launches?
Potentially.
Pre-launch QA depends on the quality of the test environment and whether the important journeys can genuinely be reproduced.
Some behaviour - particularly live consent, payment providers, referrals, production domains and third-party integrations - may still require post-launch validation.
Can you check the site after launch?
Yes.
Post-launch QA is often essential because the production environment can behave differently from staging.
It is also the point at which GA4 can be compared against real leads, purchases and other operational outcomes.
Does Launch Tracking QA include fixing every issue?
No.
QA and implementation are separately scoped.
MeasureNest may be able to complete appropriate GA4/GTM changes, while fixes involving website code, platform behaviour, the data layer, CMP configuration or third-party systems may require the relevant supplier.
Is this a complete GA4 or GTM audit?
No.
Launch Tracking QA is bounded around the website change and the agreed priority journeys.
If the concern is broader and you are unsure whether the overall setup can be trusted, use the Free GA4 Tracking Confidence Review as the initial route.
Can MeasureNest work with our developer or agency?
Yes.
The communication route, responsibilities, evidence and handover can be agreed around the project structure.
MeasureNest does not need to take ownership of the website build to provide specialist analytics QA.
Do you need access when we first enquire?
No.
At enquiry stage, provide the website, expected launch timing, platforms involved and the journeys that matter.
Do not send passwords.
The minimum appropriate access can be agreed once fit and scope are understood.
Is there a fixed price?
No universal price is published.
A small post-launch check covering a handful of lead journeys is materially different from a multi-domain ecommerce migration involving consent, checkout and third-party integrations.
The scope and price should be agreed before work begins.
Can Launch Tracking QA recover data that was missed after go-live?
No.
Tracking can normally be corrected for future collection, but GA4 data that was never collected cannot generally 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 specialists unless a specific analytics dependency is included in the agreed scope.