Methodological Principles for Customer Identity Resolution

\newpage

Abstract

Customer Identity Resolution (CIR) is a fundamental capability of a modern Customer Data Platform (CDP). Its purpose is to determine whether multiple raw customer records generated by different systems represent the same real-world individual and, when sufficient evidence exists, connect those records to a unified Master Profile.

Traditional record linkage approaches often focus primarily on whether identity attributes such as email, phone number, or customer ID match. However, customer data generated in modern omnichannel environments has different levels of reliability. A verified customer identifier from an internal CRM should not necessarily receive the same evidential weight as a phone number voluntarily entered into an anonymous web survey. Similarly, a device identifier generated by a mobile application provides useful behavioral continuity but does not necessarily prove human identity.

This paper proposes a Source-Aware Evidence-Based Customer Identity Resolution (SAE-CIR) methodology. The approach evaluates identity evidence according to three principal dimensions: identity-signal strength, source reliability, and data quality. These dimensions produce an evidence score. When representative labeled data are available, the score and other comparison features can be calibrated into a match probability to determine whether a raw profile should be linked to an existing Master Profile, subjected to additional review, or used to create a new Master Profile.

The proposed methodology further represents identity relationships as an Identity Graph, enabling the CDP to preserve identity evidence, provenance, scores or calibrated probabilities, and temporal information rather than simply merging records. This creates a more transparent, explainable, auditable, and adaptable foundation for Customer 360, segmentation, personalization, analytics, and marketing activation.

1. Introduction

Modern customers interact with organizations through many channels.

A single individual may:

• view an advertisement,
• visit a website,
• create an account,
• use a mobile application,
• submit a feedback form,
• communicate through social media,
• purchase through an e-commerce channel,
• purchase through a physical store,
• interact with customer service,
• and later return through another device.

Each interaction can produce a different customer record.

For example:

Advertising Platform
    device_id = A123
 
Website
    anonymous_id = X891
    email = customer@example.com
 
Mobile Application
    device_id = A123
    phone = 090xxxxxxx
 
CRM
    customer_id = C001
    email = customer@example.com
    phone = 090xxxxxxx

A conventional data warehouse may store these records as separate rows.

A CDP, however, needs to answer a more fundamental question:

Which of these records belong to the same real-world person?

This is the problem of Customer Identity Resolution.

CIR is therefore not simply a database deduplication operation. It is an evidence-based identity inference process.

The central proposition of this paper is:

$$\boxed{\text{Identity Resolution}\ne \text{Simple Record Matching}}$$

Instead:

$$\boxed{\text{Identity Resolution}=\text{Evidence Evaluation}+\text{Confidence Estimation}+\text{Identity Graph Construction}}$$

2. The Customer Identity Problem

Multiple representations of one person

A real-world individual can be represented by multiple identifiers:

$$P=email,phone,devic{e}_{i}d,custome{r}_{i}d,anonymou{s}_{i}d,externa{l}_{i}d,\dots$$

However, no individual system necessarily contains the complete representation.

For example:

Profile A
Source = Website
 
device_id = A123
email = customer@example.com

Profile B
Source = Mobile App
 
device_id = A123
phone = 090xxxxxxx

Profile C
Source = CRM
 
customer_id = C001
email = customer@example.com
phone = 090xxxxxxx

The CDP must infer that:

$$A\approx B\approx C$$

and construct a unified identity representation.

\newpage

3. Raw Profile Model

Let a raw profile be defined as:

$$r_i=i{d}_i,sourc{e}_i,attribute{s}_i,event{s}_i,timestam{p}_i$$

where:

• (id_i) is the source-specific record identifier;
• (source_i) identifies the originating system;
• (attributes_i) contains identity and profile attributes;
• (events_i) contains associated behavioral events;
• (timestamp_i) represents the observation time.

A raw profile may therefore look like:

Raw Profile
------------------------
source: mobile_app
device_id: A123
email: customer@example.com
phone: 090xxxxxxx
timestamp: 2026-08-24

The objective of CIR is to determine whether:

$$r_i\to M_j$$

where (M_j) represents an existing Master Profile.

4. Master Profile

A Master Profile represents the CDP’s current operational representation of a customer identity hypothesis. It may correspond to a real-world customer, but the system should not treat that correspondence as certain merely because a profile exists.

Conceptually:

                    MASTER PROFILE
                         |
          ----------------------------------
          |              |              |
      CRM Profile    App Profile    Web Profile
          |              |              |
          ----------------------------------
                         |
                    Identity Graph

The Master Profile should not be understood as simply a merged database row.

It is better represented as:

$$M_j=identity,attributes,links,evidence,confidence,provenance,events$$

This distinction is important because a CDP must preserve not only the resolved identity but also why the system believes the identity is correct.

\newpage

5. Identity Graph

CIR creates an Identity Graph representing relationships among raw profiles and Master Profiles.

