How GA4 collects data, and why your reports can differ

Google Analytics 4 collects website data as events. In a typical setup, a Google tag running in the browser sends events such as page_view to a collection endpoint. Each event carries parameters describing what happened. GA4 processes that data into reports.

Collection and reporting are separate steps. A request can leave the browser without appearing in the report you're looking at. Two reports can also show different numbers from the same property. Running an independent tool such as Simple Analytics alongside GA4 gives you a second count to check those numbers against.

This guide follows a website pageview through that process: what the tag sends, how identifiers and consent affect measurement, and what to check when the numbers don't agree.

Follow a pageview from the browser to GA4

In a typical browser implementation, the Google tag runs on your website, either installed directly or deployed through Google Tag Manager. Your configuration determines which events it sends and which web data stream receives them. GA4 uses those events and their parameters to build reports. Google Tag Manager manages when tags run; GA4 receives and reports the analytics data. Google's event setup documentation describes the event-based collection model.

Some events are collected automatically. Enhanced Measurement adds supported interactions when enabled; recommended business events such as purchase still need implementation. Installing the tag does not automatically instrument every business action.

Take a visit to /pricing. The Google tag's configuration normally sends a page_view, with values such as page_location and page_title. That is a measurement event describing a page view. It isn't, by itself, a count of a distinct person.

<div class="collection-flow" aria-label="Typical browser collection path">Page interaction→Tag and consent settings→Collection request→GA4 processing→Report</div>

Single-page applications need particular attention. Enhanced Measurement can send pageviews when browser history changes. If your application also sends its own pageviews, verify that one navigation produces the intended number of events. Disabling the initial pageview with send_page_view: false does not disable Enhanced Measurement's history-change pageviews. Those have a separate setting. See Google's pageview implementation guide.

With server-side tagging, requests can first reach a server container that processes and forwards them. Inspect both stages when diagnosing delivery. Separately, backend systems can send events through the Measurement Protocol. Google describes Measurement Protocol as a supplement to browser or app collection. Those backend events won't appear in the browser's network log.

Where cookies and identifiers fit

With Analytics storage permitted, the Google tag uses first-party cookies: _ga distinguishes users and _ga_<container-id> persists session state. Cookies support continuity between events; they are not required simply to transmit an event. See Google's GA4 tagging and cookie documentation.

This distinction matters. Receiving several pageviews does not necessarily give GA4 the persistent identifier needed to associate them with the same user. Consent Mode changes which identifiers can be used, as explained below.

Separate event collection from reported metrics

Before comparing numbers, write down the metric and its definition. “Traffic” is too broad to reconcile.

For normal identifier-based collection, GA4 creates a session ID when a session starts. The default inactivity timeout is 30 minutes and can be changed. When querying exported data, ga_session_id alone is not a globally unique session key: Google's guidance combines it with a user identifier. Missing identifiers need separate treatment; a query cannot reconstruct an identity that was never collected.

GA4 uses HyperLogLog++ approximate distinct counting for session metrics in its reporting interfaces. This is different from behavioral modeling: approximating the number of distinct session identifiers is not the same operation as estimating behavior where persistent identifiers are unavailable. Google's session documentation describes session IDs, timeouts and approximate counting.

Reporting identity adds another choice. Blended can use User-ID, device ID and modeling; Observed uses User-ID and device ID; Device-based uses device ID. Changing this setting changes how data is reported, not which requests your tag sends. Record it before comparing results. Reporting identity documentation.

What changes when analytics consent is denied?

“GA4 is installed” doesn't tell you what happens after someone rejects the banner.

With basic Consent Mode, Google tags remain blocked without consent. With advanced Consent Mode, tags can send cookieless measurements while analytics_storage is denied, without reading or writing Analytics cookies. These pings can include consent state, timestamp, referrer and User-Agent. Google's Consent Mode overview documents both implementations.

Behavioral modeling is a further step. It estimates behavior using consenting traffic from the property; enabling Consent Mode does not guarantee that a property qualifies. Google specifies minimum data thresholds and additional model-quality requirements.

Check the reporting identity and the report's data-quality indicator. In reports, Google applies behavioral modeling to metrics such as users and sessions, not to event counts such as page_view. However, modeling eligibility also affects whether denied-consent events are reportable. An unmodeled event count is therefore not automatically a count of every event received. Path and funnel explorations have additional modeling differences. Behavioral modeling documentation.

