Identification

Check the Integration section to learn about changing the identification method.

Developers can decide how to identify users of applications in devtodev. There are two options available:

1. Identification by unique device ID (by default).

2. Identification by user ID set by developer.

And for both variants, just after getting the data in devtodev for the first time, a unique devtodev ID will be created (for user or device).

Identification by unique device ID

If the developer does not set (or has not set yet) a user ID during SDK integration, then devtodev automatically uses the device identifier:

Platform	Main identifier	Additional identifier (if main identifier is not available)
Android	Advertising ID	ID generated by SDK (changes if device data is cleared or after the app is deleted)
iOS	IDFA	IDFV
Mac	ID generated by SDK using Hardware UUID (can not be changed)
Windows Phone 8.1, Windows 10	Advertising ID	Identificaton using App Specific Hardware ID (cannot be changed)
Windows (Standalone apps)	ID generated by SDK (created once, then saved on the device)
Web	ID generated by SDK (created once, then saved in localstorage or browser cookies)

Registration of a new user is the appearance of an identifier which did not exist in the database when the first dataset came from the SDK.

The first dataset is sent just after SDK initialization in the app code.

If the advertising ID is changed, switched on or off, the SDK notifies the server about ID replacement. This way, the change of device ID does not create new users.

Usage

This method is useful, if it is nessesary to calculate devices where the app is launched, but not users who do it. Or it is useful when the numbers of devices and users are considered to be equal.

Usually, this type of identification is enough for mobile devices, if the application cannot save user data on the server to expand it to this device, another device or another platform (for cross-platform projects).

It is not recommended to use this method for web applications, but it is possible to temporarily use it if the user does not identify (for example, if there is a demo access to the app before registration).

Logic of identification by device ID

Every string corresponds to SDK initialization in the app.

#	Device	User ID	devtodev ID
1	A	null	1
2	B	null	2
3	C	null	3
4	C	null	3
5	A	null	1

1. User has launched the app on device A. A new user is registered in the app by device ID, the user is assigned devtodev ID=1.

2. User has launched the app on device B. A new user is registered in the app by device ID, the user is assigned devtodev ID=2.

3. User has launched the app on device C. A new user is registered in the app by device ID, the user is assigned devtodev ID=3.

4. User has launched the app again, and the user was found by device ID=C. The user is still identified under devtodev ID=3.

5. User has launched the app again, and the user was found by device ID=A. The user is still identified under devtodev ID=1. ​

Identification by user ID set by developer

If the developer knows the unique user ID, they can identify users with this IDs, aside from devices where this ID works.

This type of identification is not used by default; it works only if the developer sets the user ID during SDK integration (setUserId method).

Check the Integration section to learn about changing the identification method.

Usage

The User ID method is universal. The main reason for not using this method can be the absence of a unique user identifier.

This method is strongly recommended for apps where it is possible to save user data on the server to use it on different devices, and also for applications where different users can use the same device.

This method is obligatory for cross-platform projects if you want to use devtodev cross-platform analytics and analyze all platforms in one place. Users can use the app on different platforms to change the data about themselves (for example, game progress).

Web SDK can use two user identifiers at the same time.

The first one is set during SDK initialization, and it can be the only ID (for example, the ID of a user in a social network).

The second one may be set only for cross-platform applications.

If both IDs use the same value for your app, you should only set the ID during the initialization.

Moving from identification by device ID to identification by user ID

If the user ID was not used earlier in the app and it is integrated in the new version of the application (or user had no ID for some time, and now it appears), then all the data received by device ID is inherited by the first set user ID.

In this case, identification by device ID is replaced with identification by user ID. Data about the number of users is not changed, because registration dates are also inherited.

Logic of identification by user ID

Moving to user ID

#	Device	User ID	devtodev ID
1	A	not set	1
2	A	not set	1
3	A	"John"	1
4	A	not set	1
5	A	"John"	1

1. User has launched the app on device A. A new user is registered in the app by device ID, the user is assigned devtodev ID=1.

2. User launches the app again and is found by device ID. The user is still in the database under devtodev ID=1.

3. A user is assigned a user ID with the setUserId method. All the data previously received from device A are now under the User ID="John". Device ID A is replaced by "John" in the devtodev database. The user is still in the database under devtodev ID=1.

4. The next launch of the app, and the User ID is not set by setUserId. SDK thinks that the User ID should be the same as in the previous session. The user is still "John" under devtodev ID=1.

5. During this or the next session, there's a User ID assignment: setUserID="John". Devtodev ID is not changed.

Several users on the same device

#	Device	User ID	devtodev ID
1	A	"John"	1
2	A	"Jim"	4
3	A	not set	4
4	A	"John"	1
5	A	not set	1
6	A	"Alex"	5

1. User "John" has launched the app on the device again; they were found by user ID. The user is still under devtodev ID=1.

2. During this or next session, there's a User ID assignment: setUserID="Jim". There were no data about such user in devtodev before. A new user is registered, and now they are under devtodev ID=4.

3. The next launch. User ID is not set with setUserId. The SDK thinks that the User ID is the same as in the previous session. The user is "Jim", and they are under devtodev ID=4.

4. During this or the next session, there's a User ID assignment: setUserID="John". This user is already registered in devtodev, and they are under devtodev ID=1.

