Leanbase captures two types of events: anonymous and identified
Identified events enable you to attribute events to specific users, and attach person properties. They're best suited for logged-in users.
Scenarios where you want to capture identified events are:
Tracking logged-in users in B2B and B2C SaaS apps
Doing user segmented product analysis
Growth and marketing teams wanting to analyze the complete conversion lifecycle
Anonymous events are events without individually identifiable data. They're best suited for web analytics or apps where users aren't logged in.
Scenarios where you want to capture anonymous events are:
Tracking a marketing website
Content-focused sites
B2C apps where users don't sign up or log in
Under the hood, the key difference between identified and anonymous events is that for identified events we create a person profile for the user, whereas for anonymous events we do not.
Important: Due to the reduced cost of processing them, anonymous events can be up to 4x cheaper than identified ones, so we recommended you only capture identified events when needed.
How to capture anonymous events
Web
Backend
Android
iOS
Flutter
The JavaScript Web SDK captures anonymous events by default. However, this may change depending on your person_profiles config when initializing leanbase :
person_profiles: 'identified_only' (recommended) (default) - Anonymous events are captured by default. Leanbase only captures identified events for users where person profiles have already been created.
person_profiles: 'always' - Capture identified events for all events.
For example:
Web
leanbase .init('phc_CTMqwSYhUFLHhkWWDKZWUkDtFH025P3OwkWfb5h1Y2v', {
api_host: 'https://us.i.leanbase .com',
defaults: '2025-05-24',
person_profiles: 'always'
})
How to capture identified events
Web
Backend
Android
iOS
Flutter
If you've set the personProfiles config to IDENTIFIED_ONLY (the default option), anonymous events are captured by default. To capture identified events, call any of the following functions:
When you call any of these functions, it creates a person profile for the user. Once this profile is created, all subsequent events for this user will be captured as identified events.
Alternatively, you can set personProfiles to ALWAYS to capture identified events by default.
Identify best practices
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, and you should avoid calling it multiple times unnecessarily.
If you call identify multiple times with the same data without reloading the page in between, Leanbase will ignore the subsequent calls.
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 leanbase . 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.
Leanbase also has built-in protections to stop the most common distinct ID mistakes.
3. Set up 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 Leanbase is up to date.
Person properties can also be set being adding a $set property to a event capture call.
See our person properties docs for more details on how to work with them and best practices.
Mobile SDK version considerations
When using leanbase 's mobile SDKs, any changes made to personProfiles configuration will only apply to users who have updated their app to the latest version. This is because mobile SDKs are bundled with your app and cannot be updated dynamically.
Impact on existing users:
Users running older versions of your app will continue using the personProfiles configuration that was bundled with their installed version, even after you release updates with new configurations.
Managing version differences:
To ensure consistent behavior across your user base, you can:
Use feature flags (with a version payload) to detect users running outdated app versions
Implement an update flow to guide users to install the latest version
Consider making app updates mandatory for critical changes
This will help maintain consistency in how person profiles are handled across your entire user base.