AEP Profile Merge Policies: Avoiding Duplicate Profiles

Understanding the Unified Profile

Adobe Experience Platform's Real-Time Customer Profile unifies data from multiple sources into a single view of each customer. It stitches together:

• Profile attributes (name, email, preferences)
• Experience events (website visits, purchases, app interactions)
• Segment memberships
• Computed attributes and ML scores

The magic happens through identity stitching—connecting different identifiers (email, ECID, CRM ID) to recognize them as the same person. But this is also where things go wrong.

What Are Merge Policies?

A merge policy tells AEP how to combine profile fragments from different datasets when identities conflict or overlap. It answers questions like:

• Which dataset's value wins when two sources have different emails?
• Should we use the private identity graph or shared?
• How do we handle timestamp conflicts?

Merge Policy Components

Setting	Options	Impact
ID Stitching	Private Graph / None	How identities are linked across datasets
Attribute Merge	Timestamp Ordered / Dataset Precedence	Which value wins when attributes conflict
Dataset Precedence	Ordered list of datasets	Priority when using Dataset Precedence merge

Common Duplicate Profile Scenarios

Scenario 1: No Identity Stitching

The most common cause of duplicates: ID Stitching set to "None".

Result: One person = Two profiles (anonymous + known)

Fix: Enable "Private Graph" for ID Stitching in your merge policy. This uses your identity graph to connect related identifiers.

Scenario 2: Missing Identity Links

Identity stitching is enabled, but identities aren't being linked at ingestion time.

// BAD: Each identity sent separately
// Profile 1
{ "identityMap": { "ECID": [{"id": "ABC123"}] } }

// Profile 2 (same person, but no link!)
{ "identityMap": { "Email": [{"id": "[email protected]"}] } }

// GOOD: Send both identities together
{
  "identityMap": {
    "ECID": [{"id": "ABC123"}],
    "Email": [{"id": "[email protected]"}]
  }
}

Scenario 3: Merge Policy Mismatch

Different parts of your implementation use different merge policies.

• Dataset A uses "Timestamp Ordered" merge policy
• Dataset B uses "Dataset Precedence" merge policy
• Segment uses a third merge policy

Result: Profiles appear differently depending on which merge policy is applied. Segments may include/exclude profiles unexpectedly.

Fix: Standardize on one merge policy for all profile-enabled datasets and segments. Document it and enforce it.

Scenario 4: Cross-Device Identity Issues

Mobile app and website generate different ECIDs. Without proper login events linking them, you get device-level profiles instead of person-level.

Symptoms:

• Profile count much higher than actual customer count
• Same person appears in multiple segments
• Activation sends duplicate communications

Configuring Merge Policies Correctly

Step 1: Create a Default Merge Policy

1. Navigate to Profiles → Merge Policies
2. Click Create merge policy
3. Name it clearly (e.g., "Production-Default")
4. Set as default if appropriate

Step 2: Configure ID Stitching

For most use cases, select Private Graph:

• Private Graph: Uses your organization's identity graph. Recommended for most implementations.
• None: No cross-identity stitching. Use only for specific isolation requirements.

Step 3: Choose Attribute Merge Method

Method	Best For	How It Works
Timestamp Ordered	Most use cases	Most recent value wins based on event timestamp
Dataset Precedence	Authoritative source scenarios	Higher-priority dataset always wins, regardless of timestamp

Step 4: Apply to Datasets and Segments

Ensure consistency by:

• Using the same merge policy for all profile-enabled datasets
• Selecting the correct merge policy when creating segments
• Documenting which merge policy destinations should use

Diagnosing Duplicate Profiles

Using Profile Viewer

1. Go to Profiles in AEP
2. Search for a customer by known identity (email)
3. Check the Identity tab for all linked identifiers
4. If identities aren't linked, you likely have duplicates

Query Service Investigation

-- Find potential duplicates by email
SELECT 
  email,
  COUNT(DISTINCT _id) as profile_count
FROM profile_snapshot
WHERE email IS NOT NULL
GROUP BY email
HAVING COUNT(DISTINCT _id) > 1
ORDER BY profile_count DESC
LIMIT 100;

Identity Graph Inspection

Use the Identity Graph Viewer to see how identities are connected:

1. Go to Identities → Identity Graph Viewer
2. Enter a known identity value
3. Review the graph visualization
4. Check if expected identities are connected

Fixing Existing Duplicates

Option 1: Re-Ingest with Proper Identity Links

If you have access to source data:

1. Delete the problematic dataset
2. Fix your ETL to include all identities in each record
3. Re-ingest with proper identity maps

Option 2: Send Linking Events

Create synthetic events that link orphaned identities:

// Event to link previously unconnected identities
{
  "identityMap": {
    "ECID": [{"id": "orphaned-ecid-123"}],
    "Email": [{"id": "[email protected]", "primary": true}],
    "CRM_ID": [{"id": "CRM-456"}]
  },
  "eventType": "identity.link",
  "timestamp": "2025-01-15T00:00:00Z"
}

Option 3: Accept and Mitigate

If re-ingestion isn't possible:

• Build segments that account for fragmentation
• Use deduplication in destination activation
• Fix the process going forward to prevent new duplicates

Best Practices Summary

1. Always use Private Graph for ID Stitching unless you have specific isolation requirements
2. Send all known identities together in login/registration events
3. Standardize on one merge policy across datasets and segments
4. Monitor identity graph health regularly for unexpected patterns
5. Document your identity strategy and train all implementers
6. Test with known users before scaling to production