First steps with bitdrift¶
After you follow the Quick start guide to successfully integrate the application into bitdrift, this gets you well on your way to see data and begin your bitdrift journey. There are a few things to consider, to make the product more valuable from the start.
Forward your existing events/logs¶
Logging libraries integration¶
Generally app developers have logging frameworks in place for their app already, and most times these are disabled when the application is released to the public, as those events are not really accessible to the app developer/operator. This is not the case with bitdrift, as we enable Recording sessions back to bitdrift SaaS.
Therefore the recommended approach is to integrate your logging framework with bitdrift and ensure those events are collected by the SDK. If a logging framework is not currently used, we suggest you implement one or use the Capture SDK log methods to and forward the logs via the integration provided in the bitdrift SDK.
Analytics Event integration¶
Frequently app operators will have an analytics framework (or several of them) in use through out the app for different purposes. Those events, while they flow into their respective solutions, can also be very valuable when creating Workflows in bitdrift to capture situations that users face in the app. We suggest that you emit those events into bitdrift using the Logger and labeled approprieately using the fields that can be attached to each log message so they can be easily recognized and matched on.
Registering screen navigation with the bitdrift Logger¶
bitdrift enables you to register Screen navigation events with the product, which then shows them in the Timeline view and gives you the ability to leverage them in User Journey Diagrams in bitdrift or simply match on them in workflows.
Labeling events using fields¶
bitdrift gives you a few different ways to attach metadata to the events that are emitted. The main options available are Global fields and Custom fields. Lets see what the differences are and why they are best used.
Global fields usage¶
The Global fields construct is generally defined at SDK Initialization and those fields will be attached to any event that is emited in the app lifecycle there after. This is extremely useful, when as a developer you want to distinguish different user sessions based on their user_id
, experiment label, feature flag, etc
As the set of these fields sometimes does need to change throughout the lifecycle of the app, you are also given an option to add/remove fields through the app lifecycle to correctly represent the user state
A great example: When the app is open and the SDK is initialized, the user is possibly not yet logged in on first start. When the user successfuly logs in, you can add the user_id
field to the Global fields
Custom fields usage¶
Custom fields are only added to the the single event where their value was specified when invoking the Logger. They can be used used for matching or grouping.
Formating events - best practices¶
When emitting events into the bitdrift SDK, it's highly recommended you make use of global or custom fields for metadata instead of putting information into raw log messages. This enables you to use the custom fields in matchers and Plot charts for matching and potential histogram or Average calculation in workflow charts.
When following the above recommendation you can match fields without having to use regular expression matching. Additionally, you can leverage emiting full JSON payloads into fields and the UI will prettify the data for east of consumption.
Network integration¶
It is always recommended you enable the network integration as this will enable the users to match on network requests and responses and their metadata (succes/failure, response time, response code) in both match nodes and Plot charts. It will also populate the Network
tab of the Instant insights view.
The instrumenation is supported via a few different ways (OkHttp
via our gradle plugin on Android and URLSession
via swizzling on iOS) however there are also manual ways to configure the integration if the app has constraints on the network stack or swizzling is not prefered.
Tracking/emitting metrics in bitdrift¶
bitdrift enables you to use global or custom fields to attach information to log messages. That can also be metrics that are calculated or measured by the app instance while the users use it.
Tracking app Time to Interactive
¶
The bitdrift SDK enables you to invoke Logger.AppLaunchTTI()
with the measured Time To Interactive. This will enable you to use that metric in Matchers and Plot charts and automatically populate the Instant Insights UX chart that displays the histogram of the metric across the whole app population.