Adobe campaign recipient schema best practice while importing from CRM , Gigya and other sources | Community
Skip to main content
KotiSyamala
KotiSyamala
Level 5
February 16, 2022
Solved

Adobe campaign recipient schema best practice while importing from CRM , Gigya and other sources

  • February 16, 2022
  • 1 reply
  • 892 views

What is the best practice for nms:recipient schema while importing from different sources such as CRM & Gigya (with multiple profiles for a single user with same email id)  and some other resources as well.

 

What approach is the best ? is it okay to have duplicate records to have different profiles with same email id with different external IDs.

 

#AdobeCampaignClassic #Gigya #CRM #ACC

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 Tobias_Lohmann

Hi,

technically this is no issue, since the email attribute is not a key in the database. Internally all links are handled based on the nms:recipient/@id.

But in general you'd want to have the single view of the customer. If you have (eg.) 3 recipients with the same email address, it is hard to see which communication was sent to the single email address and how did the person interact with the email. 

The usual approach would be to have a single source of truth for recipient data. I know in the real world customers can have multiple sources, but in Campaign you should try to either merge or write source specific fields and keep the common fields only updated by one data source. You should set up additional fields and DB keys to host the data source ids in Campaign. Additionally/Alternatively you could add subscription services for each source and subscribe the single recipient to the relevant services during import, to track in which source this recipient was found.

Lastly: if that isn't possible at all, you could set up an enumeration field with a value for each source (Source 1, Source 2, etc.) and then create a combined DB key on email and source. That way you will partition the nms:recipient schema into multiple "buckets", one for each source. But in targeting, exporting, importing you will always have to include the "source" field for differentiation. 

I hope this gives you some inspiration; be assured, every user in this community has this exact issue and there are always different ways handling it.

Best regards, Tobias

1 reply

Tobias_Lohmann
Adobe Employee
Tobias_LohmannAdobe EmployeeAccepted solution
Adobe Employee
February 17, 2022

Hi,

technically this is no issue, since the email attribute is not a key in the database. Internally all links are handled based on the nms:recipient/@id.

But in general you'd want to have the single view of the customer. If you have (eg.) 3 recipients with the same email address, it is hard to see which communication was sent to the single email address and how did the person interact with the email. 

The usual approach would be to have a single source of truth for recipient data. I know in the real world customers can have multiple sources, but in Campaign you should try to either merge or write source specific fields and keep the common fields only updated by one data source. You should set up additional fields and DB keys to host the data source ids in Campaign. Additionally/Alternatively you could add subscription services for each source and subscribe the single recipient to the relevant services during import, to track in which source this recipient was found.

Lastly: if that isn't possible at all, you could set up an enumeration field with a value for each source (Source 1, Source 2, etc.) and then create a combined DB key on email and source. That way you will partition the nms:recipient schema into multiple "buckets", one for each source. But in targeting, exporting, importing you will always have to include the "source" field for differentiation. 

I hope this gives you some inspiration; be assured, every user in this community has this exact issue and there are always different ways handling it.

Best regards, Tobias

    Terms & ConditionsAccessibility statement

    Loading footer...