Why isn't counting `session_start` events enough to count sessions?

Because the event is produced from a flag on the session's first request, and the flag can get lost on the way. When a parameter-restricting transformation in server-side Google Tag Manager (GTM), a restricted trigger or a consent check drops the first request, the session exists but `session_start` does not. The reverse is possible too: under advanced consent mode every page of a non-consenting visitor can produce its own `session_start`. The correct count is the number of distinct combinations of `user_pseudo_id` and `ga_session_id`.

Why do daily session counts add up to more than the monthly total?

In GA4 a session is not cut at midnight, but it spreads across daily tables. A session that starts at 23:50 and ends at 00:10 has events in two separate `events_` tables and is counted on both days. The right approach is to anchor the session to the timestamp of its first event and write it to a single day. The time zone has to be given explicitly when doing this: `event_timestamp` is always UTC, while `event_date` is produced in the property's reporting time zone. Mixing the two in one query produces a session shift that does not exist and puts sessions near the day boundary on the wrong day.

The purchase source shows `direct / none` but the user came from an ad. How do I verify this in BigQuery?

Pull the session containing the purchase by its key and check whether it has a `page_view`. If the session has no `page_view` at all and only one or two events, it is not a visit but a detached server-side send. Then measure the gap between the end of the previous session and the start of this one for the same `user_pseudo_id`; if the gap is below the property's timeout, the break is certain.

Why does a purchase sent through the Measurement Protocol open its own session?

The Measurement Protocol was designed to enrich an existing session, not to create one. The session identifier is not added to these sends automatically, so unless the `session_id` parameter is carried explicitly the event cannot be attached to any session and its source stays empty. A made-up identifier has the same result: a value GA4 has never seen does not match a valid session.

Doesn't data from visitors who reject consent reach BigQuery at all?

With advanced consent mode it does. The event row arrives, but `user_pseudo_id` and `ga_session_id` are empty. In basic consent mode the tag is fully blocked, so no row at all arrives from a non-consenting visitor. The distinction is made through the `privacy_info.analytics_storage` field, and its values are case sensitive.

Will the GA4 interface and BigQuery numbers ever match exactly?

No, and they should not be expected to. The interface approximates unique counts with HyperLogLog++, BigQuery counts exactly. On top of that come sampling, `(other)` grouping at high cardinality, cross-device deduplication with Google Signals and modelled data. In Google's own example the two systems show 1,463 and 1,501 sessions, but both give the same weekly change. The comparison is for reading direction, not for making the numbers equal.

Session Integrity from Landing to Purchase: Counting the Break in BigQuery

If GA4 session counts look right but purchases show up without a source, the problem is usually not the attribution model but a session split in two. The correct session key, how session_start relates to attribution, numeric proof of the break, how consent rows affect the count, and a health scorecard that tracks integrity between landing and purchase, built step by step with BigQuery queries.

2026-08-31 Updated: 2026-10-14

TL;DR

In GA4 a session's identity does not live in one field: user_pseudo_id and ga_session_id together form the key. The source is carried on session_start, so every session missing that event is also missing its source. Whether integrity between landing and purchase is broken shows up not in the interface but in countable signatures in the BigQuery export. This post gives those signatures, their queries and the threshold for intervention.

Create Free Account Sign In

The Rest of This Post Is for Members

You can read this post and the other members-only posts for free.

analytics

The Rest of This Post Is for Members

RELATED

Linking a Banner Click to a Purchase: Promotion Events, the Carrier Layer and the Consent Boundary

GA4 Landing Page (not set): A Diagnostic Playbook

Tracing the Source of GA4 and Ads Signals in Shopify

Measuring Consent Rate: Where Accepts, Rejects and Later Changes Get Counted

Joining Google Ads and GA4 at Row Level: A Shared Key and a Two-Layer Reading

Connecting a Shopify Order to an Ad Click: Choosing a Join Key for Offline Conversions

GA4 Source/Medium Debugging: Detecting the Real Source with First-Party Cookies

Measuring Purchase Lag: Google Ads Reports, the GA4 Gap and the Window Decision

Deriving ID and Slot for E-Commerce Homepage Banners

Why Google Ads and GA4 Conversions Never Match: Counting Unit and Time Axis