A simplified representation is:

                     Master Profile
                           |
             --------------------------------
             |             |             |
             v             v             v
        Raw Profile    Raw Profile    Raw Profile
          Website          App        Ads Platform

Each connection is an Identity Graph Link.

A link can be represented as:

$$L_{ij}=(r_i,M_j,S,\hat{p},D,E,T)$$

where:

• (r_i) = raw profile;
• (M_j) = Master Profile;
• (S) = evidence-support score;
• ($\hat{p}$) = calibrated match probability, when available;
• (D) = resolution decision;
• (E) = identity evidence;
• (T) = timestamp.

This approach provides an important property:

Identity decisions become explainable and auditable relationships rather than irreversible record merges.

6. Identity Signals

CIR evaluates identity signals provided by raw profiles.

Typical signals include:

6.1 Potentially strong signals

• an identifier issued and controlled by the organization and bound to an authenticated account;
• an email address or phone number verified in an authenticated context;
• a loyalty or customer identifier with documented issuer controls and uniqueness;
• an account identifier with a recent, successful authentication.

These signals are strong only when the issuing, verification, uniqueness, and recency assumptions hold. A CRM column or an identifier named customer_id is not automatically proof of identity.

6.2 Context-dependent signals

• device ID;
• application user ID;
• cookie or advertising ID;
• external customer ID;
• unverified email or phone number.

These can provide useful continuity or supporting evidence, but they may be shared, reset, recycled, copied, or controlled by another party.

6.3 Weak or contextual signals

• IP address;
• user-agent;
• geographic location;
• browsing similarity;
• behavioral similarity;
• inferred attributes.

The categories are hypotheses for an initial policy, not fixed industry truth. The strength of a signal depends on its comparison method, acquisition context, population, collision rate, verification status, and recency.

The exact strength of each signal should be configurable.

A conceptual signal-weight model is:

Identity Signal	Example Weight
Verified Customer ID	1.00
Verified Email	0.95
Verified Phone	0.95
Loyalty ID	0.90
Authenticated User ID	0.90
Device ID	0.60
Anonymous ID	0.40
IP Address	0.20

These values are illustrative priors for an example policy, not probabilities and not universal constants. They should be replaced or adjusted using labeled validation data and monitored separately by source, signal, population, and time.

7. Why Signal Strength Alone Is Insufficient

A major limitation of conventional identity matching is that it assumes:

If the same field matches, the identity evidence is equally reliable.

This assumption is incorrect.

Consider two phone numbers.

Case A

Source:
Internal CRM
 
Phone:
0901234567

Case B

Source:
Anonymous Web Survey
 
Phone:
0901234567

The identity signal is the same:

$$signal=phone$$

However, the reliability of the source is different.

The CRM record may have been collected during an authenticated customer transaction, while the survey response may have been manually entered without authentication.

Therefore:

$$\boxed{\text{Signal Strength}\ne \text{Evidence Strength}}$$

Evidence strength must consider the source.

8. Source Trust

Each observation should therefore have a configurable source-reliability factor, which is usually more precise than one global score for an entire system:

$$W_{source}(s,k,c)\in [0,1]$$

Here $s$ is the source, $k$ is the signal or field, and $c$ is the acquisition context, such as an authenticated transaction or an anonymous form. The factor represents the expected reliability of that particular observation, not the probability that the person match is correct.

A conceptual model is:

Source	Example	Illustrative prior
Internal CRM	Verified customer record	0.95
Authenticated Account	Login + verified identity	0.95
POS / Transaction	Customer / loyalty ID	0.90
Mobile App	Authenticated application	0.85
Website Login	Authenticated website	0.80
Marketing Platform	Advertising identifier	0.50
External Partner	Third-party customer data	0.40
Web Feedback Form	Self-entered information	0.30
Anonymous Survey	Self-reported feedback	0.20

These values should be governed by organizational data-quality policies and validated against representative labeled outcomes. They should not be copied into production as universal constants.

9. Source Trust and Data Governance

Source trust should be treated as a data-governance parameter, not merely an algorithm parameter.

For example:

Source Registry
----------------------------------
CRM
  trust = 0.95
 
Mobile App
  trust = 0.85
 
Website
  trust = 0.80
 
Google Ads
  trust = 0.50
 
External Survey
  trust = 0.20

This creates a direct relationship between:

$$\text{Data Governance}\to \text{Source Trust}\to \text{CIR}\to \text{Customer 360}$$

A data-governance team can maintain source policies without changing the identity-resolution engine. However, changing a trust policy changes scores and possibly links, so the policy must be versioned, approved, monitored, and reprocessed according to the organization’s change procedure.

10. Data Quality

Source trust alone is also insufficient.

A trusted source can still contain poor-quality data.

For example:

CRM
phone = 090 123 4567

may be high quality.

But:

CRM
phone = 0901234567 ???

may contain formatting or validation problems.

Therefore, CIR introduces an observation-level quality factor:

