Can AEP ignore Primary Identifier and merge only on basis of Secondary ID ? | Community
Skip to main content
I
irohitshukla
Level 2
January 3, 2023
Solved

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

  • January 3, 2023
  • 3 replies
  • 1545 views

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?

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by KevinFosterDX

    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.

    3 replies

    arijitg
    Adobe Employee
    arijitgAdobe Employee
    Adobe Employee
    January 3, 2023

    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-1
      Community Advisor
      ChetanyaJain-1Community Advisor
      Community Advisor
      January 3, 2023

      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

      K
      Adobe Employee
      KevinFosterDXAdobe EmployeeAccepted solution
      Adobe Employee
      January 6, 2023

      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.

        Terms & ConditionsAccessibility statement

        Loading footer...