Identity resolution merges each customer's complete history into a single profile, no matter where they interact with your business. It lets you understand a user’s real-time interaction across web, mobile, server, and third-party partner touchpoints. It uses an ID graph supporting device IDs, emails, and custom IDs. If you send the Group call, you can also understand user behavior at the account level.

• Supports existing data — no additional code or setup required
• Supports all sources — stitches web + mobile + server + third-party interactions into the same user
• Supports anonymous identity stitching — by merging child sessions into parent sessions
• Supports user: account relationships - for B2B companies, generates a graph of relationships between users and accounts
• Real-time performance - reliable real-time data stream merges with minimal latency

Why unify profiles?

One user or account profile commonly exists in multiple systems within your technology stack, such as a contact in HubSpot and a customer in Shopify.

For example, one profile may exist as a contact in your CRM that your sales teams can use to prospect or your service team can use to handle support cases. The same profile may also exist within your marketing automation system, where your marketing team runs campaigns.

The larger your organization, the more likely you are to have many systems with the same data in each system.
Navigating within this state can be tricky. One of the benefits of Intempt is that it can create a source of truth in which the same profile that exists in many systems can be combined into one single profile while still maintaining all of the information you care about.

Use cases

Cross app identification

Your product ecosystem can be spread out across multiple apps.

Connecting all sources to the same project allows you to understand a user’s activity across all apps. This provides a comprehensive view of a user’s activity across the entire app ecosystem.

For example, Johnny Appleseed exists in both HubSpot and Shopify. Some of the information about the user is in Shopify, and others are in HubSpot. I need one place to see all the important information.

1. Both HubSpot and Shopify will contain important, unique information about Johnny Appleseed. These two profiles, each with unique attributes, will be combined into one profile in Intempt.
2. Some fields in HubSpot and Shopify will represent the same information. Examples are First Name, Last Name, Email, and phone. Intempt has reserved attributes that allow you to unify the most commonly used attributes automatically once you create the source.
3. Some attributes may be the same but have different names. In order to map these different attributes into a single source of truth, use Attribute mapping.

Anonymous to known identification

Identity Resolution lets you link a customer’s journey from pre-account creation to post-account activity. This is important to help a brand understand the behaviors that lead a user to convert from a window shopper in the discovery stage to a buyer with intent in the consideration and decision stage to a loyal return customer in the conversion and retention stage.

By linking any anonymous events a user had before creating an account to a user’s logged-in activity, a marketing team can now fully understand a user’s past interactions with your app.

Cross-device identification

Users can interact with an app ecosystem through more than one device. For example, they might view an eCommerce site through a mobile native app, a mobile web browser, or a desktop web browser.

By tracking a user’s activity across all platforms, brands can more efficiently target campaigns to users as they’ll know about complete funnels across devices.

For example, a user who adds a product to a cart on the iPhone app but completes the checkout on the Android app shouldn’t be targeted with abandoned cart push notifications on the iPhone app.

Identity resolution logic

Intempt creates and merges user profiles based on the identifiers you are using. Intempt searches for identifiers such as userId and profileId on incoming events and matches them to existing profiles or creates new profiles.

Identifier types

• Profile ID is a source-level identifier, such as Hubspot Contact ID or Shopify customer ID. This ID is unique and only exists in one source. Events with the same profileId inside one source will be connected to a single user.
• User ID is a project-level identifier for users. The most commonly used are phone and email. This ID is shared across all sources.
• Account ID is a project-level identifier for a group of users (like companies or accounts). The most commonly used examples are company domain, name, and IDs.

These identifiers are displayed on the user details page.

Matching logic

After receiving a new event, Intempt looks for users that match any of the identifiers on the event.

Based on the existence of a match, one of three actions can occur:

1: Create a new user - when there are no pre-existing profiles that have matching identifiers to the event, Intempt creates a new user profile.

2: Add to existing user profile - when there is one profile that matches all identifiers in an event, Intempt attempts to map the traits, identifiers, and events on the call to that existing user. If there is an excess of any identifier on the final profile, Intempt defers to the Identity Resolution rules outlined below.

3: Merge existing user profiles - when there are multiple users that match the identifiers in an event, Intempt checks the identity resolution rules, and attempts to merge profiles.

Identifying users

To resolve your users' identities, you need to use the Identify call (the same applies for accounts, but you need to use the Group call).

Identify call lets you tie a user to their actions and record attributes about them. It includes a unique user identifier and any optional attributes you know about the user, like their email, name, and more.

Whenever possible, follow the Identify call with a Track event that records what caused the user to be identified.