$$W_{quality}(i,k)\in [0,1]$$

representing the quality of signal $k$ in observation $i$. Quality should be computed from documented, non-duplicative checks. For example, normalization, format validity, and verification status should not be multiplied as if they were independent when one check is derived from another.

Examples of quality factors include:

• format validity;
• verification status;
• recency;
• completeness;
• consistency;
• duplication;
• expiration;
• normalization quality.

\newpage

11. Three-Dimensional Identity Evidence

The proposed methodology therefore defines an illustrative evidence contribution as:

$$\boxed{E_k=M_k\times W_{signal,k}\times W_{source,k}\times W_{quality,k}}$$

where:

• (M_k) = the comparison result for identity signal (k);
• (W_{signal,k}) = intrinsic strength of the identity signal;
• (W_{source,k}) = trust of the originating source;
• (W_{quality,k}) = quality of the observed data.

For a simple agreement model, the comparison result can be represented by $M_k\in [-1,1]$, where positive values indicate agreement, negative values indicate contradiction, and zero indicates missing or uninformative data. The resulting $E_k$ is an evidence contribution, not a probability that two records belong to the same person. The weights must be defined for a particular signal, source context, and population; they are not universal constants.

A simple example with CRM, Web Survey, and Facebook Ads:

11.1 Example: Same customer appears in 3 sources

Suppose the system is checking whether three records belong to Nguyen Van A.

Source	Signal	Comparison (M_k)	Signal Weight	Source Trust	Quality	Evidence (E_k)
CRM	Phone = 0901234567	1.0	1.0	0.95	1.0	0.95
Web Survey	Email = a@gmail.com	1.0	0.9	0.70	0.9	0.567
Facebook Ads	Email = a@gmail.com	1.0	0.9	0.40	0.8	0.288

So:

[ E_{CRM}=1.0\times1.0\times0.95\times1.0=0.95 ]

[ E_{Survey}=1.0\times0.9\times0.70\times0.9=0.567 ]

[ E_{Facebook}=1.0\times0.9\times0.40\times0.8=0.288 ]

Interpretation

The important point is that the same identity signal does not have the same evidential value across sources.

CRM phone match = strong evidence because CRM is a highly trusted first-party source. Web Survey email match = moderate evidence because the user manually provided it, but it may contain errors. Facebook Ads email match = weaker evidence because the data may be inferred, hashed, uploaded, or less directly controlled.

For example, if Facebook Ads says the email matches but CRM says the phone belongs to a different person, the system should not treat both signals equally. The CRM evidence carries substantially more weight.

A very simple way to explain CIR is:

CIR does not ask only “Do these values match?” It asks “How strong is the match, how trustworthy is the source, and how good is the data?”

\newpage

12. Dynamic Identity Matching

CIR should not require every raw profile to contain the same attributes.

Instead, it dynamically determines which identity signals are available.

For two profiles:

$$r_i=devic{e}_{i}d,email,phone$$ $$r_j=devic{e}_{i}d,email$$

the common identity signals are:

$$S(r_i,r_j)=devic{e}_{i}d,email$$

CIR evaluates only the applicable signals.

This can be represented in the system as:

DYNAMICMATCH:
device_id
email

The dynamic approach is important because different systems naturally expose different identity information.

13. Evidence Score and Calibrated Probability

For each pair of candidate identities, CIR first computes an evidence-support score. A simple weighted formulation is:

$$S(r_i,r_j)=\sum _{k\in K_{obs}}{M}_k\cdot W_{signal,k}\cdot W_{source,k}\cdot W_{quality,k}\cdot W_{independence,k}\cdot W_{time,k}$$

where $K_{obs}$ contains the usable comparisons and the additional factors are defined when temporal decay or correlated evidence is modeled. Missing values must not be treated as agreement. Contradictory high-quality evidence should reduce the score or block an automatic link.

The score $S$ is not automatically a calibrated probability. If the system must report a probability, it should estimate it from labeled same-person and different-person pairs, for example with a supervised model:

$$\mathrm{logit}(\hat{p})={\beta }_0+\sum _k{\beta }_k{x}_k$$

where the features $x_k$ include comparison outcomes, signal type, source context, data quality, recency, and candidate ambiguity. The resulting $\hat{p}=P(Y=1\mid x)$ should be calibrated on held-out data and monitored for drift. Without representative labels, the system should report an evidence score and its uncertainty rather than call the score a probability.

The calibrated probability, when available, satisfies:

$$\hat{p}\in [0,1]$$

and can be represented as a percentage only after calibration:

$$Confidence=100\hat{p}$$

13.1 Example: Internal CRM Evidence

Suppose an internal CRM provides a phone number.

Source Trust
= 0.90
 
Phone Signal Strength
= 0.95
 
Data Quality
= 1.00

Therefore:

$$E=0.95\times 0.90\times 1.00$$ $$E=0.855$$

This represents strong identity evidence.

