GA4 Reporting Identity and User ID: Why Your User Counts Do Not Add Up

Run the same report twice with the same date range and you should get the same number. Every so often the user count moves a few per cent and nobody changed a tag, a filter or a segment. The cause is a property setting most accounts never open.

GA4 has three definitions of a user, and the property picks which ones to apply when it builds a report. That choice decides whether people are counted by your own login identifier, by a browser cookie, or by a model that estimates the visitors your consent banner blocks. It lives at Admin, then Data display, then Reporting identity.

The three identity spaces

Google's help page lists three identity spaces and calls the chosen combination the reporting identity. The current list is shorter than the one in most write-ups from 2023.

• User-ID. The identifiers you create for signed-in users. Google calls it the most accurate identity space, because it uses data you collect yourself.
• Device ID. On websites the value comes from the client ID. In apps it is the app-instance ID.
• Modelling. When users decline analytics cookies their behaviour is unavailable, so GA4 estimates those users from similar consenting users on the same property.

Google signals is no longer listed as an identity space there. It is data from users signed in to Google who enabled ads personalization, and it is managed as its own collection setting. If your notes mention four identity spaces, they are quoting an older version of the page.

Blended, Observed and Device based

Three options control how sessions get stitched together.

• Blended. By User-ID, device ID, then modelling. It uses the user ID when one is collected, falls back to the device ID when it is not, and uses modelling when no identifier is available.
• Observed. By User-ID, then device ID. Same first step, no modelling.
• Device based. The device ID only. Every other identifier the property collects is ignored.

Blended is the default and always produces the highest user counts, because it is the only option allowed to include estimated users. Google also warns that the full benefit of Blended or Observed depends on collecting user IDs, and on having enough signed-in activity to adequately obfuscate those users. That requirement is what pushes reports into data thresholds. A site with a login wall hits the ceiling faster than a site with a newsletter form.

Where the setting lives and who can change it

Admin, then Data display, then Reporting identity, pick an option, Save. The permission needed is where the documentation disagrees. The Reporting identity page says Editor or above at the account level. The behavioural modelling page and the User-ID implementation page both say Editor or above at the property level, for the same switch. If the option is greyed out, ask which level your access sits at, and escalate with both citations to hand.

What switching actually changes

Google states it plainly: the option you choose does not affect data collection or processing, and you can switch at any time without permanent impact on the data. The switch is safe, but it is not neutral. Historical reports are recalculated through the new lens, so a range you exported last month can come back different. On a property with consent denials, Observed always reads lower than Blended, because estimated users are hidden rather than removed.

One rule worth writing down: never switch reporting identity mid-campaign and present the before and after as performance. You would be measuring the setting, not the work.

When modelled data is available

Blended only includes estimated users if the property qualifies, and the prerequisites are specific.

• Consent mode runs across every page or app screen.
• On the web it is an advanced implementation, so tags load before the consent dialog appears and Google tags load in all cases, not only after consent.
• At least 1,000 events per day carry analytics_storage set to denied, for at least seven days.
• At least 1,000 daily users send events with analytics_storage granted, on at least seven of the previous 28 days.

Meeting those numbers does not guarantee eligibility. Google applies further criteria around the ratio of new to returning users and the relationship between user and session counts, and modelling switches on automatically once a property qualifies.

Where it appears matters as much as whether it appears. In reports, modelling applies to user, session and new-user counts but not to event counts, so unconsented page views and session starts stay as counted. In path and funnel explorations it is applied to first_visit and session_start, which is why those counts come out lower there than in reports. It is unavailable in audiences, user explorer, cohort and user lifetime explorations, segments with a sequence, retention reports, predictive metrics and data exports such as BigQuery. If a retention figure in a board deck comes from the retention report, no modelled users are in it.

What User-ID has to be

User-ID is the strongest signal GA4 holds and the one most often implemented badly.

• You generate the ID and assign it consistently, typically at login. Each ID is 256 characters or less.
• Every user needs a unique, persistent ID. Assigning one ID to two people merges their behaviour. Google's example is John and Mary sharing UserID123: the property reports one user who viewed product A and product B and made a single purchase.
• Never send a dummy or blank value for a signed-out visitor, and stop associating the ID after sign-out. Repeated placeholder values cause inaccurate data, including permanent data loss.
• The Terms of Service require you to avoid impermissible personally identifiable information and to give notice in your privacy policy. The ID must not contain anything a third party could use to determine identity. An email address, or a customer number that resolves in a public system, fails that test. A random internal identifier passes.

