B2B Real Time CDP - How to avoid the customer and Partner profiles from getting stitched together.

[UrvashiKiranMa]

Hi All,

We are currently working on a B2B use case where some individuals may have both customer and partner account types. In certain cases, these profiles may share the same email address, Marketo person ID, or account ID. However, our requirement is to keep these profiles separate and avoid stitching them together, even when the identities (email or Marketo person ID) overlap.

Given that we are using email ID and Marketo person ID as our primary identifiers,secondary identifiers could you please advise on the best approach or configuration to ensure that customer and partner profiles remain distinct in our system?

Thank you for your guidance.

Field	Duplicate 1 (Customer)	Duplicate 2 (Partner)
ECID	1234	1234
Email	CDP_DedupeTest4@wd-test.com	CDP_DedupeTest4@wd-test.com
First Name	Bob	Bob
Last Name	Smith	Smith
Company	XYZ	XYZ
Account Type	Customer	Partner
Account Id	99999	11111
SFDC Id	123XYZ	321ABC
Person Id	1212121	3434343
Marketo Filters	Customers Only	Partners Only

Sample record

[Abie]

Hi @UrvashiKiranMa ,

In my opinion, you got to map Customer and Partner to different classes, mentioned here-

https://experienceleague.adobe.com/en/docs/experience-platform/rtcdp/schemas/b2b

Other option could be using different identity namespace for these two identity types. 

I hope it helps. Thanks!

[Karuppiah_Sakthivel]

In AEP, profiles are stitched when they share the same identity value and namespace. If you want Customer and Partner profiles to stay separate even when they share the same email or Marketo ID, the best approach is to create distinct identity namespaces (e.g., Email_Customer and Email_Partner) or use different primary identities in each dataset.

That way, AEP treats them as separate identities in the graph and keeps the Customer and Partner profiles isolated. Another quick option is to append a role suffix or prefix to the identity value during ingestion (like email#Partner), but custom namespaces are the cleanest long-term solution.