13.2 Example: External Feedback Survey

Suppose a customer voluntarily enters the same phone number into an external web feedback survey.

Source Trust
= 0.20
 
Phone Signal Strength
= 0.95
 
Data Quality
= 1.00

Therefore:

$$E=0.95\times 0.20\times 1.00$$ $$E=0.19$$

The phone number remains a strong type of identifier, but its evidential contribution is low because the source is less trusted.

This distinction is fundamental:

A strong identifier from a weak source is not necessarily strong identity evidence.

\newpage

14. Multiple Evidence Sources

CIR should allow evidence to accumulate across independent sources.

Consider:

CRM
phone = 0901234567
trust = 0.90
 
Mobile App
device_id = A123
trust = 0.85
 
Web Survey
phone = 0901234567
trust = 0.20

The evidence can be represented as:

CRM Phone
#################  0.855
 
App Device
##########        0.510
 
Survey Phone
####               0.190

The survey evidence is not discarded.

It simply contributes less to the identity decision.

Thus:

Weak evidence may reinforce an identity hypothesis, but should rarely establish identity by itself.

15. Independence of Evidence

CIR should also consider whether multiple signals are genuinely independent.

For example:

email
phone

may provide two different identity signals.

However:

device_id
cookie_id

may both originate from the same browser or device and therefore should not necessarily be treated as fully independent evidence.

Consequently, a production CIR system should avoid simply adding every matching signal.

A more sophisticated model can introduce an independence or correlation factor:

$$E_k=M_k\cdot W_{signal,k}\cdot W_{source,k}\cdot W_{quality,k}\cdot W_{independence,k}$$

where:

$$W_{independence,k}\in [0,1]$$

reduces double-counting of correlated signals.

This factor is a modeling assumption, not proof that evidence is independent. Systems should group signals that share an origin, cap their combined contribution, and test performance on records from the same household, device, network, or account. Repeated copies of the same value from different feeds should not be counted as independent confirmations.

16. Resolution Thresholds

Once CIR calculates an evidence score or calibrated probability, the result can be classified into resolution bands.

For example:

Score or calibrated probability
    |
    +++ 0.90 +++++++++ AUTO LINK
    |
    +++ 0.70 +++++++++ REVIEW
    |
    ++++ 0.00 +++++++++ NO MATCH

The equations below assume that $\hat{p}$ is a calibrated probability. If only the raw score $S$ is available, the system must use separately validated score thresholds and must not label them as probabilities.

Conceptually:

$$\hat{p}\ge T_{auto}\Rightarrow LINK\text{if no blocking conflict exists}$$ $$T_{review}\le \hat{p}<T_{auto}\Rightarrow REVIEW$$ $$\hat{p}<T_{review}\Rightarrow NOLINK$$

An automatic link should also consider the difference between the best and second-best candidates, hard contradictions, and the cost of a false positive. The thresholds should be selected using a labeled validation set and explicit precision, recall, coverage, and review-capacity targets. Values such as 0.90 and 0.70 are examples only; they are not generally valid probabilities.

For high-risk identity operations, the organization may require stronger evidence.

For low-risk personalization use cases, lower thresholds may be acceptable.

17. Resolution Outcomes

CIR should distinguish between confidence and resolution outcome.

The possible outcomes include:

17.1 Existing Master

A sufficiently supported and unambiguous candidate match exists:

$$r_i\to M_j$$

17.2 Review

Evidence is insufficient for automatic resolution:

$$r_i\to REVIEW$$

17.3 No Match

The raw profile is not linked to the evaluated candidate, either because the evidence is insufficient or because a contradiction blocks the link:

$$r_i\to NOMATCH$$

17.4 New Master

No acceptable existing candidate is selected, and the system creates a new provisional identity cluster or Master Profile according to its lifecycle policy:

$$r_i\to M_{new}$$

18. New Master Profile Is Not a 100% Match

This distinction is particularly important for CIR system design.

Suppose a new raw profile arrives:

device_id = A123

and CIR finds no suitable Master Profile.

The system creates:

Master Profile M1005

This does not mean that the raw profile has been proven to represent a new real-world person. It also does not create a match probability for an existing candidate; that value should remain unavailable or explicitly marked as not applicable.

Instead, the correct interpretation is:

Resolution Outcome:
NEW_MASTER
 
Match Probability:
N/A

The new Master Profile is an operational container or identity hypothesis. It may later be linked, split, merged, or retired as new evidence arrives. A system should keep the candidate-level decision, the lifecycle action, and any probability or score as separate fields.

Therefore the system should maintain separate fields:

resolution_outcome
match_score
calibrated_match_probability
match_reason
match_evidence

rather than combining them into one value.

19. Identity Graph Link Model

A production identity link can therefore be modeled as:

$$\begin{array}{rl}L=\{& \text{raw\_profile\_id},\text{master\_profile\_id},\text{evidence\_score},\\ & \text{calibrated\_match\_probability},\text{outcome},\text{evidence},\\ & \text{source\_context},\text{timestamp},\text{algorithm\_version}\}\end{array}$$

