Statsig experimentation and feature gates
Statsig is a commercial experimentation platform that combines feature gates and dynamic configs with built-in metric computation. It logs exposure events when a unit sees a gate or experiment and evaluates configured metrics against those exposures. This page describes its data model and privacy posture even-handedly, without ranking it.
What this means
Statsig provides feature gates, dynamic configuration, and experiments under a shared logging model. When an SDK evaluates a gate or experiment for a unit, it logs an exposure event recording which variation that unit received.
Metrics are then computed by joining those exposures to event data, so the platform can attribute outcome changes to the gate or experiment that produced them. The unit of analysis (user, device, or custom) is configurable.
Data model and posture
The two core record types are exposure events (unit saw variation X) and the metric events used to evaluate impact. Deterministic assignment from the unit's hash keeps a unit on the same variation without a separate persisted vendor cookie in many SDK setups.
Because exposures bind an identifier to a variation, the privacy posture depends on which identifier you pass and your consent handling. Warehouse-export options let some teams keep analysis data in their own environment.
- Feature gates, dynamic configs, and experiments
- Exposure events record which variation a unit saw
- Metrics computed by joining exposures to events
- Identifier choice and consent shape the posture
How it appears in analytics and logs
Statsig in an app means SDKs are evaluating gates and logging exposure events. A user not seeing a feature usually reflects gate rules, not a measurement bug.
Diagnostic use case
Use Statsig to gate features and run experiments where exposure logging and metric analysis are handled in one platform rather than stitched together by hand.
What WebmasterID can help detect
WebmasterID's first-party events can serve as outcome metrics that an experimentation tool evaluates, keeping the measured outcomes in data you control.
Common mistakes
- Comparing results across mismatched assignment units.
- Ignoring sample-ratio mismatch warnings on exposures.
- Passing a more identifying key than consent supports.
Privacy and accuracy notes
Exposure logs tie a unit identifier to which gate or variation it saw, so identifier choice and consent govern the privacy surface. This is educational, not legal advice.
Related pages
- GrowthBook (open-source experiments)
GrowthBook is an open-source platform for feature flags and A/B experimentation that is warehouse-native: rather than collecting its own event stream, it queries metrics from your existing data warehouse to evaluate experiments. This page describes its data model and privacy posture even-handedly, without ranking it against other tools.
- Eppo warehouse-native experimentation
Eppo is a commercial experimentation platform built to be warehouse-native: rather than collecting its own event stream, it runs experiment analysis directly against metrics in your data warehouse. It supports randomization and statistical methods including variance-reduction techniques. This page describes its model and privacy posture even-handedly.
- LaunchDarkly feature management
LaunchDarkly is a commercial feature-management platform centered on feature flags and progressive delivery, with experimentation available on top. SDKs evaluate flags for a context and can log events to measure flag impact. This page describes its data model and privacy posture even-handedly, with no ranking against other tools.
- Event Explorer
Inspect the events used as experiment metrics.
Sources and verification notes
- Statsig — DocumentationVendor docs for gates, configs, and experiments.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.