Statsig

What is Statsig?

Statsig is a feature management and experimentation platform founded in 2020 by Vijaye Raji and team, engineers who built Facebook's internal A/B testing and feature flagging infrastructure. The company launched with the thesis that the statistical rigour available at companies like Meta, Google, and Airbnb should be accessible to every product team — not just those with 100-person data science teams.

Statsig's architecture is single-SDK: you instrument your product once and get feature flags, A/B experiments, and product analytics all from the same data stream. This is architecturally different from using LaunchDarkly for flags and Mixpanel for analytics — with Statsig, your experiment groups and your analytics segments are the same objects, eliminating the data joining that plagues multi-tool experimentation setups.

For Indian product teams, Statsig's free tier (1 million events/month) is exceptional — a 50K MAU app with 5 key events per user per day stays free at 7.5M events/month (barely over threshold). Many Indian Series A teams run Statsig entirely free for 12–18 months before outgrowing the event limit. The statistics layer (CUPED, sequential testing, Bonferroni) is available on the free tier, which is genuinely unusual in the experimentation tool market.

Key Features

Why Statsig Over LaunchDarkly for Most Indian Teams

Best For

• Indian Series A–B product teams wanting feature flags + A/B testing without paying for two tools
• Teams at <10M events/month where Statsig's free tier covers the entire experimentation stack
• Data-driven product teams who need proper statistical analysis (CUPED, sequential testing)
• Teams migrating from LaunchDarkly + VWO/Optimizely wanting to consolidate vendors
• Indian product teams wanting warehouse-native metrics connected to BigQuery or Snowflake

Pricing

Statsig charges per million events logged. USD billing — 18% GST reverse charge for Indian companies. 1 million events free per month, always.

Pros and Cons

Alternatives to Statsig

Getting Started with Statsig

1. Instrument your first 5 core events before creating any experiments — Statsig's power comes from connecting experiments to metrics. Before creating your first feature gate or A/B test, instrument your 5 most important product events: user_signed_up, onboarding_completed, first_transaction, session_started, and your primary retention event. These events become your experiment success metrics. Without them, your experiments can run but you can't measure whether they worked.
2. Create your metric library before your first experiment — In Statsig's Metrics section, define your key business metrics as reusable objects: D7 retention rate, signup-to-activation rate, average order value, KYC completion rate. Defining metrics once means every experiment references the same calculation — no inconsistency between "retention" meaning different things in different experiments. This is the most common statistical hygiene issue Indian teams skip when starting experimentation.
3. Use Layers for any experiment touching the same user flow — If you're running experiments on your onboarding flow, use a Statsig Layer to group them. Users in one onboarding experiment are excluded from others in the same Layer — preventing interaction effects that would invalidate your results. Teams that run multiple experiments on the same flow without Layers frequently get misleading results: an experiment appears to win because it happened to run concurrently with a losing experiment in the control group.
4. Set your experiment duration before launching, not after seeing results — Calculate your minimum detectable effect and required sample size before running an experiment. Stopping an experiment early because results look good (or bad) is peeking — it inflates false positive rates significantly. Statsig's sequential testing feature does allow valid early stopping, but requires enabling it before launch. Decide your stopping rules upfront, document them, and don't deviate — even when the CEO asks why the experiment is "still running."
5. Review your top 3 experiments monthly in a team ritual — Statsig experiments without a review ritual accumulate results that nobody acts on. Establish a monthly "experiment review" meeting where the product team walks through: experiments that concluded this month, what the results showed, and what product decision was made as a result. This ritual creates accountability for the experimentation programme and ensures that statistically significant results actually change product decisions — which is the only reason to run experiments in the first place.