Products
Solutions
Resources
Note: There’s no missing post between this and the last Color Commentary! Going forward, we're shifting the date tag to the month the post is published. Since these posts now touch on future releases, we think this system will make more sense. It’ll also make it clear which Monthly Product Update they sync with.
This past month, our product theme was scaling. As automation decreases the cost of execution, learning has become the new bottleneck to building better products. The solution is to scale up how you learn.
We’ve been working on a number of new features focused not just on helping you measure the impact of what you’re shipping, but also on helping you scale your experimentation practice in your organization. These updates help you scale how your teams use Statsig, scale how you understand results, and scale how you target the right users across your org.
Here’s what we’ve been building and why we built it.
We also covered these updates in our Monthly Product Updates webinar. Register for our next one to be the first to know what’s new in Statsig!
Scale usability with Statbot
We mentioned this last month, but we’ve been working on a new AI assistant in the Statsig console called Statbot, and it’s almost ready to go live. Our goal with Statbot is to lower the learning curve for Statsig. You shouldn’t have to know the whole UI and every stats method to start testing and learning; now you can ask Statbot, and it can help you.
Statbot is a step change from the previous Statsig AI assistant. The old one could answer questions based on references to help docs, but by reviewing thousands of real user interactions, we realized this wasn’t enough. You wanted the assistant to understand the context of your project. You wanted it to be able to take actions like setting up an experiment. You wanted it to be more like a partner instead of a reference tool.
We’ve revamped Statbot so it can take action on any object throughout Statsig. It can edit feature gates, modify rollouts, review experiment results, and more. It’s actually built off the Statsig MCP v3, so anything you can do with the MCP, you can also do with Statbot. And anything you can’t do because of access controls, it can’t do either.
Some of you may be wondering, “Why do I need an in-app AI assistant when I could use Claude or Codex with the Statsig MCP?” The honest answer is that it’s not our place to tell you where to engage with Statsig. If you want to use the MCP, that’s great! If you prefer working in the console, that’s great too! We want anyone to be able to use Statsig, wherever they want to use it.
Statbot will be fully available November 17.
Scale insights with AI Reports
Statsig makes it easy to dig into your experiment data, but distilling what you find for the rest of your org can still be pretty difficult. Our new AI reports feature automatically summarizes experimental analysis so it’s faster and easier to share your learnings.
A lesson I had to learn the hard way early in my career: leaders don’t want to see your results table. To share your findings with cross-functional partners, you need to clean them up. Create a separate document with the top metrics in bold. Add some background context. Pulling that together manually is cumbersome and time-consuming.
The new AI reports feature automatically does this for you. Go to the reports tab on any experiment for an auto-generated readout of the top metrics, executive summary, and recommended next steps.
The report is editable, so if you want to adjust or highlight based on your own insights, you can. The report is also exportable, so it’s easy to share with teammates or leaders who may not want to log in to Statsig just to see your newest discovery.
AI reports are available now, with customizable report templates coming soon.
Scale targeting with supersized ID lists
We’re making it easier for your whole org to engage your users by scaling up targeting for server-side ID lists to +100M member segments.
This was a request from several customers who have large audiences (50–100M members) defined in their warehouses. They wanted to be able to personalize based on their ID lists, but they didn’t want to have to rebuild their lists as flag rules inside Statsig. This makes total sense; maintaining a list that size in multiple locations is a recipe for data drift disaster.
Our new implementation essentially unbounds ID lists by using a forward proxy connected to a shared Redis. You look up users via the shared proxy, which goes into the shared Redis, which syncs directly to Statsig. This scales to over 100M IDs.
Because the lookups are completely local, they take 1–2 ms, and they don’t limit any external calls on the request path. This is kept up to date asynchronously with the Statsig servers. If a lookup fails, you’re in full control. If the SDK errors, you can pick a specific callback for that.
You run this proxy in Redis yourself, so there is some setup involved. We’re happy to help you through this. In return, you get much faster lookups that scale to the ID list levels you need, making it easier to work with and share your user definitions.
Node and Java support is now available.
Scaling safety with MCP v3
Since we announced Statsig MCP v3 a couple of weeks ago, we’ve heard from several customers that they’re still a little wary of taking write actions via MCP. Rogue agents are all over the news; it’s understandable that you don’t want to accidentally set one loose in your experimentation platform.
One of the key ways that Statsig MCP v3 is safer than many other MCPs is that there are two strict layers of access controls: permissions for MCP access specifically, and the permissions for Statsig you’re already familiar with.
By default, MCP usage follows a user’s Statsig permissions. Anyone who connects with MCP is not able to do anything more than what they can do through the UI. Your admin maintains this.
Beyond that, there’s an additional layer of override restrictions just for MCP. This lets an admin control MCP read/write permissions at the project level, role level, and user level. Even if a user can read and write through the console, if you don’t want them writing with the MCP, you can turn that off.
MCP is quickly becoming many teams’ preferred way to use Statsig. We’re making sure it’s a safe way to use Statsig, too.
The next episode
We’re very excited about how these features will help you scale your experimentation program for whatever challenges it may have. We hope you’ll be able to get more users measuring the impact of what they’re making.
To be the first to know what’s next, be sure to sign up for our next Monthly Product Updates webinar. The next one is December 3, assuming we’re over our tryptophan torpor by then.
Enjoy the rest of your November, good luck prepping for the holiday season, and check back here for more Statsig soon.