I’m trying to understand a suspicious user behavior pattern in my GA4 BigQuery export of my Android App Data and wanted to see if anyone else has encountered this.
The Anomaly: I am seeing individual user_ids that are associated with hundreds of unique user_pseudo_ids (which usually indicates a new app install).
The user_id is unique on user’s device Id.
However, looking at the device data, it appears these are all coming from the exact same physical device.
Key Observations:
One User, Many Identities: A single user_id is linked to 10+ different user_pseudo_ids within a short time window.
Same Device Model: All of these “different users” have the exact same device.mobile_model_name and device.operating_system.
The “Impossible” Session: When I look at the event stream, the user_pseudo_id changes mid-stream, but the ga_session_id and ga_session_number remain completely unchanged.
Example Log:
User ID
User Pseudo ID
Session ID
Session Num
Device
User_A
Pseudo_ID_1
1764200942
13.
LG-K525
User_A
Pseudo_ID_2
1764200942
13
LG-K525
User_A
Pseudo_ID_3
1764200942
13
LG-K525
My Question: Is there any valid technical reason (e.g., app updates, privacy settings, or cloud backups) why a single device/user would rotate user_pseudo_id multiple times while maintaining the same active ga_session_id?
We are seeing this on both Organic and Paid traffic.
In GA4, the user_pseudo_id represents the client-side identifier generated by the SDK on first launch or after a data reset, while user_id is an explicit identifier that your app sets. Seeing multiple user_pseudo_id values tied to the same user_id but sharing an identical ga_session_id usually indicates that the app instance is reinitializing the analytics client mid‑session. This can occur when the Firebase Analytics SDK or GA4 library is re‑registered after clearing local storage, reinstalling, or restoring app state from a backup, but the session parameters (ga_session_id and ga_session_number) are cached and reused. It may also happen if your instrumentation manually overrides session_id while the SDK regenerates new user_pseudo_id values on every re‑init.
To confirm, inspect the event stream for first_open or app_update events in BigQuery and review how your app sets user_id in the analytics configuration. If your implementation initializes Analytics multiple times on app resume or update, ensure only one instance of FirebaseAnalytics.getInstance() or Analytics.logEvent() is invoked per session. Stabilizing the SDK initialization and persisting its installation ID prevents pseudo ID rotation. If the anomaly persists across devices with identical behavior, validating SDK version consistency and reviewing client cache handling under the Firebase Analytics DebugView can isolate the trigger.