75 Reasons Your Google Analytics 4 Data can be Inaccurate or Missing

A practical guide to missing events, fragmented journeys, reporting limits and AI traffic, with 75 checks you can run on your own site.

Your analytics will never be 100% accurate, and no tool is. Usually that is fine: if you know what each number represents and can compare it over time, the trend is enough to steer by. The trouble starts when one decision rests on one figure, where the number has to be right, not just consistent, and a quiet gap can turn into a wrong call.

Take one journey. Someone finds your product on their phone, returns on a work laptop through a VPN, and buys. GA4 records the sale, but it may not connect the visits, keep the original source, or place the person in the right country. That one journey already touches several problems: some actions never reach GA4, some arrive with missing context, and some gaps appear only later, when reports apply different definitions or models.

This guide groups 75 reasons your GA4 data can be inaccurate or missing into 12 areas, each with what can change, what to check, and how to gauge the impact. Treat it as a diagnostic map, not a number to add up: the mechanisms overlap and depend on your setup.

Prioritize by the decision at stake. A missing purchase event can change bidding; a country mismatch can change a market analysis; sampling can destabilize a small segment. And a real change in behavior, for example fewer organic clicks when AI answers resolve the query on the results page, is not a tracking fault, so rule out external causes before treating a drop as a defect.

How to read this. You do not need to read top to bottom. The table below maps the areas where measurement can change. Jump to the area behind the decision you care about, scan its table of checks, then read the notes under it for the why and how to estimate impact.

For the hands-on version, which GA4 tool to open to actually see each thing, jump to How to check this in GA4.

On this page

• Where Measurement can Change
• 1. Consent State and Timing
• 2. Browser Controls and Storage
• 3. Identity Across Visits and Accounts
• 4. Campaign and Referrer Information
• 5. Apps and Journeys Across Domains
• 6. Tracking-Tag Coverage and Delivery
• 7. Events, Leads and Ecommerce
• 8. Server Integrations and Event Configuration
• 9. Geography and Unwanted Traffic
• 10. Metric Definitions and Comparisons
• 11. Reporting and Exports
• 12. AI Access and Influence
• How to Check This in GA4
• The Bottom Line

Where Measurement can Change

These mechanisms overlap. Their percentages cannot be added into one universal estimate of lost traffic.

1. Consent State and Timing

Before anything is collected, the consent layer can intervene in several ways: the visitor rejects analytics consent, leaves the banner unanswered, or chooses only after an important action has already happened, and a consent management platform can send an incorrect state or update it too late. Accepting a banner does not always grant analytics specifically, either.

Consent mode and modeling. Google distinguishes basic and advanced consent mode. Basic mode blocks Google tags until consent is granted. Advanced mode can send cookieless pings when consent is denied. Sending those pings does not mean every missing user journey will appear in reports. Behavioral modeling depends on eligibility and data quality, and Google documents concrete prerequisites, including a minimum number of consented daily users and a minimum volume of events collected while consent is denied, so smaller properties may never reach eligible volume.

Reading public benchmarks. Public consent benchmarks need care. Didomi's 2026 benchmark, based on 2025 European website data, reports an 82.7% consent rate and a 64.4% opt-in rate for Media & Publishers. The two use different denominators: the consent rate counts only people who expressed a choice, while the opt-in rate is measured against all banner displays, so it also includes people who never answered. They are vendor benchmark metrics, not measurements of your GA4 coverage.

How to test and measure impact

• Use your CMP's records to see how many visitors granted analytics, denied it, or never chose - within the group those records actually cover.
• Then check how events behave in each of those states.
• Remember that the number of banner displays is not the number of visits, and cookieless pings do not guarantee the journey will show up in reports.

Sources: Consent mode, behavioral modeling, Didomi benchmark, CMP metric scope.

2. Browser Controls and Storage

Blocking extensions and network filters. Blocking extensions, browser protections and network filters can prevent scripts or requests from reaching their destination. A browser's market share is therefore useful for choosing test environments, but it does not tell you the percentage of GA4 events that browser loses.

Browser storage rules depend on conditions, not the calendar. Under Safari's tracking prevention, cookies and storage written by JavaScript, which includes the GA cookie, can be cleared after seven days without a return visit. That is narrower than it sounds: it does not apply to server-set cookies, and a return visit resets the seven-day window, so it is not a flat loss for everyone after seven calendar days.

People can reset their own identity. Clearing cookies or site data, or browsing in a private window, gives a returning person a fresh identifier, or ends continuity when the private session closes. This is normal behavior rather than a tag fault, so the aim is to measure how often it happens, not to prevent it.

