In the simple user association scheme, all user IDs are divided into two categories, one is the device ID (anonymous ID), and the other is the login ID.

In actual business, many user identifiers at touch points will be between the above two, such as OpenID and UnionID in the WeChat ecosystem.

In order to completely solve the problem of user association, we have adopted a new user identification scheme, the biggest difference of which is that all IDs have clear meanings.

Please note that after the project is deployed, the one-to-one association scheme of simple user association is used by default. If you need to switch to the full domain user association scheme, you can contact the Sensors on-duty staff.

The user association scheme can be upgraded in the following way: simple user association one-to-one association scheme → simple user association many-to-one association scheme → full domain user association. It only allows one-way upgrade from the front to the back (it can be upgraded directly from one-to-one to full domain user association), and does not support reverse upgrading.

After the project is reset, it will revert to the simple user association one-to-one association scheme by default. If you need to switch to the full domain user association scheme, you can contact the Sensors on-duty staff.

1. Typical Scenario

2. Basic Concept

2.1. Sensors ID

Sensor Analysis uses the Sensor ID (i.e. user_id in the events table and id in the users table) to uniquely identify each product's users, and the Sensor ID is generated based on the Business ID according to certain rules.

2.2. Business ID

2.2.1. Overview

A user can get different IDs to identify user behavior at different touch points and different business stages, such as device ID, email address, WeChat's OpenID and UnionID, user login identifiers, etc. These are collectively referred to as Business ID.
The main difference between these Business IDs is the difference in life cycle and accuracy.

2.2.2. Classification

The business ID can be roughly divided into three categories: device ID, specific ecological ID, and business-related identifiers;

2.2.3. Semantically clear

Compared to the past where only anonymous ID and login ID were available, in this solution, all business IDs will be clearly identified in event reporting and the Sensor Analytics system.

In data reporting, each piece of data will have an identities structure, which will contain a clearly identified Business ID:

{ "distinct_id":"123", "login_id":"123", "anonymous_id":"xxxxxxxx", "identities":{ "identity_a_user_id":"123", "$identity_mp_unionid":"aZxxxxxxxx", "$identity_mobile":"131xxxxxxxx", "$identity_android_id":"xxxxxxxx" } 	…… } 

In the Sensor Analytics system,

About ID, commonly used IDs will be preset in the Sensor Analytics system, and you can refer to the Preset id key list

Among them, $identity_login_id is the highest priority ID in the system, and each user has and only has one such ID (the corresponding number configuration is always 1), which cannot be changed.

• Which one of the business IDs corresponds to $identity_login_id?
  • The business side needs to determine whether there is an ID that can uniquely identify all users. If there is, use $identity_login_id to bear; if not, you do not need to use this $identity_login_id.
• What impact will it have without $identity_login_id?
  • There is no impact on the business, other IDs with data will be normally associated according to the given rules.
• What are the benefits of using $identity_login_id?
  • Once a user is associated with $identity_login_id, its user_id will become stable and will not change due to the association with other IDs.
  • The event data reported using $identity_login_id will not trigger event backtracking due to the stability of its user_id, which can reduce the event changes brought about by backtracking to a certain extent.
• Does $identity_login_id have any additional restrictions?
  • Yes, $identity_login_id, as the highest priority and unique ID in the system, cannot be unbound.

3. Capability Introduction

3.1. Free Association of Business IDs

Thanks to the clear identification of each Business ID, we can support free association between any Business IDs, of course, the prerequisite is to report these Business IDs in the same data.

For example, you can directly associate a user's device ID with the corresponding OpenID, or you can associate the UnionID of the user's WeChat ecosystem with OpenID, and you can also associate the login ID of a user's different business lines.

3.2. Support business ID unbinding

In the past, once a logged-in ID and an anonymous ID were associated, they could not be changed.

But in reality, there are many scenarios where IDs need to be changed, such as the most common phone number changes and bank card unbinding.

This plan can achieve the unbinding of the associated business ID, just need to call the corresponding SDK's related interface or build the corresponding unbinding event, the user's associated business ID unbinding is completed.

Unbinding event examples are as follows:

{ "identities":{ "$identity_mobile":"131xxxxxxxx" }, "type":"track_id_unbind", "event":"$UnbindID", "project":"xxx", …… }

Association Principle

• An ID has only one sensor ID at the same time. For example, the same cell phone number cannot be both user A and user B at the same time, and the same is true for device ID;
• Completely isolated IDs are not connected; if you need to explicitly A_ID=A1, B_ID=B1 is a user, then there must be a data that has A_ID=A1, B_ID=B1 at the same time, so that they know the relationship between the two IDs, so as to achieve the connection.

4. Key Concepts

The meaning of user business ID is clear, and it will also bring a change, that is, the type of business ID has increased.

(The sensor system will preset some business IDs, covering scenarios such as WeChat public accounts, WeChat mini-programs, enterprise WeChat, App, etc.; if the business needs are still not met, you can add new ones through the "Data Fusion" -> "User Table" -> "Configure User Association" in the Sensor System.)

