Klor and Statsig

Statsig is an experimentation platform. You define a metric, run a variant against it, and it does the statistics: sequential testing, confidence intervals, guardrail metrics, the whole apparatus. Feature gates and dynamic configs come along with it, but the reason to adopt Statsig is the experiment.

If your question is "did this change increase conversion", buy something that answers it. Klor cannot, and a page that implied otherwise would be wasting your afternoon.

This is a deliberate architectural limit, not a roadmap item. Measuring an experiment requires an exposure log: which user saw which arm, joined to what that user did next. That requires a stable per user identifier leaving the device.

Klor evaluates on the device precisely so that nothing about your users is ever transmitted. Adding experimentation would mean giving that up, and it is the single property that distinguishes the product. So Klor tells you which values it served and how often, with no identifier attached, and stops there.

You can still run an experiment. Klor assigns the variant, stably and on the device, and you send that assignment to whatever analytics you already pay for. The join happens in your warehouse, not in ours.

• Force update and blocked builds. Statsig has no concept of gating an old binary out of service; you would build it on a config value.
• Privacy as a property rather than a policy. No user context is sent to Klor at all, which is a claim you can verify by watching your app traffic.
• Offline. A device with a cached snapshot still evaluates rules correctly with no network, because the rules are on the device.
• Smaller surface. If you are not running experiments, most of Statsig is weight you carry and do not use.

This is a reasonable configuration and worth saying out loud: Klor for the config and the gating that has to work offline and must not leak anything, Statsig for the experiments you actively want measured. They do not conflict, and neither needs to own the other's values.