The GA4 audit, in damage order
Start with the GA4 settings whose damage is permanent, then fix the ones that make your reports mislead.
Last updated
What you’re actually auditing
A GA4 property is trustworthy for some questions and unreliable for others. Finding the boundary between them is the job. What you want at the end of this is a defensible answer to “can I put this number in front of the board on Thursday.”
That matters more than it sounds, because most of what you’re about to fix only applies going forward. Google says so plainly for some of it: marking an event as a key event “affects reports from time of creation. It doesn’t change historic data.” Data filters behave the same way. Custom dimensions start reporting a day or two after you register them, whatever date the parameter first arrived. Fixing a GA4 property doesn’t repair your history. It draws a line through it.
So the audit has two outputs. The first is a corrected property. The second, and the one that outlasts the audit, is a sentence you can say out loud about which of your existing numbers survived the correction.
Run it in damage order
A GA4 checklist that doesn’t rank its items treats them all as equal: sixteen items, forty items, a spreadsheet with a pass column. Work one of those top to bottom with an hour to spend and you’ll link Search Console and set your time zone while the setting that’s deleting your event history goes untouched for another month.
Order the work by what it costs you to wait:
- Settings that cost you history. Every day these stay wrong is a day your reports can never fully put right. Fix them today, before you understand the rest of the property.
- Settings that distort reports. The data is landing; the reports built on it mislead. Painful, but nothing is being deleted, and each fix works from the day you make it.
- Settings that only shape convenience. Product links, channel groups, report customisation. Genuinely useful. Never urgent.
Tier one is a fifteen-minute job with a deadline attached. On a flat list it has to wait its turn.
Tier one: the settings that cost you history
Three settings sit in this tier, all of them in the Admin panel. No developer, no ticket, no tag manager.
Start with data retention, the only one of the three that deletes anything. Admin, then Data collection and modification, then Data retention. A standard property offers two options for user and event data: 2 months or 14 months, and new properties arrive on the shorter one. What the setting governs is narrower than it sounds, which is how it goes unnoticed. Your standard reports keep working regardless, because they run on aggregated tables. What expires is everything you build in Explorations and funnel reports. The cost stays invisible until the first time someone asks for a year-on-year path analysis and there’s nothing behind the question. Switch it to 14 months before you read the next paragraph. It’s a dropdown, and every day it sits on the default is a day of event history nobody can restore.
Next, open Admin and then Custom definitions, and compare what you find
against what your tags actually send. A tag can send form_id, plan_type and
branch perfectly for a year, and none of it reaches your standard reports or
explorations until someone registers each parameter as a custom dimension.
Realtime and DebugView show the values coming in, so the tagging checks out
while the reports have nothing to show. A standard property allows 50 event-scoped
dimensions, 25 user-scoped and 10 item-scoped, so three parameters come nowhere
near the quota. Register what you send, then wait: Google documents a 24 to 48
hour delay before a new dimension reports. What Google’s help pages don’t say is
whether values collected before registration ever become reportable. Plan on the
answer being no, and treat a dimension you register today as starting today.
The third one stings, because whoever set it up did most of the work. Defining
internal traffic on the data stream tags your own visits with a traffic_type
parameter, and a separate data filter under Admin decides what happens to them.
GA4 ships that filter already created, in the Testing state. In Testing, GA4
labels the matching data and leaves every session of it in your reports, so a
property can carry a correctly configured internal-traffic filter and count
head-office visits all year. Nothing is deleted while it waits. It belongs in
this tier because filters never apply to data already collected: every visit
logged while it’s in Testing stays in your standard reports for good, and
setting those visits aside takes an exploration built on the Test data filter
name dimension. Set
the filter to Active — and read this before you do, because activation runs the
opposite way from every other change in this audit. Excluded data is never
processed, so it will not appear in Analytics or in your BigQuery export, ever.
That is the point of the filter, and it is the one click in this tier you can’t
take back.
Tier two: the settings distorting what you read
The events are landing. The numbers built on top of them tell a story the business wouldn’t recognise. Three causes.
Key events come first, because the vocabulary changed underneath everyone. Google renamed conversions to key events in 2024, and a conversion now means something narrower: the action you hand to Google Ads to optimise bidding against. A key event is a marker that something happened, which says nothing about whether it mattered. Open Admin, then Data display, then Events, and read the list as a stranger would. If a newsletter signup, a PDF download, a phone-number click and every form on the site are all flagged, your key event count is measuring activity. You get 30 key events on a standard property, which is more rope than any mid-size business needs. Mark the three to five actions that would change a revenue forecast and unmark the rest, knowing that unmarking leaves the history exactly as it was.
Enhanced measurement is the most defensible mistake in the audit, because leaving a default alone never feels like a decision. Switched on, it collects scrolls, outbound clicks, site searches, video engagement, file downloads and form interactions automatically. Page views come regardless, and the settings offer no way to turn them off. The rest are generous by design: the scroll event fires once 90% of the page’s depth comes into view, which on a short page takes a single flick of the thumb and says little about whether anyone read it. Work through the six toggles on the data stream and keep the ones you’d report on. We’d keep site search and file downloads on a typical marketing site and switch off the other four, which are noise wearing the costume of insight.
Then there’s double-counting, which arrives as a suspiciously round doubling of
page views. Several setups fire two page_view events on one page load, and one
of the plainest is the Google tag hardcoded in the site template and deployed
through the tag manager, both carrying the same measurement ID. Google’s help
warns that a tag configured twice on a page “may cause duplicate data.”
Views per session double, every content report ranks on inflated numbers, and
any rate built on views is wrong by a factor nobody has worked out. With debug
mode on, DebugView shows it in seconds: load one page, watch two page_view
events arrive. The Google tag’s settings include an option to ignore duplicate
on-page configuration, but that leaves both copies in place. Take one out, from
the template or from the container. The container side of that work is its own
discipline, covered in tag manager hygiene.
Cross-domain: check the topology before you touch the setting
“Configure cross-domain tracking” turns up on GA4 audit checklists, and whether your property needs it depends on how your domains are laid out. It is a tier-two fault when it’s real, since the events still land, and the first job is finding out whether it is real.
Three shapes, and only one of them needs anything. If your Arabic and English
live in folders on a single domain, there is nothing to configure: one domain,
one cookie, one session. If they live on subdomains, there is still nothing to
configure. The Google tag writes its cookie at the highest level of domain it
can, so ar.example.ae and www.example.ae already share a visitor, and
Google’s tagging documentation is explicit that subdomains are measured without
extra setup.
The shape that genuinely breaks is separate root domains: the corporate site on
one, the Arabic site or the booking platform on another. Each domain writes its
own cookie with its own ID, so one person becomes two users and two sessions.
The second session arrives as a referral from your other domain, or as
“(direct)” if the referrer is stripped on the way, which is how your own domain
ends up in your referral report and your direct traffic swells. Bilingual
businesses across the GCC hit this whenever the second language went live on a
separate root domain. The fix lives in Admin, then Data streams, then your web
stream, then Configure tag settings, then Configure your domains: list every
root domain, and confirm each one runs the same tag ID from the same data
stream. GA4
then passes the visitor’s ID between them in a _gl parameter appended to the
link, which you can watch happen by clicking across the boundary and reading the
URL bar.
While you’re on that screen, payment gateways, and any booking engine that can’t carry your tag, belong in the unwanted referrals list beside it. Otherwise the checkouts that return through them get credited to them as referrals. That setting and six other GA4 defaults are argued through in seven settings that are wrong right now.
Nothing counts until you’ve watched it happen
An audit finding is a claim, and so is the fix for it. Both are worth what you can demonstrate. Turn on debug mode, which Tag Assistant can do for you, then open DebugView on one screen and your own site on the other, and go and do the thing: submit the form, buy the item, cross the domain boundary, load the page you suspected was double-tagged. Watch the event arrive. Read its parameters. If one you expect comes through blank, you’ve found a second problem, and it sits upstream in the tag or the data layer rather than in the property.
Two verification traps are worth knowing before they cost you an afternoon. A new custom dimension reports blank for the first day or so by design, so a “(not set)” the morning after you registered one proves nothing yet. And a data filter in Testing state only ever demonstrates that the filter matches; it never removes a session. Re-check both a couple of days later, with the same event, from the same page.
The dated line, and what your history can say
Finish with a note, three or four lines long, somewhere your team will find it: which settings changed, on what date, and what that does to data either side of it. A property whose key events were corrected on the 8th can’t have its key event counts compared across the 8th, and sooner or later someone will try.
Then be blunt with yourself about the rest. If the key event list was inflated for a year, that year’s trend line measured how many things you flagged, not how many things happened. Total sessions probably survive. Rates built on double-counted views don’t. Channel splits from before the cross-domain fix hand your own domain, or direct, the credit for visits your real sources sent across. None of that history gets thrown away. It gets annotated, and an annotated number a colleague can interrogate beats a clean one nobody can explain.
This is also where GA4 stops being the whole story. A property can be configured impeccably and still report thinly if the container feeding it holds a decade of accumulated tags, if third-party scripts nobody owns are firing outside the consent gate, or if the ad platforms are counting the same sale on a different attribution window than you are. GA4 is where those problems become visible, which is why it takes the blame for all of them. Draw the line here, then work back up the chain — the seven systems behind your reporting and the order they fail in are worth knowing before you spend a week fixing the wrong one.
Standing offer
The hard part is deciding what to do first
Bring us a URL, an audit report, or a proposal you're not sure about. We'll tell you which problems deserve budget this quarter, and you'll leave with an order of operations you can hand to whoever does the work, whether that's us or not.
Book twenty minutes