The collection behavior and the report's modeling status need to be checked separately. Finding a cookieless request in the browser does not establish how it contributes to your chosen report.

Trace a discrepancy before explaining it

Start with a reproducible browser test, then check the report. That lets you separate an event that never fired from one that was sent but is absent from the selected output.

Reproduce the collection behavior

Use separate browser profiles or clear the site's cookies and storage between tests so a previous consent choice doesn't affect the result. Test before interacting with the banner, after rejection and after acceptance. Test the initial landing page, an internal navigation and the event you're investigating. Include a history-based navigation if the site is a single-page application.

In Tag Assistant, inspect the consent state and the sequence of defaults, updates and tag execution. Defaults must be set before tags use consent state; a later denied default cannot undo an earlier cookie write. Google's Consent Mode debugging guide shows where to inspect this sequence. In browser developer tools, inspect the outgoing requests: destination, event name, page URL and whether a single action creates duplicate requests. If you use server-side tagging, also inspect what the server container receives and forwards.

For a fresh page load with pageview measurement enabled, these are the expected collection behaviors once the consent state has been applied. Assume the implementation is working and no separate browser or network restriction blocks it:

Check the event payload as well as the request count: request count alone is not an event count. Record the event name, destination stream, page URL and consent state. Then repeat for internal navigation and the selected business event. Keep the expected business-event trigger separate from automatic pageview behavior.

Use DebugView to inspect eligible debug events, but don't make it your only denied-consent check. Google explicitly says events are not visible there when Analytics cookie consent has not been given. An empty DebugView is not proof that the browser sent no cookieless requests. DebugView documentation.

Align the comparison

Choose a period whose data has had time to process. Record the timezone, hostname, page scope, event definition and filters on each side. For an initial collection comparison, start with pageview events for the same pages rather than comparing unlike session definitions.

Check deployment history around the change: CMP updates, tag changes, new templates, routing changes and collection-endpoint changes. Then look for patterns by page, device and date. A drop beginning with a release on one template is a different lead from a decline across every page.

A successful browser test confirms that tested path under those conditions. It doesn't establish collection coverage for every visitor, browser or page.

Check the reporting surface

Record whether the number comes from a standard report, an exploration, the Data API or BigQuery. Review any data-quality messages before treating those outputs as equivalent. Check for different filters, retention windows and processing times before comparing a report with an exploration. Google's reporting comparison explains these differences.

BigQuery exports event and user-level data without all the additions made in GA4 reporting. Behavioral modeling is not exported. For a historical comparison, use the daily events_YYYYMMDD tables rather than treating the best-effort streaming export as complete, and check export limits and late-arriving data. A mismatch with a blended report alone doesn't prove a broken export. BigQuery Export documentation.

What an independent dataset can add

After these checks, you may still need a baseline that doesn't depend on Analytics cookie acceptance. This is where running Simple Analytics alongside GA4 can help.

Simple Analytics records pageviews and events without creating a persistent visitor identifier. It calculates session starts from pageview context, including referrer and navigation behavior. Those are different session semantics from GA4, not a reconstruction of GA4's missing users. The collection rules and trade-offs are explained in how Simple Analytics measures sessions without consent.

For example, compare daily pageviews for the same pages and timezone. If GA4 pageviews fall while Simple Analytics pageviews remain stable, investigate the divergence: consent settings, tag releases, filtering and which events GA4 includes in the selected report. The comparison narrows the investigation; it doesn't identify the cause on its own.

Review session trends separately, with each tool's definition alongside the chart. Don't label the difference between their session totals as the number of visitors who rejected consent.

The same discipline applies to campaigns. Ad clicks, landing-page views and sessions are different units. A difference between them doesn't, on its own, measure wasted spend or the number of people who never reached the site.

Simple Analytics also doesn't connect a person's separate visits into a cross-visit conversion journey. Keep GA4 for the analysis that needs its identifiers and attribution capabilities. Use the independent dataset for the aggregate measurement questions it can answer.

Validate both installations before relying on the comparison. Missing scripts, duplicate events and blocked requests can affect the baseline too. More recorded events do not automatically mean a more accurate implementation.