ID Prioritisation - Zeotap docs

Zeotap provides you with two levels of data merge control. Level 1 is when you classify an identifier as Primary or Secondary — where the system ensures a Secondary (low-fidelity) identifier-based record or profile is never merged with a Primary (high-fidelity) based record. See High-fidelity or Custom ID Strategy for the classifications themselves. Level 2 is the ID Prioritisation feature, which gives you granular control to define how profiles are merged by setting priorities for IDs within a classification. This gives you full control to create the most accurate customer profile for your business needs. Note that ID Prioritisation is an optional feature. By default, the system defines all the IDs as Priority 1 within a classification, and you can define up to five priority levels within a classification. If this is changed, then in addition to classification, the system also evaluates the priority of an ID within the classification to perform ID resolution and unification. Priorities are always evaluated within a classification — a Secondary ID never merges into a Primary-based profile, whatever its priority.

How priorities are evaluated

For an account where more than one identifier is defined within a (Primary or Secondary) classification with different priorities, the below-mentioned actions are performed for the incoming data record.

ID Strategy Prioritise your IDs screen showing Priority 1 and Priority 2 groups under PRIMARY ID, alongside SECONDARY ID and DISABLED ID — Prioritise your IDs: identifiers are grouped by priority level within each classification.

SCENARIO	PRIORITY	ACTION
Multiple IDs within a classification (Primary/Secondary)	Same priority	The system looks up a user profile that matches each of the identifiers of the same priority. If one match is found, then merge and enrich the profile with the new record. If multiple profiles are found, then merge all the profiles with the first created UCID as the master profile. If no match is found, then create a new profile.
Multiple IDs within a classification (Primary/Secondary)	Different priorities between identifiers	The system uses the profile with the highest priority ID match as the master profile. If the match is not found, then create a new profile. For lower-priority IDs in the same classification, the system looks up a user profile match where the lower priority ID in the incoming record is the highest priority identifier in the matched profile. If a match is found, then reconcile it with the master profile.

The No. of ID to store per profile setting in the ID classification table below controls how many values of that identifier a single profile retains — typically one for identifiers that should be unique to a person (a customer ID), and several for identifiers a person legitimately has more than one of (device IDs and cookies).

Example

Below is an example stating how multiple identifiers with different priorities within a classification work. For multiple identifiers with the same priority within a classification, you can refer to the example shared under the ID Classification section. We are considering the following ID classification to further explain the use cases for ID Prioritisation:

IDENTIFIER	CLASSIFICATION	PRIORITY	NO. OF ID TO STORE PER PROFILE
`User ID`	Primary	1	1
`Email`	Primary	2	1
`Cellphone`	Primary	2	1
`Maid`	Secondary	1	5
`GA Client ID`	Secondary	2	5
`CCode`	Disabled

USE CASE	DATA RECORD	WHAT DOES ZEOTAP DO?	PROFILE CREATED	NOTES
User A logs into the Brand’s mobile app 1	`User ID: U1` `Maid: M1`	Among the identifiers received, U1 is a Primary identifier. The system looks up a match for U1. As no match is found, it creates a new UCID: Z1. It also creates a linkage with all the other identifiers and maps the other information like profile, event, and consent received in the record.	`Z1 { User ID: U1, Maid: M1 }`
User A logs into the Brand’s app 2 using a different mobile device	`Email: E1` `Maid: M2`	As E1 is a Primary identifier, the system looks up a match for E1. With no match found, it creates a new UCID: Z2. It also creates linkages with all the other identifiers and maps the other information like profile, event, and consent received in the record.	`Z2 { Email: E1, Maid: M2 }`
User A logs into the Brand’s website	`User ID: U1` `Email: E1` `GA Client ID: G1`	In this record, there are two Primary IDs, U1 and E1. But U1 has the higher priority. Hence, the ID resolution happens using U1, and E1 is used for the reconciliation of any record where E1 is the highest ID in that profile. Based on the above steps, the system finds Z1 as a match for U1. Hence, that is treated as the master UCID to which Z2 is reconciled.	`Z1 { User ID: U1, Email: E1, Maid: M1, M2, GA Client ID: G1 }`	This use case showcases how the system treats a record with two IDs received in the same classification (in this case Primary) with different priorities, and how the reconciliation logic works.
User A fills up a campaign form, shares their mobile number, and generates a unique discount code	`Cellphone: C1` `CCode: 123`	In this record, there is only one Primary ID, that is C1. As no match is found, it stamps a new UCID and links the disabled ID, CCode: 123, to the profile.	`Z3 { Cellphone: C1, CCode: 123 }`	This use case showcases how a record with a disabled ID is treated if received.
A profile of User A is shared from their Brand’s CRM	`Cellphone: C1` `Email: E1`	In this record, there are two Primary IDs, both of the same priority. Hence, both IDs are used for ID resolution (lookup). For C1, the match found is profile Z3, and for E1, the match found is profile Z1. In this case, the profile with the first created UCID, that is, Z1 is retained as the master profile, and the other matched profile, Z3, is merged into it.	`Z1 { User ID: U1, Email: E1, Cellphone: C1, CCode: 123, Maid: M1, M2, GA Client ID: G1 }`	This use case showcases how the system performs ID resolution and unification if a record contains IDs with the same priority within the classification.
User A navigates the website anonymously (without logging in)	`GA Client ID: G1`	We received data against a Secondary (low fidelity) identifier, GA Client ID. Hence, although there is a match found with Z1, the system does not update this data with Z1. It rather stamps a new UCID.	`Z4 { GA Client ID: G1 }`	This use case showcases how a Secondary ID-based record is resolved. Even though a match is found, it is not unified with a Primary ID-based profile, to keep the accuracy of the profile intact. Only future anonymous interactions continue to merge with Z4. To unify anonymous visits with a known profile instead, see How to Stitch Unknown to Known Profile.

​How priorities are evaluated

​Example

​Related Topics

High-fidelity or Custom ID Strategy

How does Custom Strategy Work

How priorities are evaluated

Example

Related Topics