It uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your mobile app.
Installation
The best way to install the leanbase Android library is with a build system like Gradle. This ensures you can easily upgrade to the latest versions.
All you need to do is add the leanbase-android module to your App's build.gradle or build.gradle.kts:
Configuration
The best place to initialize the client is in your Application subclass.
Capturing events
You can send custom events using capture:
Tip: We recommend using a [object] [verb] format for your event names, where [object] is the entity that the behavior relates to, and [verb] is the behavior itself. For example, project created, user signed up, or invite sent.
Setting event properties
Optionally, you can include additional information with the event by including a properties object:
Autocapture
Leanbase autocapture automatically tracks the following events for you:
Application Opened - when the app is opened from a closed state or when the app comes to the foreground (e.g. from the app switcher)
Deep Link Opened - when the app is opened from a deep link.
Application Backgrounded - when the app is sent to the background by the user
Application Installed - when the app is installed.
Application Updated - when the app is updated.
$screen - when the user navigates (if using android.app.Activity)
Capturing screen views
With captureScreenViews = true, Leanbase will try to record all screen changes automatically.
The screenTitle will be the <activity>'s android:label, if not set it'll fallback to the <application>'s android:label or the <activity>'s android:name.
If you want to manually send a new screen capture event, use the screen function.
This function requires a screenTitle. You may also pass in an optional properties object.
Identifying users
We highly recommend reading our section on Identifying users to better understand how to correctly use this method.
Using identify, you can associate events with specific users. This enables you to gain full insights as to how they're using your product across different sessions, devices, and platforms.
An identify call has the following arguments:
distinctId: Required. A unique identifier for your user. Typically either their email or database ID.
userProperties: Optional. A dictionary with key:value pairs to set the person properties
userPropertiesSetOnce: Optional. Similar to userProperties. See the difference between userProperties and userPropertiesSetOnce
You should call identify as soon as you're able to. Typically, this is after your user logs in. This ensures that events sent during your user's sessions are correctly associated with them.
When you call identify, all previously tracked anonymous events will be linked to the user.
Get the current user's distinct ID
You may find it helpful to get the current user's distinct ID. For example, to check whether you've already called identify for a user or not.
To do this, call distinctId(). This returns either the ID automatically generated by Leanbase or the ID that has been passed by a call to identify().
Alias
Sometimes, you want to assign multiple distinct IDs to a single user. This is helpful when your primary distinct ID is inaccessible. For example, if a distinct ID used on the frontend is not available in your backend.
In this case, you can use alias to assign another distinct ID to the same user.
We strongly recommend reading our docs on alias to best understand how to correctly use this method.
Anonymous and identified events
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
The Android SDK captures anonymous events by default. However, this may change depending on your personProfiles config when initializing leanbase:
personProfiles = PersonProfiles.IDENTIFIED_ONLY(recommended) (default) - Anonymous events are captured by default. leanbase only captures identified events for users where person profiles have already been created.personProfiles = PersonProfiles.ALWAYS- Capture identified events for all events.personProfiles = PersonProfiles.NEVER- Capture anonymous events for all events.
For example:
How to capture identified events
If you've set the personProfiles config to IDENTIFIED_ONLY (the default option), anonymous events are captured by default. Then, to capture identified events, call any of the following functions:
identify()alias()group()
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.
Setting person properties
To set properties on your users via an event, you can leverage the event properties userProperties and userPropertiesSetOnce.
When capturing an event, you can pass a property called userProperties as an event property, and specify its value to be an object with properties to be set on the user that will be associated with the user who triggered the event.
userPropertiesSetOnce works just like userProperties, except that it will only set the property if the user doesn't already have that property set.
Super Properties
Super Properties are properties associated with events that are set once and then sent with every capture call, be it a $screen, or anything else.
They are set using Leanbase.register, which takes a key and value, and they persist across sessions.
For example, take a look at the following call:
The call above ensures that every event sent by the user will include "team_id": 22. This way, if you filtered events by property using team_id = 22, it would display all events captured on that user after the leanbase.register call, since they all include the specified Super Property.
However, please note that this does not store properties against the User, only against their events. To store properties against the User object, you should use leanbase.identify. More information on this can be found on the Sending User Information section.
Removing stored Super Properties
Super Properties are persisted across sessions so you have to explicitly remove them if they are no longer relevant. In order to stop sending a Super Property with events, you can use Leanbase.unregister, like so:
This will remove the Super Property and subsequent events will not include it.
If you are doing this as part of a user logging out you can instead simply use Leanbase.reset which takes care of clearing all stored Super Properties and more.
Opt out of data capture
You can completely opt-out users from data capture. To do this, there are two options:
Opt users out by default by setting optOut to true in your leanbase config:
Opt users out on a per-person basis by calling optOut():
Similarly, you can opt users in:
To check if a user is opted out:
Flush
You can set the number of events in the configuration that should queue before flushing. Setting this to 1 will send events immediately and will use more battery. The default value for this is 20.
You can also configure the flush interval. By default we flush all events after 30 seconds, no matter how many events have been gathered.
You can also manually flush the queue:
Reset after logout
To reset the user's ID and anonymous ID, call reset. Usually you would do this right after the user logs out.
Group analytics
Group analytics allows you to associate the events for that person's session with a group (e.g. teams, organizations, etc.). Read the Group Analytics guide for more information.
Associate the events for this session with a group
Associate the events for this session with a group AND update the properties of that group
The name is a special property which is used in the Leanbase UI for the name of the group. If you don't specify a nameproperty, the group ID will be used instead.
Session replay
To set up session replay in your project, all you need to do is install the Android SDK, enable "Record user sessions" in your project settings and enable the sessionReplay option.
Offline behavior
The Leanbase Android SDK will continue to capture events when the device is offline. The events are stored in a queue in the device's file storage and are flushed when the device is online.
The queue has a maximum size defined by maxQueueSize in the configuration.
When the queue is full, the oldest event is deleted first.
The queue is flushed when the app is restarted and the device is online.
When you call flush() while the device is offline, it aborts early and the events are not flushed.
All configuration options
When creating the Leanbase client, there are many options you can set: