Identity and the Omnichannel Customer Experience

Omnichannel programmes rarely fail on channels. They fail because the same person is a different record in each one, so the app does not know what the store knows, and the call centre knows neither. The fix is not another engagement tool. It is one resolvable customer identity, plus consent and preferences that travel with it, wired into every channel including the ones staffed by humans.

I founded LoginRadius and scaled it past a billion user identities. A large share of those deployments were retail, travel, and media companies trying to make web, app, store, and contact centre behave like one business. This is what separates the ones that worked.

What omnichannel actually means

Multichannel means you sell in several places. Omnichannel means the customer experiences one relationship regardless of where they touch it. The basket started on a phone is there on the laptop. The return bought online is accepted in store without an argument. The agent on the phone can see the order without asking for the reference number twice.

Every one of those moments is an identity operation. Something has to decide that the phone, the laptop, the loyalty card, and the caller are the same person, and decide it with enough confidence to justify the action being taken.

The identity resolution ladder

Not every recognition needs the same certainty. The mistake is treating all recognition as equal, which either blocks good customers or hands account access to the wrong person. Rank it:

Level	Signal	Confidence	Safe to use for
Authenticated	Active session, passkey, or re-authentication	High	Payments, address change, order history, data requests
Deterministic link	Verified email, phone, loyalty ID, card token	Medium to high	Order status, loyalty balance, service history
Probabilistic	Device, location, behavioural similarity	Low	Personalising content, nothing account-specific
Anonymous	Session only	None	Merchandising, basket persistence on one device

Write this ladder down and attach each customer-facing action to a level. It is the single most useful artefact in an omnichannel programme, because it settles arguments between marketing, fraud, and engineering with a rule instead of a meeting.

The four jobs identity has to do in every channel

Recognition. Is this the same person we have seen before, and at what confidence? Recognition should be cheap and frequent.

Authentication. Can they prove it, right now, at the strength this action requires? Authentication should be rare, strong, and phishing-resistant.

Consent. What have they agreed to, for which purpose, in which brand or region, and when? Consent must be queryable from every channel in real time, not synchronised nightly.

Preference. How do they want to be contacted, in what language, with what accessibility needs? Preference is not consent, and storing them in the same field is a recurring source of both annoyance and fines.

Cross-channel login in 2026

The authentication layer has changed enough that the old playbook is a liability.

• Passkeys are mainstream. The FIDO Alliance reported roughly five billion passkeys in use in 2026, with 75% of surveyed consumers having enabled one on at least one account. For a retail app, a passkey is both the fastest sign-in and the strongest one.
• SMS one-time codes are on borrowed time. NIST SP 800-63-4, finalised on 31 July 2025, treats out-of-band codes over the public telephone network as a restricted authenticator, and the fraud economics of SIM swap have not improved. Keep SMS as a fallback with a retirement plan, not as the default.
• Cross-domain sessions cannot be assumed. If your app, your store kiosk, and your brand sites live on different domains, plan for redirect-based federation rather than invisible cookie sharing. Passkeys are also bound to a relying party ID, so sharing one credential across domains requires an explicit Related Origin Requests allowlist, capped at five registrable domains in practice.
• Guest checkout stays. Offer identity after the purchase, where the value exchange is obvious. Registration walls remain one of the most expensive conversion mistakes in retail.

The contact centre is where omnichannel identity actually breaks

Digital channels get the investment, and then the whole programme is undone by a phone line where an agent verifies a customer using a postcode and a date of birth. Both are public data. Knowledge-based verification is not authentication, it is theatre, and attackers know which channel is the soft one.

The workable pattern is to push the caller back through an authenticated channel: send a push or a link to the app, verify the session there, and let the agent see a green state they did not have to judge. That is a channel joined by identity rather than a channel bypassing it.

Store staff need the same discipline in reverse. An associate looking up a customer to complete a return is accessing personal data, and that access should be scoped, logged, and tied to a named employee identity.

Consent that travels

A consent record is only useful if every channel can read it at the moment of action. Three rules make that possible:

1. Store consent per purpose, per brand, per region, with a timestamp and the exact wording the customer saw. If you cannot reproduce the screen, you cannot evidence the consent.
2. Never infer consent from identity. Recognising a shopper in store does not grant permission to email them. A merged profile does not merge permissions.
3. Make withdrawal as easy as granting, and propagate it in seconds. Regulators have been active here. In September 2025, France's CNIL issued cookie-related fines of 325 million euros to Google and 150 million euros to Shein. The EDPB's 2024 opinion set a high bar for what counts as freely given consent.

What to build first

1. One customer identifier that every system references, issued by the identity layer rather than by the ecommerce platform or the CRM.
2. The resolution ladder above, with actions mapped to confidence levels.
3. A consent service with an API, called at the point of action by every channel.
4. Passkeys in the app and on the web, with SMS demoted to fallback.
5. Contact centre verification through the app, replacing knowledge-based questions.
6. Audit logging keyed on the customer identifier, so a subject access request is a query rather than a project.

How to tell whether it is working

Four measures, all of which are collectable without new tooling. Sign-in completion rate per channel. The share of active customers recognised at authenticated level during a purchase. Time to resolve a data-subject request. And the share of contact-centre verifications completed without knowledge-based questions. Revenue metrics follow these, not the other way around.

The failure modes worth naming

• The CDP as identity system. A customer data platform resolves profiles for analytics. It is not an authentication authority, and using it as one puts marketing infrastructure in the security path.
• Email address as primary key. People change addresses, share them, and mistype them. Use an opaque internal identifier and treat email as a verified attribute.
• Nightly sync as the integration pattern. If consent and preference are stale by up to 24 hours, the promise is broken at exactly the moments customers notice.
• One consent record per person. Guarantees either over-collection or under-permission across brands and regions.

How I verified this

Standards and enforcement claims were checked in September 2026 against primary sources. Those were the NIST SP 800-63-4 publication pages, the FIDO Alliance's 2026 passkey report, the W3C WebAuthn Level 3 recommendation with its browser documentation, and the CNIL and EDPB announcements on consent. Architecture recommendations come from CIAM practice rather than a vendor benchmark.

Last verified: September 2026.

Frequently Asked Questions

Is omnichannel identity the same as a customer data platform?

No. A CDP joins records for analytics and activation. A CIAM platform issues credentials, authenticates people, enforces authorization, and holds consent. You usually need both, and the CDP should consume the identifier the identity layer issues.

Do we need one login across all our brands?

Only if customers move between them. Where they do, keep the credential shared and the consent brand-scoped. The architecture choices are covered in multi-brand ecommerce SSO.

How do we recognise a customer in store without asking them to log in?

Use a deterministic link they present voluntarily: a loyalty ID in the app, a scannable code, or a tokenised payment card. Do not use face recognition to identify shoppers without explicit consent; that is a legal and reputational risk far larger than the personalisation gain.

What is the fastest win for a team starting now?

Passkeys in the mobile app plus a real consent API. The first lifts sign-in completion immediately, the second unblocks every other channel.

How does this change with AI agents shopping on a customer's behalf?

The agent is a delegated identity, not the customer. It needs its own credential, a scoped permission set, an expiry, and a log that ties every action back to the person who delegated. Treat it as a new channel with the same four jobs: recognition, authentication, consent, preference.

Where does personalisation fit?

Personalisation is a consumer of identity, never a source of it. Personalise on what the customer has agreed to share, and let the confidence level decide how specific the personalisation is allowed to be.

Related reading

• What is CIAM: a complete guide
• CIAM security buyer's guide
• Solutions to stop account compromise
• Progressive profiling and consent management platforms