Streaming Data Export schema reference

Overview

This topic explains the schema of Data Export events.

Data Export exposes the following kinds of events:

• feature events
• index events
• identify events
• click events
• page view events
• custom events
• summary events. To export summary events, start a Support ticket.
• debug events

LaunchDarkly no longer supports alias events for SDKs that support contexts. LaunchDarkly continues to support sending and receiving alias events for older SDK versions and for SDKs that do not yet support contexts. For a list of SDKs that still support alias events, read Aliasing users.

Some Data Export destinations have different event formatting schema. If you use mParticle or Segment as your event destination, we have specific documentation for their event schema:

• mParticle schema reference
• Twilio Segment schema reference

These events are described in more detail below.

Event kinds

This table lists event kinds:

SDK versioning for events

Newer SDKs generate the summary and index events described below. Older SDKs always send feature events regardless of whether detailed tracking is enabled for that flag.

Newer SDKs send contextKeys and context as objects inside feature and custom events. Older SDKs send user or userKeys objects instead.

Event kind structures

LaunchDarkly sends each of these events as JSON files to your destinations.

All events have the following top level structure:

1
{
2
  "project": "5744c96707c9900708000004",
3
  "environment": "578d1e02d2943862c52b9686",
4
  "event": {"id": "abc123xyz", ...},
5
  "version": 2,
6
}

• project: The ID of the LaunchDarkly project associated with the event.
• environment: The ID of the LaunchDarkly environment associated with the event.
• version: The Data Export event version.
• event: The event itself. It is an object with a structure described below, depending on the kind of event.
  • id: Each event has a unique ID generated at export time. Due to Data Export’s delivery guarantee model it is possible for an event ID to be delivered more than once, so we do not recommend relying exclusively on these IDs for de-duplication.

Feature events

Feature events represent individual flag evaluations and are considered “full fidelity” events. Feature events are only sent by the SDK in one of these scenarios:

• the trackEvents or trackEventsFallthrough attribute on the flag configuration is sent
• the trackEvents attribute on a targeting rule is sent
• the targeting rule or default rule when on has a rollout of kind "experiment" and the variation associated with the event is included in the tracked variations for that rollout

Here is an example feature event:

1
// this example is from Data Export event schema version 2
2
{
3
    "kind": "feature",
4
    "id": "abc123xyz",
5
    "creationDate": 1462220944000,
6
    "contextKeys": {
7
      "user": "example-context-key"
8
    },
9
    "context": {
10
      "key": "example-context-key",
11
      "kind": "user",
12
      "name": "Sandy"
13
    },
14
    "key": "flag-key",
15
    "value": ["evaluation", "result"],
16
    "default": null,
17
    "version": 1,
18
    "variation": 0,
19
    "prereqOf": "upstream-key",
20
    "reason": {
21
        "kind": "RULE_MATCH",
22
        "ruleIndex": 0,
23
        "ruleId": "id",
24
        "inExperiment": true,
25
        "bigSegmentsStatus": "HEALTHY"
26
    },
27
    "samplingRatio": 10
28
}

Here is a list of feature event properties:

• kind: The kind for a feature event is feature. An SDK only generates a feature event if the you set the trackEvents attribute of the flag to true. You can also control this with settings in the UI.
• creationDate: When the SDK requested the feature flag, as UNIX epoch time in milliseconds.
• key: The key of the feature flag requested.
• variation: The variation of the flag requested. The SDK stores flag variation values in an array. This value corresponds to the index of the variation the array. Boolean flags show as 0 or 1 for true and false. For other flags, the array index starts at 0 for the different variations.
• variationName: The evaluated variation’s name, if it exists. If the evaluated variation doesn’t have a name, this field doesn’t appear.
• value: The value of the feature flag returned by feature flag evaluation.
• default: The default value that the application passed in.
• version: The version of the evaluated feature flag.
• reason: (Optional) Included only if the flag being evaluated was in an experiment and the target was part of the experiment allocation, or if you called a variation detail method.
  • Evaluations that were part of an experiment have the optional inExperiment attribute on the evaluation reason set to true. Evaluations that were not part of an experiment omit this attribute.
  • If you called a variation detail method, the reason property will be a JSON representation of the evaluation reason.