How to test and measure impact

• For each browser and network you test (for example Safari on office Wi-Fi, or Chrome with an ad blocker on a VPN), record what actually happened: whether the event was sent and whether storage survived.
• Remember that how common a browser or extension is does not equal the share of events you actually lose.
• For anonymous visitors, you often cannot know how many real people were split into several users.

Sources: WebKit tracking prevention, EasyList policy, GA4 reporting identity.

3. Identity Across Visits and Accounts

One person and one measured user are not the same thing, and two opposite errors happen:

• Splitting: switching devices, browsers or browser profiles, clearing storage, or ending a private browsing session can break one person into several users.
• Merging: shared browsers and incorrect User-ID implementations can combine different people's activity into one.

How GA4 identifies users. For web measurement, GA4 uses the client ID as its device ID. Reporting identity can use User-ID, device ID and, where available, modeling. A VPN or IP change alone does not necessarily create a new user. No identity setting can guarantee that every anonymous visit across every device belongs to the correct person, so test the paths your customers actually use, including signed-in and signed-out states.

How to test and measure impact

• Study continuity on a group of logged-in, consented users, and keep your conclusions limited to that group.
• Remember that GA4 cannot fully rebuild an anonymous person's history across devices.
• Do not treat a changed IP, on its own, as proof of a new user.

Source: Reporting identity and its identity spaces.

4. Campaign and Referrer Information

Tagging and referrers interact. A visit's source can come from campaign parameters (UTMs), from auto-tagging (the ad click ID), or from the referrer, and these can override or replace each other. For example, when an ad's auto-tagging cannot be read, GA4 falls back to your UTM values and leaves any UTM fields you did not set blank. So a visit that lands in Unassigned or an unexpected channel is usually mislabeled, not missing.

Some links never carry the source. Redirects and short links can strip campaign parameters before the landing page, and a link copied into an email, document or chat arrives with no original source at all, so it looks like Direct rather than the real channel. A bookmark behaves the same way: saved clean, it returns as Direct; saved with old campaign parameters still in the URL, it keeps crediting that campaign on every visit. Links opened from native apps, such as messengers, email clients and social apps, often pass no referrer either, so that traffic also collapses into Direct unless the link is tagged.

Never put UTMs on internal links. A UTM on an internal banner or menu link starts a new campaign, so under last-click attribution it can steal credit from the real acquisition source, such as an ad or organic search: someone arrives from a paid ad, clicks a tagged on-site banner, and the purchase is credited to that banner instead. Track on-site banners with internal promotions (view_promotion and select_promotion), not UTMs.

Know which attribution scope you are looking at. GA4 has three, and they answer different questions: first-user (what first brought someone, shown in the User acquisition report), session (what started a given session, in the Traffic acquisition report), and event or conversion credit (set by the attribution model, in the Advertising reports). Pick the scope that fits your question and use the same one on both sides of any comparison. And remember that changing the attribution model re-credits conversions only; it does not change first-user or session source.

Cross-tool comparisons diverge by design. Google Ads and GA4 can report different conversion counts because they use different attribution models, counting methods, lookback windows and reporting time, and Search Console counts queries and clicks rather than sessions. A gap between these products is usually a definition difference, not lost GA4 data.

How to test and measure impact

• Take a fixed set of real links and check whether their campaign parameters survive all the way to GA4.
• In reports, watch for visits landing in unexpected channels as a warning sign, not a final count.
• Remember that Direct, Unassigned and (not set) neither add up to all attribution errors nor explain their causes.

Sources: Traffic-source processing, default channels, source scopes, Ads and Analytics discrepancies, direct traffic.

5. Apps and Journeys Across Domains

Source information is fragile along several paths. Links opened from mobile apps, desktop apps, emails, documents and private messages can arrive with limited source information. Redirects may remove campaign parameters. External checkouts can interrupt continuity when cross-domain measurement is missing or fails.

In-app browsers. Do not assume every in-app browser has isolated cookies: Android Custom Tabs can share browser state. Behavior depends on the app and browsing component, so test the actual link-opening path.

Some outcomes never happen on the site. Calls, marketplace purchases and CRM results occur off-site or offline, so they reach GA4 only through an intended import or server integration, if at all.

How to test and measure impact

• Run a full test journey through each important app and domain path.
• For outcomes that happen off-site, compare the eligible business records with whatever import or integration is meant to capture them.
• Remember that a gap in browser-side tracking (for example no page_view after an external checkout) does not prove the server-side purchase event is missing; check the server integration separately.

