Why Your Data Stitches in the Identity Graph but Fails in AEP Profiles

Have you ever noticed a strange behavior in Adobe Experience Platform (AEP)?

You can build a structural blueprint called a Schema with a special map called an identityMap. You can add an email and a phone number as normal identities, but leave the "Primary Identity" field completely blank. The system still allows you to click "Enable for Profile" and save it without any errors at all!

It looks like everything is working perfectly. But underneath the hood of Real-Time CDP, this creates a hidden trap: the system will connect your IDs in the map, but it will fail to create actual customer profiles.

Let’s understand why this happens using a simple story based on a real-world company: Walmart.

The Problem: Missing Profiles

Imagine Walmart is tracking digital shopping activity using an AEP Schema. A customer goes online and makes a purchase, providing their phone number and email.

Because the Walmart Schema has an identityMap at its root, AEP stores this transaction. Later, a data analyst checks what happened inside the system:

• The Identity Graph (Success):
  The system sees the phone number and the email and links them together. It knows both belong to the same customer.

• The Real-Time Customer Profile (Failure):
  The marketing team tries to find the customer’s profile to check purchase history or preferences, but no profile exists.

The system connected the dots, but it failed to create the actual profile.
All the valuable data ends up stored as raw records in the Data Lake, instead of being organized into actionable profiles.

The Architecture: Two Different Workers

Why does this happen? Because AEP has two independent systems working behind the scenes:

• Worker 1: The Graph Builder (Identity Service)
  This system focuses only on linking identities. If the same phone number appears in multiple places, it links them together. It does not create profiles. This is why the identity graph looks correct.

• Worker 2: The Profile Builder (Profile Service)
  This system is responsible for creating customer profiles. To build a profile, it requires one main identifier (Primary Identity).

When you save the schema without defining a Primary Identity, you are relying on the incoming data to specify it later.

If the incoming data does not clearly define which identity is primary, the Profile Service cannot proceed and does not create the profile.

The Solution: Fixing the Data Payload

Since the responsibility shifts from schema design to the data payload, the fix must be applied in the data being sent.

Every data payload must explicitly define the primary identity using "primary": true.

Correct JSON Example

{
  "email": "shopper@walmart.com",
  "phone": "+1234567890",
  "identityMap": {    
    "Phone": [
      {
        "id": "+1234567890",
        "primary": true
      }
    ],
    "Email": [
      {
        "id": "shopper@walmart.com",
        "primary": false
      }
    ]
  }
}

✅ Why This Works

• The Identity Service links both identities.
• The Profile Service identifies the primary identity using "primary": true and creates the customer profile.

🔑 Key Takeaways

• An identityMap without Primary Identity shifts responsibility to the data payload.
• Identity linking is not equal to profile creation.
• Always ensure one identity is marked as "primary": true in every payload.
• Without this, data remains isolated in the Data Lake and does not form unified profiles in RTCDP.