How User ID works
By default, analytics recognises a browser rather than a person. It writes an identifier into the device and treats every visit from that device as the same user, which means one customer using a phone, a laptop and an office computer arrives as separate users who never meet inside a report.
User ID replaces that guess with something you already know. When someone signs in, your site takes the internal reference your own database holds for that account and passes it to analytics with every hit, and the platform uses it to stitch those sessions together. Google Analytics 4 then offers a reporting view built on that identifier, falling back to the device-based one for visitors who never log in.
Why User ID matters
It changes what you are able to ask. Without it, a returning customer looks like new traffic every time they switch device, so repeat purchase behaviour, the true length of a sales cycle and any measure of customer value are all understated. With it, the record follows the account rather than the hardware.
It also corrects the raw counts. Device-based measurement inflates users and deflates engagement, because it splits one journey into fragments and treats each as a stranger. For a business with logged-in customers — a subscription, a client portal, an ecommerce account, a remittance app — the identifier is often the difference between analytics describing sessions and analytics describing customers. It rests on the same asset that makes first-party data valuable everywhere else: information you hold yourself.
Where User ID goes wrong
The dangerous mistake is sending something that identifies the person. Email addresses, phone numbers, full names and government identity numbers must not be used as the identifier. Google’s terms forbid personally identifiable information in Analytics, and once it is in the property the usual remedy is deleting the data. Send an opaque internal reference instead: a hashed value or a database key that means nothing outside your own systems.
The quieter failures are about consistency. If the identifier only fires on some pages, the sessions split anyway. If your website and your mobile app use different references for the same customer, the join never happens. If a customer’s reference changes when they update their account, their history breaks in half. And browsing done before sign-in cannot be retrofitted, because the platform can only join what it sees from the moment the identifier appears.
How to act on it
Start by deciding whether you have the raw material. If very few visitors ever log in, this is effort spent on a thin slice of traffic, and the analytics work is better aimed at event quality and conversion measurement. Where logins are central to the business, treat the identifier as part of the login flow rather than a marketing extra, and specify it with whoever builds the site.
Then test it properly. Confirm the value is present on every page after sign-in, that it survives navigation, that it matches between web and app, and that it never leaks into a URL or a page title where it would end up printed in reports. Document what the identifier maps to internally, and cover it in your privacy notice alongside the rest of your analytics and tracking disclosures.