If a lot of types of business IDs are reported in a piece of data, whether these business IDs can be successfully associated depends on two other concepts: quantity and priority.

4.1. Association Constraints

The association constraint is a configuration at the business ID level, which means that a user can have one or multiple this type of business ID;

For example, for a mobile phone number, one person can only have one, so the number of mobile phone numbers is set to single value;

For example, AndroidId, a person may change phones or use multiple phones at the same time, so the number configuration of AndroidId is multi-value;

When the reported data violates the association constraint, the newly reported business ID will fail to associate and cannot be written into the corresponding business ID in the user table.

4.2. Priority

When the business ID of the reported data cannot be successfully associated, the business ID priority needs to be used to determine the ownership of the event.

Assuming, the customer has two IDs, one is A_ID, and the other is Device ID, the ID configuration is as follows:

The user's operations are as follows:

1. When the user logs in A_ID=A1 on Xiaomi phone (AndroidID=Xiaomi 1), Xiaomi 1 and A1 are successfully associated;
2. When the user switches to log in another account A_ID=A2 on the same Xiaomi phone, Xiaomi 1 and A2 cannot be successfully associated. If A1, A2, and Xiaomi 1 are associated with one user, it violates the limit of A_ID quantity as 1.

So, who should the user behavior belong to after switching accounts?

Because the priority of A_ID is higher than that of Device ID, the behavior after switching accounts should belong to the user corresponding to A2.

4.3. Associated upper limit

User identifiers with multiple value associated constraints can set an associated upper limit, that is, the maximum number of identifiers a single user can associate with.

This number can only be an integer greater than 1 and less than 500.

4.4. Excess strategy

Specify the handling strategy when a single user's associated identifier exceeds the associated upper limit.

Rolling unbinding: (default strategy) delete the earliest identifier, and continue to associate with the new identifier.

Data intercept: the entire data is intercepted, and the associated identifier will not change.

5. Applicable scenario

This solution is mainly suitable for scenarios with complex and diverse ID sources, and complex ID relationships, for example:

• Multiple business touchpoints: it is necessary to connect full-channel data from WeChat ecosystem, H5, App, e-commerce platform, internal CRM and so on,
• Pull through user data from multiple independent business lines: for example, the same mobile number logs in to different business lines, and the obtained business line login IDs are inconsistent. Now, it is necessary to pull through the same user from different business lines;

6. Implementation Method

1. Sort out the business IDs needed to identify users at various touchpoints;
2. Determine the number and priority of each business ID;
3. The tracking side will collect and report the corresponding business IDs.

7. Case

Business ID configuration information (The configuration below is only an example, the actual configuration might differ.)

events table

users table

The detailed steps are as follows:

1. The user downloads and installs the App, gets AndroidId=AndroidId_x, assigns the corresponding sensing ID as 1, and writes the sensing ID 1, AndroidId_x into the corresponding fields in the users table;
2. The user registers and logs into the App, gets login_id=login_id_1, AndroidId_x and login_id_1 are successfully associated, and login_id_1 is written into the corresponding field in the users table;
3. The user binds the phone number, gets mobile=131xxxxxxxx, and AndroidId_x, login_id_1, 131xxxxxxxx are successfully associated, and 131xxxxxxxx is also written into the corresponding field in the users table;
4. The user interacts with Subscription Account A, obtaining the corresponding Subscription Account A_OpenID=A1 and UnionID=U1, A1, U1 are all new business IDs, so the new allocation Sensor ID is 2, at the same time, the ID 2, A1, U1 are written into the corresponding fields of the users table;
5. The user interacts with Service Account B, obtaining the corresponding B_OpenID=B1 and UnionID=U1, B1 and U1 are associated successfully, and B1 is written into the corresponding fields of the users table;
6. The user visits Mini Program C and authorizes the mobile number, which can simultaneously obtain mobile=131xxxxxxxx and UnionID=U1, because mobile=131xxxxxxxx is the same as the mobile number of Sensor ID 1, and the association does not violate the principle, so Sensor ID 2 will merge into Sensor ID 1, at the same time, Sensor ID 2 is deleted from the users table;
7. The user unbinds the original mobile number mobile=131xxxxxxx on the App, after successful unbinding, 131xxxxxxxx will be deleted from the mobile field of Sensor ID 1 in the users table;
8. The user binds a new mobile number mobile=156xxxxxxxx on the App, after successful binding, 156xxxxxxxx will be written into the mobile field of Sensor ID 1 in the users table;

Subsequent repair:

1. Because the user visits Mini Program C and authorizes the mobile number, it triggers the merger of Sensor ID 1 and Sensor ID 2, and then the users table will delete Sensor ID 2;
2. The original Sensor ID 2 in the event table will also be repaired into Sensor ID 1;

Up to this point, the user's behavior on the App end and WeChat ecosystem has all been connected.

8. Limitations

8.1. Doesn't express relationships between different users

Universal user association can complete the connection of user identifiers in different business lines and different touch points for a single user, but it cannot express the relationship between different types of users.

For example, the relationship between students and teachers, one teacher can have multiple students, and one student can also have multiple teachers.