Cross-Device Visitors

What is a CDV (Cross-Device Visitor)

CDV is a logically unified user whose actions were recorded from different devices (desktop, smartphone, tablet, etc.) but recognized as belonging to the same person.

You can find more details about the problem of cross-device users and its solution here.

Creating a customer card

Description

A partner can receive data about their clients from various sources:

• website
• mobile application
• call-center
• offline stores
• other external systems

Each source can identify the same client differently, which leads to fragmented profiles. Without a stable identifier, it is impossible to combine a client's actions across different channels. Example:

• A client registered on the site, left an email — a profile with a customerId and email appeared.
• Later, the client, without logging in, entered the mobile application, continuing to browse the online store's catalog — a new separate profile appeared, not linked to the unique customerId identifier.
• Then they called the call center and placed an order. If the call center is not connected to the master system, a separate profile is created, again without a customerId.
• The same client made a purchase at a retail store using a loyalty card. Similarly, another profile appears.

Thus, the same person can exist in the system as four different customers.

To combine events into a single profile, the customer card creation method is used — by passing the customerId and link pointers associated with it.

This method should be used when the unique user identifier is known — during authorization and registration.

Terminology

customerId

• A unique and stable client identifier.
• Issued by the master system (website, CRM, etc.) — most often upon registration.
• Stable: always points to only one client.
• Used to link communication channels (email, push, sms), behavioral data, personal attributes (full name, date of birth), and order history.

Usage tips

• Use a surrogate key (e.g., UUID), not personal data (phone, email, card number).
• Avoid reusing customerId.
• Ensure its uniqueness to prevent merging different clients.

Not recommended

• Passing mutable data (email, phone, loyalty card) as customerId.
• Caching requests to pass customerId. A failure can lead to a mass merging of clients under one ID.

link

• link — a string pointer to a user (e.g., phone, loyalty card, ID in an external system, installId in an application, etc.).
• One customerId can have multiple link pointers.
• Used for matching and subsequent merging of user events.
• A link can be reused by another person (e.g., when the owner of a number or card changes).

If customerId is not passed, the data for each link forms a separate profile. Only with a customerId can they be linked into a single customer card.

Note

When integrating the platform via JS SDK, the link parameter is not used explicitly; instead, a cookie issued to the user automatically is used for its value. However, it is possible to pass additional user pointers using the softLinks parameter of the method for creating a customer card.

Examples of behavior in different scenarios

Scenario	Result
Only link is passed	A temporary profile is created
customerId + link are passed	The client's profile is created or updated, the link is associated with the customerId
Multiple links are used, previously used with different customerIds	A merge occurs, all links now point to the last customerId passed with them
The same customerId is passed for different clients	All data is merged, a critical situation 🛑