GA4 Data Inaccurate? 7 Reasons Your Numbers Don't Match Reality

Direct in GA4 does not mean someone typed your URL. It is the catch-all bucket for sessions GA4 cannot attribute to a known source: dark social, in-app browsers, stripped referrers, AI assistants that send no referrer, and HTTPS-to-HTTP downgrades all land there.

A common audit finding is a marketing team reading a large Direct channel as brand strength, when most of it is LinkedIn posts and Slack messages that lost their referrer inside native apps. In one Enterprise SaaS project, server-side tagging with Google Tag Gateway plus UTM and referrer fallbacks cut the share of leads counted as direct from 53% to 38%, 2 months before vs 2 months after. The Enterprise SaaS server-side tagging case shows how.

Real traffic that routes into Direct usually comes from:

• Links shared inside the Instagram, LinkedIn, TikTok and Facebook apps, whose in-app browsers drop the referrer
• HTTPS pages linking to HTTP destinations, where the browser drops the referrer
• Push notifications that open in webviews, and email clients that strip referrers
• AI assistants that send visitors without a referrer header
• Strict browser privacy modes, such as Brave's, and server-side redirects that lose the original referrer

Channel: Dark Social
Condition: Source matches regex (lnkd\.in|l\.facebook\.com|l\.instagram\.com|t\.co|out\.reddit\.com)
Place: Above Direct in the channel group order
Channel: AI Assistant (custom)
Condition: Source matches regex (chatgpt\.com|perplexity\.ai|copilot\.microsoft\.com)
Place: Above Direct

GA4 excludes known bots automatically, using Google research and the IAB/ABC International Spiders and Bots List. You cannot switch that filter off, and you cannot see how much it removed. What it misses is the traffic that matters: headless browsers and scrapers that run JavaScript, fire your tags and simulate scrolling and dwell time.

Crawlers that do not execute JavaScript, which includes most AI crawlers such as GPTBot and ClaudeBot, never fire a GA4 tag. Their visits show up in server logs and never in GA4 reports. The sessions that inflate GA4 come from automation that renders the page like a browser.

The usual symptom is a traffic lift with no campaign change and no SEO win, concentrated on a few page types, with zero engagement time and zero conversions, coming from a handful of data-center networks. If leadership is celebrating that lift, it is celebrating the wrong number.

-- Zero-engagement sessions by day, browser and country
WITH events AS (
  SELECT
    event_date,
    device.web_info.browser AS browser,
    geo.country AS country,
    user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params)
      WHERE key = 'ga_session_id') AS session_id,
    (SELECT value.int_value FROM UNNEST(event_params)
      WHERE key = 'engagement_time_msec') AS engagement_ms
  FROM `project.analytics_xxxxx.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260401' AND '20260430'
),
sessions AS (
  SELECT event_date, browser, country, user_pseudo_id, session_id,
    SUM(IFNULL(engagement_ms, 0)) AS engagement_ms
  FROM events
  GROUP BY 1, 2, 3, 4, 5
)
SELECT
  event_date,
  browser,
  country,
  COUNT(*) AS sessions,
  COUNTIF(engagement_ms = 0) AS zero_engagement
FROM sessions
GROUP BY 1, 2, 3
HAVING sessions >= 50 AND zero_engagement / sessions > 0.8
ORDER BY sessions DESC
LIMIT 100;

A GA4 conversion is whatever event someone flagged as a key event. It rarely equals a qualified lead or a closed deal, and the mismatch between GA4 conversions and CRM revenue is built into how each tool counts.

GA4 counts sessions and events. The CRM counts contacts, opportunities, qualified leads and revenue. They use different denominators, different attribution windows and different identity resolution. GA4 defaults to data-driven attribution, Google Ads credits only its own clicks, and the CRM uses self-reported or first-touch source. The same lead shows a different source in each tool, and none of them is wrong.

Identity is where the gap widens: measured across Waftr client audits, 28-41% of CRM leads arrive with no GA4 client ID, so no tool can tie those leads back to a session.

The typical argument goes like this. GA4 reports hundreds of conversions for the month, the CRM shows a few dozen qualified leads, and leadership asks which number is right. Both are. GA4 is counting every form submission, including bots, internal QA tests and personal-email sign-ups. The CRM is counting people sales accepted. The fix is not making them match. It is deciding which number drives which decision.

On a standard GA4 property, Explore reports sample once a query covers more than 10 million events. Standard reports are not sampled, but they can apply data thresholds that withhold rows with small user counts, mostly when Google signals is enabled, and they fold high-cardinality dimensions such as user_id or account_id into an (other) row.

Sampling kicks in silently. The badge on an Explore report says it is based on 100% of available data until it does not, and most users never notice the badge change. The pattern is familiar: a high-value segment shows one session count in Explore and a materially higher count when the same query runs in BigQuery against raw data, enough to change which channel looks profitable for the quarter.

With Consent Mode v2 in advanced mode, GA4 still receives cookieless pings when a visitor denies consent. If the property meets Google's eligibility thresholds, behavioral modeling then estimates the sessions and conversions of those visitors from the behavior of consented ones. The estimates appear in standard reports with no visual flag.

The output is plausible. It is not what happened, and the higher your denial rate, the larger the modeled share. A typical case: after a new consent banner rolls out, GA4 shows a stable conversion rate while measured conversions in BigQuery fall and modeled conversions fill the gap. Consent rates drive everything downstream, which is why this check belongs in the same review as cookie consent and privacy compliance.

When a visitor leaves for Stripe, PayPal, an SSO provider or any third-party domain mid-session, GA4 treats the return as a new referral by default. The original source is overwritten, and the sale is credited to the payment provider instead of the campaign that drove the visit.

Cross-domain measurement and the unwanted referrals list are configured per data stream. Without them, every checkout looks like Stripe brought the customer, every SSO login looks like Google did, and every chat widget on another domain splits the session. The classic symptom is stripe.com listed as a top revenue source, while paid social looks unprofitable, loses budget, and the campaigns that actually closed the sale get no credit.

Recommended unwanted referrals list: starting set

• stripe.com
• checkout.stripe.com
• paypal.com
• checkout.shopify.com
• pay.amazon.com
• accounts.google.com
• login.microsoftonline.com
• auth0.com
• okta.com
• intercom.io
• zendesk.com

Unassigned is GA4 admitting it cannot place a session in any channel. If it is more than about 1 percent of sessions, treat the channel grouping as broken.

Sessions become Unassigned when their source and medium match no rule in the default channel group. The usual cause is UTM tags with custom medium values such as sms_blast, pdf_link or qr_code that the default rules do not recognize; recognized mediums include organic, cpc, referral, email, display and affiliate. A growing cause is links that set utm_source but no utm_medium. One agency template with a non-standard medium can push a large share of paid traffic into Unassigned for months, and every paid performance report quietly excludes it.