Sources: Android Custom Tabs, cross-domain measurement, Measurement Protocol.

6. Tracking-Tag Coverage and Delivery

Here, the tag is the GA4 tracking tag: the Google tag (gtag.js) or the tag you deploy through Google Tag Manager.

Collection can fail before an event is even built. On the client side, watch for:

• missing tracking tags on templates, JavaScript errors and content security policies;
• slow loading and unreliable delivery when a page closes;
• single-page application navigation (the site changes the view without reloading the page) and embedded forms.

Each of these can drop or duplicate events on specific templates, locales or connections while the rest of the site still looks healthy.

Enhanced measurement toggles. Confirm which enhanced measurement events (scroll, outbound click, site search, video, file download, form interactions) are enabled: a disabled toggle means those events never exist, and an enabled one can duplicate a manual event that measures the same thing.

How to test and measure impact

• Perform a fixed set of actions, then compare the events you expected with the events GA4 received.
• Record failures for each path and condition you tested.
• Do not assume a failure rate from a few lab tests applies to all traffic unless the test is representative.

Sources: SPA measurement, page-view measurement, page-exit delivery constraints.

7. Events, Leads and Ecommerce

Why totals can mislead. Suppose the order system and analytics both show 100 orders, but they share only 90 order IDs. The matching totals conceal discrepancies in both directions. Compare records as well as totals: check missing and unexpected IDs, repeated events, values, currencies, refunds and the time zone each system uses. Comparing each order's purchase time with its event time can also confirm matches or surface gaps.

A tracked event is not proof of the real outcome. A form submission does not prove your backend accepted a valid lead, and a fired purchase event does not prove a confirmed, paid order. Decide which business outcome you care about, pick the event that should represent it, and check that the event fires only when that outcome truly happens.

How to test and measure impact

• Compare order IDs in both directions, then compare matched values and currencies.
• Count duplicate events separately.
• Remember that matching totals can hide different underlying records, and comparing gross revenue is not the same as reconciling net revenue after refunds.

Sources: Enhanced measurement, purchase deduplication, purchase and refund event specification.

8. Server Integrations and Event Configuration

Server-side sends have their own failure modes. Identifiers, timestamps, retries and payload validation each introduce risk, and field limits, custom-definition and event-modification rules, and client redaction or server transformations can change which fields arrive and what an event means. A successful Measurement Protocol HTTP response does not establish that a payload is valid, and server-side tagging does not restore unknown user history or remove consent requirements.

How to test and measure impact

• Match the records your server sent with the records GA4 received, using a shared ID where possible.
• Count validation errors, late records and duplicates as separate categories.
• Remember that server-side tagging does not recover unknown users' history and still needs consent.

Sources: Protocol validation, protocol reference, collection limits, event rules, data redaction.

9. Geography and Unwanted Traffic

How mismatches arise. A person physically in China could connect through a VPN exit in the United States and be classified there. Corporate gateways, proxies and mobile networks can create similar mismatches. This is an example of a possible mechanism, not an estimate of how much traffic is hidden in another country's totals.

Limits of IP geolocation. IP geolocation has limits: a VPN endpoint does not reliably reveal the user's physical location, and accuracy figures published by a geolocation vendor cannot be treated as GA4 accuracy guarantees. For a market decision, compare analytics geography with an appropriate business field, such as customer-declared country or delivery destination. GA4's granular location and device data collection can also be turned off for chosen regions, which removes city, precise location and some device details for users there, so a gap can come from a setting rather than the network.

Not all traffic is your audience. Internal and staging activity, known and unknown bots, and server-side location overrides can all enter production metrics. Data filters that exclude traffic at collection are also easy to confuse with report filters or referral-exclusion settings, so separate them deliberately.

How to test and measure impact

• Use the business location that fits the question (for example customer-declared country or delivery address), not analytics geography alone.
• For bots, count requests separately from sessions, and rely on verified evidence rather than location or odd engagement alone.
• Test your data filters carefully: an active exclusion filter permanently drops incoming data.

Sources: IP geolocation accuracy, Private Relay location, data filters, known bots, unwanted referrals.

10. Metric Definitions and Comparisons

A setting can change a metric without changing behavior. A key event configured to count once per session can return one count for five triggers in that session; counting once per event can return five. Both follow the selected setting.

One duplicate can affect two metrics. GA4's engaged-session definition includes sessions with at least two page or screen views. If a duplicate page_view is counted, it can affect engagement as well as view totals. Engagement can also depend on session duration or a qualifying key event, so higher engagement can reflect a tracking change rather than better behavior.

