Using Identify

Heap empowers you to use the rich information about your users to build enhanced reports, and better understand how they interact with your site or app.

There are two primary APIs for enriching user data in Heap. The identify API allows you to identify users with a unique identifier and maintain user histories across sessions and devices under a single profile. The addUserProperties API allows you to attach custom properties to your users, whether they are identified, or still anonymous.

Anonymous Users

When a person interacts with your site or app, Heap generates a random unique user ID and stores it in a cookie, or on iOS, in NSUserDefaults. In Heap, these people will appear in the Users view as "User 123456" where the 123456 is their user ID, we refer to these users as anonymous users throughout this document.

Identified Users

You can use the identify API to attach your own unique identifier to a user. The identify API takes a single case-sensitive string value as an argument.

If you use the same identity for another user, their past sessions and event activity will be merged into the existing Heap user with that identity.

User Properties

The addUserProperties API can be used to attach properties to users' profiles. Heap sets some of these properties automatically, like Initial City, Initial Referrer, and Initial Landing Page. You can set any property, with any value, as long as those values are a string or an integer.

Some practical properties to use include: payment plan, marketing segment, or A/B experiment. Once set, these properties can be used in reports to group by and filter against. You don't need to use a unique identifier to add new properties since Heap already maintains a unique user ID associated with the user. Jump to some specific examples farther down this page.

When and Where to Call identify and addUserProperties

The identify and addUserProperties APIs can be called at any time, and as many times as needed. The typical place for an identify call that includes a unique identifier is on any post-login or post-signup page. When setting properties, it's OK to call the addUserProperties API on any page.


Anonymous to New Identity

Let's say we have an internal user ID from our own database, and we want to identify a user based on that ID. We can do that like this:


Now their profile in the Users view will look like this:

Anonymous to Existing Identity

In the last example, we identified a user with the unique user ID of 12345. Let's say that this person visits your site from their mobile device for the first time. Heap will generate a new, random, unique userID, in this case it's 1565941335949135. In Heap's Users view, this visitor looks like this:

When this person logs in, and you recognize that their internal user ID is 12345, and call identify like this:


The previous user's profile with the random user ID of 1565941335949135 is merged, along with its previous sessions and events into the Heap profile of the identified user with the identity of 12345.

Identified User to New Identity

In some rare scenarios, a person who we already identified visits your site and is identified with a new ID. A person, let's call her Kate, creates an account on your site, then, her friend Jack uses the same browser to create an account.

The identify calls will look the same as in the previous examples. Before the identify call is made, all the sessions, page views, and event data for this person will be associated with Kate's existing identity in Heap.

After the identify API is called when Jack signs up, all session, page view, and event data from that point on, will appear in a new profile associated with Jack. To understand what happens if Kate returns and logs in, see the next example.

Identified User to Existing Identity

In the previous example, we described how, after Kate was identified, Jack visited the site from the same computer. Jack was identified and a new Heap profile was created.

What happens if Kate returns to the site on the same browser after Jack was using it?

When this happens, all of Kate's session, page view, and event data associated with the current session appear in Jack's Heap profile, since he was the last one to be identified. When Kate logs in, and is identified, only data from that point on now appear with the existing data already in Kate's profile.

Uses of Properties

Account Plan

Many products include some sort of tiered pricing plan. Using heap.addUserProperties() to attach this information to your visitors' Heap profiles can help you compare and contrast usage between different segments.

When Heap first launched, our pricing tiers were Free, Startup, Growth, Premium, and Enterprise. We used the addUserProperties API ourselves to measure the success of different product features depending on the account tier.

When someone visits Heap, we pull their account tier from our database and inject that into an identify call like this:

heap.addUserProperties({plan: "Startup"});

This let us build powerful reports, like this graph report, showing sign ups split by the plan.

Identify Pitfalls

Using a Non-Unique Identifier

A common assumption is that a unique identifier attached via identify is required in order for the addUserProperties API to attach properties to a user. In cases where a unique identifier isn't available, we've seen people include a specific name, like guest, or Anonymous User.

This can cause catastrophic behavior with how Heap merges user profiles. You can call addUserProperties at any time, whether or not the user has been given a unique identity.

Let's say that you have a marketing campaign, and you want to associate it with a visitor when they visit your landing page. They aren't logged in, so you don't have a unique identifier.

Don't Do This

heap.addUserProperties({campaign: 'Campaign Name'});

What this will do, is merge all visitors into a single user profile called guest. This will break any metrics that rely on user flow, or the unique user count.

Instead, Do This

heap.addUserProperties({campaign: 'Campaign Name'});

Now, the campaign property will be associated with the anonymous user, using the value of the JavaScript variable campaign.

Adding an Anonymous Unique Identifier of Your Own

Some tools require a unique identifier to be provided in order to add user-level properties. This leads people to adding their own unique identifier to all visitors. Heap automatically assigns each unidentified user a unique user ID so you are not required to call identify to add user-level properties. Assigning an identity to a user when it is not required can lead to undesirable, or unexpected behavior.

In the earlier section Identified User to New Identity, we covered what happens when an identified user is identified again with a different identity. Heap does not allow you change an already applied identity or assign multiple identities to the same user. If you call identify with an anonymized identity, for example, a uuid or random hash, this will be their permanent identity in Heap. If you call theidentify API at another time for the same user with a different identity, such as an internal user ID or username, this will create a new user in Heap, splitting this users into two identified users, one with the random uuid containing all the historical events, and another with the user ID or username which has events going forward.

Since Heap automatically creates a randomized unique identifier, it's not necessary for you to send your own identifier unless you are certain it is a unique, permanent identifier for the user. If you want to add properties to a user using addUserProperties, you can do so without providing a unique identifier. Calling heap.addUserProperties({property: 'value'}) will add this property to the anonymous user's Heap profile automatically.

Limitations of Server-Side Add User Properties

Heap's server-side add_user_properties API allows you to set user-level properties without having them tied to an existing session. This is useful when you want to backfill certain values that may not have been available at the time someone was visiting your site, or using your app.

The server-side API only takes a single identity parameter as its first argument. The client-side API acts within the context of a session, and because of this, uses a known Heap user ID when attaching properties. Since that user ID is not readily available when using the server-side API call, it's up to you to know the user's identity when applying properties.

Using Identify

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.