Identity resolution

Identity resolution is the process of linking multiple identifiers (email, user ID, device token, advertising IDs) to a single customer profile. ZMP performs this automatically so your campaigns reach the right person, not just the right device.

On this page

• Why identity resolution matters
• How it works
• Key identifiers
• Profile merging
• Session management basics
• Common scenarios

Why identity resolution matters

A single customer may interact with your brand through multiple touchpoints: your mobile app, your website, email campaigns, and in-store visits. Without identity resolution, each touchpoint creates a separate profile, leading to:

• Duplicate profiles that inflate your audience counts.
• Fragmented views of customer behavior.
• Campaigns that target the same person multiple times or miss them entirely.

ZMP's identity resolution connects these touchpoints into one profile, giving you an accurate count of your audience and a complete view of each customer's behavior across channels.

How it works

1. Anonymous profile creation. When a user first opens your app, the SDK creates an anonymous profile in ZMP. At this point, ZMP knows a device exists but does not know who the user is.

2. Identifier attachment. As your app collects identifying information (the user logs in, enters an email address, or your backend provides a user ID), the SDK sends these identifiers to ZMP. ZMP attaches them to the profile.

3. Profile matching. ZMP checks whether any existing profile shares the same identifier. For example, if the mobile user logs in with [email protected] and ZMP already has a profile with that email from your email campaigns, ZMP links the two.

4. Profile merging. When two profiles are confirmed to represent the same person, ZMP merges them. The resulting profile contains the combined event history, properties, and contact channels from both sources.

5. BSIN assignment. Every profile in ZMP has a BSIN (Zeta's unique user identifier). After merging, the combined profile retains one BSIN. All future activity from any of the merged identifiers maps to this BSIN.

Key identifiers

ZMP uses several identifiers from the SDK for identity resolution:

Note: You do not create or manage BSINs. ZMP assigns them automatically. Your role is to ensure your app provides consistent identifiers (uid, emailId, or UCLID) so ZMP can match profiles correctly.

Profile merging

Profile merging happens automatically when ZMP detects that two profiles share the same identifier. Here is how different identifiers trigger merges:

• uid match: if two profiles have the same uid, they are merged.
• emailId match: if two profiles have the same emailId, they are merged.
• UCLID match: if two profiles share the same unique client ID name-value pair, they are merged.

Merge behavior

• The merged profile retains the event history, user properties, and contact channels from both source profiles.
• If the two profiles have conflicting values for the same property (for example, different first names), ZMP uses the most recently updated value.
• Device tokens from both profiles are preserved, so push notifications can reach all of the user's devices.

Note: Profile merging is a one-way operation. Once two profiles are merged, they cannot be separated. Ensure your identifiers are accurate before sending them to the SDK.

UCLID considerations

UCLID (unique client ID) is a custom identifier that your app sends to ZMP through the SDK. It is useful when your system has its own unique identifier (loyalty program ID, CRM record ID) that may not match email or user ID.

Important rules for UCLID:

• No two profiles may have the same UCLID name-value pair. If a match is detected, the profiles are merged.
• A UCLID pair is discarded if the same key already exists on the profile with a different value.
• Contact your account team to enable UCLID support.

Session management basics

The SDK manages identity sessions to track which user is active on the device:

• Starting a session. Setting uid or emailId in the SDK starts an identity session. All subsequent events are attributed to that user's profile.
• Clearing a session. When the user signs out or switches accounts, your app should instruct the SDK to clear the session. This prevents events from being attributed to the wrong profile.
• Anonymous sessions. If no identity is set, the SDK operates in an anonymous mode. Events are still sent to ZMP but are attributed to an anonymous device-level profile. When an identity is later provided, ZMP links the anonymous activity to the identified profile.

Note: Session management is handled by your development team during SDK integration. From a business perspective, the important thing is that your app calls the SDK's clear method on logout and sets identity on login. This ensures clean attribution.

Common scenarios

New user installs the app

1. User installs and opens the app. The SDK creates an anonymous profile.
2. User signs up and provides an email. The SDK sends emailId to ZMP.
3. ZMP creates a new identified profile (or matches an existing one if the email is already known).

Existing customer installs the app

1. User installs the app. The SDK creates an anonymous profile.
2. User logs in with their existing account. The SDK sends uid and emailId.
3. ZMP matches the identifiers to the existing profile from email or web interactions.
4. Mobile activity is now linked to the customer's full profile.

User logs in on a second device

1. User already has the app on Device A with a linked profile.
2. User installs the app on Device B and logs in with the same credentials.
3. ZMP receives the same uid from Device B and links it to the existing profile.
4. The profile now has device tokens for both Device A and Device B. Push notifications can reach either device.

User logs out and a different user logs in

1. User A is logged in. Events are attributed to User A's profile.
2. User A logs out. Your app clears the SDK session.
3. User B logs in on the same device. Your app sets User B's uid.
4. Events are now attributed to User B's profile. No cross-contamination occurs.

See also

• User properties: what identifiers and properties the SDK collects.
• User guides: how the mobile SDKs connect to ZMP.
• Glossary: definitions of BSIN, UCLID, and other identity terms.