Quick Audience:ID Mapping and User Unique Identifier QAID

Background information

Your Quick Audience data pool may contain the data of the same user from multiple channels, such as imported order data tables from Taobao, WeChat mini programs, and self-owned apps, imported tag data from CRM, behavior event data from self-owned apps, mini programs, Web, or third-party systems that are collected and reported by tracking points, and uploaded crowd ID lists.

How to identify the same user in different channels, make the data of each channel form a synergy, and assist your insight and decision-making is the problem that V4 focuses on solving.

The user ID may be associated with the enterprise ID and third-party platform ID. The device ID may be associated with the account ID of the tracking app. No matter what channel the data comes from, when different types of IDs are associated with each other, we assume that these IDs belong to the same user.

ID Mapping is the user identification that we implement based on this idea.

ID Mapping Basic Logic

In general, ID Mapping identifies and deduplication users based on correlated ID data, and assigns each independent user a unique QAID in Quick Audience.

First, let's look at an example of ID Mapping in the simplest case:

The first day:

• The imported order table contains one row: Taobao ID1, mobile phone number 1...

• The behavior event table collected and reported by the app tracking point contains one row: IDFA1, mobile phone number 1...

Then the system determines that these IDs belong to the same user and assigns QAID1 to this user.

The results are shown in the table below.

ID Conflicts in ID Mapping and Solutions

Each ID in Example 1 above has only one value. What if an ID has multiple values?

In this case, the system will merge and trade-off the ID according to the single value /multi-value of the ID and the priority. In this section, for ease of description, it is assumed that the single-value /multi-value and priorities of the involved IDs are shown in the following table.

Next, let's look at some examples of ID mapping in complex cases. For ease of representation, the ID types in all tables are sorted by priority from high to low.

The following user data is available on the first day:

On this basis, the second day:

• The imported order table contains one row: Taobao ID2, mobile phone number 1...

• The behavior event table collected and reported by App tracking point contains one row: IDFA2, mobile phone number 1...

Under the preceding single-value /multi-value rules and priority rules:

1. Because the IDFA is a single value, IDFA2 and IDFA1 conflict, but because the priority of the IDFA is lower than the mobile phone number and the mobile phone number is the same, it is still determined to be the same user. Under the default overall merge policy, only the IDFA1 with the earliest creation time will be retained.

2. After the user is identified as the same user, multiple Taobao IDs are retained because the Taobao ID is multi-value.

The results are shown in the table below.

On the basis of the user data of the second day in the above table, the third day:

• The imported order table contains one row: Taobao ID1, mobile phone number 2...

Under the preceding single-value /multi-value rules and priority rules:

• Although the Taobao ID matches, because the mobile phone number is a single value, the mobile phone number 2 conflicts with the mobile phone number 1, and the priority of the mobile phone number is higher than the Taobao ID, so it is determined that the two mobile phone numbers belong to different users.

The results are shown in the table below.

On the basis of the third day user data in the above table, the fourth day:

• The uploaded crowd ID file contains one line: Taobao ID1

Under the preceding single-value /multi-value rules and priority rules:

• Both QAID1 and QAID2 have a Taobao ID1. You cannot confirm which Taobao ID1 belongs to the newly uploaded Taobao ID1. Therefore, you are determined to be the third party other than QAID1 and QAID2.

The results are shown in the table below.

Let's use an example to understand the impact of QAID consolidation on user data before and after.

In the example, IDFA3 of QAID4 is new data, which is merged through IDFA3.

Before the merger:

After the merger:

Note:

• Before the merge, if you have referenced QAID4 by creating a crowd, after the merge, when you query users by using QAID4, you can query the data of QAID3. Therefore, the marketing tasks related to the crowd can still be performed normally.

• Before the merge, they are considered as two different users with one Taobao ID. After the merge, they are considered as only one user with two Taobao IDs. Therefore, the number of users and IDs in a marketing task may change over time, and the number of users and IDs may be inconsistent.

Label conflicts in ID Mapping and solutions

In the ID mapping process, in addition to the ID conflicts described above, tag conflicts may also occur, that is, for single-value tags in the same tag table, if originally two independent users are identified as the same user because the newly added data is identified as the same user, only one of the values can be taken during pooled data.

In this case, the system retains the tag value with the earliest creation time.

For example, QAID5 and QAID6 are two independent users, as shown in the following table.

When you import the tag table later, QAID6 adds a new mobile phone number as mobile phone number 5, which is the same as the QAID5 mobile phone number and has a high priority. In this case, QAID5 and QAID6 are identified as the same user during ID mapping. The following data is retained: