ID Prioritisation - Zeotap docs

Level 2 is using our ID Prioritisation feature that provides you the granular control to define how the profile must be merged by setting priorities for IDs within the classifications. This is one of a kind feature that 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. 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. 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.

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 profile 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, looks up for a user profile match, where the lower priority ID in the incoming record is the highest priority identifier in matched profile If a match is found, then reconcile it with the master profile.

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 and more received in the record.	`Z1 {User ID: U1Maid: 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, consent and more received in the record.	`Z2 {Email: E1Maid: 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: U1Email: E1Maid: M2, M1GA Client ID: G1}`	This use case showcases how the system treats a record with two IDs received in the same classification (in this case it is Primary) with different priorities and how the reconciliation logic works.
User A fills up a campaign form and shares the mobile number and generates a unique discount code	`Mobile: 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 {Mobile: C1CCode: 123}`	This use case showcases how a record with a disabled ID is treatedif received
A profile of User A is shared from their Brand’s CRM	`Mobile: C1` `Email: E1`	In this record, there are two Primary IDs, both are 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, that is, Z3 is merged to it.	`Z1 {User ID: U1Email: E1Mobile: C1Maid: M2, M1GA Client ID: G1}`	This use case showcases how the system performs ID resolution andunification if a record contains IDs with the same priority within the classification.
User A navigates 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 Z3, the system will not update this data with Z3. 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-basedprofile to keep the accuracy of the profile intact. Here, the GA Client ID is classified as low-fidelity. Hence it does not lead to the merging of this record with Z3 (Primary ID-based profile).Only the future anonymous interaction continues to merge with Z4