Each event is telling you something from the user's perspective therefore events need to have a userId to indicate who this concerns. By default the SDK will generate a random ID and store this on the device, this will survive upgrades but not forced wipes of data and will cause for one user per device to be created, even if the devices are owned by the same person/
Deciding what to use for the userID can be very straightforward. If a user has to log in before they can play it is probably wise to use the ID they log in with to base the userID on. For privacy reasons it might be good to hash the value rather than using an identifiable ID. On the other hand if there is no login required then you can just use any random value, such as we generate automatically in the sdk's, that you then store on the device.
A problem arises when you can do both, if players can play without logging in and then can decide to log in. This means two different devices can start generating gameplay data and after a certain time it will become clear that these two sets of data actually originate from two devices.
There is no perfect way of dealing with this and each way of dealing with this has it's caveats. The following three are the most obvious ways of dealing with this problem.
Don't record any events until the user logs in.
pros:
no duplicate users and no orphaned users
cons:
missing data and sometimes even the critical FTUE data.
Switch userId to logged in ID upon logging in.
pros:
The userID in the platform is the userID the user has been playing on so it will be easy to follow progress
cons:
This will create an orphaned user in the main success scenario, you will have twice as many installs
All retention and ltv numbers should only be based on the logged in users, not the guest users so for standard analytics there will always need to be a segment applied when looking at user averages.
Add the logged in ID as a parameter on a logIn or socialConnect event.
pros:
No duplicate users in the main success scenario, only when a user starts playing on a different device you will have two users for one account.
cons:
When a user plays on one device and on another they are not aggregated by default, this has to be done by looking at the last value of the logged in ID and compare these across users in the user_metrics table.