Best Practices to Avoid Profile Collapsing in Adobe RTCDP

[bestImv]

Hi Community,

I'm looking for guidance on best practices to prevent profile collapsing in Adobe RTCDP, especially when multiple users log in on the same device. Here's a scenario we're facing:

Originally, there 2 profiles in CDP:

CRM ID	Last Name	First Name	Phone	Loyalty Points Balance
crmid_1	Williams	Mich	+3333333333	50000
crmid_2	Gordon	Alex	+4444444444	500

Then, these two users logged in on the same device using their own CRM IDs. However, since the ECID is the same for both logins, the users are merged into one profile (`14858459145543911681221832870687150231`).

Event Example:

{ "timestamp": "2024-08-21T02:00:00Z", "event": "logged in", "CRM ID": "crmid_1", "ecid": "14858459145543911681221832870687150231" }

{ "timestamp": "2024-08-23T02:00:00Z", "event": "logged in", "CRM ID": "crmid_2", "ecid": "14858459145543911681221832870687150231" }

Questions:

1. How can we avoid this profile collapsing?
2. Once the profile is stitched, how can we split it?

This is crucial for sending marketing automation messages, such as those related to loyalty point balances, to the correct user rather than a mixed profile. What options do we have?For example, we can't send an email to William and tell him he only has a balance of 500. 

I've been searching for a solution on this forum and have read many posts about profile collapsing in RTCDP, but still not founding the true solution. I would really appreciate direct solutions instead of referrals to other posts.

Thank you,
Imv

[ccg1706]

Hi @bestImv,

Regarding your questions:

1. To mitigate profile collapsing you can implement the following practices: 

Device-Based Segmentation: Ensure that your identity management is configured to differentiate profiles based on the device. You can do this by associating unique device identifiers (such as ECID) with session - based or device- specific attributes. 

Session-Based Tracking: Implement session-based tracking, where each user session is treated independently. This involves using session IDs that are unique per user login. It will help to ensure that a new session does not automatically inherit the previous session's identity data unless explicitly indicated.

First-Party Identifiers: Prioritise first -party identifiers such as CRM IDs or login details over ECIDs for identity stitching. This will mean your stitching rules should only merge profiles when key-first party identifiers (like CRM Ids ) match, not only based on ECID.

Custom Identity Graphs: Use custom identity graphs to enforce strict identity resolution rules. You can define custom identity stitching logic  that prevents different CRM IDs from merging if they share the same ECID.

2. To split it you can follow the next steps:

Manual segmentation: Manually segment the stitched profile based on different events or attributes.

Attribute deletion or modification: Depending on business requirements and privacy policies, you might consider deleting or modifying specific attributes that caused the profiles to merge. Its important to manage this carefully to avoid data loss.

Custom Workflow for Re-stitching: Create a custom workflow to unmerge profiles. This could involve the identification of the event that led to profile emerging, deleting the incorrect associations, and then reprocessing the correct profiles separately.

Finally I leave you some useful doc links.

Identity service

Identities

Data quality 

Cheers, 

Celia

@jpetermarias 

[Rite18]

Consider using First-Party Identifiers: FPID instead of ECID directly 

[arpan-garg]

Hi @bestImv  - Recently Adobe released a solution to this problem, the solution is setting priority on the namespace. Its still in beta version but i tested it personally and it works quite well. More information can be found here https://experienceleague.adobe.com/en/docs/experience-platform/identity/features/identity-graph-link...

Thanks,

Arpan

[arijitg]

In addition to Arpan's response you can also set unique identity for identity graph configuration. So if you set CRM_ID to be unique then due to same device usage when a ECID is about to collapse 2 CRM_ID it will split out from the older graph and get linked to the new graph so no 2 CRM_ID will reside in a single graph. 

p.s. This feature is in beta status now and is Adobe employee confidential, you can reach out to your Technical Account Manager or Customer Success Manager to enroll

[kautuk_sahni]

@bestImv Did you find the suggestions helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!