Page tree
Skip to end of metadata
Go to start of metadata

Using the Interaction Studio Identity System, you can configure the identifiers that determine a unique known individual within Interaction Studio. You can configure Interaction Studio to support multiple identifiers for lookup and user merge. The provided identifiers determine how events are applied to visitor profiles whether originating from a web event, a feed import, or another channel.

After you Configure Identity Types and Attributes, if you plan to leverage the identity system to look-up and merge user profiles when processing web events, you will need to select the default identity attribute that will be leveraged by the web SDK. 

This Article Explains

This article details the process for configuring the identity system for the web SDK and includes examples of how the identity system merge logic works to resolve identities in common scenarios.

Sections in this Article

Before You Begin

  • You must be an Interaction Studio administrator (tenant administrator) to perform the steps outlined in this article.
  • Complete the process detailed in Configure Identity Types and Attributes first.
  • Once you select a default identity attribute for the Web SDK, you should not alter it.

Configure the Identity System for the Web SDK

If you plan to leverage the identity system to look-up and merge user profiles when processing web events, you will need to select the default identity attribute that will be leveraged in the web SDK. For instance, if you have both an email address and a loyalty ID available on the web, you can select the loyalty ID as the default web identity attribute.

  1. Access Interaction Studio
  2. Navigate to Settings > General Setup
  3. Click Advanced
  4. Scroll to the Select the Identity attribute to use as the WebSDK Identity drop down
  5. Select the default identity attribute from the drop down menu 
  6. Click SAVE

Send Identities in the Sitemap

The default identity attribute you select as the web SDK Identity must be supplied as the user.id in web events. In addition to the default identity, Interaction Studio supports lookup and merge using the web SDK for any other identity attributes supplied under user.attributes in web events. The set of all supplied identity attributes accumulates in the web browser. If there are changes to the default identity sent as user.id, Interaction Studio clears the set of all identity attributes stored on the client. This can happen when a different individual starts using the browser on the same device and logs in to a different account.

Merge Logic: Anonymous Visitors, First-Party Cookies, and the Interaction Studio Identity System

The Interaction Studio Web SDK supports both anonymous and named profiles and leverages a first-party cookie to track behavior on your website. A profile can transition from being anonymous to named based on the setup of your identity attributes. Let's look at a few examples of how this process works.

Example 1: Anonymous Profile

The web SDK generates an anonymous ID for all events. However, Interaction Studio will only consider the event anonymous and use the anonymous ID as the user’s identity if there are no identity attributes present in the event. For an anonymous event, Interaction Studio will use the anonymous ID to to determine if the event matches the anonymous ID of an existing Interaction Studio profile or if the event was generated by a new user. Let’s look at a few examples of lookup and merge for anonymous users on the web.

Example 1A

A customer is tracking Email Address as an identity attribute. Interaction Studio receives the page view event without an email address so the visitor is determined to be an anonymous user. The anonymous ID matches an existing profile in Interaction Studio, so the event is assigned to that existing anonymous profile.

Example 1B

A customer is tracking Email Address as an identity attribute. Interaction Studio receives the page view event without an email address so the visitor is determined to be an anonymous user. The anonymous ID does not match an existing profile in Interaction Studio, so a new anonymous profile is created and that event is assigned to that new profile.

Example 2: Named Profile

If one or more identity attributes are present in a web event, that event is considered a named event. Interaction Studio leverages the identity attributes that are present in the event to either assign that event to an existing profile or create a new profile. That means that an anonymous profile can become a named profile through this lookup and merge process. Let’s look at a few examples of lookup and merge for named users on the web.

Example 2A

Interaction Studio receives an event with an email address and the Email identity attribute is configured with a Uniqueness of Identity Namespace, meaning it is a unique identity attribute. The email address does not match an existing profile within Interaction Studio, but the anonymous ID of the event matches the ID of an anonymous profile in Interaction Studio. The event is assigned to that matched anonymous profile which is updated to be a named profile with email address stored as the identity attribute.

Example 2B

Interaction Studio receives an event with an email address and the Email identity attribute is configured with a Uniqueness of Identity Namespace, meaning it is a unique identity attribute. The value populated for the email address, john.doe@ac.com, matches an existing named user, so this event is assigned to that named user.

Example 2C

Interaction Studio receives an event from the web with two configured identity attributes: Email and Customer ID. There are two existing users that have an identity attribute that matches those in the event: one with a matching Email and the other with a matching Customer ID. However, on the record with the matching customer ID, the email address does not match the value on the event. Interaction Studio merges the two existing users and retains the email address with the latest timestamp, which in this case is the email address from the inbound event.

Example 3: Merging Behavior Across Devices

Interaction Studio can resolve users that are using different devices.  Consider a user that visits your website both from a desktop computer and from a mobile device. This user will have 2 different anonymous IDs and will be tracked with two separate profiles.  Interaction Studio merges these profiles when a named event such as a login or a purchase occurs on each device. If those profile are updated to named and have a matching identity, they will be merged and their behavioral histories combined.

Example 3A

A customer is tracking Email Address as an identity attribute. A user visits to their website from a desktop computer and is assigned an anonymous ID. Later, the same user visits the website from a mobile device and is assigned a different anonymous ID. The user then completes a login action from both the desktop computer and mobile device and an email address is captured and sent with the event. Interaction Studio uses the matching Email identity attribute to merge both anonymous profiles into a single named profile with the combined behavioral history from both profiles.