For AI agents: a documentation index is available at /llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.
Winsorization
How Statsig applies winsorization to cap extreme metric values, reducing variance and stabilizing experiment results against influential outliers.
Winsorization caps a metric's extreme values at a percentile : Statsig measures the value of the metric and sets every unit-level value above to . This reduces noise from outliers in experiment results without dropping any units. Statsig Cloud winsorizes at the 99.9th percentile by default; Warehouse Native lets you set upper and lower bounds per metric. Use metric capping instead when you know the business maximum for a metric, such as a maximum purchase amount per day, rather than a percentile.
Statsig computes from all non-zero, non-null unit-level values of the metric, aggregated from rows or events. The value of the unit at is the threshold Statsig applies to the other units' values.
Default percentile and configurable bounds by deployment
In Statsig Cloud, the default percentile for winsorization is 99.9%. This default reduces the influence of extreme outliers caused by factors such as logging errors or bad actors.
Statsig applies winsorization to sum, event count, mean, ratio, and funnel metrics, including imported metrics. Winsorization doesn't apply to participation or user accounting metrics.
Metric capping
Metric capping handles outliers by setting a maximum value for a metric. You define the maximum for each unit type configured for that metric, and Statsig adjusts any value that exceeds the cap downward to the cap.
For example, if purchases greater than $10,000 per day shouldn't skew analysis, Statsig adjusts any transaction exceeding that threshold downward to $10,000. Statsig supports capped metrics for event count and aggregation (sum) metric types.
Was this helpful?