5. The next launch. User ID is not set with setUserId. The SDK thinks that the User ID is the same as in the previous session. The user is "John", and they are under devtodev ID=1.

6. During this or next session, there's a User ID assignment: setUserID="Alex". There were no data about such user in devtodev before. A new user is registered, and now they are under devtodev ID=5.

Same users on different devices

#	Device	User ID	devtodev ID
1	A	"John"	1
2	B	"John"	1
3	B	not set	1
4	B	"Alexia"	6
5	D	"Alexia"	6

1. User "John" launches the app on device A, they are found by User ID. The user is still in database under devtodev ID=1.

2. There is a launch of the app on device B under User ID "John" set by the setUserId method. The user is already registered in devtodev, and they are still in the database under devtodev ID=1.

3. There is a launch of the app on device B, but User ID is not set by setUserId method. The SDK thinks that the User ID is the same as in the previous session. The user is "John", and they are under devtodev ID=1.

4. There is a launch of the app on device B under User ID "Alexia" set by the setUserId method. There is no data about such user in the devtodev database. A new user is registered, and now they are under devtodev ID=6.

5. There is a launch of the app on device D under User ID "Alexa" set by the setUserId method. The user is already registered in devtodev, and they are still in the database under devtodev ID=6.

If it is possible to use the app for both registered and non-registered (no permanent ID) users

#	Device	User id	devtodev Id
1	A	"John"	1
2	A	""	7
3	A	not set	7
4	A	"John"	1
5	A	"Jane"	7
6	A	""	8
7	A	"George"	8

1. User "John" launches the app on device A again, they are found by User ID. The user is in the database under devtodev ID=1.

2. User launches the app by demo access, user has no permanent ID. setUserId ="" is set during initialization. Since there is no User ID, the SDK will identify the user by device ID. Only user "John" has used this device before, there is no ID of device A in devtodev database. A new user is registered, and now they are under devtodev ID=7.

3. The next launch is from device A, User ID is not set using setUserId. The SDK thinks that the User ID is the same as in previous session. There was setUserId ="" in the previous session, so the user was identified by device ID. The user is still taken into account as devtodev ID=7.

4. User "John" launches the app on device A again, they were found by User ID. They are in database under devtodev ID=1.

5. During this or the next session, there's a User ID assignment: setUserID="Jane". User "Jane" did not use device A before, so it is assumed that "Jane" is the user who previously used demo access, then registered and got a User ID. Jane inherits all the data previously collected by device ID. "Jane" has not previously registered in devtodev, so they inherit devtodev ID=7.

6. There is a new launch of the app in demo access on device A, and again the user does not have a permanent id. setUserId ="" is set during initialization. Since there is no user ID, the SDK will identify this user by device ID. Until this moment the device was used by "Jane", they inherited the ID of device A and then replaced it by "Jane" in devtodev database. Because there is no such ID in the devtodev database, a new user is registered, and now they are under devtodev ID=8.

7. During this or the next session, there's a User ID assignment: setUserID="George". User "George" did not use device A before, so it is assumed that "George" is a user who previously used demo access, then registered and got a User ID. "George" inherits all the data previously collected by device ID. "George" has not previously registered in devtodev, so they inherit devtodev ID=8.

FAQ

What can be the unique user ID?

It could be any available identifier of the user (but not the device). Examples:

• user ID in developer server database

• user ID in a social network

• application store game center ID, publisher ID

• email

• telephone number etc.

Moreover, if your project is cross-platform, use the ID that is available from all of the platforms.

When shall I assign the user ID, before or after SDK initialization?

We recommend you to assign the User ID before the SDK initialization. It is the most sustainable way to avoid data distortion.

In most cases, if you assign the User ID after SDK initialization, nothing is broken. But if several users use the app, or the project is cross-platform, then data distortion is possible. The SDK "thinks" by default that the same user launches the app next time. You have to use another User ID to avoid a mix-up.

Let's have a look at the examples when the ID is assigned after SDK initialization:

1. User "John" launched the app and then close it. Then user "Jim" opened the app from the same device, but the SDK did not know about it, so it thought it was John again. All events (before initialization of "Jim") belong to "John", so DAU, users online metrics, date of "John's" last visit, "John's" events and user profiles become distorted.

2. User "John" plays a cross-platform game on his Android device. At friend's home, "John" installs the app on the friend's iPad. Since the SDK initialization is before the moment of User id assignment, the SDK takes the device ID into account. The new user is created on the devtodev server with the device (iPad) ID. Then there is an assignment of the "John" identifier, but the server already knows such user and does not think that it is the same user who inherited all the data from the iPad device ID before. So, the number of users, DAU and users online are distorted.

Is it possible to change the user during the session?

When the app works, it is possible to change the user an unlimited number of times (for example, to re-login the user). You just have to make an assignment using the setUserId. In the case of Web SDK, if the ID used during initialization changes, you have to repeatedly initialize the SDK with a new id.

When changing the user, we recommend that you also assign the current user level to the user (if you have such parameter).

Is it possible to change the User ID?

If the developer needs to change the User ID (for example, if the developer wants to use another variant of identification), it is necessary to use the replaceUserId method once; otherwise, users with new IDs will be taken into account as new users.

Also, the developer shall do the same if it is possible for users to replace their ID themselves (for example, to change their email, which is used as login).