Can AEP ignore Primary Identifier and merge only on basis of Secondary ID ?

[irohitshukla]

We faced a problem with an unexpected profile merge. 

Consider this scenario : 

Schema having some GlobalID as primary ID and email as secondary ID 

Now I have 2 profiles with below values: 

profile1 : GlobalID = 12345 ; Email = abc.xyz@mno.com 

profile2 : GlobalID = 98765 ; Email = abc.xyz@mno.com 

I see these two profiles got merged. My first question is if this is expected behaviour (primary ID is different yet it merged). 
If yes, how can we bypass this?

[arijitg]

Profiles were merged as expected. To merge two profiles if any identity matches it'll merge, it doesn't need to be primary identity only.

You can't bypass this because you designed your schema in this way, if you don't want profiles to merge over Email don't mark that as an identity.

[ChetanyaJain]

Hi @irohitshukla,

As @arijitg mentioned this is expected. In the real world, if the same email is used (eg: husband & wife using sharing the same email id) for different profiles then the profiles will get merged. So do your data analysis thoroughly and understand how the data is captured since that is one of the most important activities. Once you know how data is captured then you can decide which fields should be marked as identity.

If you have any further questions or want to discuss on the use case, please feel free to post follow-up questions.

Thanks,

Chetanya

[KevinFosterDX · Accepted solution]

It's expected behavior and no, you cannot bypass this.

When deciding on whether to mark something as an identity you need to first evaluate whether it's truly unique for the level of profile granularity that you want. In your case you seem to want GlobalID as the determination of profile granularity, and per your example above, email is not a good identity in your data as it is not unique per GlobalID.

Normally you won't need to mark email or phone numbers as identities BTW, as you can still activate to those values without marking them as identities. Those values are typically better left as simple profile attributes that aren''t marked as identities.

To stop using email as an identity the best path forward is to drop the dataset, unmark the email field in the schema so that it's no longer an identity, recreate the dataset, and then reload your data.