Five Setup Mistakes That Break GA4 Data

If Google Ads reports 340 conversions and GA4 reports 517 for the same period, the gap is not a modelling difference. It is the setup. In the accounts we have taken over during the past two years, the majority had at least one configuration fault on the GA4 side, and almost all of those faults fell into the same five categories. Below is how to spot each one and how to fix it, in the order that matters.

Double counting: the same tag loading twice

The most common fault by far. The usual sequence: a developer hard-codes the GA4 gtag snippet into the site template, then the marketing team adds a GA4 configuration tag in Google Tag Manager. Both use the same Measurement ID. Every pageview is now reported twice, and some events two to four times.

WordPress builds have a second variant: the theme's "Analytics ID" field, the SEO plugin's Analytics tab, and a Site Kit installation. The same ID in three places, none of the three teams aware of the others.

How to spot it:

• Engagement rate is abnormally high while average engagement time is abnormally short. Duplicate page_view hits make single-page sessions look engaged.
• Open one page yourself and watch the Realtime report. If the event counter shows 2 instead of 1, you have a collision.
• In Tag Assistant or the Chrome Network tab, filter for `collect?v=2` requests. The same `en=page_view` parameter firing twice confirms the diagnosis.
• In GTM preview mode, check the "Tags Fired" list. More than one GA4 configuration tag means the duplication can live inside a single container.

The fix is to pick one source of truth, preferably GTM, and strip out the hard-coded snippets, plugin fields and theme settings. Wait 48 hours after the cleanup and compare page_view volume with the previous period. A 40–50% drop is normal — that is not data loss, that is the real number. Add an annotation to your reporting so the step change is explained; three months later nobody remembers why the line broke.

Why conversion events go missing, and how to complete the set

GA4 arrives with automatically collected events, but none of them is a conversion for your business. The pattern we see repeatedly: form submissions are measured only through the thank-you page URL. If the form posts over AJAX and the page never changes, nothing is recorded. Or an ecommerce build fires purchase but not add_to_cart, so the middle of the funnel simply does not exist.

Another classic: the event is being sent, but nobody ticked "Mark as key event" in Admin › Events. The data is there, the conversion definition is not, and there is nothing to import into Google Ads.

To check, open DebugView and walk a real conversion journey on the live site. View a product, add to cart, move through checkout, complete a form. At each step, confirm that the expected event appears in the DebugView stream and that its parameters are populated. A purchase event with an empty `value` parameter will never produce revenue in your reports.

Fix it in this order: write the event list first (how many events, which parameters), then build the triggers in GTM, then mark key events last. For forms, use a dataLayer push or the form plugin's own success callback instead of a URL match. Do not skip phone and messaging-app clicks — in service businesses they often account for a large share of real enquiries.

The attribution window nobody revisited after setup

GA4 and Google Ads count the same conversion with different rules, and most teams compare the two numbers without aligning them first. Three settings do the damage.

1. Reporting attribution model. Check Admin › Attribution settings. Cross-channel data-driven and "Google paid channels preferred" produce visibly different channel credit, and a model chosen once during setup is rarely reviewed again.
2. Conversion lookback window. GA4 lets you shorten or extend the window for acquisition and other conversion events. If your sales cycle runs six weeks and your window is seven days, paid search will look weak and direct will look strong.
3. Session timeout. The 30-minute default suits most sites, but long-form content, configurators and booking flows generate artificial session breaks that inflate session counts and distort last-click reporting.

There is no single correct configuration. There is only a documented one. Write down the model, the window and the timeout, note the date you set them, and compare GA4 to Ads only after both sides use comparable definitions. When a stakeholder asks why the two platforms disagree, the answer should be a sentence, not an investigation.

Consent mode gaps: the data you never collected

For any traffic from the EEA, the UK or Switzerland, consent mode is not optional if you use Google advertising products. The failures we find are almost always structural rather than legal.

• The consent management platform loads after the GA4 tag, so the default consent state is never set and hits go out before the user has chosen.
• Only `analytics_storage` and `ad_storage` are handled, while `ad_user_data` and `ad_personalization` were never added when Consent Mode v2 landed.
• Basic consent mode is implemented where advanced was intended. In basic mode no pings are sent at all when consent is denied, which removes the input that behavioural modelling needs.
• Consent is set correctly on the cookie banner but not restored on subsequent pageviews, so returning visitors are treated as undecided.

Diagnosis takes minutes: inspect the `collect` request in the Network tab and read the `gcs` parameter. G100 means both storage types denied, G111 means both granted. Click through your own banner in each state and confirm the parameter changes as expected. Tag Assistant shows the same consent state per tag if you prefer a visual view.

Unlike double counting, this one has no retroactive repair. Sessions that were dropped because consent signals never fired are gone. That is why consent sits above every other item on the fix list.

Internal traffic: your own team inflating the numbers

Small sites feel this hardest. A developer refreshing a page fifty times a day, a content team reviewing every new article, an agency running QA — on a property with a few thousand monthly sessions, that is easily a measurable share of the total, concentrated on exactly the pages you care about most.

Two steps are needed and teams routinely complete only the first. Define internal traffic under Admin › Data streams › Configure tag settings › Define internal traffic, listing office IP ranges. Then go to Admin › Data filters and switch the internal traffic filter from Testing to Active. A filter left in testing mode excludes nothing; it only tags the traffic. For remote teams on dynamic IPs, add a `traffic_type` parameter through a GTM variable driven by a cookie your team sets once from an internal URL.

Also exclude staging and preview domains at the data stream level rather than hoping nobody visits them. Unfiltered internal traffic, like consent gaps, cannot be scrubbed from historical data.

What to fix first

Order matters because two of these five faults destroy data permanently while three only distort it. Start with consent mode and internal traffic filters — every day they stay broken costs you records you will never get back. Then remove duplicate tags, since every event volume you look at afterwards depends on that cleanup being done. Then complete the event set and mark key events. Attribution settings come last: they change how existing data is interpreted, so there is no benefit in tuning them before the data underneath is trustworthy. Budget an afternoon for the audit, a week for the fixes, and 30 days before you treat the new baseline as comparable to anything.