GA4 can receive a pageview without a persistent browser identifier. Receiving an event and linking it to other events are different things. That distinction matters when you are explaining users, sessions or a change in reported traffic.
The identifiers in your implementation do different jobs. A Client ID identifies a browser instance. A User-ID is supplied by your business. A session ID groups activity within a session. None of those is the name of a cookie, and they are not interchangeable. Simple Analytics takes a different route: it creates no visitor identifier and no persistent session ID, and calculates session starts from pageview context, which is why its counts are not interchangeable with GA4's either.
This guide focuses on the identifiers a web analyst needs to check when investigating GA4 measurement.
Client ID and cookies are different things
On websites, GA4 uses the Client ID as its device identity. In a typical cookie-based implementation, the _ga cookie supports recognition of that browser over time. Google also documents _ga_<container-id> cookies for persisting session state. The cookie is the storage mechanism; the identifier is a value used in measurement. GA4 cookie documentation.
Do not read a Client ID as a count of people. One person can use several browsers or devices, and several people can share a browser. Clearing cookies or losing access to browser storage can also break continuity.
The fact that different websites use a cookie named _ga does not mean they share the same visitor ID. Cookie names and cookie values are different. Cross-domain measurement requires configuration; it is not established by matching cookie names. Google's cross-domain measurement guide.
User-ID comes from your own implementation
User-ID lets you send a consistent identifier for a user you recognize, usually after sign-in. If you send the same ID across devices, GA4 can associate that activity. Google does not generate your business's User-ID for you.
Implementation errors matter here. Sending one placeholder ID for everyone can combine unrelated activity. Failing to clear the ID after sign-out can associate later activity with the wrong account. Google specifies null to clear the value, rather than a shared dummy string. User-ID must also comply with Google's restrictions on personally identifiable information. Google's User-ID guide.
Check what your application sends on sign-in, sign-out and account switching. A populated field is not enough to establish that the identity is correct.
A session ID is not a user ID
With automatic collection through the Google tag or Firebase SDK, GA4 generates ga_session_id when a session starts. Its value is the session's start timestamp in seconds, so the session ID alone is not globally unique. Google recommends combining it with user_id or user_pseudo_id when distinguishing sessions outside GA4. Session identifiers are not automatically included in events sent through Measurement Protocol or Data Import.
GA4 normally ends a session after 30 minutes of inactivity, although the timeout can be configured. Its session definition therefore depends on both identity and timing. Google's session documentation.
If you work with exported data, record the session definition used in your query. Counting distinct session timestamps across the whole dataset can combine sessions belonging to different users. Inspect missing identifiers separately; a session key cannot be constructed from a field that is absent.
Counting session_start events does not reproduce GA4's Sessions metric. Google uses approximate distinct counting (HyperLogLog++) for reported session counts. This counting approximation is separate from Consent Mode's behavioral modeling. Even an exact count of session keys in BigQuery is therefore not guaranteed to match the report. How GA4 calculates sessions.
Know which identifier you are inspecting
| Field or concept | What it represents | What to check |
|---|---|---|
| Client ID | The device identity used for web reporting. | Whether the same browser retains it where collection is permitted. |
User-ID / user_id |
An identifier supplied by your business. | Correct assignment and clearing after sign-out. |
ga_session_id |
The start timestamp used as a session identifier. | Pair it with a user identifier when constructing a session key. |
user_pseudo_id |
The pseudonymous user identifier in the BigQuery export. | Its availability and meaning for the stream being queried. |
| App-instance ID | The device identity used for app reporting. | Keep app and website measurement definitions separate. |
Google documents the export fields in its BigQuery schema and the web/app identity distinction in its reporting identity documentation. Advertising identifiers serve other purposes; they are not substitutes for the web Client ID in this comparison.
Denied consent changes what can be linked
With basic Consent Mode, Google tags are blocked until consent. With advanced Consent Mode, tags can send cookieless measurements while analytics_storage is denied, without reading or writing analytics cookies. Receiving those events does not give GA4 the normal persistent cookie identifier needed to connect them. Google's Consent Mode documentation.
Do not assume Consent Mode removes every identifier your application supplies. Google explicitly notes that collected User-ID data is exported to BigQuery regardless of consent status. Review whether your implementation sends user_id when it should not. User-ID collection and export.
Where eligible, GA4 can use behavioral modeling to estimate user and session metrics from the behavior of consenting users. An estimate does not recover a persistent identity for each visitor who rejected consent. Cookieless collection alone does not guarantee modeling eligibility. Behavioral modeling requirements.
Reporting identity can change the result without changing collection
GA4 offers three reporting identity options:
- Blended: User-ID, device ID, then modeling where available.
- Observed: User-ID, then device ID.
- Device-based: device ID only.
Google states that changing this setting does not change data collection or processing. When user counts differ between reports or reviews, record the selected identity before diagnosing a collection problem. Reporting identity settings.
GA4's Observed setting is a specific reporting option. It is not a claim that all website traffic has been collected, and it is not the same thing as Simple Analytics' observed pageviews.
What a baseline without visitor IDs can answer
Simple Analytics records pageviews and events without creating a persistent visitor identity. It calculates session starts from pageview context, including the referrer. It does not reconnect those records into a person's cross-visit journey. How Simple Analytics measures sessions without consent.
For an analyst, that creates a useful comparison alongside GA4. Start with pageviews over the same pages, period and time zone. Validate both installations and document collection and reporting differences. Compare session trends separately, with each tool's definition attached.
If GA4's user count changes while pageviews remain stable, inspect identity availability and reporting settings as possible explanations. The pattern does not prove the cause. Likewise, an independent dataset is only a baseline for the events it successfully collects, not a guarantee of complete coverage.
Keep GA4 for analysis that needs its user identities and attribution capabilities. Use Simple Analytics to answer the aggregate traffic questions that do not require recognizing the visitor.
Free 30-day proof of concept
Compare Simple Analytics with GA4 on your website
Run a free 30-day proof of concept alongside your existing GA4 setup and CMP.
We help you:
- Agree on the measurement question, metrics, pages and comparison period.
- Set up Simple Analytics, including support for proxies and custom domains where needed.
- Review the counts, trends and methodological differences together.
Tell us what you want to compare. We’ll agree on the scope of the POC together.