This solution is a brand new user association solution. For usage, please contact customer success.

In the previous user identification solution, all user IDs are divided into two types: device IDs (anonymous IDs) and login IDs.

In actual business scenarios, many user identifications of touchpoints fall between the two types, such as the OpenID and UnionID in the WeChat ecosystem.

In order to completely solve the user association problem, we have adopted a new user identification solution. The biggest difference between this solution and the past is that all IDs now have clear meanings.

Typical Scenarios

Basic Concepts

Sensors ID

Sensors Analytics uses Sensors ID (user_id in the events table and id in the users table) to uniquely identify users for each product. Sensors ID is generated based on business IDs according to certain rules.

Business ID

Overview

A user can obtain different IDs to identify user behavior on different touchpoints and different business stages, such as device IDs, email addresses, WeChat's OpenID and UnionID, user login identifications, etc. These are collectively referred to as business IDs.
The differences between these business IDs mainly lie in their lifecycle and accuracy.

Classification

Business IDs can be roughly divided into three categories: device IDs, IDs specific to certain ecologies, and business-related identifiers;

Clear semantics

Compared to the past when there were only anonymous IDs and login IDs, in this solution, all business IDs in event reporting and the Sensors system will have clear identifiers.

In data reporting, each piece of data will have an "identities" structure, which contains business IDs with clear types:

{ "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 Sensors System,

About the ID, the Sensory System will pre-set commonly used IDs, for details, please refer to pre-defined ID key list

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

• Which ID in the business corresponds to $identity_login_id?
  • The business side needs to determine whether there is an ID that can uniquely identify all users. If yes, it can be associated with $identity_login_id. If no, $identity_login_id can be ignored.
• What will happen if there is no $identity_login_id?
  • There is no impact on the business. Other IDs with data will be associated normally according to the given rules.
• What are the benefits of using $identity_login_id?
  • Once a user is associated with $identity_login_id, their user_id becomes stable and will not change when other IDs are associated.
  • For event data reported using $identity_login_id, because of the stability of user_id, it will not trigger event backtracking, which can reduce the changes caused by backtracking to some extent.
• Are there any additional restrictions on $identity_login_id?
  • Yes. As the highest priority and unique ID in the system, $identity_login_id cannot be unbound.

Capability Introduction

Free Association of Business IDs

Thanks to the clear types of each business ID, we can support free association between any business IDs, provided that these business IDs are reported in the same data.

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

Support Business IDs Unbinding

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

However, there are many scenarios in actual business where ID needs to be replaced, such as the most common scenario of changing mobile numbers or unbinding bank cards.

This solution can achieve the unbinding of associated business IDs by simply calling the relevant SDK interface or constructing the corresponding unbinding event.

The unbinding event is shown below:

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

Association Principle

• At the same time, an ID has one and only one Sensing ID. For example, a mobile number cannot belong to both user A and user B at the same time, and the same applies to a device ID;
• Isolated IDs cannot be linked; if it is necessary to specify that A_ID=A1 and B_ID=B1 belong to the same user, there must be a data record with both A_ID=A1 and B_ID=B1, which allows us to understand the relationship between the two IDs and achieve linkage.

Key Concepts

The clear definition of user business ID also brings about a change, which is the increase in the number of types of business IDs.

(The Sensing system will pre-set some business IDs to cover major scenarios such as WeChat Official Account, WeChat Mini Program, Enterprise WeChat, App, etc.If the business requirements are not met, you can add new ones through the "Metadata Management" -> "User Identification" page in the Sensing system.)

If a data record reports multiple types of business IDs, whether these IDs can be successfully associated depends on two other factors: quantity and priority.

Quantity

The quantity is a configuration at the business ID level, which refers to whether a user can have 1 or multiple business IDs of this type;(Currently, only 1 and multiple are supported, not specific quantities like 2, 3, 4, 5, etc.);

For example, for a mobile number, a person can only have one, so the quantity configuration for mobile numbers is 1;

For instance, for an Android ID, a person may change phones or use multiple phones at the same time, so the quantity configuration for Android IDs is N;

If the reported data violates the quantity limit, the newly reported data will fail to be associated and cannot be written into the business ID corresponding to the user table.

Priority

When the business ID in the reported data fails to be successfully associated, the business ID priority is used to determine the ownership of the event.

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

The user's actions are as follows:

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

So, after switching accounts, which user should the user behavior be attributed to?

Since A_ID has a higher priority than device ID, the behavior after switching accounts should be attributed to the user corresponding to A2.

Applicable scenarios

This solution mainly applies to scenarios where the ID source is complex and diverse, and the ID relationship is complex. Examples are as follows:

• Multiple business touchpoints: need to connect data from WeChat ecosystem, H5, App, e-commerce platforms, internal CRM and other channels,
• Unify user data from independent business lines: for example, for the same phone number, different business lines have different login IDs, and now we need to unify the same user across different business lines;

Implementation Method

1. Sort out the business IDs used to identify users at each touchpoint;
2. Determine the quantity and priority of each business ID;
3. The corresponding business IDs are collected and reported by tracking.

Case Study

Business ID Configuration Information (the following configuration is for illustration purposes, the actual configuration may vary)

events table

users table

Detailed steps are as follows:

1. Users download and install the App, obtain the AndroidId=AndroidId_x, assign the corresponding Sensory ID as 1, and write Sensory ID 1 and AndroidId_x into the corresponding fields of the users table;
2. Users register and log in to the App, obtain the login_id=login_id_1, and associate AndroidId_x with login_id_1. write login_id_1 into the corresponding field of the users table;
3. Users bind a mobile phone number, obtain the mobile=131xxxxxxxx, successfully link AndroidId_x, login_id_1, and 131xxxxxxxx, and write 131xxxxxxxx into the corresponding field of the users table;
4. Users interact with subscription A, obtain the corresponding A_OpenID=A1 and UnionID=U1, allocate a new Sensory ID as 2, and write Sensory ID 2, A1, and U1 into the corresponding fields of the users table;
5. Users interact with service account B, obtain the corresponding B_OpenID=B1 and UnionID=U1, link B1 with U1, and write B1 into the corresponding field of the users table;
6. When users access mini-program C and authorize their mobile phone number, they can simultaneously obtain mobile=131xxxxxxxx and UnionID=U1. Since mobile=131xxxxxxxx is the same as the mobile phone number of Sensory ID 1 and the association does not violate the principle, Sensory ID 2 will be merged into Sensory ID 1. At the same time, Sensory ID 2 will be deleted from the users table;
7. Users unbind the original mobile phone number mobile=131xxxxxxx on the App, the unbinding is successful, and 131xxxxxxxx will be deleted from the mobile field of Sensory ID 1 in the users table;
8. Users bind a new mobile phone number mobile=156xxxxxxxx on the App, the binding is successful, and 156xxxxxxxx will be written into the mobile field of Sensory ID 1 in the users table;

Subsequent fixes:

1. Since users access mini-program C and authorize their mobile phone numbers, triggering the merge of Sensory ID 1 and Sensory ID 2, Sensory ID 2 will be deleted from the users table thereafter;
2. The Sensory ID 2 in the event table will also be repaired as Sensory ID 1;

At this point, the user behavior on the App side and the WeChat ecosystem are completely connected.

Limitations

Does not support expressing relationships between different users

Global user association can achieve the mapping of user identities for individual users across different business lines and touchpoints, but cannot express relationships between different types of users.

For example, the relationship between students and teachers, where one teacher can correspond to multiple students and one student can correspond to multiple teachers.