# User Identification Rules

This chapter mainly introduces the user identification rules adopted by TA, and explains how to distinguish two users and the behavior associated with the same user in the login state and the non-login state.

Abstract:

    1. A user will have three IDs for identification
       Namely:
        Visitor ID      #distinct_id   The uer ID in unlogged state
        Account ID      #account_id    The uer ID in logged state
        TA User ID    #user_id         Unique ID of the user by TA

    2. The most critical ID to identify a user is the user ID
       User IDs in each piece of data are generated from account IDs and visitor IDs
       Generation will take precedence over account ID and will be based on visitor ID if account ID does not exist

    3. When the TA background receives data containing the new account ID, it will be bound to the visitor ID of the current data.
       If a visitor ID exists and is not bound by another account ID, the binding is successful and the data identified by both IDs will use the same user ID
       If the visitor ID does not exist or has been bound by another account ID, the binding fails and is no longer bound, the unbound ID is NULL

    4. User ID, account ID and visitor ID all correspond to each other, there is no case of more than one bundle

Users may use your products on different devices or without logging in, making accurate user identification quite complicated. TA chose a more accurate and easy-to-understand solution. This document will explain the rules of user identification in detail and provide examples to help you understand quickly.

# I. Identification Rules

The TA platform mainly uses three IDs to identify users, namely visitor ID ( #distinct_id), account ID ( #account_id) and TA user ID ( #user_id). This section will introduce the rules for generating these three IDs:

# 1.1 Visitor ID ( #distinct_id )

Visitor ID is the identity of the user in the unlogged state. If you use the client SDK to access, when the user installs the application, the SDK will automatically configure a #distinct_idfor the user, that is, the user's visitor ID. If you need to configure the visitor ID, please use identifyto set it before uploading the event. The visitor ID will be saved by the SDK and there is no need to configure it many times. Be careful not to use identifyagain after the upload event to change the visitor ID, otherwise it will cause problems of users not matching and duplicate users.

Before loginis used, the user's data will only have #distinct_id, not #account_id,which will be associated with the user ID according to #distinct_id.

# 1.2 Account ID ( #account_id )

When the user logs in or registers successfully, he can call loginto set the account ID. At this time, the data will have #account_idand #distinct_id. The SDK will save the account ID. If you call loginto configure the account ID multiple times, the last incoming value will be taken as the account ID. You can call logoutto clear the account ID, and the cleared data will only be #distinct_id.If the incoming data has #account_id, the background will preferentially associate the user ID according to #account_id.

# 1.3 TA User ID （ # user _ id ）

The user ID is a unique sign to identify the user. When the TA receives the incoming data, it will look for the user ID associated with it according to the account ID and visitor ID, insert each Event as the primary key, or look for the profile setting user feature corresponding to the primary key in the User table.When the account ID exists, it will first search for the associated user ID based on the account ID, and when the account ID does not exist, it will search for the associated user ID based on the visitor ID.

When the account ID does not find the associated user ID, or when the account ID does not exist and the visitor ID does not find the associated user ID, a new user ID is created and bound to the account ID or visitor ID (when there is no account ID). User ID, account ID and visitor ID correspond to each other. When the account ID does not find the associated user ID, TA will bind the visitor ID to the account ID according to the following rules.

# II. Bind Visitor ID and Account ID

When TA receives data from a new visitor user, it generates and binds a user ID based on the visitor ID. When receiving data from a new login user, it may be that the visitor ID has been bound to the user ID. At this time, it is necessary to judge whether the visitor ID has been bound to the user ID to determine whether the visitor ID and account ID can be bound. Three scenarios can occur:

The visitor ID is not bound to the user ID and can be considered as the first event sent by the logged-in user. If no event occurs in the visitor state, a new user ID is created and bound to account ID and visitor ID.
Visitor ID has been bound to user ID, but account ID has not been bound before. That is, when a visitor user changes to a logged-in user, the account ID will be bound with the visitor ID and the corresponding user ID, and no new user ID will be generated.
Visitor ID has been bound to user ID and account ID has been bound. This may occur when a new user registers his or her account on a device that has been used by a logged-in user, at which point the account ID will not bind the visitor ID, and a new user ID will be created to bind the account ID without processing the visitor ID.

It should be noted that the binding judgment between account ID and user ID only occurs once when a data containing a new account ID is received in the background, i.e. the binding judgment of account ID only occurs once, so the third case will result in the account ID being permanently unable to bind any visitor ID.

# III. Case Analysis

To help you better understand TA's User Identification Scheme, this section presents a case study of how the rules work. The case will show the operation of configuring the user ID after receiving the data in the background. What you need to pay attention to is the value of #user_idin each step and the principle of association.

# 3.1 Visitor ID Only

When there are only visitor IDs, only #distinct_iduser IDs will be generated

#account_id	#distinct_id	#user_id
null	A	1
null	B	2
null	C	3
null	A	1

In the above scenario, the background receives three new visitor IDs, so three new user IDs are created, while the corresponding user ID '1' exists in the visitor ID 'A' in step 4, so there is no new user ID, which is considered to be a previously created user with a user ID of '1'.

# 3.2 Visitor ID is Bound to User ID but Not Account ID

When the visitor ID has a corresponding user ID, but no account ID is bound, the incoming account ID will bind the account ID and the visitor ID.

#account_id	#distinct_id	#user_id
null	A	1
A	A	1

In the above scenario, the background receives a new guest ID, and thus create a new user ID. After receiving a new account ID, the guest ID is not bound to the account ID, so the new account ID is bound to the guest ID.

# 3.3 Visitor ID is Bound with Both User ID and Account ID

When a visitor ID has a corresponding user ID and an account ID has been bound, the new account ID will not be able to bind the visitor ID which can then be attempted to bind with other visitor IDs.

#account_id	#distinct_id	#user_id
A	A	1
B	A	2
B	B	2
null	B	2
null	A	1
C	B	3

In the above scenario, you can see that the visitor ID 'A' has been bound with account ID 'A', at which time the new account ID 'B' will not be able to bind the visitor ID 'A', only with the new user ID '2'; When the third step account ID "B" is passed in at the same time as the visitor ID 'B', the visitor ID 'B' has not been bound with the account ID, so both are bound; So in the fourth step, the incoming visitor ID "B" is attributed to the user ID "2", and then the new account ID "C" is passed in at the same time as the visitor ID "B". Similarly, no binding occurs and is considered as the new user. The following is the final binding relationship:

#user_id	#account_id	#distinct_id
1	A	A
2	B	B
3	C	null

# IV. Analysis of Complex Scenarios

In order to facilitate understanding, we will present the User table structure of the key steps. You can understand it by comparing the explanation of this step:

Steps	#account_id	#distinct_id	#user_id
1	null	A	1
2	A	A	1
3	B	A	2
4	null	B	3
5	B	B	2
6	C	B	3
7	C	C	3
8	B	C	2
9	D	C	4
10	null	C	2

We will analyze the above complex scenes step by step:

(1) Pass in new visitor ID 'A' and bind with new user ID '1'.

(2) New account ID 'A', visitor ID 'A' does not bind account ID, so 'A', 'A' and '1' are bound.

(3) New account ID 'B', visitor ID 'A' has been bound to account ID 'A', so it is bound to new user ID '2', at this time it is not bound to visitor ID. User table is as follows:

#user_id	#account_id	#distinct_id
1	A	A
2	B	null

(4) At this time, the new visitor ID 'B' is not actually bound with any ID. It is regarded as the new visitor ID and is bound with the new user ID '3'.

(5) Account ID 'B' and visitor ID 'B' belong to two users, so no binding occurs. At this time, the User table is as follows:

#user_id	#account_id	#distinct_id
1	A	A
2	B	null
3	null	B

(6) New account ID 'C', visitor ID 'B' does not bind account ID, so 'C', 'B', '3' are bound. User table is as follows:

#user_id	#account_id	#distinct_id
1	A	A
2	B	null
3	C	B

(7) Account ID 'C', which has been bound with user ID '3' and visitor ID 'B', does not operate on visitor ID 'C' at this time.

(8) Account ID 'B' and visitor ID 'C' are passed in at the same time. Visitor ID 'C' is not bound with other account IDs, so they are bound. User table is as follows:

#user_id	#account_id	#distinct_id
1	A	A
2	B	C
3	C	B

(9) The new account ID 'D' is the new user and the visitor ID 'C' belongs to the user ID '2', so no binding is required. The User table is as follows:

#user_id	#account_id	#distinct_id
1	A	A
2	B	C
3	C	B
4	D	null

(10) Last visitor ID 'C' has been bound with user ID '2'

The final User table structure is:

#user_id	#account_id	#distinct_id
1	A	A
2	B	C
3	C	B
4	D	null

← ThinkingData Privacy Policy Data Rules →