Interaction Studio Knowledge Base
Space shortcuts

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.

Interaction Studio comes preloaded with several identity types including email address and Customer ID. These default identities work out-of-the-box without further configuration other than the set-up of event capture mechanisms like the site map or ETL.

This Article Explains

This article details the process for configuring the identity system. For more information about leveraging the identity system in in the Web SDK and Open-Time Email, please reference the following documentation:

Sections in this Article

IDENTITY SETUP IS PERMANENT AND HAS SIGNIFICANT IMPLICATIONS FOR YOUR DEPLOYMENT

  1. The documentation should be read in its entirety before you start configuration. Once an identity type is configured, no alterations are allowed for that identity type.
  2. If you have already started collecting data on your dataset and are considering setting up the identity system, you should understand the following before proceeding:
    1. Once configured, the identity system will only collect data from that day forward. The identity system will only look at the configured and collected data in the identity system for lookup and merge.
    2. The data that was collected previously as a regular attribute will not be migrated to the identity system. For example, if you have been collecting Customer ID as an attribute and now want to collect Customer ID as an identity, the historically captured data will not be migrated to the new identity attribute.
    3. You should never leverage an attribute that is already collecting data as an identity attribute.
  3. You must be an Interaction Studio administrator (tenant administrator) to perform the steps outlined in this article.
    1. If you have been granted access to the account as a Salesforce employee, you will not be allowed to configure new identities in the account.  Only the tenant administrators of the account have this access.  
  4. All default identity types are configured to allow for identity lookup and identity merges. You need to think through the implications of using any combination of the identity types. For example, if you have both Customer ID and email address as identity types, both will be leveraged for lookup and merge. If you track/store multiple email addresses for a single Customer ID, Interaction Studio will maintain only the most recent email address on a user, not all email addresses. Events that have an email address that matches the one stored on a user will be merged to that user’s profile.
  5. Identity types should be considered carefully. Only identities that are required should be configured. For example, if you set First Name as an identifier, you would merge every visitor named Bob to a single user profile and will be unable to later separate them. Once a merge has been completed there is no way to split the profile. Consider the implications of identity management before making changes.

Process Overview

  1. Determining identity attributes. To start your configuration, you need to determine which attributes should be leveraged as identity attributes. The identity attributes you select will define a unique user record within Interaction Studio so these attributes should be chosen based on confidence, availability, and uniqueness. Interaction Studio has built in identities pre-configured to work out-of-the-box and you can add up to three additional identity attributes, specific to your organization and needs. Before finalizing your identity configuration, you should review the section below on lookup and merge implications. Once merges occur, they cannot be reversed or backed-out.
  2. Configure prior to data collection. The identity system should be set up prior to starting any data collection such as site mapping, event collection, or data feeds. Once you have defined and selected your complete list of identities, you can configure the identity system.
  3. Determine Identity Type Screen configuration. 
    1. Uniqueness: An identity attribute can be configured either for user look-up and merge or solely for searching for a unified customer profile within Interaction Studio. Interaction Studio supports look-up and merge on unique identifiers only. If an identifier is configured to be shared across different user profiles with a uniqueness type of not unique, then that identifier will not be leveraged for user look-up and merge. For example, since phone numbers can be shared between users and are not unique to one user, this identifier would not be supported for look-up and merge.
    2. Type: Only string attributes are supported in the identity system.  An identity attribute can only have a single value stored.  
  4. Associate the Identity types to an Attribute. Once an identity type has been created you must tie that identity to an attribute on the user attribute screen to successfully capture data against that identity.


Identity Type Configuration

  1. Access Interaction Studio
  2. Navigate to Settings > Identity Types from the left navigation pane

Review Existing Identity Types

There are several identity types already available in your account which are configured for look-ups and merges. If you do not see these attributes pre-configured, please reach out to support. During implementation, if you decide to leverage any of these system values, use the corresponding built-in identity type.