For example:

Raw Profile
759301f2...
 
Master Profile
M000128
 
Calibrated Match Probability (illustrative)
0.96
 
Outcome
LINKED
 
Evidence
device_id
email
phone_number
external_customer_id
 
Sources
Mobile App
Website
CRM
 
Algorithm Version
cir-v2.4
 
Timestamp
2026-08-24

This creates complete provenance.

20. Explainability

Every CIR decision should be explainable.

Instead of simply returning:

MATCH = TRUE

CIR should return:

MATCH = TRUE
 
CONFIDENCE = 0.96
 
REASON:
Matched using:
- email
- phone
- device_id
 
SOURCE EVIDENCE:
CRM = high trust
Mobile App = high trust
Website = medium trust

This allows business users, data engineers, and auditors to understand why an identity relationship exists.

\newpage

21. Temporal Identity

Identity is not necessarily static.

A person may:

• change their phone number;
• change email address;
• replace a device;
• stop using an application;
• share a household device;
• lose access to an account.

Therefore, identity evidence should include time:

$$E_k(t)$$

A recent verified phone number may be more relevant than an old phone number.

A temporal decay factor can be introduced when historical evidence is expected to become less predictive. It is not universally appropriate: a device ID may be short-lived, while a contractual customer identifier may remain valid until explicitly revoked. Expiration, revocation, and effective-validity rules should be modeled separately from statistical decay.

$$W_{time,k}(\Delta t)=e^{-{\lambda }_k\Delta t}$$

where:

• ($\Delta t$) = age of the evidence;
• (${\lambda }_k$) = signal-specific decay rate.

The extended evidence model becomes:

$$\boxed{E_k=M_k\cdot W_{signal,k}\cdot W_{source,k}\cdot W_{quality,k}\cdot W_{independence,k}\cdot W_{time,k}}$$

This allows CIR to distinguish between current and historical identity evidence. The decay parameters should be estimated or approved for each signal and validated against time-sliced data. Decay must not silently erase historical provenance or override an explicit revocation.

22. Adaptive Source Trust

Source reliability should not necessarily remain static.

Let:

$$T_s(t)$$

represent the trust score of source (s) at time (t).

Historical validation can be used to update the score.

If a source repeatedly produces correctly labeled identity information:

$$T_s(t+1)>T_s(t)$$

If a source produces many incorrectly labeled matches:

$$T_s(t+1)<T_s(t)$$

This can support an adaptive identity-resolution system, but the update must not learn only from CIR’s own decisions or from unverified business outcomes. Those signals are subject to selection bias and can reinforce existing errors. Trust updates should use independently verified labels, minimum sample sizes, confidence intervals, approval controls, versioned policy changes, and a rollback path.

Historical Resolution Outcomes
             |
             v
       Source Accuracy
             |
             v
        Source Trust
             |
             v
      CIR Evidence Model
             |
             v
      Score or Match Probability
             |
             v
      Identity Graph

This creates a feedback loop between data quality and identity resolution.

\newpage

23. Identity Resolution Pipeline

The complete CIR process can be represented as:

                     RAW CUSTOMER DATA
                            |
             ----------------------------------
             v              v              v
       Ads Data Sources   Website          App
       Google Ads         Web Events       Mobile SDK
       TikTok             Login            User ID
       Facebook Ads       Forms            Device ID
             |              |              |
             ----------------------------------
                            v
                           CIR
              Customer Identity Resolution
                            |
                            v
                Identity Signal Extraction
                            |
                            v
                  Candidate Generation
                            |
                            v
                 Dynamic Signal Matching
                            |
                  ------------------------
                  v         v         v
                Email      Phone    Device ID
                  |         |         |
                  ------------------------
                            v
                  Source Trust Evaluation
                            |
                            v
                    Data Quality Check
                            |
                            v
                   Evidence Aggregation
                            |
                            v
                   Match Confidence
                            |
                ----------------------------
                v           v           v
             LINK         REVIEW      NO MATCH
                |
                v
          Existing Master
             Profile
 
              OR
 
          New Master Profile

\newpage

24. Architectural Interpretation

CIR can therefore be viewed as a decision layer between raw data ingestion and Customer 360.

DATA SOURCES
     |
     v
RAW DATA
     |
     v
IDENTITY RESOLUTION
     |
     +++ Identity Signals
    +++ Source Reliability
     +++ Data Quality
     +++ Temporal Evidence
    ++++ Score or Match Probability
     |
     v
IDENTITY GRAPH
     |
     v
MASTER PROFILES
     |
     v
CUSTOMER 360
     |
     +++ Segmentation
     +++ Personalization
     +++ Customer Journey
     +++ CLV
     +++ Predictive AI
     ++++ Marketing Activation

This architecture prevents downstream applications from having to independently solve customer identity.

