Analytics events

Read time: 3 minutes

Last edited: Mar 04, 2024

Overview

This topic explains analytics events, how SDKs send them to LaunchDarkly, and what features they are generated for.

Newer versions of LaunchDarkly SDKs replace users with contexts

A context is a generalized way of referring to the people, services, machines, or other resources that encounter feature flags in your product. Contexts replace another data object in LaunchDarkly: "users."

Creating contexts and evaluating flags based on them is supported in the latest major versions of most of our SDKs. For these SDKs, the code samples on this page include the two most recent versions.

Client-side and server-side SDKs send analytics events to LaunchDarkly as a result of feature flag evaluations and certain SDK calls. There are several kinds of analytics events.

Here is a list of analytics event kinds and their functions:

summary events describe a set of individual feature evaluations over an interval.
feature events include additional feature flag evaluation details for flags used in Experimentation and flags you enable detailed tracking for.
debug events describe feature flag evaluations when debugging mode is on.
migration_op events describe metrics collected as part of reading and writing migration flags.
index and identify events push context data to LaunchDarkly.
page view and click events are sent by JavaScript-based SDKs when pages are visited or clicked as part of an experiment.
custom events are sent when an application calls the SDK's track method.

Analytics events are crucial to the functioning of several features in LaunchDarkly.

Your network must be allowed to send events

For analytics events to reach LaunchDarkly, your network must be allowed to send events. Ensure that event streaming endpoints, mobile.launchdarkly.com and events.launchdarkly.com, are on your allow list. To learn more about how SDKs send events, read Recording events.

Here is a list of LaunchDarkly features that rely on analytics events:

Event buffering and sending

Server-side, client-side, and mobile LaunchDarkly SDKs automatically send pending analytics events to LaunchDarkly at regular intervals. This is called a flush interval. The buffer between flushes prevents the SDK from having to send constant network requests, and varies by SDK. By default, server-side SDK buffer time is usually a few seconds, and mobile SDK buffer time is around 30 seconds. A longer buffer time for mobile SDKs helps preserve the device's battery life, and events do not need to be flushed as often because events build up much more slowly for client-side SDKs with only a small number of contexts.

You can configure your SDK's buffer time between flushes.

Configure your SDK: Configuration

Manually calling flush

You can manually call flush to send events immediately without waiting for the next interval. Most customers do not need to use the manual flush feature, but it can be useful if you test the SDK in a simulator.

Try it in your SDK: Flushing events

Shutting down your SDK

You will not need to manually shut down your SDK in most situations. However, if your app dies while there are still events in the buffer, the SDK discards them. If you know your application is about to terminate, or if you're testing an app, you should manually shut down the LaunchDarkly client before quitting to ensure it delivers any pending analytics events to LaunchDarkly.

Try it in your SDK: Shutting down

Disabling SDKs from sending events

You can disable SDKs from sending events for testing purposes. To learn more, read Managing test data in your production environment.

Disable sending events only for testing purposes

You can disable SDKs from sending events, but we strongly recommend against it outside of testing purposes. Many LaunchDarkly features will not work correctly if they do not regularly receive analytics events.