If you do not plan to use one of identity attributes, you may unlink the attribute Identity Type value on the attribute screen, however once the value is unlinked you will be unable to relink the attribute to the attribute type. Alternatively, you can also choose to not capture data against the attribute and the result will be the same.

  1. Email Address
    1. Uniqueness is set to Identity Namespace because each email address is unique to an individual across the entire identity namespace (which is the dataset). Any user profiles with that email address will belong to the same individual so the records can be merged.
    2. Case Sensitive is set to false because email addresses are not case sensitive.
  2. Salesforce Marketing Cloud Contact Key
    1. Uniqueness is set to Identity Namespace because each Salesforce Marketing Cloud Contact Key is unique to an individual across the entire identity namespace (which is the dataset). Any user profiles with that Contact Key will belong to the same individual so the records can be merged.
    2. Case Sensitive is set to false because Salesforce Marketing Cloud Contact Keys are not case sensitive.
  3. Customer Id
    1. Uniqueness is set to Identity Namespace because a customer address is unique to an individual across the entire identity namespace (which is the dataset). Any identities with that Customer Id will belong to the same individual so the records can be merged.
    2. Case Sensitive is set to false because Customer Ids are not case sensitive.
  4. Salesforce CRM Contact ID
    1. Uniqueness is set to Identity Namespace because each Salesforce CRM Contact ID is unique to an individual across the entire identity namespace (which is the dataset). Any user profiles with that ID will belong to the same individual so the records can be merged.
    2. Case Sensitive is set to true because Salesforce CRM Contact IDs are case sensitive.
  5. Salesforce CRM Lead ID
    1. Uniqueness is set to Identity Namespace because each Salesforce CRM Lead ID is unique to an individual across the entire identity namespace (which is the dataset). Any user profiles with that ID will belong to the same individual so the records can be merged.
    2. Case Sensitive is set to true because Salesforce CRM Lead IDs are case sensitive.
  6. Profile ID
    1. Profile ID is the Interaction Studio generated identity for a unique unified customer profile.  All unified customer profiles existing and new will have an assigned profile id.
    2. Uniqueness is set to Identity Namespace because each profile id is unique to an individual across the entire identity namespace (which is the dataset). 
    3. Case Sensitive is set to false because email addresses are not case sensitive.

Email Address, Salesforce Marketing Cloud Contact Key, and Customer Id already have corresponding attributes configured. If you plan to use the Salesforce CRM Lead ID and Salesforce CRM Contact ID, follow the steps below to set up the associated attribute.

Add a New Identity (Optional)

If the included identity types do not meet the needs of your business, you can add additional types.  Once a new identity type is added and saved you will be unable to edit the record.  Prior to saving you should validate your identity plan before proceeding.  If you have been granted access to the account as a Salesforce employee, you will not be allowed to configure new identities in the account.  Only the tenant administrators of the account have access to complete the following steps.

  1. Click Add new record
  2. Complete the fields
    1. ID - this is the unique identifier for the identity type. Alphanumeric characters only without spaces (i.e. SecondaryEmail)
    2. Label - this is the more descriptive or readable label that should correspond to the ID. For example, if the ID is “SecondaryEmail”, the label should be “Secondary Email Address.”
    3. Uniqueness
      1. Identity Namespace - ID value can belong to only one user profile in the dataset and can be used for identity lookup and merge. For example, email address - every identity with the unique email address is considered one individual and merged.
      2. Not Unique - ID value can belong to multiple user profiles and can’t be used for lookup or merge. For example, home phone number or mailing address - more than one profile could have this identity so it can only be used as a way to filter a group.  Non unique identities cannot be updated by etl.
    4. Case Sensitive - select True for a case-sensitive identifier; select False for a case-insensitive identifier. For example, a case-sensitive ID for Customer ID = ABC123 and Customer ID = abc123 will not be seen as a match for either lookup or merge. 
  3. Click the check mark icon to the right to save 


Attribute Configuration

Once you add a new identity type, you must configure the attribute(s) that correspond(s) to it. For more information on configuring attributes in Interaction Studio, please see Modify Attributes at the User or Account Level in this knowledge base.

Identity attributes can only be configured with the attribute type “string” which can only have a single value for each user. If you configure an attribute with a different type, you will not be able to save updates to that attribute.