25. Relationship to Customer 360

Customer 360 depends heavily on identity quality, but identity resolution is only one contributor to downstream quality.

If CIR incorrectly merges two people:

$$Perso{n}_A+Perso{n}_B\to WrongMasterProfile$$

then every downstream analytical and marketing process can become contaminated.

For example:

• purchase history becomes incorrect;
• CLV becomes incorrect;
• segmentation becomes incorrect;
• recommendation becomes incorrect;
• lead score becomes incorrect;
• personalization becomes incorrect.

Ingestion failures, stale attributes, incomplete consent, transformation bugs, measurement error, and downstream business logic can also degrade Customer 360. CIR is therefore not merely an infrastructure component.

It is a foundational data-quality layer for Customer 360.

26. Identity Resolution Metadata in Customer 360

The system should preserve the evidence and decision status of each identity relationship. A single aggregate confidence value for a Master Profile can hide conflicts between links and should not replace link-level detail.

For example:

Master Profile
------------------------------
master_id: M000128
 
Identity Resolution Summary:
link_status: active
conflict_status: none
last_evaluated_at: 2026-08-24
 
Linked Profiles:
4
 
Trusted Sources:
CRM
Mobile App
Website
 
Evidence:
email
phone
device_id
customer_id

Each linked profile should retain its own score or calibrated probability, evidence, validity period, and model/policy version. A summary may help downstream systems make risk-aware decisions, but it must define how it was derived and must not be interpreted as a probability unless calibrated.

For example:

High calibrated probability and permitted purpose
 personalized marketing
 
Medium calibrated probability
 less sensitive personalization
 
Low calibrated probability or unresolved conflict
 anonymous experience

Identity-resolution evidence can therefore become a useful feature for downstream decision systems, provided that its score, calibration status, validity, and permitted purpose are explicit.

\newpage

27. Identity Graph vs. Traditional Deduplication

Traditional deduplication asks:

Are these two records duplicates?

CIR asks:

What evidence suggests that these records represent the same real-world person?

Traditional deduplication often produces:

Record A
Record B
      
MERGE

CIR produces:

Record A
      |
      + evidence
      + confidence
      + provenance
      v
Master Profile
      ^^
      + evidence
      + confidence
      + provenance
      |
Record B

The latter is more suitable for continuously evolving CDP environments.

28. Methodological Principles

The proposed CIR methodology is based on seven principles.

Principle 1 - Identity is probabilistic

Identity resolution should recognize uncertainty rather than assume every match is deterministic.

Principle 2 - Evidence has different strengths

Email, phone, device ID, and anonymous IDs should not automatically receive equal weight.

Principle 3 - Sources have different trust levels

A verified internal CRM record should generally contribute more evidence than an anonymous external survey.

Principle 4 - Data quality matters

Even trusted sources can contain invalid, stale, incomplete, or inconsistent data.

Principle 5 - Evidence should be explainable

Every identity relationship should provide a reason and provenance.

Principle 6 - Identity should be temporal

Identity evidence changes over time and should therefore retain timestamps and, where appropriate, decay.

Principle 7 - Identity should be represented as a graph

The system should preserve relationships between raw profiles, identity signals, sources, and Master Profiles instead of simply destroying source records through irreversible merging.

29. Proposed CIR Data Model

Logical relationship

SOURCE REGISTRY
       |
       +-------------------+
       |                   |
       v                   v
 RAW PROFILE       IDENTITY EVIDENCE
       |                   ^
       |                   |
       v                   |
 IDENTITY LINK -----------+
       |
       v
 MASTER PROFILE

---

A conceptual CIR data model can contain:

cir_master_profile
------------------------
master_profile_id
identity_resolution_summary
created_at
updated_at
status
 
 
cir_raw_profile
------------------------
raw_profile_id
source_id
source_record_id
attributes
created_at
updated_at
 
 
cir_identity_link
------------------------
link_id
raw_profile_id
master_profile_id
match_score
calibrated_match_probability
resolution_outcome
match_reason
algorithm_version
created_at
updated_at
 
 
cir_identity_evidence
------------------------
evidence_id
link_id
signal_type
signal_value_hash
signal_weight
source_id
source_reliability
data_quality
time_weight
evidence_weight
observed_at
 
 
cir_source_registry
------------------------
source_id
source_name
source_type
trust_weight
quality_score
status
updated_at

This separates:

• raw data;
• Master Profiles;
• identity links;
• evidence;
• source governance.

30. Example End-to-End Resolution

Consider the following records.

Website

device_id = A123
email = customer@example.com

Mobile App

device_id = A123
phone = 0901234567

CRM

customer_id = C001
email = customer@example.com
phone = 0901234567

Facebook Ads

campaign_id = FB-C100
ad_id = FB-A200
click_id = CL123
email = customer@example.com

The Facebook record provides supporting identity evidence because the email is available. A normal Facebook Ad impression or click without an identity attribute would primarily be behavioral evidence.