Definitions decide the number. User metrics, session rules, attribution scope and window, and the way a query aggregates data each change the result without any change in behavior, so align the definition on both sides before comparing.

How to test and measure impact

• Change one setting or definition at a time, then compare the results.
• Assume the difference comes from the definition or the query, unless you have separate evidence of a real collection problem.
• Remember that unique users are de-duplicated per time range: a visitor active on several days is counted once each day, so adding up daily unique users overstates the true weekly or monthly total.

Sources: User metrics, sessions, key-event counting, engagement, source scopes.

11. Reporting and Exports

Sampling. Sampling uses a subset of events to estimate a query result. Google documents a limit of 10 million events for event-level queries in standard properties. This is a query threshold, not a monthly collection limit, so inspect the data-quality indicator for the report you are using.

Keep these other reporting mechanisms separate. They change what a report shows for different reasons:

• Privacy thresholds can withhold data from a result to protect individual privacy, so a blank cell or a suppressed row does not always mean zero activity.
• High-cardinality reporting: when a dimension has more distinct values than a report can hold, GA4 groups the overflow into a single (other) row, so individual values disappear from that report.
• HLL++: to count unique users and sessions quickly, GA4 estimates them with an algorithm (HLL++) instead of tallying every ID, so these totals are close but not exact, even in unsampled reports.
• Retention settings affect access to older event-level data in tools such as Explorations, but not standard aggregated reports; the standard default is the shorter option, so older event-level detail is often missing unless the longer setting was selected in advance.

BigQuery is not a recovery tool. It helps inspect exported events, but it does not recover events that were never collected. Standard daily export has a one-million-event limit, streaming export is best effort, and behavioral modeling is not included. The daily export tables are dated in the property time zone while event_timestamp is recorded in UTC, so align dates, time zones, late-arriving records and metric definitions before comparing it with the interface.

Demographics availability and deletions. Google Signals governs whether demographic and interest reports have data; with it off, those reports are sparse. Separately, an approved data-deletion request permanently removes past events, which can change historical reports after the fact.

How to test and measure impact

• Save the report dates, filters, data-quality indicators and export status alongside each comparison.
• Remember that the sampling percentage is not a margin of error.
• Treat BigQuery as an export of what was collected, with its own limits, not a way to recover data that was never collected.
• Check whether Google Signals is on, and whether any data-deletion request has run, before treating a demographics gap or a historical drop as a tracking fault.

Sources: Sampling, thresholds, other row, HLL++, retention, freshness, BigQuery, Google Signals, data deletion.

12. AI Access and Influence

Four different things can happen, and only some create GA4 events: an AI crawler can fetch a page without creating a GA4 event; an assistant can retrieve content on a person's behalf; a browser-based agent may execute the analytics tag and generate events; and a person clicking a citation creates another, distinct kind of visit.

Crawler roles differ. These are technical conditions, not a claim that every AI service behaves identically. OpenAI, for example, distinguishes search crawling, training crawling and certain user-triggered page visits in its agent documentation.

Query fan-out is not a visit count. Google describes query fan-out as issuing multiple related searches while preparing an answer. Ten searches do not imply ten visits to your website. A page may already be indexed; fetching it, citing it and a person clicking it are separate events.

Use server or CDN logs. Use them to investigate requests for content. A verified bot request is evidence of access, not proof of citation or human exposure. GA4 automatically excludes known bots, but that does not guarantee exclusion of every new agent.

How AI clicks are classified. When a person clicks through from an AI product, the visit is recorded. Until 2026 these referrals landed in the generic Referral channel (source hosts such as chatgpt.com or perplexity.ai), so they were easy to miss. GA4 has since added a native AI Assistant channel that groups recognized assistants (ChatGPT, Gemini, Claude and others) into their own row in the default channel group. Confirm your main AI sources appear there, and add a custom channel-group rule above Referral for any that are not yet recognized.

Influence without a visit. When someone reads an AI answer without visiting, there is no site session for GA4 to record. A later visit may also lack the earlier AI context. That limits attribution, even when website tracking works correctly.

How to test and measure impact

• Report verified AI requests as a share of a clearly defined set of server (HTTP) requests.
• Report the human visits you can identify as coming from AI as a share of a separately defined set of sessions.
• Remember that neither number captures all AI influence, and a bot fetching a page does not prove it was cited, part of a fan-out, or seen by a person.
• There is no single "add X%" correction that fixes AI undercounting; the size of the gap depends on your site and its sources.

Sources: OpenAI agent roles, Google AI features and fan-out, GA4 known-bot exclusion.

How to Check This in GA4

