Executive summary

Identity resolution (IDR) is the foundation of any Customer Data Platform, and is best understood as a staged capability rather than a single feature. Salesforce Data 360 and Adobe Experience Platform (AEP) address non-deterministic, or “fuzzy”, data matching through radically different architectural paradigms.

• Salesforce Data 360 uses an object-relational, rule-engine approach. It resolves identities via downstream batch or asynchronous rulesets using fuzzy string algorithms (Levenshtein distance, Jaro-Winkler) alongside exact-match rules.
• Adobe Experience Platform (AEP) uses a streaming-first, graph-database approach. Its native Identity Service evaluates deterministic edge-links in real time. AEP intentionally omits a native, in-flight probabilistic string-matching engine to prevent edge-latency bottlenecks, delegating non-deterministic matching to upstream pipelines or external identity graph providers.

The core scenario: resolving the ambiguous customer

Consider a consumer interacting across three channels over 24 hours.

The core challenge: how does a platform merge the offline CRM entry (“Jon Smith”) with the web-form entry (“Johnathan Smith”) when variations in names, typos, or missing primary keys occur?

Platform 1: Salesforce Data 360 — native probabilistic and fuzzy matching

Salesforce resolves this by treating identity as an asynchronous table transformation problem.

Mechanics

1. Ingestion and staging. Data lands in Data Landing Objects (DLOs) and maps to Data Model Objects (DMOs) — for example an Individual DMO and a Contact Point Email DMO.
2. Ruleset configuration. Architects configure an identity resolution ruleset with multiple match rules: a deterministic rule (exact match on normalised email address) and a probabilistic rule (fuzzy first name at medium precision, with exact last name and exact phone number). This is where Data 360’s probabilistic matching does its work, using fuzzy match methods such as Levenshtein distance and Jaro-Winkler configured through the platform’s match-rule criteria.
3. Execution. The identity engine runs across the DMO tables. It evaluates the string distance between “Jon” and “Johnathan”, identifies the match on shared email and phone constraints, and creates a consolidated row in the Unified Individual DMO.

Trade-offs

Advantages: native, out-of-the-box support for typos, name variations, and dirty legacy data. Constraints: processing happens asynchronously downstream, introducing a delay between raw event ingestion and unified-profile activation.

Platform 2: Adobe Experience Platform — deterministic in-flight graph

Adobe approaches this through an in-flight graph-database model built on a native identity graph.

Mechanics

1. In-flight key extraction. As HTTP payloads hit the Adobe Edge Network, the ingestion engine scans the identityMap array in sub-seconds.
2. Deterministic edge linking. If a single payload contains two identifiers (for example ECID: 101 and Email: jon.smith@email.com), AEP’s Identity Service instantly draws a directed edge between those two nodes in the identity graph, following its identity graph linking rules. This is what makes AEP a real-time identity resolution architecture.
3. Virtual profile assembly. AEP does not rewrite records. When a profile lookup occurs, it queries the identity graph for connected nodes, retrieves the corresponding isolated profile fragments (web fragment, CRM fragment), and dynamically merges them using configurable merge policies.

The gap

If the offline CRM record contains Email: jon.smith@email.com and a separate web record contains Email: j.smith@email.com, with no shared cookie or primary key, AEP’s Identity Service will not link them. It lacks native fuzzy text evaluation on incoming streams.

Architecting workarounds in Adobe for probabilistic matching

Because AEP prioritises low-latency ingestion, non-deterministic matching must be handled through deliberate architectural patterns upstream or via partner ecosystems. The same trade-off appears wherever coverage on high-value records depends on multi-signal, probabilistic matching rather than exact keys alone.

Pattern A: upstream processing (Databricks, Snowflake, or enterprise MDM)

How it works: data engineers run identity resolution logic in the cloud data lakehouse or master data management (MDM) platform before pushing data to AEP.

Execution: algorithms — for example entity-resolution scripts in Databricks or Reltio — evaluate “Jon Smith” and “Johnathan Smith”, resolve them, and assign a persistent enterprise identifier such as Enterprise_ID: Master-8821.

AEP ingestion: data is ingested into AEP using an XDM schema where Enterprise_ID is defined as the primary identity. AEP’s graph then links Enterprise_ID: Master-8821 to incoming web cookies or device tokens.

Pattern B: third-party identity graph ingestion (LiveRamp, Merkle)

How it works: enterprise organisations leverage external identity resolution providers, such as LiveRamp RampID or Merkle Merkury, that maintain off-the-shelf deterministic and probabilistic identity networks.

Execution: raw customer attributes are mapped against the vendor’s identity graph offline or via batch pipelines.

AEP ingestion: mapped pairs — for example RampID: 9921 linked to ECID: 101 — are ingested directly into AEP’s Identity Service as a custom identity namespace. AEP ingests the pre-resolved edges natively into its graph structure without performing string calculations itself.

Comparative architectural summary