When events arrive in Data Activation from your websites or applications, the system needs to decide whether to create a new customer profile or attach the event to an existing one. Deciding which profile to update with the event data is called identity resolution.

The goal is to keep all activity from the same person under a single profile, even if they use multiple devices or browsers.

Identifier types

Identity resolution in Data Activation is based on two identifiers from events:

cookie_id

• Identifies the device or browser where the event originated.
• It is collected automatically by the SDKs.
• Its value is influenced by privacy settings such as session hash or visitor cookies.

user_id

• Identifies the actual person performing the activity.
• Its value must be provided by you at sign-in, sign-up, or whenever a visitor's real identity becomes known.
• Should uniquely represent one individual (examples: internal account number, email address, phone number).
• Enables Data Activation to connect activity across devices and sessions to the same person.

You can learn more about user_id and how to set it up in this guide.

🚧

Warning

Data Activation does not validate or filter out identifier values.
Don't send empty values ("", 0, null, undefined), as this may incorrectly merge unrelated profiles.

How identity resolution works

When Data Activation receives an event, the system examines the identifiers in it and decides what to do:

• If none of the identifiers have been seen before, it creates a new profile and attaches the event to it.
• If at least one identifier is known, and it matches an existing profile, the event is added to that profile. Any new identifiers from the event are also saved in the profile, so future events can be matched correctly.
• If the event contains identifiers linked to separate profiles, Data Activation assumes they belong to the same person. It merges the profiles into one, keeps the oldest profile as the base, and combines all identifiers and event history. The new event is then attached to this unified profile.

In short, Data Activation merges profiles whenever they share at least one identifier.

Example: cross-device identity resolution

1. Alice visits your website on her smartphone for the very first time. Events from this session include cookie_id = A. Since Data Activation has never seen this identifier before, it creates a new profile with cookie_id = A and records Alice's first visit.

2. Alice creates an account while still using her smartphone. Events now contain both cookie_id = A and user_id = 0123. Because Data Activation already knows cookie_id = A, the new user_id = 0123 is added to the same profile. All post-signup activity is recorded under this enriched profile.

3. A few days later, Alice returns to your website, but this time from her laptop. Events from the laptop include cookie_id = B. Since Data Activation has not seen this identifier before, it creates a separate profile based only on her laptop activity.

4. Alice signs in on the laptop using her account. Events now include both cookie_id = B and user_id = 0123. Data Activation sees that cookie_id = B belongs to one profile and user_id = 0123 belongs to another. Because these identifiers represent the same person, Data Activation merges the two profiles into one unified profile. The merged profile now contains all identifiers: cookie_id = A and cookie_id = B, one user_id = 0123, and a combined visits history.

Profile merging

When profiles get merged, the resulting profile contains all identifiers from the merged profiles. Attribute values follow attribute aggregation rules:

• String attribute with aggregation "list" will contain all seen values, in chronological order.
• String attribute with aggregation "first" will contain the first value ever seen.
• Number attribute with aggregation "sum" will store the sum of all values from both profiles.

Common challenges and configuration tips

Identity resolution works well in most cases, but there are situations where profiles may not reflect reality. Below are the most common challenges and the configuration options you can use to handle them.

Device sharing

Sometimes, the same device is used by more than one person. For example, a family might share a home computer. In this case, events from different people can end up in the same profile because they all share the same cookie_id.

If the users sign in with separate accounts, we can detect it and block activations that would accidentally expose one person's browsing history to another. This option can be enabled in the activation settings.

If you want to split the activity from a shared device into different profiles, you can change the tracking setup in one of two ways:

1. Reset cookie_id on sign-out: Each time a user signs out, a new cookie_id is generated. This way, any activity that happens after the sign-out is attributed to a new profile. Be aware that if a person forgets to sign-out, their activity and the next person's activity will still be recorded in the same profile due to common cookie_id.
2. Reset cookie_id on sign-in: Each time a user signs in, a new cookie_id is generated. This attributes actions from before sign-in to the previously signed-in user. Keep in mind that the activity before the first sign-in on a device will be stored under a separate profile.

Account sharing

In some cases, multiple people share the same account. Because they all use the same user_id, their activity is grouped into a single profile. If you want to separate their activity, you need to adjust the user_id setup:

• Set user_id to a value that uniquely identifies each person on a shared account - for instance, a profile name.
• If having profiles per device (instead of per account) is enough for your use case, you can skip tracking user_id and rely only on just cookie_id.

Another situation to consider is when customer support staff act on behalf of customers while signed in to their accounts. The events they generate may merge customer profiles because of a shared cookie_id from the support agent's browser. To prevent this, use dedicated support accounts or exclude support traffic from tracking.

Intranet traffic

When session hash is enabled, the client's cookie_id may be replaced with a previously seen cookie_id if events share the same IP address and user agent. On internal networks (like offices or school campuses), many computers often use the same public IP and browser setup. This can cause events from different people to be merged into one profile. If that happens, you can fix it by disabling session hash.

Limits

Profiles that accumulate more than 1,000 identifiers are treated as corrupted and are automatically deleted. Any incoming events that would have updated a deleted profile instead create a new profile and attach their data there.