Skip to main content
Events are the main way to record data for Confidence Cloud. An event records something that a user does or that happens in your product, such as a page view, a purchase, or a crash. Confidence uses events to back fact tables and metrics for your experiments. Event tracking has two parts:
  1. Send events to Confidence. Your application calls track on a Confidence SDK.
  2. Set up an event schema. Confidence stores an event only when an event definition with a matching name and schema exists.
You can define the schema in advance, or send events first and then review and create the event from the detected schema. After you create the event, Confidence records the events.
Application events are different from apply events. SDKs send apply events automatically when your application uses a flag. You send application events explicitly with track.

SDK Support

Events authenticate with the same client credentials that the SDK uses to resolve flags.

JavaScript (Web)

OpenFeature Provider

The Confidence OpenFeature provider for web browsers implements the OpenFeature tracking API. Call track on the same OpenFeature client that you use for flags.
Tracking in the web provider requires @openfeature/web-sdk 1.3.0 or later and @spotify-confidence/openfeature-web-provider 0.3.22 or later, with a matching version of the @spotify-confidence/sdk peer dependency.

Confidence SDK: track(name, data?)

The @spotify-confidence/sdk package exposes track on any Confidence instance. The SDK appends the context set on the instance to each event.
Confidence plans to retire the standalone Confidence class. For new integrations, use the OpenFeature provider.

Confidence SDK: track(manager)

Pass a tracking manager instead of an event name to track data automatically. The web SDK includes these managers:

Event Payload

The web provider builds the payload from two sources:
  • Tracking details. The object you pass to track becomes top-level fields in the payload.
  • Evaluation context. The provider adds the current evaluation context under a context field. It renames targetingKey to targeting_key and converts Date values to ISO 8601 strings.
The OpenFeature example produces this payload:
The provider reserves context for the evaluation context and ignores a tracking detail named context.

Batches and Delivery

track returns immediately and doesn’t report whether Confidence accepted the event. The SDK queues events in memory and sends them in batches.
  • Rejected events. The SDK logs a warning and doesn’t resend them.
  • Network errors, server errors, and HTTP 429. The SDK retries the batch with increasing delays, from 5 seconds up to 5 minutes. It stops retrying 30 minutes after the first try and drops the batch.
  • Other request errors, such as an invalid client secret. The SDK logs an error and drops the batch.
  • Page hidden. The SDK tries to send up to 25 queued events with the browser sendBeacon API.
The queue exists only in memory. When the page closes, you lose events that haven’t reached Confidence.

Swift

See the iOS SDK reference for provider setup.

Android (Kotlin)

See the Android SDK reference for provider setup.

Flutter

See the Flutter SDK reference for setup.

Unity and .NET

Go

The Go SDK Track returns a *sync.WaitGroup.

Java

JavaScript (Server)

Python

Rust

Ruby

The provider also has a track! method with the same parameters.

Event Schema

An event definition names an event type and describes its payload with a schema. The event name in track must match the event definition name. Event definition names use lowercase letters, digits, and hyphens, and are 4 to 63 characters long, for example checkout-completed.

Define the Schema in Advance

  1. In the sidebar, select Events and click Create. The Create event dialog opens.
  2. Enter the event name.
  3. Edit the Schema to add fields. Set the field that identifies the user, such as context.targeting_key, to type String with semantic type Entity.
Every event needs at least one entity field. Without one, Confidence generates no fact table for the event.

Send Events First, Then Create the Event

  1. Send the event from your application.
  2. Confidence rejects events with no matching definition, detects a schema from the payload, and lists the event in the Events table as Sent but not stored.
  3. In the event’s row, click the outlined Create.
  4. Review the schema. Set at least one String field to semantic type Entity.
  5. Click Create.
Confidence stores events of this type from then on.

Schema Changes

  • Fields missing from the schema. Confidence drops fields that aren’t in the schema and accepts the rest of the event. The event page shows a warning. Click Update in the warning to add the fields. Confidence doesn’t recover values it dropped before the update.
  • Wrong field types. Confidence rejects the event and counts it as a validation failure.
  • Type changes. You can’t change a field’s name or type after you save it. Create a new event definition instead.

Verify That Events Arrive

After your application starts sending an event:
  • The Events page shows a status icon for each event type that indicates when the event last received data.
  • The event page shows a Usage chart with hourly counts of published events and validation failures.
  • A missing-fields warning on the event page means clients send fields that Confidence drops.
  • Events with no definition appear as Sent but not stored.
These views show counts and status, not individual events. If you use your own warehouse, query the tables that your event connector writes.

Fact Tables

Turn event data into metric sources

Event Connectors

Export events to your own warehouse

Evaluation Context

Configure the context that SDKs attach to events

Apply Events

Understand automatic flag assignment tracking