Tracking unique users is a complex process because users can log in and out of your product, browse anonymously, and use multiple devices. In order to keep an accurate count of users, we have a comprehensive solution using a combination of Device IDs, User IDs, and Amplitude IDs.
Table of Contents
- Determining Unique Users
- Example Scenarios
- Example 1: No User ID is assigned
- Example 2: User ID is assigned after anonymous events
- Example 3: Same User ID on multiple Device IDs, with no anonymous events
- Example 4: Multiple User IDs on the same Device ID
- Example 5: Same User ID on multiple Device IDs, with anonymous events
- Merged Users
Determining Unique Users
Amplitude uses a system of three IDs to track users: Device ID, User ID, and Amplitude ID. First, we gather the Device ID and User ID as detailed below. Then we will produce an Amplitude ID, which is the ID that is used to track unique users throughout the platform.
- Device ID: We will pull the IDFV or generate a random alphanumeric string that ends with the letter 'R' for Device ID and is stored locally in the browser's cookie or mobile device. However, there is a flag that you can toggle to use the Identifier for Advertiser (IDFA for iOS) and the Advertising Identifier (AdID for Android) as the Device ID (see the relevant SDK installation guide for more information).
- Note: iOS users have the option of resetting their IDFA on their devices at any time. As of iOS 10, if a user limits ad tracking, then this would send an IDFA of all zeros. Amplitude will instead set Device ID as IDFV or a randomly generated string.
- Note: Android users have the option of resetting the AdID on their devices at any time.
- iOS: If the Device ID is set to the IDFA, then it will persist across installs.
- Android: If the Device ID is the AdID, then it will persist across installs.
- Web: The Device ID will be set to a randomly generated UUID by default. It will persist unless a user clears their browser cookies and/or is browsing in private mode.
- User ID: This identifier is configured by you. Many products use a username or an internal unique identifier to track their users. To set a User ID, use the
setUserIdmethod outlined in our SDKs.
Important Note:
- If the User ID gets changed, then this would create a new user. We recommend not setting the User ID to something that may change (e.g. email address).
After gathering the Device ID and User ID, Amplitude formulates an Amplitude ID. The general rule is that we will prioritize using a User ID over a Device ID when assigning an Amplitude ID. Amplitude uses this Amplitude ID to identify unique users. With the exception of special circumstances, an Amplitude ID will always be prioritized over a Device ID or a User ID. See the examples below for different scenarios.
Anonymous Users
Anonymous users should not be assigned a User ID. These anonymous users will still have Amplitude IDs and Device IDs. Users will later be merged when we identify they are the same user.
Cross Domain Tracking
You can track anonymous behavior across two different domains. For example, let's say you have the following two domains:
- Site 1: https://www.landingpage.com
- Site 2: https://www.productpage.com
If you want to track an anonymous user who starts on Site 1 and navigates to Site 2, then you will need to pass the Device ID from Site 1 as a parameter to Site 2. After that, you will need to reinitialize the SDK with the passed Device ID. It would look something like:
- From Site 1, grab the Device ID from
amplitude.options.deviceId. - Pass the Device ID to Site 2 via a URL parameter or third party cookie.
- Initialize the Amplitude SDK on Site 2 with
amplitude.init('YOUR_API_KEY', null, {deviceId: '$DEVICE_ID'}).
Example Scenarios
Example 1: No User ID is assigned
If your product does not assign a User ID, then an Amplitude ID is generated when a Device ID is seen for the first time.
| Device ID | User ID | Amplitude ID |
|---|---|---|
| A | null | 1 |
| B | null | 2 |
| B | null | 2 |
| C | null | 3 |
| A | null | 1 |
| C | null | 3 |
In the example above, the first event came from device A and because there was no record of this device we assigned it a new Amplitude ID of 1. The second event came from device B and because there was no record of this device, we assigned it a new Amplitude ID of 2. The third event also came from device B and because we already had a record of this device, it was assigned an Amplitude ID of 2. The same logic applies for device C. There are three unique users in this set.
Example 2: User ID is assigned after anonymous events
If your product assigns a User ID, then we assume any events logged anonymously prior to a User ID being known on the device belong to that user. The same Amplitude ID is used for both.
| Device ID | User ID | Amplitude ID |
|---|---|---|
| G | null | 4 |
| G | null | 4 |
| G | John | 4 |
In the example above, the first two events are logged anonymously on device G and are assigned an Amplitude ID of 4. The third event is the first event to have a User ID on device G and therefore is assigned the same Amplitude ID as the anonymous events. We can then say that user John did all three events. There is one unique user in this set.
Example 3: Same User ID on multiple Device IDs, with no anonymous events
User ID takes priority over Device ID when it comes to assigning an Amplitude ID.
| Device ID | User ID | Amplitude ID |
|---|---|---|
| K | Zack | 5 |
| L | Zack | 5 |
In the example above, user Zack did an event on device K and was assigned an Amplitude ID of 5. Whenever Zack shows up again on any device, we will automatically assign it an Amplitude ID of 5 regardless of what the Device ID. There is one unique user in this set.
Example 4: Multiple User IDs on the same Device ID
If an event is sent anonymously after at least one User ID has been seen on the device, then we assume the anonymous event is done by the last known user and is given that user's Amplitude ID.
| Device ID | User ID | Amplitude ID |
|---|---|---|
| R | Jane | 6 |
| R | null | 6 |
| R | Mary | 7 |
| R | null | 7 |
| R | null | 7 |
In the example above, Jane logs the first event on device R and is assigned an Amplitude ID of 6. The next event is sent anonymously (perhaps Jane logged out) but is still assigned an Amplitude ID of 6 because Jane was the last known user. The third event is done by Mary on device R and is assigned and Amplitude ID of 7. The next two events are done anonymously (perhaps Mary logged out) and are assigned an Amplitude ID of 7 because we assume that Mary did those events because she was the last known user. There are two unique users in this set.
If you want to explicitly log users out or log events under an anonymous user, then you will need to set the User ID to null and regenerate a new Device ID. You can do this by following the instructions in our SDK documentation. Here is a link to our iOS documentation and here is a link to our Android documentation.
Example 5: Same User ID on multiple Device IDs, with anonymous events
| Device ID | User ID | Amplitude ID |
|---|---|---|
| Y | David | 8 |
| Z | null | 9 |
| Z | David | 8 |
| Z | null | 8 |
In the example above, David logs an event on device Y and is assigned an Amplitude ID of 8. Next, an anonymous user logs an event on device Z and is assigned an Amplitude ID of 9 because there is no user associated with the device. Then, David logs into the product on device Z and the event has an Amplitude ID of 8 because that is David's Amplitude ID. Last, an event is logged anonymously on device Z and is given an Amplitude ID of 8 because David was the last known user and the event is attributed to him. In this scenario, the anonymous events on device Z have two different Amplitude IDs even though there is just one User ID associated with the device. As a result, Amplitude ID 9 is mapped to Amplitude ID 8, as we will assume that Amplitude ID 9 was also David. So, the Amplitude interface will merge these IDs and there will only be one user counted. However, please note that if you are using Redshift, the data is immutable and the anonymous event will still have an Amplitude ID of 9 in the raw data. See the below Merged Users section for more information.
Merged Users
The merged user problem arises when an anonymous user (a user who only has a Device ID associated) becomes a recognized user (has a User ID) which already exists in our system. One example is when a user gets a new device — when opening your product they log events anonymously before signing in. As a result, these anonymous events appear to be coming from a new user so they are mapped to a new Amplitude ID.
However, when the user logs into their existing account, events going forward are then mapped to their existing Amplitude ID. A couple of problems arise from this:
- The user is counted twice in active and new user counts.
- Events received while the user was anonymous are “lost” in that they will not be attributed to the true Amplitude ID and the user's actual User ID.
Amplitude solves this problem by cross referencing the list of Amplitude IDs with an internal mapping of Amplitude IDs that have been "merged" (Amplitude IDs that we have determined to be the same user). This all occurs at the time you query on the dashboard. You can view a list of a user's merged ID(s) in their User Activity page along with the merge times.
Important Note:
- It is important to note that this solution currently does not apply to the raw data in Amazon Redshift as the database contains the raw event logs. On average, without this merged users logic we have seen an average change of about 5% in DAU numbers for our users with higher than average change for web data.
Device ID
When users are merged, the count for Device ID continues according to the devices. See the below table.
| Device ID | User ID | Amplitude ID | Event ID |
|---|---|---|---|
| A | null | 8 | 1 |
| A | David | 8 | 2 |
| A | David | 8 | 3 |
| B | null | 9 | 1 |
| B | David | 8 | 2 |
| B | David | 8 | 3 |
In addition, if the product data is cleared, then the Event ID will reset to 1 (e.g. if a user deletes the app and reinstalls, the Event ID will restart at 1).
When a user deletes the app and reinstalls, a new Device ID will be generated in most cases, which means a new merging will be triggered. When that happens, the user will "lose" user property values that were not meant to be changed at all (i.e. Start Version or initial UTM parameters). If you are a paying customer and this affects you, please reach out to our Support team to resolve it.