• prereqOf: A feature flag key, if this flag evaluation was only performed in order to determine whether the prerequisite values were met for the indicated flag.
• contextKeys: The keys of the context object used in a feature flag evaluation. SDKs periodically transmit details for the context object used in a feature flag evaluation as reported by the feature event with a separate index event.
• context: The context object used in a feature flag evaluation.
• userKey: The key of the user object used in a feature flag evaluation. SDKs periodically transmit details for the user object used in a feature flag evaluation as reported by the feature event with a separate index event. Not included if your SDK configuration is set to inline users. Not included if your SDK supports contexts.
• user: The user object used in a feature flag evaluation. Only included if your SDK configuration is set to inline users. Not included if your SDK supports contexts.

Index events

Server-side SDKs send index events periodically to describe the attributes of contexts referenced by the contextKey in feature events.

An example index event is shown below:

1
// this example is from Data Export event schema version 2
2
{
3
  "kind": "index",
4
  "id": "abc123xyz",
5
  "creationDate": 1462220944000,
6
  "context": {
7
    "key": "example-context-key",
8
    "kind": "user",
9
    "name": "Sandy Smith",
10
    "jobFunction": "doctor",
11
    "moreComplex": {
12
      "city": "Springfield",
13
      "moreThanOne": [1, 2, 3]
14
    }
15
  }
16
}

Here is a list of index event properties:

• kind: The kind of an index event is index.
• creationDate: The time this context was recorded at UNIX epoch time in milliseconds.
• context: The same schema as context objects for feature flag evaluation.
• userKey: The same schema as userKey for feature flag evaluation. Not included if your SDK configuration is set to inline users. Not included if your SDK supports contexts.
• user: The same schema as user objects for feature flag evaluation. Only included if your SDK configuration is set to inline users. Not included if your SDK supports contexts.

Client-side SDKs do not send index events. Instead, client-side SDKs send identify events when the SDK initializes, which include all of the context properties.

Identify events

identify events are produced when the client application calls the identify SDK method. identify events have a similar structure to index events.

An example identify event is shown below:

1
// this example is from Data Export event schema version 2
2
3
{
4
  "kind": "identify",
5
  "id": "abc123xyz",
6
  "creationDate": 1462220944000,
7
  "context": {
8
    "key": "example-context-key",
9
    "kind": "user",
10
    "name": "Sandy Smith",
11
    "jobFunction": "doctor",
12
    "moreComplex": {
13
      "city": "Springfield",
14
      "moreThanOne": [1, 2, 3]
15
    }
16
  }
17
}

Here is a list of identify event properties:

• kind: The kind of an identify event is identify.
• creationDate: The time this context was recorded at UNIX epoch time in milliseconds.
• context: The same schema as context objects for feature flag evaluation.
• userKey: The same schema as userKey for feature flag evaluation. Not included if your SDK configuration is set to inline users. Not included if your SDK supports contexts.
• user: The same schema as user objects for feature flag evaluation. Only included if your SDK configuration is set to inline users. Not included if your SDK supports contexts.

Click events

JavaScript-based SDKs produce click events when an end user clicks on an HTML element matching a CSS selector configured on an experiment metric. To learn more, read Clicked or tapped conversion metrics.

An example click event is shown below:

1
// this example is from Data Export event schema version 2
2
3
{
4
  "kind": "click",
5
  "id": "abc123xyz",
6
  "key": "<internal id, not used>",
7
  "url": "https://example.com/",
8
  "creationDate": 16420388151234,
9
  "selector": "button.click-track",
10
  "contextKeys": {
11
    "user": "Sandy",
12
    "anonymousUser": "123213421231"
13
  }
14
}

Page view events

JavaScript-based SDKs produce pageview events when an end user loads a page with URL matching a regular expression configured on an experiment metric. To learn more, read Page viewed conversion metrics.

An example pageview event is shown below:

1
// this example is from Data Export event schema version 2
2
3
{
4
  "kind": "pageview",
5
  "id": "abc123xyz",
6
  "key": "<internal id, not used>",
7
  "url": "https://example.com/",
8
  "creationDate": 16420388151234,
9
  "contextKeys": {
10
    "user": "Sandy",
11
    "anonymousUser": "123213421231"
12
  }
13
}

Custom events

SDKs produce custom events:

• when your application calls any of the SDK’s track* methods
• automatically when the SDK is initialized, when an error occurs, and when other web vitals occur, if you are using an observability SDK

Try it in your SDK: Sending custom events

An example custom event is shown below. The metricValue field will not appear if the event did not provide a metric value.

1
// this example is from Data Export event schema version 2
2
3
{
4
  "kind": "custom",
5
  "id": "abc123xyz",
6
  "key": "example-event-key",
7
  "creationDate": 16420388151234,
8
  "data": { "arbitrary": "customer-provided-data" },
9
  "metricValue": 5.3,
10
  "samplingRatio": 10,
11
  "contextKeys": {
12
    "user": "example-context-key"
13
  },
14
  "context": {
15
    "key": "example-context-key",
16
    "kind": "user",
17
    "name": "Sandy"
18
  }
19
}

If the custom events are generated by your application when it calls an SDK’s track method, then the data field will include the information that you pass to the track call.

If the custom events are generated by LaunchDarkly, for example if you are using a LaunchDarkly observability SDK, then the data field will have a specific structure. For instance, in custom events that are automatically created by LaunchDarkly because of an error, the data field is a JSON object that always includes a sessionId.

Summary events

SDKs send summary events periodically to describe a set of feature evaluations. Summary events include all feature evaluations, regardless of whether the trackEvents field was set for individual flags. They are sent when events are flushed, or during the configured flush interval. To learn more, read Event buffering and sending.

An example summary event is shown below:

1
// this example is from Data Export event schema version 2
2
3
{
4
  "kind": "summary",
5
  "id": "abc123xyz",
6
  "startDate": 1517350765387,
7
  "endDate": 1517350825243,
8
  "features": {
9
    "example-flag-key": {
10
      "default": true,
11
      "counters": [
12
        {
13
          "value": true,
14
          "count": 10,
15
          "version": 3
16
        }
17
      ],
18
      "contextKinds": ["user", "device"]
19
    }
20
  }
21
}

The summary event represents a set of feature flag evaluations occurring during an interval defined by startDate and endDate, sorted by feature flag.

Each feature flag includes the following details:

The counters field is an array of objects with the following contents:

Debug events

The debug event is a variant of the feature event, with two differences. It has kind set to debug and it inlines the context value. The information can help you to troubleshoot feature flag evaluations more quickly.

SDKs send debug events only if the debugEventsUntilDate attribute is set for a feature flag and the attribute indicates a UNIX epoch timestamp in milliseconds that has not yet elapsed.

To set the debugEventsUntilDate attribute for a feature flag, navigate to the Live events page. Find a summary event for the flag you are interested in and click Full fidelity details.

debug events are not controlled by the trackEvents field.

Here is an example debug event:

1
// this example is from Data Export event schema version 2
2
3
 {
4
    "kind": "debug",
5
    "id": "abc123xyz",
6
    "context": {
7
      "key": "example-context-key",
8
      "kind": "user",
9
      "name": "Sandy"
10
    },
11
    "creationDate": 1462220944000,
12
    "key": "example-flag-key",
13
    "value": false,
14
    "default": false,
15
    "version": 42,
16
    "prereqOf": "parent-flag-key-456def"
17
  }

Here is a list of the debug event properties:

• kind: The kind of a debug event is debug.
• context: The same schema as context objects for feature flag evaluation.
• creationDate: When the SDK requested the feature flag, as UNIX epoch time in milliseconds.
• key: The key of the feature flag requested.
• value: The value of the feature flag returned by feature flag evaluation.
• default: Optional. This will be true if the feature flag evaluation failed and the SDK served the fallback value instead. This field will be false or omitted if the SDK did not serve the fallback value.

Try it in your SDK: Evaluating flags