Identifying users

Last updated:

|Edit this page

On this page

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 events can be submitted anonymously.

To link events from anonymous to specific users, capture events with person profiles by calling 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
);

This creates a person profile if one doesn't exist already.

Under our current pricing, events without person profiles can be up to 4x cheaper than events with them (due to the cost of processing them), so it's recommended to only capture events with person profiles 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, or distinctId.

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:

Web
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.

Alias: Assigning multiple distinct IDs to the same user

Sometimes, you want to assign multiple distinct IDs to a single user. For example, if a distinct ID which is typically used on the frontend is not available in certain parts of your backend code, you can use alias to connect the frontend distinct ID to one accessible on the backend. This will merge all past and future events into the same user.

In the below example, we assign the user with distinct_id another ID: alias_id. This means that any events submitted using either distinct_id or alias_id will be associated with the same user.

client.alias({
    distinctId: 'distinct_id',
    alias: 'alias_id',
})

There are two requirements when assigning an alias_id:

  1. It cannot be associated with more than one distinct_id.
  2. The alias_id must not have been previously used as the distinct_id argument of an identify() or alias() call. For example: Assume we previously called posthog.identify('distinct_id_one'). It is not possible to use distinct_id_one as an alias ID:
// Assume we previously identified a user with 'distinct_id_one' using posthog.identify('distinct_id_one')
// ❌ The following is not possible:
// You cannot use distinct_id_one as an alias for any_other_id
client.alias({
    distinctId: 'any_other_id',
    alias: 'distinct_id_one',
})

You can view whether a user can be merged into another user using alias when viewing their properties in the PostHog app: Under their ID, you'll see Merge restrictions. This will indicate whether there are merge restrictions or not – i.e., whether you can use their ID as an alias_id or not.

Merge restrictions tooltipl

Note that when calling alias in the frontend SDKs, if you have set any properties onto the anonymous user, they will be merged into the user with distinct_id. For more details, see the FAQ on how properties are managed when identifying anonymous users.

Processing person profiles

If your person_profile config option is set to identified_only, PostHog creates a person profile once you call one of the following functions or methods:

  • identify
  • alias
  • setPersonProperties
  • setPersonPropertiesForFlags
  • group
  • setGroupPropertiesForFlags

Once you create a person profile for a user distinct ID, all events for that distinct ID count as ones with person profiles.

If your person_profile config option is set to always, PostHog creates a person profile for every user on your site, whether or not they have been officially identified.

Troubleshooting and FAQs

What happens if you call identify or alias with invalid inputs?

When calling either of these with invalid inputs (such as in the examples described in this doc e.g., using null strings with identify, or by trying to use a distinct ID of another user as an alias ID), the following will happen:

  1. We process the event normally (it will be ingested and show up in the UI).
  2. Merging users will be refused and an ingestion warning will be logged (see ingestion warnings for more details).
  3. The event will be only be tied to the user associated with distinct_id.

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.

  • We do not allow identifying users with empty space strings of any length – e.g.,' ', ' ', etc.

  • We do not allow identifying users with the following strings (case insensitive):

    • anonymous
    • guest
    • distinctid
    • distinct_id
    • id
    • not_authenticated
    • email
    • undefined
    • true
    • false

  • We do not allow identifying users with the following strings (case sensitive):

    • [object Object]
    • NaN
    • None
    • none
    • null
    • 0

  • We do not allow identifying a user that has already been identified with a different distinct ID. For example:

posthog.identify(
    'distinct_id_one',
    {} 
    {}, 
);
posthog.identify(
    'distinct_id_two',
    {} 
    {}, 
);
// ❌ Not possible, since we already identified this user with "distinct_id_one"
// so we cannot identify them again with a different distinct ID "distinct_id_two"

How to handle duplicates of the same user

It may happen that, due to implementation issues, the same user in your product has multiple users in PostHog associated with them. In these cases, you can use $merge_dangerously to merge multiple PostHog users into a single user.

