Experiment Quality Score

The Experiment Quality Score is a metric designed to get a sense for the quality of an experiment configured within Statsig. It helps experimenters quickly identify potential issues in experiment setup, execution, and data collection, ensuring more confident decision-making. Measuring this over a number of experiments can help measure improvements in maturity over time.

Learn more about enabling and configuring it here. This is rolling out now.

🟢 Node Server Core SDK

Server Core is a full rewrite of our Server SDKs with a shared, performance-focused Rust library at the core - and bindings to each other language you'd like to deploy it in. Today, we're launching Node Server Core (Node Core).

Performance & functionality exclusive to Server Core

Node Core leverages the natural speed of a core written in Rust - but also benefits from all of our latest optimizations in a single place. Out initial benchmarking suggests that Node Server Core can evaluate 5-10x faster than our native Node SDK. Beyond that, Node Core supports new features like Contextual Multi-Armed Bandits, and advanced bootstrapping functionality, like bootstrapping Parameter Stores to your clients. Using Node core with our Forward Proxy has even more benefits, as changes can be streamed, leading to 1/10th of the CPU intensity.

Node Server Core is in open beta beginning today, see our docs to get started. In the coming months, we'll ship Server Core in Ruby, PHP, and more - if you're looking forward to a new language, let us know in Slack.

🏁 Experiment at Startup

Evaluating at startup: an unsolved problem

One caveat of most experimentation implementations is the latency required to get experiment values for each user. Various approaches attempt to work around this, some of which Statsig provides - like local evaluation SDKs, bootstrapping, and non-blocking initialization, but each have their own caveats - like security, speed, and making sure you have the latest values (respectively).

The Local Eval Adapter

Today we're announcing a new feature that we believe resolves many of these concerns for experimenting at app startup: the Statsig Local Eval Adapter. With this approach - you can ship an app version or webpage with a set of config definitions, which can be evaluated immediately on startup. Following that initial evaluation - values from the network can takeover.

Differences from other approaches

While local evaluation SDKs - which download the experiment ruleset for all users - could theoretically solve this problem in the past by shipping that ruleset with the SDK, they didn't have the ability to switch into a "precomputed" mode after that, meaning if you wanted to ship configurations with an app, you were compromising security. With this approach, you can be selective on the info included in the Adapter, ensuring security. Check out the Local Eval Adapter in our docs!

Reuse Experiment Salts

The Statsig SDKs use deterministic hashing to bucket users. This means that the same user being evaluated for the same experiment will be bucketed identically - no matter where that happens. Every experiment has it's own unique salt, so that each experiment's assignment is random.

For advanced use cases - e.g. a series of related experiments that needs to reuse the control and test buckets, we now expose the ability to copy and set the salts used for deterministic hashing. This is meant to be used with care. and is only available to Project Administrators. It is available in the Overflow (...) menu in Experiments.

Extreme Measurement with Min and Max on Statsig WHN

We’re excited to release Max/Min metrics on Statsig Warehouse Native. Max and Min metrics allow you to easily track users’ extremes during an experiment; this can be extremely useful for performance, score, or feedback use cases. For example, these easily let you:

• Understand how your performance changes impacted users’ worst experiences in terms of latency

• Understand if changes to your mobile game made users’ peak high scores change

• Measure the count of users in your experiment that ever left a 2-star review, or lower — using MIN(review_score) with a threshold setting

Mins and maxes can map directly onto users’ best and worst experiences, and now it’s just a few clicks to start measuring how they’re changing with any feature you test or release.

Ship experiment with (experiment specific) Holdback

When you're done with your experiment, you can now chose to ship it with an experiment-specific holdback. This is helpful when you're done with the test, are shipping a test group, but still want to measure impact on a small subset of the population to understand longer term effects.

