Does AEP automatically clean up old identity nodes when email/phone updates via batch ingestion?

Hi ​@santoshkr,

AEP does not automatically remove old identity nodes when an email or phone updates via batch ingestion. The identity graph is additive by design, new identity links are added, but existing nodes are not deleted when a value changes.

What happens in practice: if a user’s email changes and the new batch injects the updated email as an identity, AEP creates a new node for the new email and links it to the same profile. The old email node remains in the graph unless explicitly removed via the Identity Service API (DELETE /identity/cluster).

This means over time you can accumulate stale identity nodes, which can cause unintended profile merges if the old email/phone gets reused by another person, a real risk worth planning for.
 

For the identityMap migration specifically, the behavior is the same, identityMap doesn’t change the graph’s additive nature, it just changes how you’re sending the identity data in.

Recommended approach: implement a periodic identity graph audit and use the Privacy Service or Identity deletion APIs to clean up stale nodes proactively, especially for high-churn identifiers like phone numbers.

​@santoshkr 

Hi,

By default, ingesting a new email or phone value does not itself act as a deletion request for the previous identity relationship. Moving from schema identity descriptors to `identityMap` does not change this default behavior.

However, if your business rule is that each person should have only one current email and one current phone, you can use **Identity Graph Linking Rules**.

In Identity Service → Settings, configure the relevant person namespaces as **Unique per graph**, for example:

1. CRMID — Unique per graph, highest priority  
2. Email or Email_LC_SHA256 — Unique per graph  
3. Phone or the applicable hashed-phone namespace — Unique per graph  

A unique namespace is limited to one identity value within an identity graph. Therefore, if the graph already contains:

```text
CRMID: 123 + Email: old@example.com
```

and a later batch contains:

```text
CRMID: 123 + Email: new@example.com
```

the Identity Optimization Algorithm evaluates the unique-namespace constraint and retains the more recent valid relationship, removing the older conflicting link from the graph.

Adobe specifically documents “an end-user changes their email address” as an Identity Graph Linking Rules scenario.

A few considerations:

- Send only one current value for each unique namespace in an individual record.
- Use a stable, non-reassignable CRMID as the highest-priority person namespace.
- Mark email/phone unique only if the business truly allows one value of each per person. If multiple emails or phone numbers are valid, they should not be unique.
- Identity Graph Linking Rules manage graph links; they do not delete the old value from the source system or Data Lake.
- Existing graphs are generally re-evaluated when new data updates them after the rules are enabled. For correcting existing graphs at scale, Adobe recommends contacting the Adobe account team or Support.
- Use Graph Simulation to test the email/phone-change scenario before enabling the rules in production.

Also, Adobe’s current public Identity Service API does not document `DELETE /identity/cluster`, and Privacy Service should be reserved for regulatory data-subject requests—not routine identity maintenance.

​@santoshkr 

One important correction regarding deletion tools:

**Privacy Service should not be used for routine identity cleanup or correcting stale identity links.** Adobe documents Privacy Service specifically for data-subject requests under regulations such as GDPR and CCPA.

For operational data cleansing or data minimization, use **Advanced Data Lifecycle Management** record-delete work orders instead. These can target Identity Service, Real-Time Customer Profile and the Data Lake, depending on the request configuration and entitlements.

However, Data Lifecycle deletion is broader than simply replacing an old graph link and generally matches records using the dataset’s primary identity. Therefore, if the requirement is only to maintain one current email or phone per person, Identity Graph Linking Rules with **Unique per graph** is the better preventive solution. Use Data Lifecycle deletion only when the underlying records or identities must actually be removed.