Warning: Merging users with merge_dangerously is irreversible and has no safeguards! Be careful not to merge users who should not be merged together.

Due to the dangers, we don't recommend you merge users frequently, but rather as a one-off for recovering from implementation problems.

Merging users is done by sending a $merge_dangerously event:

client.capture({
    distinctId: 'distinct_id_of_user_to_merge_into',
    event: '$merge_dangerously',
    properties: {
        alias: 'distinct_id_of_user_to_be_merged',
    },
})

How to split a merged user back into separate users

If you've accidentally linked distinct IDs together that represent different users, or you've made a mistake when merging users, it's possible to split their combined user back into separate users. You can do this in the PostHog app by navigating to the user you'd like split, and then clicking "Split IDs" in the top right corner.

Warning: This will treat the distinct IDs as separate users for future events. However, there is no guarantee as to how past events will be treated – they may be be considered separate users, or be considered a single user for some or all events.

How are properties managed when merging users?

When a User B is merged into another User A, all the properties of the User B are added to User A. If there is a conflict, the properties of User A are prioritized over User B. For example:

Node.js
/* Assume User A has the properties:
{ 
        name: 'User A',
        location: 'London',
}
*/


/* Assume User B has the properties:
{ 
        name: 'User B',
        location: 'Rome',
        phone: '0800-POSTHOG',
}
*/


client.capture({
    distinctId: 'distinct_id_of_user_A',
    event: '$merge_dangerously',
    properties: {
        alias: 'distinct_id_of_user_B',
    },
})


/* User B has merged into User A. The resulting user will now have properties:
{ 
  name: 'User A',
  location: 'London', 
  phone: '0800-POSTHOG', 
}
*/

How are properties managed when identifying anonymous users?

When an anonymous user is identified as User A, all the properties of the anonymous user are added to User A. If there is a conflict, the properties of User A are prioritized over the anonymous user. For example:

Web
/* Assume existing User A has the properties:
{ 
        name: 'User A',
        location: 'London',
        timezone: 'GMT',
}
*/


/* Assume User A uses your app on a new device, 
but has not yet logged in and so identify has not been called.
They are still an "anonymous user"


New properties are set for this "anonymous user"
*/
posthog.capture(
    'event_name', 
    { 
        $set: { 
            name: 'Anonymous User',
            phone: '0800-POSTHOG',
          },
    }
)


// After log in, we identify the user as User A
client.identify({
    distinctId: 'user_A',
    properties: {
        timezone: 'GMT+8',
    },
})


/* User A will now have properties:
{ 
  name: 'User A',
  location: 'London', 
  phone: '0800-POSTHOG', 
  timezone: 'GMT+8' 
}
*/

