Statsig

Statsig — built by a team from Facebook’s experimentation culture and acquired by OpenAI in late 2025, under which it continues to operate as a product serving external customers — treats every feature gate as a potential experiment. If vendor ownership matters to your event-data governance review, note that the acquirer is an AI lab; the product itself and its data-handling terms remain separately contracted. Flag exposures are logged as events on the same stream as your analytics, and Pulse automatically computes each rollout’s impact on your metrics — so shipping behind a gate produces an experiment readout whether or not you formally designed one. Product analytics (metrics, funnels, retention) and session replay ride the same stream.

Implementation splits cleanly by SDK type, and the split matters. Server SDKs (Node, Java, Python, Go, Ruby, PHP, Rust, .NET) download your project’s full ruleset and evaluate gates locally with no network request per check, polling Statsig for rule updates every 10 seconds by default. Client SDKs (JavaScript, React, React Native, Next.js, Swift, Android, and others) work the other way around: Statsig precomputes every evaluation for the current user server-side and ships the results down, so a gate check is a dictionary lookup and config names are obfuscated in the payload. Two gotchas fall out of this. First, client-side configuration persists until the next initialize or updateUser call — if user attributes change mid-session and you don’t re-fetch, targeting is stale. Second, server SDKs receive the definitions of all configurations in the project, so anything sensitive in rule values is visible to any service holding a server secret key. Exposure events are batched (roughly every 10 seconds on clients, 60 seconds on servers by default), which is worth knowing when debugging “missing” exposures.

For teams that cannot ship raw events to a vendor, warehouse-native mode runs the experimentation compute jobs directly inside your own Snowflake, BigQuery, Databricks, Redshift, or Athena, using datasets you already have — intermediate tables and results stay in your warehouse, and every query is auditable there. Statsig’s cloud remains the control plane (experiment setup, targeting, SDK management); data only transits Statsig’s infrastructure if you opt into its real-time logging for faster diagnostics, and you can instead log assignments straight to the warehouse. Warehouse-native also accepts assignment data from third-party or internal experimentation systems, which makes it a practical migration path: point it at your existing assignment tables and get its stats engine before (or without) ever adopting Statsig’s SDKs.

Pricing meters analytics events — exposures, logged events, ingested metrics — while flag and config checks are unlimited on every tier, which keeps pure feature-flagging cheap at any scale. The free tier covers 2M events and 50K session replays a month with 1-year retention; Pro starts at $150/month with 5M events included; warehouse-native deployment is an enterprise-tier feature, so the privacy-first architecture comes with a sales conversation.

Use it when an engineering org wants rollout-by-default experimentation with automated analysis, warehouse-native stats without building the engine, or a stats engine layered over an existing homegrown assignment system. Look past it when you want open-source and fully self-hosted, or when marketers need visual-editor web testing rather than SDK-driven flags.