Why Your GA4 Is Probably Broken (And How to Know for Sure)

If you run Google Ads and rely on GA4 for conversion tracking, there's a non-trivial chance your data is wrong. Not slightly off — wrong in ways that affect bidding strategy, budget allocation, and the decisions you present to stakeholders.

You probably don't know about it, because GA4's own tooling won't surface these issues and a manual audit takes hours most teams don't have. This post covers the five most common failures we see in production audits, how to identify each, and what fixing looks like.

1. Consent Mode v2 is misconfigured (not just missing)

Since March 2024, Consent Mode v2 is required for EEA traffic. "Required" and "correctly configured" are not the same thing. The most common failure isn't absence — it's misconfiguration that passes casual inspection but fails in production:

• Default state not set. Consent Mode needs denied defaults before the user makes a choice. Many implementations only set granted after consent — meaning no baseline signal for users who decline or never see the banner.
• Tags fire before the consent signal.The consent update must execute before GA4's config command. In GTM, firing order is frequently wrong.
• Only 2 of 4 signals configured. ad_storage and analytics_storage are set, but ad_user_data and ad_personalization are missing entirely. Google treats that as non-compliant and excludes your users from conversion modeling. (See our deep-dive on the ad_user_data signal.)

Why it matters: beyond GDPR exposure, incorrect Consent Mode directly degrades GA4 data quality and disqualifies EEA traffic from Google Ads conversion modeling.

2. Events fire before consent is given

This is distinct from Consent Mode misconfiguration. This is the browser-level question: is /g/collect actually being called before consent is registered?

Using DevTools Network in an incognito window, you should see no requests to google-analytics.com/g/collect until either the user grants consent or your Consent Mode update fires. We frequently see collectfire on page load, before the banner has rendered. This happens because the tag priority in GTM is wrong, or because the CMP's integration tag fires asynchronously after GA4 has already initialized.

Why it matters:this is a GDPR violation, not just a data-quality issue. Google won't protect you from it — the obligation sits with the data controller.

3. Duplicate or cross-tag conversion tracking

GA4 conversions can be configured in at least three places: native events marked as conversions, imported UA goals, and Google Ads conversion actions that pull from GA4. Evolved setups frequently double- or triple-count:

• A custom GTM tag fires a purchaseevent AND GA4's enhanced ecommerce purchase also fires. Both marked as conversions. Every purchase counted twice.
• Cross-property duplication: the site sends page_views to two differentGA4 measurement IDs. We see this on major sites regularly — it's the single most common silent failure we detect. See our dedicated post on GA4 cross-tag duplication for the full breakdown.

4. Cross-domain tracking broken

If your user journey spans multiple domains — main site to Shopify checkout, separate booking system, subdomain with a different GTM container — GA4 needs explicit cross-domain config to keep sessions intact. Without it, every domain boundary starts a new session attributed to (direct) / (none). The original Google Ads click or organic search is lost.

Symptoms: unusually high direct/none traffic, session counts inflated relative to users, conversion paths that show direct last-touch even when you know users came from paid.

5. PII leaking into event parameters

GA4 prohibits sending personally identifiable information — emails, phone numbers, names, any linkable ID — in event parameters. The prohibition is in the terms of service and has real teeth: Google can suspend your GA4 property, Google Ads account, or both.

Most common source: a developer passes user_email or user_id (containing an email) as an event parameter, often for debugging, and never removes it.

Why it matters:a suspended GA4 property isn't recoverable while suspended. Historical data access stops, Google Ads conversion import stops, remarketing audiences stop updating. The fix before suspension is simple; the fix after is not.

Why manual audits miss most of this

GA4's own tooling won't tell you that consent signals fire out of order, that conversions are double-counted, that a _glparameter is missing from cross-domain links, or that PII is leaking. GA4 Diagnostics shows you the number. It doesn't validate that the number is right.

A manual audit works but has three structural problems:

• Inconsistent. Different analysts check different things. Complex GTM containers with dozens of triggers escape checklists.
• Slow.Thorough audit of one property is 3-5 hours. For an agency with 20 clients, that's a project, not a regular check.
• Point-in-time.A deploy two days later can break Consent Mode and you won't know until conversion data goes wrong.

7 questions to ask right now

1. Does your site send a consent signal with all 4 v2 defaults set to denied before any GA4 collect request fires?
2. Can you trace a specific transaction ID from your backend to a GA4 purchase event — with no duplicates?
3. Are all your domains (checkout, booking, third-party tools) listed in GA4's cross-domain configuration?
4. Have you reviewed every active conversion action across GA4 and Google Ads in the last 90 days?
5. Have you scanned your GTM container for variables referencing user-submitted form fields?
6. Is your GA4 property receiving data from every environment — production, staging, subdomains?
7. When did you last run a structured audit of this setup — not just check that "things look normal"?

If you can't confidently answer yes to all seven, you have open questions in your GA4 setup. Most of them are detectable in under 60 seconds — run a free scan to surface them.