Feedback Survey

phone = 0901234567

CIR observes:

                       CUSTOMER IDENTITY
                              |
              +---------------+---------------+
              |               |               |
             CRM           Website           App
              |               |               |
              |               |               |
          customer_id       email         device_id
              |               |               |
              |               +-------+-------+
              |                       |
              +-----------+-----------+
                          |
                        phone
                          |
              +-----------+-----------+
              |                       |
          Survey                  Facebook Ads
          phone                    email
              |                       |
              +-----------+-----------+
                          |
                          v
                        CIR
                          |
                          v
                   Evidence Model
                          |
              +-----------+-----------+
              |           |           |
            Signal      Source      Quality
            Weight      Trust        Score
              |           |           |
              +-----------+-----------+
                          |
                          v
                   Match Confidence
                          |
                          v
                 Existing Master Profile

The CRM evidence receives high trust.

The mobile application provides supporting identity evidence through the shared device ID and phone number.

The website provides supporting evidence through the email and device ID.

The Facebook Ads record provides weaker identity evidence when an email or other usable identifier is available; an ad click alone should not be treated as proof of human identity.

The survey provides weaker evidence because the phone number is self-reported.

The combined evidence can produce a high-confidence identity relationship while preserving the different trust levels of each source.

31. Security and Privacy Considerations

CIR operates on identity information and therefore requires appropriate privacy and security controls.

Identity values should generally not be stored or compared in plaintext where unnecessary. A plain deterministic hash is not anonymization: email addresses and phone numbers have limited, guessable domains and can be subject to dictionary attacks.

For example:

$$email\to \mathrm{normalize}(\mathrm{email})\to \mathrm{keyed}\mathrm{HMAC}\mathrm{or}\mathrm{token}$$

and:

$$phone\to \mathrm{normalize}(\mathrm{phone})\to \mathrm{keyed}\mathrm{HMAC}\mathrm{or}\mathrm{token}$$

Keyed comparison tokens require protected key management, rotation procedures, access controls, and careful handling when multiple organizations or tenants must interoperate. Encryption at rest or in transit does not by itself replace authorization, retention, deletion, and purpose controls.

The system should also implement, as required by applicable law and policy:

• access control;
• encryption;
• audit logging;
• data minimization;
• retention policies;
• consent management;
• purpose limitation;
• PII protection;
• tenant and purpose isolation;
• data-subject access and deletion procedures.

The identity graph should therefore preserve the minimum information required to establish and maintain identity relationships.

32. Operational Monitoring

A production CIR system should continuously monitor:

Identity quality

• match rate;
• false-positive rate and false-negative rate, measured against a documented labeled or adjudicated sample;
• unresolved profile rate;
• duplicate Master Profile rate.

Source quality

• source trust;
• source completeness;
• source freshness;
• source validation rate.

Resolution behavior

• score calibration and uncertainty;
• percentage of automatic links;
• percentage of review cases;
• percentage of new Master Profiles;
• identity-link changes over time.

False-positive and false-negative rates cannot be inferred from match counts alone. The evaluation set should include hard negatives, difficult positives, time-sliced examples, and relevant populations. Organizations should also monitor calibration, candidate coverage, cluster-size distribution, review outcomes, and drift in signal and source behavior.

\newpage

33. Feedback Loop

CIR can operate as a controlled learning system, but business outcomes are not automatically identity labels.

                 CIR DECISION
                      |
                      v
                Master Profile
                      |
                      v
              Business Outcomes
                      |
       ----------------------------------
       v              v              v
    Purchase       Login         Customer
    Confirmed      Confirmed      Service
       |              |              |
       ----------------------------------
                      v
               Identity Validation
                      |
                      v
                Update Trust
                      |
                      v
                    CIR

For example, if a supposedly matched identity later authenticates with a different verified customer account, that event may be evidence that the previous resolution was incorrect, subject to account-sharing, takeover, and other explanations. High-quality labels should come from verified account relationships, adjudicated reviews, confirmed disputes, or other independently validated events.

The controlled feedback process is:

$$\text{Identity Resolution}\to \text{Validation}\to \text{Learning}\to \mathrm{Improved}\mathrm{Resolution}$$

Training and policy updates should be evaluated on held-out data before deployment, with versioned rollouts and rollback controls. A system must not update source trust solely from its own prior links, since that can reinforce false matches.

34. Theoretical Model

The complete SAE-CIR evidence model can be summarized as:

$$\boxed{S(r_i,r_j)=\sum _{k\in K_{obs}}{M}_k\cdot W_{signal,k}\cdot W_{source,k}\cdot W_{quality,k}\cdot W_{independence,k}\cdot W_{time,k}}$$

where:

• $M_k$ = comparison result for identity signal $k$;
• $W_{signal,k}$ = intrinsic strength of the identity signal;
• $W_{source,k}$ = source- and context-specific reliability;
• $W_{quality,k}$ = quality of the observed data;
• $W_{independence,k}$ = adjustment for correlated evidence;
• $W_{time,k}$ = temporal relevance of the evidence.

