How Metrics Work on Statsig

How metrics work on Statsig

A metric in Statsig is a numeric value that Statsig tracks for each user on a given day. You aggregate this value across your entire user base or a subset, such as the test or control group of an experiment, to measure how your product performs. Statsig's Stats Engine joins these metrics with your exposure events to compute experiment results and analytics.

For example, say one user made two purchases on September 1st, and another made only one. You can aggregate these values across multiple users to calculate the total number of purchases across all users on September 1st.

By default, Statsig computes metrics from logged raw events in the production environment. When testing experiments in lower environments (such as development or staging) with Enable for Environments, you can track cumulative exposures and metric results from those environments. Tracking lower-environment data lets you validate your experiment setup before launching to production. Statsig prioritizes production data for final Pulse result analyses.

Sources of Statsig metrics

There are two fundamental sources of metrics in Statsig:

1. Raw Events
   • Statsig auto-generates certain metrics such as event_count and user accounting metrics from these events.
   • You can also define custom metrics using your logged raw events.
2. Precomputed Metrics: You can provide these pre-computed values to Statsig.

Statsig's Stats Engine joins these metrics with your exposure events from feature gates and experiments to compute experiment results and analytics.

Delayed and backfilled data

Statsig Cloud computes metrics once per day, using the raw events ingested by the time that day's computation runs.

If events for a given day arrive after that day's computation has already run, Statsig doesn't automatically include them in the already-computed metric value. Statsig doesn't update the stored metric for that day to reflect late-arriving data.

To get the most accurate metric results, send events as close to when they occur as possible. Use timestamps that reflect the actual event time. Don't stamp events with a past date or time when ingesting them.

Reprocessing or backfilling delayed data isn't a standard Cloud capability. Enterprise customers using specific import-based ingestion setups have more flexibility to retrigger computation for affected days. Contact your account team to learn whether this applies to your setup.

This behavior applies to Statsig Cloud. Warehouse Native handles data timing differently; refer to About Warehouse Native for details.