Identity resolution: a UK privacy review guide

What to take away

Identity resolution is the decision about which records describe one person, and every one of those decisions is processing of personal data.
Deterministic matching on verified keys is easier to defend than a score, because the evidence is a rule rather than a threshold.
The ICO's expectations on accuracy, minimisation and transparency apply to merges, unmerges and the notes you keep about both.
Name an owner for thresholds and disputes before rollout. The controller remains accountable; involve the data protection officer (DPO) where one is appointed. A platform will merge whatever you configure, mistakes included.
Treat the match threshold as a policy decision with a review date, not a setting buried in a platform menu.

How the law frames identity matching

Linking two records that describe the same person is processing of personal data under the UK GDPR and the Data Protection Act 2018. Both apply from the moment a merge rule runs, not from the moment the resulting profile is used. Privacy teams should record the purpose, lawful basis and relevant safeguards for the merge in their records of processing activities.

Accuracy is the principle that bites hardest. UK GDPR Article 5(1)(d) requires personal data to be accurate, and Article 16 gives people the right to have inaccurate data rectified. A false merge creates a record that is wrong about someone and stays wrong until a person notices. The ICO's UK GDPR guidance and resources set out how accuracy, storage limitation and individual rights interact once records are joined.

Map the customer data journey while the match rules are still on paper. Assess whether a Data Protection Impact Assessment (DPIA) is required: under UK GDPR Article 35, it is required where processing is likely to result in a high risk to people's rights and freedoms. A merge you cannot explain after go-live is expensive to unwind.

Marketing use is a separate question. Joining records so you can send one addressed message brings the Privacy and Electronic Communications (EC Directive) Regulations 2003 (PECR) into consideration alongside the UK GDPR. Check the requirements that apply to the message and channel; a UK GDPR lawful basis does not by itself satisfy PECR. The ICO's Direct marketing guidance and Direct marketing code of practice cover this separately from the general processing principles.

Deterministic and probabilistic matching compared

Most platforms support both methods. In your chosen CDP, check how its match rules and profile-unification settings apply identifiers, combine profiles and allow a later unmerge; labels and behaviour vary by product. The useful question is what each method can evidence when someone challenges a merge.

Deterministic vs probabilistic matching

Deterministic matching

Key: Verified identifier
Output: Rule fires or not
Main risk: Shared or recycled key
Evidence: Rule version, inputs
Reversal: Unwind rule, re-run

Probabilistic matching

Key: Weighted signals
Output: Score to interpret
Main risk: Drift in weights
Evidence: Model, features, threshold
Reversal: Unwind score, re-check

Deterministic matching

Key: A verified identifier such as an account number or a hashed email
Output: A rule that fires or does not
Main risk: False merges when a key is shared or recycled
Evidence: Rule version and the input values
Reversal: Unwind the rule and re-run

Probabilistic matching

Key: Weighted signals such as device, address and timing
Output: A score that must be interpreted
Main risk: Drift as weights and cut-offs change
Evidence: Model version, features and threshold
Reversal: Unwind a score range and re-check neighbours

Probabilistic matching earns its place when verified keys are thin, such as a guest checkout on a shared household device. For a straightforward deterministic rule, for example, merge only when both records contain the same verified account number; do not use a shared address or device as a standalone match key. A score is a judgement, so it needs a documented cut-off, a named approver and a review date. Cut-offs drift as data changes, so a threshold set at launch is evidence about launch, not about this quarter.

A sequence that survives a privacy review

List every identifier you hold and mark each one as verified, inferred or bought from a third party.
Write the match rules down before configuration, naming the fields permitted to trigger a match and any field that can never be used on its own.
Set and document a score cut-off for probabilistic matches, and name the person allowed to change it.
Log the reason for every merge, including the rule version, timestamp and fields that triggered it.
Test the unmerge and correction paths before go-live, including how a customer disputes a link.
Review merge rates each month and investigate a step change rather than adjusting the cut-off.

Steps three and five carry most of the defensive weight, because they leave the evidence a challenge needs.

Six steps that survive review

List identifiersverified, inferred, bought
Write match rules before configuration
Set score cut-off and name approver
Log reason, rule version, timestamp, fields
Test unmerge and correction paths
Review merge rates monthly

What to log when a merge happens

Merge logic inherits whatever quality problems already exist, so cleaning records before implementation costs less than debugging a split profile later.

The rule or score range that fired, with its version.
The timestamp and identifier fields that triggered the match, including which identifiers were verified.
The person who approved the threshold, and the date.

Keep those three together with the profile, so an unmerge is a lookup rather than an investigation.

Common questions

Does identity resolution always need consent?

No. Consent is one lawful basis among several. Identify an appropriate UK GDPR Article 6 basis for each purpose before the first merge; do not assume that a customer relationship automatically makes contract necessary or legitimate interests appropriate. If you rely on legitimate interests, document your assessment and balancing of the interests involved. If the matched profile includes special-category personal data, identify an applicable Article 9 condition as well.

What match rate should we aim for?

Pick a rate you can explain rather than one quoted in a vendor deck. Track false merges as closely as missed matches, because the wrong link is harder to spot and harder to reverse.

Can we resolve identity without a verified email address?

Yes, using device, address or account signals. The evidence is weaker, so the cut-off decision and the record behind it matter more.

Does a merge give us permission to market?

No. Joining records tells you who someone is, not whether you may contact them. Check the UK GDPR basis and the relevant PECR requirements for the message and channel separately.