---
title: Statsig events in Amplitude
description: "Reference for the exposure and custom events the Statsig Amplitude Native integration forwards into an Amplitude project, including every event property it sets."
product: data
lang: en
last_updated: 2026-11-11
token_estimate: 1981
---
# Statsig events in Amplitude

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.

> For AI agents: a documentation index is available at [/docs/llms.txt](/docs/llms.txt). Append `.md` to any page URL for markdown, or send `Accept: text/markdown`.

You configure the integration in Statsig, not in Amplitude. For the setup steps, refer to [Amplitude Native](https://docs.statsig.com/integrations/data-connectors/amplitude/native) in the Statsig documentation.

> **Note:** 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](https://amplitude.com/docs/data/create-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 |

> **Note:**
>
> 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)](https://amplitude.com/docs/data/destination-catalog/statsig) destination do count toward event volume.