Per Dataset Limit

The maximum number of user attributes per dataset is capped at 100.

  1. Open a new tab of Interaction Studio so you can refer to the Identity Type Configuration screen
  2. From the left navigation, select Settings > Attributes
  3. Click New Attribute
  4. At the far right, select the Identity Type that corresponds to the new attribute. Identity Type labels populate this drop-down which is why it is important to match Identity Type IDs and labels.
  5. Complete the following fields, starting from the left:
    1. Name - enter the unique name. Ideally, this should match the Identity Type ID
    2. Label - enter a more descriptive or readable label that corresponds to the ID
    3. Types - select String which is for text that has a single value (e.g. primary email address or loyalty card number)
    4. Classification Override
      1. Sensitive -the attribute will be displayed only to those with Editor with Export or higher permissions and cannot be used in a campaign. Those with lesser permissions will see ******* in place of a value on the Unified Customer Profile and segment list screens. Additionally, email address fields (specifically named "emailAddress") will not be searchable
      2. Personally Identifiable - the identity types pre-loaded into your account should all be considered personally identifiable and should be classified with this option. Additionally, the attribute can be viewed by anyone, but cannot be used in a campaign
      3. Non-Sensitive - the attribute can be viewed by anyone and used in campaigns
  6. At the far right, select the Identity Type that corresponds to the new attribute. Identity Type labels populate this drop-down so it is important to match Identity Type IDs and labels
  7. Click the check icon to the right to save
  8. You will receive a confirmation message that the attribute has been saved. Do not navigate away from this page until you see that message


Merge Logic

Interaction Studio supports merging user profiles based on shared identity attribute data. However if there isn't shared identity data across the profiles, Interaction Studio will not forcefully merges or split user profiles. For example, a request to rename or merge LoyaltyID 123 with LoyaltyID 567 would not be supported if there was nothing shared across the two profiles. Identity attributes should be carefully selected during implementation since there is no mechanism to split merged profiles. 

When the identity system receives events with populated identity attributes, Interaction Studio determines whether the event is for a new or existing user. An event will be assigned to an existing user when that event has at least one identity attribute with a uniqueness of Identity Namespace and that attribute matches a value for that specific identity attribute already assigned to an existing user.

When Interaction Studio merges two records, all historic events, transactions, and interactions for both records are stored on the merged record based on the following logic:

  • Any attribute that exists on only one user record is kept and applied to the merged user
  • When an attribute exists on more than one user record, the attribute kept is the one with the latest timestamp
  • If metadata does not exist or does not have a timestamp, the system updated timestamp is referenced instead

Under the following circumstances a merge will not occur even if there is at least one matching identity attribute in the record:

  • An anonymous user attempts to merge to a known user profile that has an active session currently
  • Anonymous user B attempts to merge into a known user X when anonymous user A already merged with the known user X in the last 30 mins

Let’s explore several examples of event scenarios that would or would not match with an existing contact based on the configuration of the identity attributes.

Platform Identity Setup - Example 1

In the following identity setup, a client has selected Email Address, Customer ID, Salesforce Marketing Cloud Contact Key, and Phone as identity attributes. Salesforce Marketing Cloud Contact Key, Email Address, and Customer ID are configured as unique (Type is Identity Namespace), meaning they are eligible for both lookup and merge. Phone is configured as non-unique, meaning that it is not eligible for lookup and merge.

The same phone number can exist on multiple customer profiles in Interaction Studio, therefore Phone is only used for searches. This setup is best leveraged when you have a 1 to 1 relationship between Email Address, Customer ID, and Salesforce Marketing Cloud Contact Key. Interaction Studio only stores the most recent email address if there are multiple email addresses that can be tied to a single Customer ID.


Example 1A

Interaction Studio receives an event with a configured identity attribute: Email Address. Since the value (john.doe@ac.com) populated for the email address matches an existing user, Interaction Studio assigns the event to that user.

Example 1B

Interaction Studio receives an event with two configured identity attributes: Salesforce Marketing Contact Key and Email Address. Both of these identity attributes are considered unique. The value populated for Salesforce Marketing Contact Key matches an existing customer record, but the Email Address in the event does not match the existing email address stored on the user.

