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) Holdout

When you're done with your experiment, you can now chose to ship it with an experiment-specific holdout. 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 holdout. Statsig will ship the Test experience to 95% of your users - and will continue to compute lift vs a the 5% Holdout. It compares this 5% holdout (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 holdout when you conclude this. See docs

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

🐍 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.

👤 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.

⚙️ 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.

📊 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.

Results in your Warehouse

People running many experiments use Statsig's Meta-analysis tools. When they want to explore this dataset more directly, they've had access to it via the Console API. We're now adding the ability to have Statsig push the final results that are visualized in the Console, into your warehouse also.

This feature is gradually rolling out across Statsig Warehouse Native customers.

Differential Impact Detection on Cloud

This feature automatically flags when sub-populations respond very differently to an experiment. This is sometimes referred as Heterogeneous Effect Detection or Segments of Interest.

Overall results for an experiment can look "normal" even when there's a bug that causes crashes only on Firefox, or when feature performs very poorly only for new users. You can now configure these "Segments of Interest" and Statsig will automatically analyze and flag experiments where we detect differential impact. You will be able to see the analysis that resulted in this flag.

Learn about how this works or see how to turn this on in docs. This feature shipped on Statsig Warehouse Native last summer and is now available on Statsig Cloud too!

Java Server Core

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 want to use it in. Today, we're launching Java Server Core.

Server Core

Server Core leverages Rust's natural speed, but also benefits from being a single place that we can optimize our server SDKs' performance. Our initial benchmarking suggests that Server Core can evaluate configs 5-10x faster than native SDKs.

You can install Java Core today by adding the necessary packages to your build.gradle - see our docs to get started. In the coming months, we expect to ship Server Core across Node, Python, PHP, and more!

Interaction Detection on Experiments

We shipped Interaction Detection on Statsig Warehouse Native last year. We've now brought it to Statsig Cloud customers too.

What is Interaction Detection​

When you run overlapping experiments, it is possible for them to interfere with each other. Interaction Detection lets you pick two experiments and evaluate them for interaction. This helps you understand if people exposed to both experiments behave very differently from people who're exposed to either one of the experiments.

Should I worry about it?​

Our general guidance is to run overlapping experiments. People seeing your landing page should experience multiple experiments at the same time. Our experience is echoed by all avid experimenters (link). Teams expecting to run conflicting experiments are typically aware of this and can avoid conflicts by making experiments mutually exclusive via Layers (also referred to as Universes).

Read more in docs or the blog post.