Linking events to specific users enables you to build a full picture of how they're using your product across different sessions, devices, and platforms.
This is straightforward to do when capturing backend events, as you associate events to a specific user using distinct_id
, which is a required argument. However, on the frontend, a distinct_id
is not a required argument and you can capture events anonymously.
To link events to specific users, call identify
:
posthog.identify('distinct_id', // Replace 'distinct_id' with your user's unique identifier{ email: 'max@hedgehogmail.com', name: 'Max Hedgehog' } // optional: set additional person properties);
Events captured after calling identify
are identified events and this creates a person profile if one doesn't exist already.
Under our current pricing, anonymous events can be up to 4x cheaper than identified events (due to the cost of processing them), so it's recommended you only capture identified events when needed.
How identify works
When a user starts browsing your website or app, PostHog automatically assigns them an anonymous ID, which is stored locally. This enables us to track anonymous users – even across different sessions.
Note: depending on your persistence configuration, the anonymous ID may not be stored, and thus regenerated across sessions.
By calling identify
with a distinct_id
of your choice (usually the user's ID in your database, or their email), you link the anonymous ID and distinct ID together.
Thus all past and future events made with that anonymous ID are now associated with the distinct ID. This enables you to do things like associate events with a user from before they log in for the first time, or associate their events across different devices or platforms.
Using
identify
in the backend:Although it is technically possible to call
identify
using our backend SDKs, it is typically most useful in frontends. This is because there is no concept of anonymous sessions in the backend SDKs.
Best practices when using identify
1. Call identify
as soon as you're able to
In your frontend, you should call identify
as soon as you're able to. Typically, this is every time your app loads for the first time, and directly after your users log in. This ensures that events sent during your users' sessions are correctly associated with them.
You only need to call identify
once per session.
2. Use unique strings for distinct IDs
If two users have the same distinct ID, their data is merged and they are considered one user in PostHog. Two common ways this can happen are:
- Your logic for generating IDs does not generate sufficiently strong IDs and you can end up with a clash where 2 users have the same ID.
- There's a bug, typo, or mistake in your code leading to most or all users being identified with generic IDs like
null
,true
, ordistinctId
.
PostHog also has built-in protections to stop the most common distinct ID mistakes. See the FAQ at the end of this page for more details.
3. Reset after logout
If a user logs out on your frontend, you should call reset()
to unlink any future events made on that device with that user.
This is important if your users are sharing a computer, as otherwise all of those users are grouped together into a single user due to shared cookies between sessions. We strongly recommend you call reset
on logout even if you don't expect users to share a computer.
You can do that like so:
posthog.reset()
If you also want to reset the device_id
so that the device will be considered a new device in future events, you can pass true
as an argument:
posthog.reset(true)
4. Person profiles and properties
You'll notice that one of the parameters in the identify
method is a properties
object. This enables you to set person properties. Whenever possible, we recommend passing in all person properties you have available each time you call identify, as this ensures their person profile on PostHog is up to date.
Person properties can also be set using a capture
and not only with identify
. See our person properties docs for more details on how to work with them and best practices.