Product Updates

Announcing Session Replay Beta

Session Replay Launch Video

We're excited to introduce Session Replay, our new tool designed to give you a clearer understanding of how users interact with your product. This feature complements our existing Product Analytics by providing qualitative insights that help explain the reasons behind user behaviors.

Session Replay allows you to visually track a user's journey through your app or website. For example, if Product Analytics shows that users are dropping off at a particular step in a signup or checkout process, Session Replay enables you to see what happened during those sessions. You might discover issues like unclear instructions, overly complex UI, or missing information—factors that could lead to user frustration or abandonment.

For startups, Session Replay is particularly beneficial. We offer 10,000 free session replays each month, making it accessible for new businesses to start optimizing user experiences right away. Setup is straightforward: integrate a code snippet or use a package manager to enable autocapture and begin recording sessions. This tool not only helps identify where users encounter problems but also supports your efforts to make informed decisions to improve design and functionality.

Together with Product Analytics, Session Replay enriches your understanding of user interactions by adding context to the data you collect. This integration helps you make more targeted improvements, enhancing user satisfaction and conversion rates. If you're already using Statsig for Product Analytics, adding Session Replay is a seamless step to gain deeper insights into the 'why' behind the data. Get started today and enhance your ability to observe, analyze, and respond to user needs.

👥 Teams Configuration Settings

We're continuing to build on the recently-launched Teams functionality with a spate of new settings to more granularly control Project Settings at the team-level. New settings include:

1. Require Teams- Project setting to require all config creations are tied to a team, for easy categorization

2. Require Reviews- Team-level setting to require reviews at the team level (if reviews aren't already required at the project-level)

3. Default Holdout- Setting to automatically add all of a team's configs to a specified holdout to track cumulative impact over the course of a Quarter, Half, etc.

Teams are a powerful new organizational mechanism in the Statsig Console to make tracking configs, product changes, and business impact easier than ever at the team level.

Review configuration and default holdout settings in Teams Settings

Refreshing Pulse (Experiment Scorecards)

Coming soon to Statsig is a new look to Pulse - our Experiment Scorecard page. As we added more features to this page (Target Apps, Allowed Reviewers, Hypothesis...) metric lifts got pushed off the screen. The new version will bring back focus on the metrics when the experiment is running. You can still access any of the context you're used to with one click.

The Summary tab is unchanged with this refresh. Reach out in Slack with any feedback you have - we're keen to listen as we make this view better.

📍 Local Metrics on Warehouse Native

Local Metrics are metrics that are scoped to an individual experiment. They let you create the exact specific custom metric you want to measure in the context of your experiment or gate, without having to clutter up your Metrics Catalog on an ongoing basis.

Local Metrics can be created from the Setup tab sections of your entity, will be calculated for the duration of your experiment or rollout, and then will cease to exist when you make a decision on your experiment.

This rolled out on Statsig Cloud recently, and is now available on Statsig Warehouse Native too.

See docs

Schemas for Dynamic Configs

Today, we're excited to add the ability to define a schema for your dynamic configs, making it easier and less error-prone for multiple team members to collaborate together on dynamic configs.

To define a schema, you’ll see an optional “Schema” definition unit at the top of the page. When you add a schema, it will validate your rule & default return value JSON against this schema and block saving changes until the return values match the schema.

Optional space to define a schema for a dynamic config

Inline Comments for Dynamic Configs

You asked and we answered! One top feature request has been the ability to add inline comments to dynamic configs to help provide clarity and visibility on field values and definitions.

With commenting, you can add comments to any new or existing dynamic config by escaping with "//". Comments will render in the dynamic config editor, but will not be sent down to your SDK.

Inline comments on a dynamic config

🧮 More Metric Flexibility on WHN

Ratio Metrics: In addition to creating ratio metrics from Metric Sources, you can now create ratio metrics over existing metrics from your metric catalog.

Multi-source metrics: You can now create metrics that span multiple Metric Sources. e.g. If you have setup Online and Offline Purchases as separate metric sources, you can create a metric that sums up purchases from both metric sources.

🌸 Dashboards Spring Cleaning

We've recently made some quality of life improvements to help you find dashboards more easily and quickly derive meaningful insights.

Dashboard Summaries and Settings

When viewing dashboards, we've made it simpler to grasp the most important insights at a glance. Charts on dashboards now, by default, show the latest metric value and the percent change over time for the metric being plotted. This makes understanding current product health more straightforward than ever. You can also edit the summary value being display as the latest value, average value, or cumulative value of the metric over the time range.

Favorite Dashboards

You can now mark dashboards as favorites if they are particularly important to you. Your favorite dashboards will always appear at the top of your dashboard list, making them easier to access and ensuring you quickly get to the data that matters most.

Popular Dashboards

We've also added a new "Popular Dashboards" section to the dashboard list view. This feature makes it easy to discover dashboards that are popular within your project, helping your team share insights and context around the dashboards and product data that are proving most insightful.

We've enhanced our dashboards with new features to improve user experience. Now, charts display the latest metric value and percent change over time, making it easier to understand product health at a glance. Users can also favorite dashboards for quick access and explore a new "Popular Dashboards" section to discover trending insights within their project.

📍 Local Metrics

Local Metrics are metrics that are scoped to an individual experiment or gate rollout. Local Metrics enable you to create the exact specific custom metric you want to measure in the context of your experiment or gate, without having to clutter up your Metrics Catalog on an ongoing basis.

Local Metrics can be created from the Setup tab or the Scorecard (or Monitoring Metrics) sections of your entity, will be calculated for the duration of your experiment or rollout, and then will cease to exist when you make a decision on your experiment or launch your gate.

Rolling out now on Statsig Cloud; on Statsig Warehouse Native in mid-April.

See docs

Local Metrics creation wizard in Experiment Setup tab

🍯Persistent Assignment on Experiments

This is a new SDK feature that makes user bucketing decisions on experiments sticky even in situations they wouldn't have been previously. Users exposed to an experiment are bucketed into Control or Test deterministically (see how); however allocation or targeting changes can cause a user to to be excluded from an experiment after they were exposed to it. Persistent Assignment ensures that users stay bucketed in the experiment even when allocation or targeting changes.

Some scenarios this unlocks

1. You can roll out an experiment to 100% of users for a week, and then drop allocation to 0%. Users exposed to the experiment in that first week will continue to experience the experiment; other users will not.

2. When you target an experiment at set of users (e.g. low engaged users), if the user state changes they usually fall out of the experiment. With Persistent Assignment they will continue to see the experiment (e.g. even if they move from low engaged -> high engaged).

Learn more about Persistent Assignment on Client SDKs, Server SDKs