GA4 User-ID: what it fixes, what it doesn't, and consent

Short answer: User-ID sends your own login identifier to GA4 so one person's phone, laptop and tablet stop counting as three users. It fixes cross-device counting for signed-in traffic and nothing else. It is not a way to recover data a visitor declined, and it is not covered by the UK's analytics exception to the cookie rules: the ICO's finalised guidance says the statistical purposes exception "is about how your service is used, not about who uses it", and that you must obtain consent for "connecting a visitor ID to their site activity" (ICO, checked 13 August 2026). If you're switching it on to make your user counts look better, you'll get a smaller number and a new legal question.

User-ID joins events to a person you already identified

It carries no intelligence of its own. You mint the identifier, you send it, Google joins on it.

Google's description is narrow: the feature "lets you associate your own identifiers with individual users so you can connect their behaviour across different sessions and on various devices and platforms" (Analytics Help, checked 13 August 2026). The identifier must be one you already hold — a customer number, a hashed account key — assigned at login and used consistently. It must be 256 characters or less, and it "must not contain information that a third party could use to determine a user's identity", which rules out an email address, a raw phone number and anything else that reads as a person on sight.

Two limits shape what you get. The first is that it only applies to signed-in traffic; a visitor who never logs in has no user ID, so GA4 falls back to the device identifier as it always did. The second is that it doesn't reach backwards: "any data in your Analytics account collected and recorded prior to implementation won't be reprocessed and associated with a user ID" (Analytics Help, checked 13 August 2026). Whatever cross-device history you were hoping to recover isn't coming.

There's also an expiry nobody plans for. Google's data retention control applies "to user-level and event-level data associated with cookies, user-identifiers, such as User-ID" (Analytics Help, checked 13 August 2026), and the standard options are two months or 14 months. Your cross-device joins live inside that window. Beyond it, the aggregated reports survive and the user-level detail does not.

Your active-user counts change because the counting rule changed, not the traffic

Nothing about collection changes. What changes is which identifier GA4 uses to decide whether two event streams are the same person.

GA4 offers three reporting identities. Blended works "by User-ID, device ID, then modelling", Observed works "by User-ID, then device ID", and Device based "uses only the device ID and ignores all other IDs that are collected" (Analytics Help, checked 13 August 2026). Switching between them is a reporting choice, not a collection one: Google states the option you choose "does not affect data collection or processing" and that you "can switch between the options at any time without making any permanent impact on data".

Read those two facts together and the shape of the change falls out. Once you send user IDs and pick an identity that uses them, a signed-in person on two devices resolves to one user rather than two, so counts of users fall while sessions and events stay where they were. Google frames the same mechanism as an improvement — "Analytics interprets each user ID as a separate user, which provides you with more accurate user counts" (Analytics Help, checked 13 August 2026) — and both descriptions are true at once. The number gets smaller and more honest.

How much smaller depends entirely on how many of your customers log in on more than one device, and Google publishes no figure for it. Neither does anyone else: we went looking for an independent study of typical User-ID de-duplication rates and there isn't one, so treat any percentage you've been quoted as a guess. The way to find out is to run the same date range under Device based and under Observed and read the difference off your own property.

One nuance saves an argument later. The identity switch applies at query time, so flipping it re-cuts history you already have. The user IDs themselves only exist for data collected after implementation. So the step in your charts appears on the day collection started, not the day you changed the setting.

The lawful-basis question is the one that decides whether you can do this at all

Consent, in almost every case, and the analytics exception won't rescue you.

UK rules changed under the Data (Use and Access) Act, and the ICO finalised its guidance in April 2026. There is now a statistical purposes exception — the analytics exception — that lets you store and access information on a device without consent when the sole purpose is "to collect information for statistical purposes about how the service is used with a view to making improvements to the service" (ICO, checked 13 August 2026). Plenty of teams read that as permission to run analytics without a banner.

It doesn't stretch to User-ID. The ICO is explicit that the exception "is not for identifying, tracking or monitoring people or groups of people who use your service", that the resulting information must be aggregate statistical information "that you cannot use to identify people", and that consent is required for "connecting a visitor ID to their site activity" and for "monitoring the browsing of website visitors across different services and applications" (ICO, checked 13 August 2026). Joining a logged-in customer's sessions across their phone and their laptop is the exact activity named there.

Then there's the order of operations. The ICO's position is that where storage and access technologies are in use you "must consider PECR compliance before you look to the UK GDPR", and that if you have to obtain consent for that storage and the information is personal data, "you should use consent as your lawful basis under the UK GDPR for subsequent processing" (ICO, checked 13 August 2026). You don't get to gate the cookie on consent and then process the identifier under legitimate interests.

Google's own terms land in the same place. Its Measurement Protocol, SDK and User-ID feature policy says you "must not session stitch authenticated and unauthenticated sessions of your end users unless your end users have consented to such activity, and such merger is allowed under applicable laws and regulations" (Google for Developers, checked 13 August 2026), and its EU user consent policy requires consent for "the use of cookies or other local storage where legally required" (Google, checked 13 August 2026). Both are contractual obligations to Google on top of whatever the regulator does. This isn't legal advice, and the enforcement picture around the new exceptions is young — but the documents above are the ones your DPO will read.

Google confirms one leak and says nothing about the other

Sending an identifier and gating it on consent are separate jobs, and the second one is yours.

The confirmed leak is in the export. Google states plainly: "When you collect user IDs and you have linked Analytics to BigQuery, that information is exported to BigQuery regardless of the consent status of your users" (Analytics Help, checked 13 August 2026). If your data warehouse is meant to be the consent-clean copy, that sentence deserves a meeting.

The silence is in consent mode. Google's consent mode documentation sets out what analytics_storage denied means for cookies and describes URL passthrough for measurement without them, but it does not state whether a configured user_id is stripped from those cookieless pings (Google for Developers, checked 13 August 2026). We're not going to guess on your behalf. Open your browser's network tab, decline everything, trigger a page view as a logged-in user and look for the uid parameter on the request to Google. If it's there, your identifier is travelling on a hit the visitor refused, and the fix is in your tag configuration rather than your CMP: set the user ID from a variable that reads consent state, so it's populated only after a grant.

What to do this week

If User-ID is already live, run the two-identity comparison before anyone panics about a drop, and write the date collection started on the chart so the step has an explanation attached to it.

If it isn't live yet, settle the consent question first. Decide where the identifier is set, confirm it only populates after a grant, and check the BigQuery export against what you told people in your privacy notice.

And when the numbers still disagree with each other, remember that the reporting identity is only one of the reasons two GA4 surfaces show different figures — funnel and path explorations sample and threshold differently from standard reports, which produces the same argument with a completely different cause. Getting the whole chain right, from the consent signal through the tagging layer to what the bidding platform receives, is what we do.

Sources

1. 1.Analytics Help — [GA4] Measure activity across platforms with User-ID · Checked 2026-08-13
2. 2.Analytics Help — [GA4] Reporting identity · Checked 2026-08-13
3. 3.Analytics Help — [GA4] Data retention · Checked 2026-08-13
4. 4.Google for Developers — Measurement Protocol, SDK, and User-ID Feature Policy · Checked 2026-08-13
5. 5.Google — EU user consent policy · Checked 2026-08-13
6. 6.ICO — Guidance on the use of storage and access technologies: what are the exceptions? (April 2026 update) · Checked 2026-08-13
7. 7.ICO — How do the PECR rules relate to the UK GDPR? · Checked 2026-08-13
8. 8.Google for Developers — Consent mode implementation guide · Checked 2026-08-13