Most checks above map to a small set of hands-on tools. The core loop is the same every time: mark your own test traffic so you can find it, trigger the action, then confirm what actually arrived. Use it to test local changes, new events, sources and journeys; the extra checks after it cover specific areas.

The Core Test Loop

1. Mark your test traffic so you can isolate it. Before testing, make your own visits findable. Any of these works:

• add a unique query parameter to the landing URL, for example ?qa=jane-0917, and keep it through the journey;
• use a unique campaign source, for example utm_source=qa-test;
• turn on debug mode so your device appears only in DebugView. The simplest ways are the Google Analytics Debugger Chrome extension or GTM Preview mode (both route your hits to DebugView); server-side, send debug_mode: true.

2. Watch the raw request (browser DevTools). Open the Network tab, filter for collect, and do the action. Each hit shows the event name and its parameters (client ID, consent state, page location, value, currency). This is the ground truth before GA4 processes anything, so it is best for collection, consent, duplicates and ecommerce payloads (areas 1, 2, 6, 7).

3. Confirm events and parameters (DebugView). In GA4, open Admin > DebugView. It shows your debug device's events in near real time, with the parameters and the consent state on each event. Best for consent mode, event meaning, custom definitions and server events (areas 1, 7, 8, 10).

4. Confirm the hit arrived (Realtime). The Realtime report shows roughly the last 30 minutes. Find yourself by your unique source or a filter on your test parameter. Good for a quick "did it reach GA4", but it is short-lived and shows limited detail.

5. Inspect the full journey later (Explore). In the GA4 Explore section, after processing (allow up to 24 to 48 hours), open an exploration and filter by your unique URL parameter or campaign source to isolate the test sessions, then:

• use the User explorer technique to read one visitor's event stream in order, which is ideal for identity, session stitching and attribution (areas 3, 4, 5);
• use a free-form or path exploration to check page_view counts, engagement and channels (areas 6, 10).

Prerequisite for seeing URLs in Explore. To filter on, or even see, the full page URL (with your ?qa= parameter) inside an exploration or User explorer, first register page_location as an event-scoped custom dimension in Admin > Custom definitions. Custom dimensions are not backfilled, so add it before you run the test.

Extra Checks for Specific Areas

Check tag firing and consent order (Tag Assistant or GTM Preview). These show which tags fired, the dataLayer, and the order of consent initialization on a fresh visit and a returning visit, which is the fastest way to test CMP defaults and timing (area 1, checks 04 to 06).

Validate server events (Measurement Protocol). For server-side sends, use the validation endpoint (/debug/mp/collect) and inspect the result; a normal response from the live endpoint does not prove the payload was valid (area 8).

Reconcile exact numbers (BigQuery and your backend). For revenue, order IDs and unique counts, query the raw export and compare it with the interface - and, where you can, with the actual sales from your payment processor or order backend, which is the real source of truth (areas 7, 11).

Investigate machines and AI (server or CDN logs). GA4 never sees a bot fetch that does not run the tag. Use server or CDN logs to see crawler and AI-agent requests, and keep them separate from human sessions (areas 9, 12).

Audit what is already being excluded (Admin). Open Data Filters in Admin and check each filter's state: an active internal, developer or custom filter permanently removes matching events, while a testing filter only tags them. Review the internal-traffic IP rules and any unwanted-referral or cross-domain settings too, and check whether granular location and device data collection is disabled for any region (which removes location and device detail for those users). This is where legitimate traffic is most often dropped by mistake and then forgotten (area 9, checks 53 to 55).

Confirm cross-domain setup (Admin). In your web stream, open Configure tag settings > Configure your domains and check that every domain in the journey is listed. Then walk the real transition and confirm the _gl parameter is carried across and the session does not restart with your own site as a self-referral (area 5, check 29).

Tip: keep a reusable "QA" landing parameter and, optionally, a debug audience or an internal-traffic rule, so you can repeat these checks without hunting through live traffic each time.

The Bottom Line

GA4 will never be perfectly accurate, and that is usually fine. Use the checks above when a specific problem shows up in your reports, to know where to dig, or when you analyze a particular segment, to see where its data might be off. And remember that even inside one GA4 account, two people can pull two different numbers for the same thing; the subtleties above are what help you explain the difference.

I'm Irina Saprykina, and I've worked in SEO and digital marketing since 2006, mostly in-house, promoting international SaaS companies. I'm a mathematician by training, which is probably why I'd rather test and automate a process than take a claim on faith. datairi is where I publish those experiments and the tools that come out of them.

Connect on LinkedIn →