Sending it without breaking the reports

Set the user ID in the Google tag configuration, in the fields to set, so every event inherits it. Do not send it as an event parameter, and do not register it as a custom dimension. A high-cardinality dimension like an ID collapses into the (other) row for no gain, which is why Google recommends against it.

The JavaScript values are a quiet source of damage.

• undefined means no user ID goes on the hit, and the event is not logged with a user_id.
• null sends an unset value, and it is the only acceptable value after a user has signed out.
• An empty string also reads as signed out, but null is recommended instead, because empty strings cause coding problems later.
• The literal strings "undefined" and "null" are treated as real user IDs. That is how a property ends up with a user called undefined.

Test the logout path on staging. Log out, trigger a page view, and confirm the hit carries null.

How GA4 joins sessions around sign-in

Google's example explains the behaviour. A user triggers Event 1 and Event 2 with no user ID attached, then signs in and triggers Event 3. Events 1, 2 and 3 are now all associated with that user's ID. The user signs out and triggers Event 4, which carries no ID. Events 1 to 3 keep theirs. If the same user signs back in during the same session on Event 5, that event rejoins the same user.

A sign-in at checkout therefore pulls the anonymous browsing before it into the login ID. Most e-commerce and SaaS teams want that. It is also the behaviour a privacy review will ask you to describe, so have the answer ready.

What you can do with User-ID

• Signed in with user ID. A predefined dimension for comparing sign-in and anonymous behaviour inside standard reports.
• User exploration. The activity timeline of individual users, useful when one client account reports a broken journey.
• Remarketing audiences. Audiences built on user IDs appear in the shared library in Google Ads once the accounts are linked.
• BigQuery. The export carries user_pseudo_id for the device identifier and user_id for yours. That pair is the join key for CRM data and offline imports.

Two limits to state before anyone forecasts from those audiences. With User-ID in use, Analytics includes only the user identifier and the device identifier for the last device associated with each signed-in user. Without it, every device and user identifier is included. Audience sizes will not match your own counts. Separately, data collected before implementation is never reprocessed, and user ID data cannot be mixed between properties.

The UK compliance layer

A user ID is a pseudonymous identifier, and it is personal data as soon as you can link it back, which is the point of collecting it. Lawful basis, transparency and erasure stay your problem.

The BigQuery export is the item most teams miss. Google states that when you collect user IDs and have linked Analytics to BigQuery, that information is exported to BigQuery regardless of the consent status of your users. A visitor who declined analytics cookies can still have their sign-in identifier land in your warehouse. That belongs in your privacy notice and in the warehouse retention schedule.

Retention is the second. The retention period covers user-level and event-level data tied to cookies, user identifiers such as User-ID, and advertising identifiers. On a standard property the user-level options are two months or fourteen months, and other event data adds 26 and 38 months for Analytics 360. The reset switch matters more than most people realise. With reset on new activity turned on, the clock restarts each time the identifier appears, so a user who visits monthly is never deleted. Turn it off if your notice promises deletion after a fixed period. Editor role is needed to change either setting.

Third, the consent position. The ICO's guidance on storage and access technologies expects clear information and prior consent before non-essential storage or access, with a simple means of objecting for anything justified on statistical grounds. A login identifier written to a cookie or local storage is in scope.

What to check this week

1. Record the current reporting identity on every property you manage. One line in the account notes.
2. Check whether the property collects user IDs at all. If it does not, Blended and Observed work from device IDs alone, and modelling carries more weight than anyone assumes.
3. Test the logout path and confirm the value sent is null.
4. Check the data quality warnings for a User ID implementation notice. Malformed IDs surface there first.
5. If Blended is on, note the modelling status and the date the property became eligible, so a step change in user counts has an explanation attached.
6. Compare the retention setting against your privacy notice. If they disagree, the notice is right.

The short version

A GA4 property does not count people. It counts identity spaces, and you choose which apply at the reporting layer. Blended can include modelled users, Observed cannot, and Device based ignores login IDs altogether. Nothing about collection or processing changes when you switch, which is why the numbers move without anything breaking.

User-ID remains the most accurate signal available. It works when the IDs are unique, non-identifying, set on the configuration tag, cleared to null at sign-out, and matched by a retention and privacy position you can defend in writing.