Insights / Analytics
The gaps that survive a GA4 migration.
A migration can complete successfully and still leave a business measuring less than it was before. None of the failures announce themselves, because the interface keeps returning numbers throughout.
Migrations get judged on whether the new property is receiving data. That is a low bar, and almost everything clears it. Data arrives, reports populate, charts have a shape, and the project is marked complete. The problems surface a quarter later, when somebody tries to answer a question they used to be able to answer and finds that they cannot.
What follows is the set of failures we look for first. They recur because they share a property: in each case the system continues to report something, so nothing looks broken.
Events that were migrated but never marked as conversions
An event can arrive correctly, appear in reporting, and still not be designated a key conversion. Everything looks present because the event is visibly there. What is missing is its status, and status is what advertising platforms optimize against. The downstream symptom is a campaign that appears to have stopped working, when what stopped was the signal being sent back to it.
Parameters collected but never registered
This is the most expensive quiet failure in the list. An event can carry a custom parameter perfectly from day one, but unless that parameter is registered as a custom dimension it is not available to segment or report on. The data is being collected and discarded at the same time.
It is worse than it first appears, because registration is generally not retroactive. The months between implementation and registration are not recoverable later. Businesses routinely discover this when they finally need the breakdown, and find the field empty for exactly the period they wanted to analyze.
Filters that were never recreated
Internal traffic exclusions, developer and staging traffic, known bot sources and office IP ranges are configured once in an old property and forgotten. They do not carry across. The new property quietly includes the company's own team, its agency, and anyone testing the site.
For a high-traffic site this is noise. For a low-volume, high-value business, where a month might legitimately contain thirty conversions, internal activity can be a large proportion of the total and it distorts every rate that is calculated from it.
Referral exclusions that did not come with
Payment providers, booking engines and identity providers need to be excluded as referral sources, or the return journey from them starts a new session and steals the conversion. The new property starts with defaults that do not know about the third parties your specific business routes people through.
The signature is recognizable once you have seen it: a payment domain appearing as a meaningful traffic source, and paid campaigns whose conversion counts fell at the exact moment the migration completed.
Commerce data mapped approximately
Commerce schemas differ between generations of analytics in their event names, their parameter names and their nesting. A partially correct mapping produces transactions with no items, items with no value, or revenue that arrives at the right total by a route that breaks as soon as anyone looks at product-level detail. Refunds are the commonest omission, and a property that records purchases but not refunds overstates revenue permanently.
Retention left at its default
Event-level retention has a conservative default. For anything touching exploration or year-over-year comparison, this quietly caps how far back the question can be asked. Nobody notices in the first months, because there is not yet any history to lose. It is noticed a year later, by which time the data is gone.
Every failure here shares one property: the interface keeps returning numbers, so nothing looks broken.
Consent implemented as a switch
If consent is implemented by preventing tags from loading, declined consent contributes nothing at all. Implemented as a signal, a declined state still allows an aggregated or modeled contribution. The difference does not show as an error. It shows as a total that is lower than the business knows it should be, with no indication of where the shortfall came from.
It is done when a named list of business questions can be answered from the new property, and each answer has been reconciled against a source outside analytics. That list should be written before the migration starts, because writing it afterward tends to produce a list of the questions the new setup happens to be able to answer.
How to audit one you have already done
- List the business questions the property exists to answer. Try to answer each one now.
- Check that every event that should be a conversion is designated as one.
- Check that every custom parameter you rely on is registered as a dimension, and note the date it was.
- Confirm internal and bot traffic are excluded, and test it from your own office.
- Confirm every third-party domain in a conversion path is on the referral exclusion list.
- Reconcile one month of revenue, including refunds, against the system that took the money.
- Confirm retention is set to what your reporting horizon actually requires.
None of this requires a rebuild. Most of it is configuration that was missed once and has been quietly costing since. The work is in checking rather than in fixing, which is precisely why it tends not to get done.