The match is based on Salesforce Marketing Contact Key, so the event is assigned to the existing user. Since the email address value in the event represents a more recent email address value than the one previously stored against the profile, Interaction Studio updates the email address on the existing user profile to match the incoming one from the event: jane.doe@ac.com.

Example 1C

Interaction Studio receives an event with two configured identity attributes: Customer ID and Email Address. Both of these identity attributes are considered unique. The value populated for Email Address matches an existing customer record, but the value on the event for the Customer ID does not match the value currently stored on the existing profile.

The match is based on Email Address, so the event is assigned to the existing user. Since the value in the event represents a more recent value for the attribute, Interaction Studio updates the Customer ID on the existing user profile to match the incoming one from the event: 23423223223.

Example 1D

Interaction Studio receives an event with two configured identity attributes: Email Address and Phone. Email Address is a unique identity attribute, while Phone is not. The value populated for Email Address does not match any existing user in the system, but the value on the event for Phone does match a value stored on an existing profile.

Since Phone is a Not Unique identity attribute, no profile merging occurs in this scenario. Instead, Interaction Studio creates a new user profile using the data from the event.

An event can also result in Interaction Studio merging two existing users into a single user. A merge occurs when Interaction Studio receives an event with multiple identity attributes and it matches multiple existing users. Let’s explore several scenarios where two existing users would merge into a single user after Interaction Studio receives an event.

Example 1E

Interaction Studio receives an event with two configured identity attributes: Email Address and Customer ID. Both of these identity attributes have a Uniqueness of Identity Namespace, indicating that they are unique.

There are two existing users in the system that have identity attributes that match the ones in the event: one has a matching Email Address and the other has a matching Customer ID. Interaction Studio merges the two user records and assigns the event to the merged user. The merged user now has populated identity attributes for email address, phone, and Customer ID.

Example 1F

Interaction Studio receives an event with two configured identity attributes: Email Address and Customer ID. There are two existing users that have an identity attribute that matches those in the event: one with a matching email address and one with a matching Customer ID.

However, on the record where the Customer ID matches, the Email Address does not match the value on the event so Interaction Studio merges the two existing users and retains the email address with the latest timestamp, which in this case is the email address included in the inbound event.

An event can also result in two existing users merging into a single user. A merge occurs when Interaction Studio receives an event with multiple identity attributes and it matches multiple existing users.

Let’s explore several scenarios where two existing users would merge into a single user after Interaction Studio receives an event.

Platform Identity Setup - Example 2

In the following identity setup the client has chosen to use Customer Id and Salesforce Marketing Cloud Contact Key as identity attributes. Both identity attributes are configured to result in a lookup and merge since they have a uniqueness of Identity Namespace. This setup is best leveraged if you have an internal customer key that is available on the web and offline channels. If there is not a 1 to 1 relationship with salesforce marketing key and Customer Id Interaction Studio will retain the most recent Salesforce Marketing Cloud Contact Key.

Example 2A

Interaction Studio receives an event with a configured identity attribute: Customer ID. The value populated for the Customer ID matches an existing user, so this event is assigned to that user.

Example 2B

Interaction Studio receives an event with two configured identity attributes: Customer ID and Salesforce Marketing Contact Key. The value populated for Salesforce Marketing Contact Key does not match an existing user, but the Customer ID matches an existing user.

Interaction Studio assigns this event to the existing user based on the match of the Customer ID attribute. The Salesforce Marketing Contact Key attribute on the existing user profile is updated to match the incoming attribute from the event.

Example 2C

Interaction Studio receives an event with two configured identity attributes: Salesforce Marketing Contact Key and Customer ID. There are two existing users that have an identity attribute that matches those in the event: one with a matching Customer ID and the other with a matching Salesforce Marketing Contact Key. However, the attribute values for these two existing users do not match both attributes: Salesforce Marketing Contact Key and Customer ID.

Interaction Studio merges the two existing users and retains the Salesforce Marketing Contact Key and Customer ID values with the latest timestamp and assigns this event to the merged user.