Customer Identifiers and Profile Unification

Blueshift builds a single, comprehensive, 360-degree profile for each customer by tracking behavioral, event, and attribute data for anonymous and signed-in identifiable customers across channels. Devices, and sessions and merging/stitching profiles using explicit, deterministic methods using a hierarchy of customer identifiers.

Blueshift unifies all the data into individual profiles for each individual and anonymous customer. These profiles are flexible and customized to your unique data sets. As you continuously learn more about your customers and send new data to Blueshift, the customer profile becomes more granular and robust.

Customer Identifiers

Blueshift uses several standard identifiers to identify customers and generate comprehensive customer profiles. You can also use custom identifiers based on your business requirements. Blueshift supports a maximum of 14 identifiers, in a custom hierarchy.

Standard identifiers

The following standard customer identifiers are used in Blueshift:

• uuid: Blueshift internal UUID for each customer
• customer_id: Unique customer ID from your system
• email: Email address
• device_id: One or more device ids associated with the customer
• cookies: One or more cookies associated with the customer

You can also add phone_number as a standard identifier to address SMS marketing use cases. You can define the required hierarchy for this identifier with respect to the other standard identifiers. Contact your CSM to use phone_number as a standard identifier.

Custom identifiers

You can add custom identifiers based on your requirements and define the hierarchy in which they should be used in Blueshift. You can add a maximum of 10 custom identifiers.

Examples

• IDs from your internal systems so that it is easier to match data. For example, Customer IDs, Account IDs etc.
• Multiple email addresses. For example, Customer email, Billing email, Ship to email.
• WhatsApp phone number, Instagram profile, and other unique social media identifiers.

Identifier types

The customer identifiers can be of the following types: scalar and vector identifiers.

Scalar identifiers, such as customer_id, passport_id, and email, can only have one value. ID resolution relies on a predefined ranking on the priority of all the scalar identifiers. Customers with scalar identifiers are considered as known or identified customers.

Vector identifiers, such as cookies, device_ids, can have multiple values. Vector identifiers have the same ranking and are always ranked after all the scalar identifiers. Customers with only vector identifiers are considered anonymous customers.

Note: Blueshift currently limits up to 20 values for the same type of vector identifier. Oldest values for an identifier will be purged to make room for the new values. For example, there can be a maximum of 20 cookies for a customer, anonymous or identified.

Profile Unification

Blueshift connects, unifies, and resolves identity, attribute, and event data from multiple touch points, devices, and channels into a single customer view. A 360-degree customer profile is built by tracking both anonymous and logged-in behavior across devices and sessions and merges them using explicit first-party data.

1. A first-party cookie is used on your website to track anonymous website behavior. The device_id collected from the mobile SDK tracks anonymous mobile app behavior.
2. After the customer signs in (authentication is completed), you must send an identify event that contains any previously registered identifiers to Blueshift to initiate the merging of profiles. 
3. For identified customers, customer attribute and event data are resolved and merged into the customer profile based on the customer identifying themselves using one of the known customer identifiers.

Merging Profiles

Blueshift uses the following hierarchy of user identifiers to merge profiles:

• customer_id
• email
• device_id
• cookies

Note: Standard identifiers are considered for merging profiles before any custom identifiers are considered.

The following rules are used to merge profile data into the final user profile:

• If you use standard customer identifiers, customer profiles are merged when either a customer ID or email (or both) are available, with the customer ID getting a higher priority. Cookies and device_ids are also used for merging.
• If you are using custom identifiers, customer profiles are merged based on the identifiers available and their defined hierarchy.
• All user profiles referenced by the identifiers in this identify event will be merged to the oldest user profile.
• All the user attribute data and event data are resolved and merged into the final user profile subsequently.

Consider that a user has two profiles, A and B. When the profiles are merged, profile A, which is the oldest profile, remains. Data from Profile B is merged into data from Profile A.

The following rules are used to merge boolean attributes. A “true” value for either profile gets precedence for boolean attributes.

Blueshift is uniquely able to support customers' use cases where account, group, and a householding data model is applicable. In this scenario, different customer profiles are linked to a common parent entity called a group.

API to merge profiles

You can also programmatically merge two customer profiles using the merge API endpoint.

When you use the API to merge profiles, you can implement your custom logic and decide which profile to retain and which to merge.

For more information, see the Merge customer API documentation.

Profile unification examples

Here are some examples that show how user profiles are created and unified in Blueshift.

Merging multiple profiles

A user browses your website and mobile app anonymously. The user later logs into the mobile app and the website on different days using different devices but using the same email address and user ID.

1. An anonymous user browses the /about-us page on your website. This information is sent to Blueshift using a pageload pixel. The cookie is sent automatically for every website event.

This creates a new anonymous profile: customer1.

For example: pageload(cookie: <cookie1>, url: domain.com/about-us)

2. The same user opens the mobile app a week later and views a few products. This information is sent to Blueshift using the Mobile SDK with an item view event. The device_id is sent automatically for every mobile SDK event. 

This creates a new anonymous profile: customer2.

For example: view(device_id: <device1>, product_id: itemA)

3. The user signs in to the mobile app with the email john1@mail.com and userid123. This information is sent to Blueshift using an identify pixel. The user with the matching mobile device_id is found, and the user's customer_id and email address are updated.

For example: identify(customer_id: userid123, email: john1@mail.com, device_id: <device1>)

4. The user returns the next day and signs in to the website with john1@mail.com and userid123. 

• Blueshift detects that there are two profiles for the same user, userid123.
• A merge is triggered, resulting in a single customer profile with all attributes and behaviors merged. 
• The oldest profile is retained.

For example: identify(customer_id: userid123, email: john1@mail.com, cookie: <cookie1>)

Merging an anonymous and known profile

A user browses your website anonymously. The user later receives an email and clicks a link in the email, which takes the user to a product page on your site.

1. An anonymous user browses the About Us page on your website. This information is sent to Blueshift using a pageload pixel. The cookie is sent automatically for every website event.

This creates a new anonymous profile: customer1.

For example: pageload(cookie: <cookie1>, url: domain.com/about-us)

2. The next day, the user receives an email at the address john1@mail.com from a Blueshift campaign that contains a link to one of your products. When the user clicks on the link, the product's page on your site opens in the browser.

This creates a new profile: customer2.

At this point, Blueshift detects two profiles for the same user and triggers a merge, resulting in a single customer profile with all attributes and behaviors merged. The oldest profile is retained.

Merging with the oldest profile

Consider that a customer has 3 profiles in Blueshift - one anonymous, one with an email, and one with a customer ID. An identify event that contains all the identifiers results in the merging of the profiles into one profile for the customer.

Identify event: identify(cookie: cookie1, customer_id: userid123, email: john1@mail.com)

All profiles are merged to the oldest customer profile by referencing the existing customer_id, and email.

Identifier with higher priority does not match

Consider that a customer has two profiles in Blueshift with separate customer_ids.

The following identify event is sent to Blueshift:

Identify event: identify(customer_id: userid123, email: john1@mail.com, cookie: cookie2)

The identifier customer_id has a higher priority, and since the customer_ids for customer1 and customer2 do not match, the profiles are not merged. Instead, the profile for customer1 is updated.

Identifier with lower priority does not match

Consider that a customer has two profiles in Blueshift with separate email addresses.

The following identify event is sent to Blueshift:

Identify event: identify(customer_id: userid123, email: john2@mail.com, cookie: cookie2)

The identifier email does not match. However, customer_id has a higher priority than email. Hence, the profiles are merged. 

• The email address from the identify event is retained in the profile. 
• Both cookies are retained.