How to Implement GA4 User-ID for Ecommerce

Google describes User-ID as a way to send identifiers generated by the business so Analytics can associate activity across sessions, devices, and platforms. The identifier must be unique and consistently reassigned to the same authenticated user. Begin with a written contract covering the source system, generation method, maximum length, persistence, collision monitoring, account merges, deletion, consent, access control, retention, and owners. Google states that User IDs must be 256 characters or fewer. A technical ability to send an identifier is not authorization; privacy and legal requirements for the business and its jurisdictions still govern the implementation.

Google prohibits identifiers that a third party could use to determine a person's identity. Do not send email addresses, phone numbers, names, raw customer numbers exposed elsewhere, or another directly identifying value. Use an internal opaque identifier under an approved policy. Document whether guest checkout activity remains device-based and when an authenticated identity becomes available. Do not create a dummy User-ID for unsigned users or reuse one shared value. Google warns that assigning the same ID to multiple people combines their activity and distorts reporting. Collision tests belong in the source system and the analytics validation plan.

Create a state table for first visit, consent decision, sign-up, sign-in, authenticated browsing, checkout, purchase, sign-out, account switch, password reset, and account deletion. For every state, specify whether collection is permitted, whether User-ID is present, and which device or session identifier remains. Google explains that null is the acceptable value after logout to clear the former User-ID, while blank strings and literal strings such as undefined or null can be interpreted incorrectly. Ensure the implementation distinguishes the JavaScript null value from text and does not leave the prior authenticated identifier attached to later signed-out events.

Decide whether identity is set before or after the authentication response and how queued events behave. Prevent one browser account switch from sending later events with the previous user's identifier. Verify server-rendered pages, single-page navigation, client and server event paths, mobile apps, consent updates, and error states. Keep the ecommerce transaction identifier separate from User-ID: one identifies a commerce transaction and the other associates authenticated user activity. Do not backfill User-ID into historical events. Google states that data collected before implementation is not reprocessed and associated with a later User-ID.

Use safe test accounts and inspect whether Analytics receives the expected identity state without copying the raw identifier into tickets, screenshots, or broad logs. Test two different users on one browser, one user on two supported devices, login after anonymous browsing, logout followed by anonymous activity, consent denial, consent change, duplicate tabs, expired sessions, and account deletion. Confirm that two people never share an identifier and that one person receives the stable approved value. Record pass or fail by test case, environment, release, and timestamp rather than storing the identifier itself as evidence.

Validate ecommerce events at the same time. Confirm that view, cart, checkout, purchase, and refund events retain their required transaction and item fields while identity state changes. Check that server-side or measurement-protocol events use the same approved mapping and do not introduce personally identifying payloads. Google recommends using the built-in User-ID feature rather than registering User ID as a high-cardinality custom dimension. Avoid parallel custom dimensions that duplicate the identifier, increase reporting cardinality, or make access harder to govern. Repair collection defects before enabling a reporting identity that relies on User-ID.

After validation and approval, configure a GA4 reporting identity that includes User-ID when that matches the measurement design. Google documents blended and observed reporting identities that can evaluate User-ID and device identifiers in different ways. Record the prior and new reporting identity, approver, change time, affected reports, and rollback plan. Use the signed-in-with-user-ID dimension or supported explorations to compare authenticated and unauthenticated activity, but keep population differences visible. Signed-in customers are not a random sample of all visitors and may have different history, intent, devices, or purchase behavior.

Reconcile counts with the authentication and commerce sources on fixed windows. Investigate collisions, missing IDs after login, IDs persisting after logout, unexpected account switching, and gaps by device or consent state. Do not expect historical reprocessing or complete cross-device coverage for users who never authenticate. Do not claim that User-ID caused higher retention, revenue, or attribution accuracy from a reporting change alone. The implementation improves the available identity contract for approved signed-in activity. Business conclusions still require source records, stable definitions, complete periods, privacy review, and careful treatment of modeled or device-based data.

Add identity-state checks to release regression testing and privacy review. Authentication code, tag containers, consent platforms, server events, and mobile releases can each change the point where the identifier is set or cleared. A passing launch test is not permanent evidence.