Expand my Community achievements bar.

SOLVED

No Identity stitching

Avatar

Level 8

Hi, 

 

What is actual response if we do not choose Identity stitching

Does AEP would response with data regarding only that specific identity namespace which we are looking for in the profile? 

 

Michael_Soprano_0-1709291446817.png

 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @Michael_Soprano  - As @Kumar_Saurabh_  pointed out, selecting this option ensures that IDs will not be combined. This means that if segmentation occurs, the system will not attempt to merge identities potentially belonging to the same individual. Instead, segmentation will evaluate the attributes associated with each unique ID to decide whether a customer fits into a particular audience group. Consequently, it is possible for a single customer to be represented by multiple profiles, each qualifying for different audience segments. This could lead to the same customer receiving several marketing messages tailored to these diverse segments.

 

One practical application of creating a merge policy that excludes ID stitching involves situations where you need to delete data associated with a specific identity. Consider having two schemas: one with the primary ID as CRM ID, and the other with ECID as the primary ID and CRM ID as the secondary ID. Under normal circumstances, using stitching would combine data from both sources.

However, if you later decide to remove data ingested under the first schema, which uses CRM ID as its primary identifier, you can establish a merge policy that does not incorporate stitching. By providing the CRM ID and the merge policy ID to the deletion API, you can ensure that only the data from the first dataset is eliminated.

 

Thanks,

Arpan

View solution in original post

3 Replies

Avatar

Employee

HI @Michael_Soprano ,
Identity stitching (ID stitching) is the process of identifying data fragments and combining them together to form a complete profile record. To help illustrate the different stitching behaviors, consider a single customer who interacts with a brand using two different email addresses.

  • None: When this option is selected, IDs will not be stitched together. When segmentation occurs, identities that may belong to the same person will not be stitched together and segmentation will only consider the attributes attached to each individual ID when determining if a customer qualifies for audience membership. This could result in a single customer having multiple profiles and each profile could qualify for different audiences, resulting in multiple marketing messages being sent to the same customer.
  • Private graph: When the private graph is selected, multiple identities related to the same individual are stitched together. This results in the customer having a single profile and allows segmentation to consider multiple attributes from multiple related identities when determining segment qualification. In this scenario, the customer is likely to have a single profile, qualify for one audience based on the combination of attributes across identities, and receive only one marketing message.
    https://experienceleague.adobe.com/docs/experience-platform/profile/merge-policies/overview.html?lan...

Avatar

Correct answer by
Community Advisor

Hi @Michael_Soprano  - As @Kumar_Saurabh_  pointed out, selecting this option ensures that IDs will not be combined. This means that if segmentation occurs, the system will not attempt to merge identities potentially belonging to the same individual. Instead, segmentation will evaluate the attributes associated with each unique ID to decide whether a customer fits into a particular audience group. Consequently, it is possible for a single customer to be represented by multiple profiles, each qualifying for different audience segments. This could lead to the same customer receiving several marketing messages tailored to these diverse segments.

 

One practical application of creating a merge policy that excludes ID stitching involves situations where you need to delete data associated with a specific identity. Consider having two schemas: one with the primary ID as CRM ID, and the other with ECID as the primary ID and CRM ID as the secondary ID. Under normal circumstances, using stitching would combine data from both sources.

However, if you later decide to remove data ingested under the first schema, which uses CRM ID as its primary identifier, you can establish a merge policy that does not incorporate stitching. By providing the CRM ID and the merge policy ID to the deletion API, you can ensure that only the data from the first dataset is eliminated.

 

Thanks,

Arpan