Home / Product / Experiments & flags
Ship it, roll it out, and find out if it worked.
Flags and experiments in the same place as the metrics they move. No exporting assignments into a second tool and hoping the two systems agree about who saw what.
Assignment
Deterministic, and identical in every SDK.
A user's variant is derived by hashing their identifier with the experiment key. The same person gets the same variant on web, on iOS, on your server — without a network call, and without a shared assignment database to go down.
The algorithm is specified in the documentation and covered by the same conformance suite that every SDK runs, so "it should match" is a tested claim rather than a hope.
// identical in all nine SDKs
bucket = hash(user_id + ":" + experiment_key)
variant = bucket % 100 < 50 ? "control" : "treatment"
// no network call, no shared state, no driftReadouts
A result that tells you how sure it is.
Exposure is tracked as an event, so the analysis runs on who actually saw the variant — not on who was theoretically eligible. The readout reports the difference, the interval around it, and whether the test has collected enough data to say anything yet.
If it has not, it says so. An experiment that has not reached a conclusion is a normal state, not a number to squint at.
| Variant | Users | Converted | Rate |
|---|---|---|---|
| control | 6,240 | 1,489 | 23.9% |
| treatment | 6,198 | 1,702 | 27.5% |
Feature flags
Roll out by percentage, kill instantly.
Ship code dark, enable it for one tenant, then five percent, then everyone — and turn it off in one click when the graph goes the wrong way. Flags are evaluated locally, so a flag check never adds latency to your request path.
The honest part
What this is not.
There is no sequential-testing or always-valid-inference engine yet, so peeking at a running experiment carries the usual risk of reading noise as signal. We say so in the product and in the docs rather than letting you learn it the expensive way.