Example use case : When ending a 50% Control vs 50% Test, you can ship Test with a 5% experiment specific holdback. Statsig will ship the Test experience to 95% of your users - and will continue to compute lift vs a the 5% holdback. It compares this 5% holdback (who don't get the test experience) to a similar sized group who got the test experience when you made the ship decision. You can ship to the holdback when you conclude this experiment. See docs

Statsig also natively supports Holdouts. These typically are used across features, and aren't experiment specific.

⚙️ Custom Metrics in Funnels

Funnels become more powerful with the ability to use saved custom metrics as funnel steps. This integration eliminates the need to manually reconstruct complex event combinations or filtered events each time you build a funnel.

What You Can Do Now

• Use saved custom metrics as steps in your conversion funnels

• Apply filtered events and multi-event combinations consistently across your analyses

• Build funnels faster by using your existing metric definitions

• Maintain consistent event definitions across your team's funnel analyses

How It Works

• When creating a funnel step, you can now select from both raw events and your saved custom metrics

• Each custom metric maintains its original configuration, including filters and event combinations

• Changes to a custom metric automatically reflect in any funnel using it as a step

• Mix and match raw events and custom metrics within the same funnel

Impact on Your Analysis

Say you're tracking signup conversion and your "Completed Signup" step needs to capture multiple success events while excluding test accounts. Instead of rebuilding this logic for each funnel:

1. Use your saved custom metric that already has the correct configuration

2. Drop it directly into your funnel as a step

3. Trust that all your funnel analyses use consistent event definitions

This update reduces manual setup time and helps your team measure conversion points consistently across your analytics.

🐍 Python Server Core SDK

Server Core is a full rewrite of our Server SDKs with a shared, performance-focused Rust library at the core - and bindings to each other language you'd like to deploy it in. Today, we're launching Python Server Core (Python Core).

Performance & Python-threading optimized

Python Core leverages the natural speed of a core written in Rust - but also benefits from all of our latest optimizations in a single place. Out initial benchmarking suggests that Python Server Core can evaluate 5-10x faster than our native Python SDK. As an added benefit, Python Core's refresh mechanism is a background process, meaning it never needs to take the GIL. Using Python core with our Forward Proxy has even more benefits, as changes can be streamed, leading to 1/10th of the CPU intensity.

Python Server Core is in open beta begging today, see our docs to get started. In the coming months, we'll ship Server Core in Node, PHP, and more - if you're looking forward to a new language, let us know in Slack.

📊 Distribution Charts++

Distribution Charts now offer three specialized views to help you uncover patterns in your user behavior and event data, along with smarter automatic binning.

What You Can Do Now

• Analyze user engagement patterns with Per User Event Frequency distributions to see how often individual users perform specific actions

• Explore value patterns across events using Event Property Value distributions to understand the range and clustering of numeric properties

• Discover user-level patterns with Aggregated Property Value distributions, showing how property values sum or average per user over time

• Let the system automatically optimize your distribution bins, or take full control with custom binning

How It Works

• Per User Event Frequency shows you the spread of how often users perform an action, like revealing that most users share content 2-3 times per week while power users share 20+ times

• Event Property Value examines all instances of a numeric property across events, such as seeing the distribution of order values across all purchases

• Aggregated Property Value calculates either the sum or average of a property per user, helping you understand patterns like the distribution of total spend per customer

• Smart binning automatically creates 30 optimized buckets by default, or you can set custom bucket ranges for more precise analysis

Impact on Your Analysis These new distribution views help you answer critical questions about your product:

• Is your feature reaching broad adoption or mainly used by power users?

• What's the typical range for key metrics like transaction values or engagement counts?

• How do value patterns differ when looking at individual instances versus per-user aggregates?

The combination of flexible viewing options and intelligent binning makes it easier to find meaningful patterns in your data, whether you're analyzing user behavior, transaction patterns, or engagement metrics.

👤 User Profiles

Your user data just got more manageable. User Profiles now store user properties independently from events, creating a single source of truth for user attributes that can be joined with any event during analysis.

What You Can Do Now

• Join user profile data with any event in Metrics Explorer without requiring properties on the events themselves

• Send events with minimal payload by removing redundant user properties from .logEvent() calls

• Maintain a centralized, always-current record of user attributes

• Access a complete view of user properties for any user in the dedicated Users Tab

How It Works

• User properties sent through .logEvent() automatically sync to the user's profile

• New properties are added to the profile while existing ones update as values change

• During analysis, user profile properties are available to join with any event, regardless of when the event occurred

Impact on Your Analysis

Let's say you run a social network and track a user's friend count. Instead of sending this property with every interaction event, you can:

1. Store friend count once in the user profile

2. Update it only when it changes

3. Analyze any event (likes, comments, posts) by friend count segments

4. Trust that you're always using the most current user data

This separation of user context from event data gives you cleaner event tracking and more reliable analytics, while reducing the complexity of your event logging code.