Anonymous users

If you’re using Intempt Javascript SDK or iOS SDK, the Intempt SDK generates and sets a UUID as profile ID on the user’s first visit to your site. That profile ID is saved in the user’s cookie and localStorage and will stay with that user until the cache is cleared or a reset call is triggered.

You can use the profile ID to link events performed by the user as they navigate around your website. When you track the profile ID, you can attribute activities over multiple days to the same user by collecting all of the activities with that ID. If a user chooses to register for your site or log in to your app, you can Identify them and still include their profile ID in the event payload and the new user ID.

The illustration below shows a timeline with a user’s interactions on a website, including sample API calls above that show Intempt calls, and the user’s profileId and userId used.

This timeline illustration shows three points at which a user interacts with a website (visits homepage, signs up for newsletter, and clicks the demo request button) and the corresponding API calls Intempt makes for each step

When the user first visits a page, Intempt JS SDK automatically assigns the user a profile ID and saves it to the user’s local storage. As the user interacts with the site, for example, by clicking around to different pages, SDK includes this profile ID and some contextual information with each Page view and Track calls. The contextual information might include the user’s IP address, browser, etc.

When a user signs up to create an account on the website, the .identify("userId") and .track(“Signed Up”) events fire, in that order. You pull the user ID unique to the user from your systems and send it to Intempt so you can label that user’s later events with their ID. The later Track call (“Signed Up”) contains both the userId and the automatically-collected profileId for the user, and any other information you capture about them - such as their first name, last name, and email address.

User ID merge examples

Let’s go through some more scenarios to explain how a profile ID is assigned and how it might be merged with a user ID.

Scenario #1 - Multi-day, single device

If a user clicks on an ad and is directed to a webpage, they are assigned a profile ID. While this user is anonymous, they navigate to different pages and click around on the website. Say they come back two days later from the same device, sign up, and are assigned a user ID from your database.

This timeline illustration shows four points at which a user interacts with a website (visiting the homepage, clicking a button, visiting the page again, and signing up) and the corresponding API calls Intempt makes at each point.

For simplicity, we’re assuming that the user has not cleared their cookies or localStorage, where the original profileId is stored. If they had, they’d be assigned a new profile ID when they visited the website, and the user ID they got when they registered on the website would not be attached to the activities tracked with the old profile ID.

Scenario #2 - Multi-day, multi-device, single login

In this scenario, the person interacts with your site using both a web browser and a mobile application. In each case, they are assigned different profile IDs. In this scenario, the user signs up on the web browser, so Intempt assigns their web session a user ID. However, because they do not log in on the mobile application, Intempt cannot tie the mobile activity to this specific user. Their mobile application activity remains anonymous unless they log in on the mobile application.

This timeline illustration shows two parallel paths: one for a user logging into a desktop site and one for an anonymous mobile app user, and the API calls Intempt makes to identify the users.

Scenario #3 - Multi-day, multi-device, multiple logins

Similar to the previous scenario, the user accessed your website and mobile application and logged in on both. In this case, both web and mobile app sessions receive the user’s user ID so Intempt can tie the anonymous activity on both web and mobile to this user.

Identifying accounts

To identify accounts, you need to use the Group call - this is how you associate an individual user with an account, such as a company, organization, account, project, or team.

The Group call enables you to identify what account or organization your users are part of. There are two relevant IDs in a Group call: the user ID, which belongs to and refers to the user, and the account ID, which belongs to and refers to the specific group. A user can be in more than one group, which would mean different account IDs, but the user will only have one user ID that is associated with each of the different groups.

In addition to the account ID, which is how you’d identify the specific group or company, the group method receives attributes specific to the group, like industry or number of employees, for example, that belong to that specific account. Like the attributes of an identify call, you can update these when you call the same attribute with a different value.

When to call identify and group

You should make an Identify call in the following situations:

• When the user provides any identifying information (such as a newsletter sign-up with email and name)
• When first you create a user (and so it is assigned a user ID)
• When a user changes information in their profile
• When a user logs in

📘

Good to know

Check the Javascript SDKdoc for how to use identify and group calls.

Accound ID merge examples

Scenario #1 - Multi-day, multi-device, multiple logins with user and account IDs

Similar to scenario #3, the user accessed your website and mobile application and logged in on both. In this case, both web and mobile app sessions receive the user’s user ID, but only the web source receives the account ID.

The account ID is automatically connected to the User ID. If a user is identified in one source (website) with the account ID and user ID and on the app source only with a user ID, all user's events in the app will still be attributed to the same account ID even if the app source did not have an account ID assigned.