What Identity Resolution Actually Does

Identity resolution is the layer between the publisher's data sources and the publisher's measurement and personalisation tools. It takes the inputs — first-party cookies, server-side session IDs, hashed email addresses from logged-in sessions, mobile advertising IDs from the publisher's app, smart-TV device identifiers, and a constellation of probabilistic signals like IP address, user agent, and behavioural fingerprint — and produces an output: a stable internal identifier that represents a single consumer across all the surfaces the publisher operates.

Deterministic Stitching

The cleanest path is deterministic stitching: when the consumer logs in on two surfaces, the publisher knows the two devices belong to the same person and merges their identifier graph accordingly. Newsletter subscribers, registered readers, and paying subscribers produce deterministic stitching naturally. The data is high-confidence, the legal basis is clear (the publisher has a direct relationship), and the consent decisions made at one surface can propagate to the other with no probabilistic guess.

Probabilistic Stitching

The harder path is probabilistic stitching: inferring that two devices belong to the same person without an authenticated link. The signals are IP-address co-occurrence, behavioural similarity, time-of-day patterns, geographic clustering, and proprietary models that combine all of the above. Probabilistic stitching gives publishers far more reach — most readers are logged out for most visits — but the legal basis is much weaker, and EU regulators have been increasingly active in pushing back against probabilistic identity layers that operate without explicit consent.

Vendor-Provided Identity Graphs

The third path is buying or licensing an identity graph from a vendor — LiveRamp, ID5, The Trade Desk's Unified ID 2.0, or one of the many smaller providers. The vendor maintains the graph, the publisher provides hashed identifiers, and the vendor returns a stitched identifier the publisher can use downstream. The legal posture here is mixed: it depends entirely on the vendor's own data origins and the contractual terms, and the EU's enforcement actions through 2025 against several large identity vendors have made publishers more cautious about which graphs they integrate.

The Consent Question Cross-Device Resolution Raises

The hard question identity resolution raises is whether the act of stitching itself requires consent, separate from the downstream advertising or personalisation that the stitched identifier feeds.

The Stitching Itself

Under GDPR, identity resolution is processing of personal data. The legal basis required depends on the purpose: for fraud prevention or basic service operation, legitimate interests can sometimes apply; for advertising, personalisation, or audience extension, consent is required. ePrivacy adds a separate layer for any cookie or device identifier read on the user's device, and the cookie or identifier read needs consent regardless of what the publisher then does with the result.

The Propagation of Consent

The more interesting question is how the consent decision made on one device propagates to the other. If a reader rejects advertising cookies on the laptop and the laptop's identifier is stitched to the phone's identifier through deterministic email matching, must the phone honour the laptop's rejection on the next visit? The European Data Protection Board's published guidance is clear that the answer is yes — consent decisions attach to the data subject, not to the device, and a stitched identity graph that lets the publisher recognise the data subject is also a graph that requires the publisher to honour their decisions.

The Withdrawal Path

Withdrawal needs to propagate too. A reader who logs into the publisher's account settings on the laptop and clicks 'reject all advertising' must see the same state reflected when they open the phone app, even if the phone app session is anonymous and uses a different cookie. The CMP and the identity layer must share state, and the propagation has to be near-real-time — a withdrawal honoured a week later is not honoured.

The Architectural Pattern

The cross-device-aware CMP and identity stack has a small number of repeatable elements that have stabilised across mature publishers by 2026.

The Single Source of Truth

The consent state lives in a publisher-owned consent service, not inside the CMP vendor's database. The service is keyed on the resolved identifier, not on the cookie that triggered the most recent consent decision, and every consent-aware downstream service reads from this single source. The CMP populates the service on every consent change, and the service provides a real-time API the ad-stack and personalisation layer can call on every page load and every event.

The Identity-Layer Consent Index

The identity resolution layer maintains a bidirectional index: every device identifier maps to a resolved identity, and every resolved identity maps back to the set of device identifiers it has touched. When a consent change happens on any one device, the index lets the publisher fan the change out to every other device the same identity has used, with the appropriate cooldown and propagation logging.

Per-Surface Consent UI

The consent UI surfaces on each device should reflect the cross-device state. A reader who consented on the laptop should not see a fresh banner on the phone if the identity stitching has succeeded. A reader who has never been seen before should see the banner with default-deny settings. The CMP must be able to read the identity layer's state and render the UI accordingly, which is a real engineering integration but a one-time investment.

The Special Cases

Several surfaces and contexts produce edge cases that the architecture has to handle explicitly.

Connected TV and Over-the-Top Apps

The smart TV and OTT app context is unusual because the device is often shared across a household — multiple people use the same TV, but only one of them has the publisher's app account on their phone. The deterministic stitch from phone to TV is unreliable, and probabilistic stitching on a household-shared device produces consent confusion. The compliant pattern is to treat the TV app as an unauthenticated surface by default, fire its own consent banner on first launch, and only stitch to a known account when the user takes an explicit linking action.

Incognito and Private Browsing

An incognito session by definition rejects identity resolution. The CMP should treat the session as a brand-new visitor every time, render the banner with default-deny, and not attempt to stitch the session to any known identifier even if the IP address and behavioural pattern would otherwise produce a probabilistic match. The user has signalled they want isolation, and the publisher honours that signal.

Children's Surfaces

Any surface where the audience could include minors — kids' content sections, family-oriented apps, accounts with under-eighteen self-declared age — should default to no identity resolution at all and consent defaults set to deny for advertising and personalisation. The DSA's minor-targeting ban and COPPA's restrictions in the US are absolute and override any cross-device propagation from a household member's adult account.

Common Cross-Device Mistakes That Trigger Findings

The cross-device deployments that produce regulator findings tend to fail in patterns the EU's enforcement decisions have made specific. The probabilistic identity graph operates without an explicit consent gate, on the theory that probabilistic matching is below the GDPR threshold — a position that has not survived recent rulings. The withdrawal path on one device takes a week to propagate to the other through a batch process, leaving a window where the user's wishes are not honoured. The vendor identity graph integration goes live without a Data Protection Impact Assessment and without contractual clauses extending the publisher's lawful basis to the vendor's processing. The connected-TV app stitches deterministically to the household's primary phone account without any explicit user action, importing one user's consent decision onto a different user. The CMP renders a banner that does not reflect the cross-device state, frustrating returning readers who already consented on a different surface and producing the consent-fatigue findings that the EDPB has been pursuing through 2025.

The Bottom Line

Cross-device consent is not a technology problem and not a legal problem — it is the place where the two converge. The identity resolution layer that publishers built to make audience extension and frequency capping work also creates the obligation to make consent and withdrawal coherent across surfaces. The architecture is settled by 2026: a publisher-owned consent service keyed on resolved identity, a bidirectional index in the identity layer, near-real-time propagation, per-surface consent UI that reflects the cross-device state, and explicit handling for the household-shared, incognito, and minor edge cases. None of this is dramatic engineering. All of it is operationally specific. The publishers who built it during the third-party-cookie deprecation cycle are now operating cleanly across phones, laptops, and TVs; the publishers who treated cross-device as a measurement upgrade without the consent layer are spending 2026 explaining to the EDPB why a reader's withdrawal on the laptop did not reach the smart TV until the following Tuesday.