Questions?

  • Yaba    2 months ago

    Identify without Auth system

    I have website that collect email and have a lot of pages, and don't have auth. so is it possible to identify user when they submit email ? and how would I reset the identify because I don't have sign-in or sign-out ?

    • Jeremy      23 days ago

      yes, just use .identify with a unique key and the mail as properties. You can create some sort of hash from the mail which should fit your needs.

    • Yaba      Author23 days ago

      The identify works but all the activities before that have ids instead of the email even if it does know the user ( but grouped them using the email )

  • Daniel    2 months ago

    Person Properties Not Searchable in Insights for Once Anonymous Events

    When a user enters our website, we collect data as an anonymous user until they register. Then we make the identify() call and associate the user with their email address as a property. We also use the generated uuid as a second distinct_id in the identify() call and for all subsequent events. In PostHog, the user is correctly merged into a single profile with two distinct IDs. The person profile also shows all initial properties set correctly. So far, so good.

    However, when I search in the Activity Log or within Insights filtered by a person property like initial_utm_source (which is correctly set in the person profile), I only get events that occurred after the first identify() call. All events from when the user was still anonymous aren’t recognized, even though the raw data shows the correct person_id, and these events are listed in the Events tab of the person profile.

    This issue can be resolved by switching the person_profile flag in the init() call from identified_only to always. However, I’m not satisfied with this solution because switching to always creates a person profile for every anonymous user in PostHog, not just for users who register.

    Am I missing something? Is this the intended behavior, or could this be a bug?

    Any help is much appreciated.

  • eric    2 months ago

    Per browser session?

    Is identify assuming you can only be logged in as one user on a domain/app?

    I'm calling identify() each page which seems to be causing a billing issue.

    Was trying to dedupe that to avoid the bill, so that it only calls if get_distinct_id() returns undefined...but then realizing we have testing users that log in with different accounts and so we would get incorrect results. We also have users that need to login with different credential levels etc. concurrently. So if identify is associating users via a cookie that could cause some issues. It's like when you have more than one AWS account and so you have to open multiple anonymous browsing windows :(

    We have a distinct cookie for our domain, but then can have multiple sessions based on url params that tie them together. It's not the pretty little world we like to pretend we live in sometimes. Feels like identify should really be a part of init() since init is also async and without a callback I'm not really sure what to do here.

  • Lukasz    2 months ago

    When to call identify in server rendered apps i.e. Django

    After reading the docs it's still not clear to me when to call .identify() in server-rendered apps like Django and how does it differ for authenticated and anonymous users. Should I call it for anonymous users at all? And only call it once they login? If so, can it be done on the backend using the SDK with the distinct_id from the cookie?

  • Matt    6 months ago

    What is considered a 'session' for the purposes of calling Identify?

    I have an app which is not fully a "single-page app," so navigating between some sections/pages of the site consists of a full page refresh. I need to track some events using Javascript in the browser.

    Since it sounds like .identify calls count as events for the purposes of billing, I would like to reduce them as much as possible.

    Is each full page refresh considered a "session" which would require an .identify call, or can .identify be called once after login/first visit and then the session is stored by Posthog for some period of time, even across page refreshes?

    • Alex      6 months agoSolution

      You're welcome! To clarify:

      If a user leaves the site and comes back after more than 30 minutes (the default session timeout), a new session will be started for analytics purposes, but this does not necessarily mean you need to call .identify() again, as long as the session cookie is still present and the user is still recognized.

      Key Points: Session for Analytics: After 30 minutes of inactivity, PostHog will start a new session for analytics purposes (e.g., for tracking sessions and events). However, this is independent of the user's identity. User Identification: The .identify() call is used to associate events with a specific user (e.g., a logged-in user). As long as the PostHog session cookie (which stores the user's identity) is not cleared or expired, PostHog will still recognize the user without needing to re-call .identify()—even if a new session is started for analytics tracking. When to Call .identify(): You would typically call .identify() only after user login or when the user’s identity is determined (first visit or login). If the session cookie is intact, there's no need to call it again on subsequent visits, even if it's a new analytics session. Thus, you generally do not need to re-call .identify() unless:

      The session cookie is cleared (e.g., after a long period of inactivity or browser settings that clear cookies). The user logs out and then logs back in. If your app doesn't force re-authentication for the user within 30 minutes, you’re safe to avoid extra .identify() calls.

  • Shubham    7 months ago

    How to identify an anonymous user if he resets his cookies

    I want to discuss a user flow:-

    1. An Anonymous User comes to my web app. He is assigned an anonymous ID by Posthog

    2. Eventually he signs up and I identify him as User1

    3. If this user, then logs out, clear his cookies, go to incognito and then again signs in.

    Q1 - Will his activity be still linked to the same user, given I identify him after signing up?

    Q2 - If the user doesn't signs in through incognito, is there a way to still identify him as the same user?

    Q3 - Is there a way to store cookie on server side instead of cookies?

    • Benjamin      6 months ago

      Hi Shubham,

      Let my try and answer this:

      Q1 - If the user were to go to incognito they would be assigned a different anonymous ID however as soon as they logged in, if you identify them using a distinct_id that you used previously the activity for the anonymous part and the logged in part of the session would be connected to the original user.

    • Benjamin      6 months ago

      Q2 - The only way would be to use the identify call again for this user but it would require you to somehow know that it was the same user and send through the same disctinct_id

      Q3 - This bit is a little beyond what I can help with but if you could achieve it and then similar to the above send the identify call with a disctinct_id Posthog would see the same user.

      Something else to look at is your persistance settings between logged out and in users: https://posthog.com/docs/libraries/js#persistence this has some helpful information on the different methods for persisting the user.

  • Adrian    9 months ago

    Handling anonymous sign in

    My app allows users to sign in anonymously and then use the app. They then can, at any stage, sign in with an auth provider. I want to link my anonymous user ID to Post Hog rather than use Post Hog's anonymous user feature.

    I'm not entirely sure of the best approach and would like to double-check it.

    When a user signs in anonymously, I call to identify with ID - 1. Then, when they sign in with email, I call alias with ID - 2. If the user signs out, I call reset. If they then sign in again by email I call identify with ID - 2. It may be possible that the same user downloads the app on another device, in which case I will have called identify with ID - 3, and then when they sign in, I will call alias with ID - 2.

    I'm wondering if this is all possible or if "merge dangerously" needs to be used at some point.

    • Marcus      9 months agoSolution

      Hey Adrian, that sounds about right, but the identify with ID-3 will require you to use merge_dangerously, since both of those users will have merge restrictions applied.

  • Travis    a year ago

    How to call every time your app loads for the first time, and directly after your users log in?

    "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 phrase is confusing to me. Should we call identify twice? or only on login and then reset on logout?

    Any examples of this with firebase login on next.js

    Im hooked into onAuthStateChanged, but that runs every time the page is manually refreshed, therefore potentially calling identify multiple times in a session. Im really not understanding the proper patterns to get this to be called just once a session.

    • Quentin      a month ago

      Why not build a boolean value somewhere that will let you know if identify() has already been called for your session?

  • David    a year ago

    : How to check if a user has already been identified in PostHog and avoid multiple identifications?

    Certainly! Here's a rephrased version of your question:

    Is there a way to check if a user has already been identified using the PostHog library, similar to how we can check if PostHog has been loaded using posthog.__loaded?

    I want to include this check in my layout component to initialize PostHog and identify the user, but I want to avoid identifying the user multiple times if they have already been identified.

    How can I determine if a user has already been identified using the PostHog library, and how can I structure my code to handle this check appropriately?

    • eric      2 months ago

      having the same issue. did you find a resolution?

  • Mark    a year ago

    Anonymous User ID to form field?

    Is it possible to capture the Creator Event ID to a form field?

    018e75c0-c613-727e-a4a7-2ef4f01ccbce

    I want to link sessions to users, so I can see who did what.?

    • Marcus      a year ago

      Hey Mark, the Creator Event ID is the ID of the event that created the person. In your case, it sounds like you want to get the current distinct_id. You can get that ID by calling posthog.get_distinct_id().

  • Laurent    a year ago

    distinct_id case sensitivity

    Is the distinct_id case sensitive?

    • Marcus      a year agoSolution

      Yes, the distinct_id is case-sensitive.

  • Parth    a year ago

    Getting a lot of Anonymous users due to Auth redirect

    Hi, Let me start by explaining our scenario and implementation. We are currently live on 2 platforms using Flutter:

    1. Web (mWeb and Desktop both)
    2. Android

    We have a separate react app for authentication (Auth Webapp). Both have posthog imlemented with the same project token.

    Now, this is how our user flow for login works:

    Flutter App -> Auth webapp -> Redirected back to Flutter App with token

    More specficially, this is how it works for Web:

    1. User comes to web.peakmind.in
    2. If the user is not logged in they are redirected to auth.peakmind.in
    3. They fill in their login details and then they are directed back to web.peakmind.in with the auth token

    For android:

    1. User comes to the Android app
    2. If the user is not logged in we open auth.peakmind.in in a webview
    3. They fill in their login details and then they are directed back to the app using message passing between the app and webview.

    Problem:

    1. Whenever the user doesn't complete the login flow, two anonymous users get created with different journeys: One with the initial App home screen and another user with just the auth.peakmind.in journey.
    2. If the user logs in we are able to call identify in both places to unify them but this doesn't happen if the user drops off before that.

    This is creating a lot of anonymous users with broken journeys for us that we can't easily analyze and is messing up the metrics.

    How do we solve this problem? Could posthog not just have a single anonymous ID linked to the device instead of creating a new one each time the front-end SDK is initialized?

    Thanks, Parth Sharma Peakmind.in

    • Manoel(he/him)      a year agoSolution

      There's no communication between multiple SDKs being used at the same time.

      For example, a Flutter app using the Flutter SDK and a React App using the JS SDK.

      Each of them has its own anonymous ID, they don't share an anonymous just because they are running on the same device, and the web view/browser is sandboxed.

      The only option you have is to call identify on both sides with the very same ID but as you said it's not always possible, not sure we can do much more than that.

      Maybe it's possible to make a wrapper on your WebView and pass the ID from the Flutter App to the WebView via javascript and set that ID on the JS SDK, so they share the same anonymous ID at least, is that feasible on your side?

      For example, something like that, your function on JS is gonna set the ID on the JS SDK that was given by the Android SDK.

  • Amitav    a year ago

    Adding properties to anonymous users

    Hi, We keep collecting details about anonymous users until we capture their email and create a contact in our backend for the user. What we've been trying to do in the frontend web is something like this:

    posthog.identify(undefined, {
      some_prop: some_value
    });

    till the point where we capture the email, and then doing this call in our backend:

    posthog.alias({ distinctId: contactId, alias: phAnonymousId });

    where the anonymous ID is the one from the browser. This doesn't seem to be working though, I don't see some_prop being set on my contact. Are we doing this right? Are we not allowed to associate custom props to an user till they've been identified with a distinct ID?

    • Alec      5 months ago

      cc @marcus/30211

  • Jarrett    a year ago

    Users accumlate many IDs

    Everytime a user visits our dashboard and is signed out, they get a new id. Once they sign in, we call identify with their UUID from our system. If the user signs out and back in, we call posthog.reset(). Is it normal for users to accumulate many IDs or are we doing something incorrectly.

    • James      a year agoSolution

      nope, this is normal - simply we track them separately until they're identified them merge them together so they'll pick up lots of extra ids along the way!

    • Peter      15 hours ago

      If you merge them together, does this merge propagate correctly to BigQuery if you've set up an export destination with a daily cadence?

  • Amitav    a year ago

    Identifying users vs user's users

    We have a chat widget that is installed on our client's websites. There are different interfaces each - a Next.js dashboard for our clients (users) and the react chat widget for our user's users (website visitors). Our users sometimes go play around with their chat widget as well. We want to independently analyse chat widget behaviour and dashboard behaviour.

    What's the recommended approach for -

    1. Posthog workspace creation - should we create different projects for the chat widget and dashboard? Will it be simpler to analyse within posthog this way?
    2. Calling identify - if we call identify for each anonymous website visitor, then we need to filter out internal users for analysis of different cohorts. Can't add our users as internal users for the sake of our chat widget usage insights, because that will break our dashboard insights.

    Any ideas are appreciated!

    • Simon(he/him)      a year agoSolution

      Hi Amitav,

      1. You'll likely want to have two separate PostHog projects here. It's recommended to keep tracking in the same project if you want to see users going between the widget and dashboard, but as in your case they are two separate groups of users you will likely want to separate them out.
      2. You should only identify users when you know who they are. By definition if they are anonymous you don't know who they are so identify() isn't needed.
  • Alton    a year ago

    Email as Distinct ID...

    I know that we can/maybe should be setting a universal distinct ID for the user but is there a really good reason that when I call identify, I don't just set the users email as distinct ID?

    • Marcus      a year agoSolution

      Hey Alton, we recommend setting your UUID as a distinct_id and the email as a user property instead. That is because the email is not permanent and might change in the future.

  • Kamran    a year ago

    Identifying will override initial set_once properties?

    I am seeing some behavior I think is explained by this:

    When an anonymous user is identified as User A, all the properties of the anonymous user are added to User A. If there is a conflict, the properties of User A are prioritized over the anonymous user.

    The problem is that if I want to track first touch attribution with $initial_referring_domain or similar properties already set on the anonymous user, identifying the user on the backend and associating with my unique ID apparently blows away the initial props that were set on the FE so I can no longer track attribution.

    Originally, I think this was because I was capturing the sign up event and calling Identify. Now I've switched my BE to not call Identify and just attach person properties on the individual events, so the FE can merge properties.

    I just wonder if this is expected. Shouldn't only non-initial User A properties be merged on an anonymous user? I feel like it should be safe to call Identify on the BE and safely merge with a FE anonymous user without losing first-touch attribution props.

    • Kamran(He/Him)      Authora year agoSolution

      I was able to fix my issue.

      Here was the problem, which wasn't super apparent to me:

      1. Anon user hits homepage and gets tracked as anon user
      2. PostHog creates a new Person with an anon ID
      3. User is tracked across session until they sign up
      4. On backend, server sees new user signup and emits a new Signup event with distinct_id set to the new user ID
      5. PostHog doesn't have a user by this distinct ID, so it creates a net new Person
      6. On frontend, user is redirected to another page where posthog.identify is called using their user ID
      7. PostHog sees backend-created user, and MERGES the frontend session INTO the backend user -- but keeps all initial properties set by the BACKEND

      So that is why, after the Signup event, it "blows away" the anonymous session's initial properties.

      To fix this, I created a hidden form field to populate the Posthog's distinct ID (if anonymous), and pass it up to the server. The server then aliases the old anonymous ID to the new distinct user ID.

      Code snippet:

      posthog.init('ph-abc123', {
          api_host: 'https://app.posthog.com',
          loaded: function (posthog) {
              var isAnonymous = posthog.persistence.get_user_state() === 'anonymous';
      

              if (!isAnonymous) return;
      

              var distinctId = posthog.get_distinct_id();
              var aliasFields = document.querySelectorAll('[data-alias-id]');
      

              if (aliasFields.length > 0) {
                  Array.from(aliasFields).forEach(field => {
                      field.value = distinctId;
                  });
              }
          }
      })

      (Then on backend, if alias ID is not empty, it emits the $create_alias event)

      This fixed my problem!

      I wish this flow was a little more clear in the docs (How to Identify Frontend Users with a Backend) as it was pretty confusing to see in analytics why all my referral data was wiped after implementing server events.

  • Arthur    a year ago

    How to persist feature flag value from anonymous user with random uuid, to newly registered user with different id

    For anonymous user i call feature flag on server with posthog-node and unique uuid. Then on client, when user registers, i want to persist feature flag value with posthog-js lib and newly created user id. For already existing users the feature flag value may change, if they called feature flag before.

  • Zach    a year ago

    Use identify only on log in with Auth0

    Hey all, we don't currently host our own login page (Auth0) and any page on our app will call identify dozens of times (leading to an abundance of Set events). Any recommendations on where to put identify or how to integrate to only run identify once on login?

    • Marcus      a year agoSolution

      Hey Zack, right now it's not possible to avoid those $set events. We are planning to update that behaviour, feel free to follow along in this GitHub issue.

  • Maksim    a year ago

    Quota consumption

    Will identify consume events quota limit?

    I'm looking how can I update user properties and how it will consume quota

    • Marcus      a year agoSolution

      Hey Maksim, the $identify event will in fact count against the monthly event quota.

Was this page useful?

Next article

Person properties

Person properties enable you to capture, manage, and analyze specific data about a user. You can use them to create filters or cohorts , which can then be used in insights , feature flags , surveys , and more. Person properties are stored on person profiles and create a profile if one doesn't exist. How to set person properties What is the difference between set and set_once ? How to remove person properties Similarly to how you set properties, you can use $unset to remove…

Read next article