Almost every user-level query against the GA4 export leans on one column, user_pseudo_id, and almost everyone slightly misunderstands what it counts. Getting it right is the difference between honest user numbers and confidently wrong ones. Here is what it actually is.

What user_pseudo_id is

user_pseudo_id is a pseudonymous, device-level identifier that GA4 assigns to a browser or app instance. On the web it is derived from the client ID stored in GA4's first-party cookie; in an app it is tied to an app-instance ID. It identifies a device-and-browser, not a person, and that distinction drives everything else.

Why it is not a person

Because it is anchored to a cookie or app instance, one human easily becomes several user_pseudo_ids, and occasionally several humans become one:

  • The same person on a phone and a laptop is two different IDs.
  • Clearing cookies, switching browsers, or using incognito creates a new ID for the same person.
  • A shared device can put several people behind a single ID.

So a distinct count of user_pseudo_id is really a count of devices-and-browsers, which slightly overstates real users.

user_pseudo_id vs user_id

GA4 also has a separate user_id field, which is an identifier you assign when a user logs in, and it can follow that person across devices. user_pseudo_id is always present but device-bound; user_id is person-level but only populated for authenticated users. Serious cross-device analysis uses user_id where it exists and falls back to user_pseudo_id where it does not.

Using it correctly

Treat user_pseudo_id as the reliable key for device-level behavior, sessions, and most day-to-day user counts, while remembering it counts devices rather than people. When you need true people, count distinct user_id instead, and expect the two numbers to differ. Consent also matters, since users who decline may not get a stable identifier at all, which is by design rather than a bug.

How it is created and when it resets

On the web, user_pseudo_id comes from the client ID that GA4 stores in a first-party cookie the first time a browser loads your tag. Because it lives in that cookie, it survives across visits on the same browser but resets whenever the cookie is cleared, expires, or is blocked, and a brand-new one is minted. In apps the equivalent is the app-instance ID, which resets on reinstall. Knowing where it is stored explains exactly when it changes.

What it means for privacy and consent

Being pseudonymous rather than anonymous matters legally: user_pseudo_id is not tied to a name, but it is still an identifier and is treated as personal data under regimes like GDPR. Under Consent Mode, users who decline may never receive a stable identifier, so a portion of traffic is modeled rather than keyed. That is deliberate, and it is another reason device counts and real people never line up exactly.

Nearly every user-level query rests on user_pseudo_id, and the trap is reading it as a person when it is really a device-and-browser. Know that it comes from a cookie or app instance, that one person can spawn many of them, and that user_id is the person-level alternative when someone logs in. Hold that distinction and your user counts stop being confidently wrong and start meaning exactly what you say they mean.

Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.