For each observed identity signal:

$$\boxed{E_k=M_k\cdot W_{signal,k}\cdot W_{source,k}\cdot W_{quality,k}\cdot W_{independence,k}\cdot W_{time,k}}$$

The total evidence score is therefore the sum of the individual evidence contributions:

$$S(r_i,r_j)=\sum _k{E}_k$$

The score $S$ is an evidence score, not a probability. Its value depends on the selected weights and the available evidence.

Example

Suppose CIR evaluates whether a raw profile belongs to an existing Master Profile.

Source	Signal	$M_k$	$W_{signal}$	$W_{source}$	$W_{quality}$	$W_{independence}$	$W_{time}$	$E_k$
CRM	Phone	1.00	0.95	0.95	1.00	1.00	1.00	0.903
Web Survey	Phone	1.00	0.95	0.30	0.90	1.00	1.00	0.257
FB Lead Ad	Phone	1.00	0.95	0.40	0.85	1.00	1.00	0.323

Therefore:

$$S=0.903+0.257+0.323=\boxed{1.483}$$

This example shows that the same phone match can contribute different amounts of evidence because the observations come from sources with different trust and data-quality levels.

The score may be used directly for a validated rule-based resolution policy. When representative labeled same-person and different-person pairs are available, the evidence features can instead be calibrated into a match probability:

$$\mathrm{logit}(\hat{p})={\beta }_0+\sum _k{\beta }_k{x}_k$$

where:

$$\hat{p}=P(Y=1\mid x)$$

and $x_k$ may include the comparison results, signal type, source context, data quality, independence, recency, and candidate ambiguity.

Without representative labeled data, CIR should report the evidence score $S$ rather than presenting it as a probability.

The final resolution decision is then conceptually:

$$Decision(\hat{p})=\{\begin{array}{ll}LINK& \hat{p}\ge T_{auto}\\ REVIEW& T_{review}\le \hat{p}<T_{auto}\\ NOLINK& \hat{p}<T_{review}\end{array}$$

If no suitable existing Master Profile is found, the system may create a new provisional Master Profile according to its lifecycle policy.

\newpage

35. Practical CIR Architecture

A production implementation can therefore be organized into the following logical components:

\begin{figure}[h] \centering \begin{verbatim}

•          DATA SOURCES                     +
  

| |

• Ads + Website + App + CRM + POS + Surveys +

---

                  |
                  v

---

•         RAW PROFILE STORE                 +
  

---

                  |
                  v

---

•      IDENTITY SIGNAL EXTRACTION           +
  

| |

• Email + Phone + Device + Customer ID + … +

---

                  |
                  v

---

•         CIR ENGINE                        +
  

| |

• Candidate Generation +
• Dynamic Matching +
• Source Trust +
• Data Quality +
• Evidence Aggregation +
• Confidence Estimation +

---

                  |
                  v

---

•         IDENTITY GRAPH                    +
  

| |

• Raw Profiles + Master Profiles +
• Evidence + Confidence + Provenance +

---

                  |
                  v

---

•         CUSTOMER 360                      +
  

| |

• Profile + Journey + CLV + Segments + AI +

---

\end{verbatim} \end{figure}

\newpage

36. Conclusion

Customer Identity Resolution should be understood as an evidence-based identity inference system, rather than a simple record-matching or database-deduplication mechanism.

The proposed Source-Aware Evidence-Based CIR methodology evaluates identity evidence using three core dimensions:

$$\boxed{\text{Evidence}=\text{Signal Strength}\times \text{Source Reliability}\times \text{Data Quality}}$$

The model can be extended with independence and temporal factors when required:

$$\boxed{\text{Evidence}=\text{Signal}\times \text{Source}\times \text{Quality}\times \text{Independence}\times \text{Time}}$$

The resulting evidence contributions are aggregated to evaluate whether a raw profile should be linked to an existing Master Profile, sent for review, or kept unresolved.

This approach recognizes an important reality of customer data:

Not all customer information has equal evidential value.

A verified internal CRM record may provide strong evidence, while a self-reported value from a web survey or a marketing platform may provide weaker evidence. The evidence is therefore evaluated according to both the identity signal and the context in which it was observed.

The resulting Identity Graph preserves:

• identity evidence;
• source provenance;
• data quality;
• evidence scores or calibrated probabilities;
• temporal context;
• resolution outcomes.

CIR therefore becomes more than a matching mechanism. It provides an explainable and auditable identity layer for Customer 360.

The methodology can be summarized as:

$$\boxed{\text{Detect}\to \text{Evaluate}\to \text{Resolve}\to \text{Learn}}$$

Its practical objective is not to claim certainty where none exists, but to make every identity decision measurable, explainable, and revisable as new evidence becomes available.