Statsig events in Amplitude

Early Access

This feature is in Early Access. During this time, aspects of the functionality may still be developed, and this documentation may not always be up to date. If you have any questions, contact Amplitude Support.

The Statsig Amplitude Native integration forwards Statsig exposures and custom events into a linked Amplitude project, where the forwarded events behave like any other Amplitude event. This page lists the events that arrive, the properties on each one, and the behavior that makes forwarded counts differ from the counts Statsig reports.

You configure the integration in Statsig, not in Amplitude. For the setup steps, refer to Amplitude Native in the Statsig documentation.

Availability

Amplitude Native isn't enabled for every account. Contact your Statsig or Amplitude account team to request access.

Forwarded events

Statsig forwards exposures under reserved event names and leaves custom event names unchanged.

Event	Statsig source
`statsig::gate_exposure`	Statsig evaluated a feature gate for a user
`statsig::experiment_exposure`	Statsig evaluated an experiment or an autotune for a user
`statsig::config_exposure`	Statsig evaluated a dynamic config for a user
`statsig::layer_exposure`	Statsig evaluated a layer for a user
`statsig::holdout_exposure`	Statsig evaluated a holdout for a user

Experiment exposures and autotune exposures share the statsig::experiment_exposure name. Use the statsig::config property to separate them.

Custom events keep the names they have in Statsig. An event called checkout_started in Statsig arrives in Amplitude as checkout_started, with no prefix. The forwarded event looks the same as an event sent directly to Amplitude.

Forwarded events arrive as unexpected events because they aren't in your tracking plan. Add the events you plan to chart to the tracking plan so they carry the same descriptions and governance as your other events. For the procedure, refer to Create a tracking plan.

Gate exposure properties

statsig::gate_exposure carries these properties.

Property	Type	Description
`statsig::gate`	Any	Name of the evaluated feature gate
`statsig::gateValue`	Any	Value the gate returned for this user
`statsig::ruleID`	String	ID of the rule that matched
`statsig::ruleName`	String	Name of the rule that matched
`statsig::reason`	String	How the SDK resolved the value, such as from the network or from cache
`statsig::idType`	String	Unit ID type the evaluation used
`statsig::isHoldout`	Any	Whether a holdout applied to this evaluation
`statsig::isSecondaryExposure`	Any	Whether this exposure came from a nested evaluation rather than a direct check
`statsig::keyEnvironment`	String	Environment of the SDK key that logged the exposure
`statsig::sessionID`	String	Statsig session identifier
`statsig::tier`	String	Environment tier reported by the SDK
`statsig::is_bot`	Boolean	Whether Statsig tagged the traffic as a bot
`statsig::configVersion`	String	Version of the config specification the SDK evaluated
`statsig::lcut`	String	Timestamp of the last config update the SDK had
`statsig::languageVersion`	String	SDK language and runtime version
`statsig::serverTime`	Any	Server timestamp for the evaluation
`statsig::receivedAt`	String	Timestamp when Statsig received the event
`statsig::initTime`	Any	Timestamp when the SDK initialized
`statsig::configSyncTime`	Any	Timestamp of the SDK's most recent config sync
`statsig::bootstrapMetadata`	String	Metadata about the bootstrap payload, on bootstrapped clients

Experiment exposure properties

statsig::experiment_exposure carries these properties.

Property	Type	Description
`statsig::config`	String	Name of the evaluated experiment or autotune
`statsig::groupID`	String	ID of the assigned variant
`statsig::groupName`	String	Name of the assigned variant
`statsig::ruleID`	String	ID of the rule that matched
`statsig::ruleName`	String	Name of the rule that matched
`statsig::reason`	String	How the SDK resolved the value, such as from the network or from cache
`statsig::idType`	String	Unit ID type the evaluation used
`statsig::keyEnvironment`	String	Environment of the SDK key that logged the exposure
`statsig::sessionID`	String	Statsig session identifier
`statsig::tier`	String	Environment tier reported by the SDK
`statsig::is_bot`	Boolean	Whether Statsig tagged the traffic as a bot
`statsig::configVersion`	String	Version of the config specification the SDK evaluated
`statsig::lcut`	String	Timestamp of the last config update the SDK had
`statsig::languageVersion`	String	SDK language and runtime version
`statsig::receivedAt`	String	Timestamp when Statsig received the event
`statsig::bootstrapMetadata`	String	Metadata about the bootstrap payload, on bootstrapped clients

Dynamic config, layer, and holdout exposures carry the same properties. Only the property that names the evaluated object changes, to match the object type.

Duplicated properties

Several diagnostic fields arrive twice, once under a statsig:: prefix and once without it. Both copies hold the same value. Prefer the prefixed copy, which Statsig sets consistently across every exposure type.

Unprefixed property	Prefixed equivalent	Appears on
`bootstrapMetadata`	`statsig::bootstrapMetadata`	Gate and experiment exposures
`lcut`	`statsig::lcut`	Gate and experiment exposures
`receivedAt`	`statsig::receivedAt`	Gate and experiment exposures
`configSyncTime`	`statsig::configSyncTime`	Gate exposures
`initTime`	`statsig::initTime`	Gate exposures
`isSecondaryExposure`	`statsig::isSecondaryExposure`	Gate exposures
`serverTime`	`statsig::serverTime`	Gate exposures

Statsig hasn't settled which of these properties it keeps. Build charts and cohorts on the statsig:: properties.

Why exposure counts differ from Statsig

Exposure counts in Amplitude don't match the counts in Statsig Metrics Explorer, for two reasons:

One exposure per identity per day: Statsig forwards only the first exposure it records for each identity and configuration each day, not every exposure.
UTC day boundaries: The daily window resets at midnight UTC, not in your Amplitude project's configured timezone.

If you change a dynamic config's targeting so a user matches a different rule, Statsig records a new exposure. The same user can then produce a second forwarded exposure on the same day.

Identity resolution

Statsig forwards only events tied to an Amplitude user_id or device_id. Amplitude drops events whose Statsig identity uses another unit ID, such as companyID.

Unlike the Statsig event-streaming destination, Amplitude Native doesn't promote a Statsig stableID into the Amplitude user_id field. A Statsig stableID maps to device_id instead.

Device and location properties

Statsig resolves device and location dimensions itself before forwarding. Operating system, browser, device model, country, region, and city can hold different values than Amplitude resolves for the same user from its own SDK traffic. Forwarded events keep the Statsig values.

Event volume

Amplitude doesn't count events arriving through Amplitude Native toward your event volume. Statsig events that reach Amplitude through the Statsig (Event Stream) destination do count toward event volume.

Was this helpful?