Growthbook Updates & Release Notes

Great tools and data are critical to an experimentation program, but they’re not enough on their own. A strong program also needs a culture where teams experiment with rigor, share ideas, learn from results, and make decisions based on evidence.

For a lot of organizations, much of that culture lives in Slack. That’s where teams discuss what to build and decide what’s next. But experiment updates don’t always make it into those conversations, which makes it harder to act on what teams learn.

That’s why we’re so excited about the GrowthBook Slack app released in GrowthBook 5.1. About to launch an experiment? The right people see it in Slack and can weigh in before it goes live. Had a big win (or a loss worth learning from)? The results are automatically shared in your team’s channel.

By bringing experiments, feature flags, and AI-powered answers about your data into the conversations where teams already collaborate, the Slack app encourages broader participation and makes experimentation a more natural part of how your organization operates.

What the Slack app does

Chat with GrowthBook’s AI assistant directly from Slack

Tag @GrowthBook in any channel to ask about your experiments and get answers without opening GrowthBook. It's the same AI assistant you use in the app, now available in Slack.

Ask for a quick status check like “@GrowthBook how is the homepage hero test doing?" Or explore past experiments with “@GrowthBook give me a list of all the experiments that tested our checkout flow.” You can even ask broader questions like “@GrowthBook what are the key Learnings we have so far this year?”

Get real-time, granular notifications from GrowthBook

Stay on top of experiments and flags without constantly checking GrowthBook. Get immediate alerts for important events, including SRM issues, significance results, and pending approvals. Filters by project, environment, or tag keep each channel focused on what’s relevant.

What changed: Activity and change tracking

Keep teams informed as experiments and flags evolve, from experiment launches and edits to flag revisions and ramp schedule changes.

Potential issues: Health and data quality

Surface issues that need attention, including sample ratio mismatch (SRM), multiple exposures, missing data, underpowered results, failed updates or publishes, and failing guardrails.

What we learned: Results and decisions

Bring significance results, decision points, and bandit variation weight changes into the conversation so teams can triage and decide what to do next.

Someone needs to act: Reviews and follow-ups

Keep approval requests for flags and experiments visible so they are more quickly actioned. Get updates when experiments are ready for approval, ready to launch, or have been running longer than 90 days.

Building a culture of experimentation

A strong culture of experimentation is one where teams challenge assumptions, test ideas, and let evidence guide decisions. It requires getting the right people involved, designing experiments that maximize learning, making insights accessible so teams can make decisions collaboratively in the moment, and ensuring those insights guide future decisions to shape the longer-term strategy. It also means giving evidence more weight than the most senior opinion in the room.

Bringing experimentation into the Slack channels where teams already collaborate helps make these practices part of everyday decision-making across the organization

Bring more people into experimentation

Experimentation works best when it extends beyond just the teams running tests. Product, engineering, design, growth, marketing, and leadership all have a role in identifying opportunities, challenging assumptions, and deciding what to do next.

But involving those teams at the end of an experiment, if at all, limits their ability to contribute. Bringing relevant updates into Slack gives stakeholders visibility while there's still time to offer context, raise concerns, or influence a decision. This helps keep people involved throughout the process, rather than bringing them in only when results are ready.

Make data-driven decisions together

Experiments often reveal trade-offs that aren't obvious from a single metric. A change that lifts conversions might also increase cancellations a month later. Weighing that trade-off well takes input from across the business. For example, customer success can share what they're hearing about churn and finance can speak to what a cancellation costs.

The GrowthBook Slack app gives teams a natural place to discuss and work through those trade-offs. When results are posted to a shared channel, people can share their perspectives in the moment, add context, and weigh in on conversations, helping teams make informed decisions together.

Turn experiment insights into better business decisions

Experiments can inform broader business decisions. For example, an online grocery store might test different ways of featuring products and find that one approach drives fewer sales but shifts customers toward higher-margin items. That insight could influence everything from inventory choices to how much to spend on marketing.

Sharing those findings across the organization helps teams build on what they've learned and identify new opportunities to test. The GrowthBook Slack app helps drive collaboration by making results and insights accessible in the channels where teams already work. Combined with GrowthBook's Learnings, it helps teams use those insights in future experiments and strategy.

What's next

The GrowthBook Slack app is currently in beta and we’re continuing to improve it. Future enhancements will include more proactive AI capabilities, like regularly summarizing your top experiments and new learnings, surfacing what needs your attention, and flagging issues before you have to go looking for them.

We’d love to hear what's working well for you and what you'd like to see next. Join our Slack App GitHub discussion to share your feedback and help shape what’s ahead.

Bring experimentation into the conversation

Experimentation has the greatest impact when insights reach the people who can act on them. The GrowthBook Slack app brings launches, results, and AI-powered answers into the conversations where teams make decisions.

Original source

Every new AI model brings its own response style, its own strengths, its own sharp edges when it meets your application.

You’ve probably written offline eval specs to capture the most important response qualities for your users. As you consider switching from Sonnet 5 to Sonnet 5.5 or updating your prompts to work with the new models (or your changing users), you run these evals to make sure the new model's sharp edges don't show up as regressions in quality or performance.

Until you ship to prod, though, you don’t really know how your customers, with all their edge cases, will respond. Or what impact your changes will have on your revenue, daily active users, and token costs.

Before your release to everyone, everywhere, all at once, you can figure out that potential cost. You can run an online, controlled experiment, using the trace data you already collect.

GrowthBook can now use your LLM trace data as experiment metrics, so you can connect your changes with your observed LLM behaviors and the business metrics that matter.

Experiments are stronger with traces and business metrics

Trace data on its own is valuable, whether it’s observed data like latency or cost, or data generated through offline evals or LLM-as-a-judge setups. Experiments that leverage just trace data can help you determine, with experimental validity rather than gut feel or quick comparison, which model, prompt, or parameter configuration actually improves your scores without degrading other metrics.

But experiments on your AI features are stronger when tied in with business data. GrowthBook analyzes your data where it lives. When your trace data rests in the same warehouse as your product and business data, a single experiment can measure both: token cost, latency, tool calls alongside revenue, clicks, and daily active users. Your trace metrics could be goals or guardrails or both, and integrating them with other experiment metrics enables you to answer more complex questions. You can answer not just “which prompt scores better,” but “which prompt leads to higher feature adoption rates and revenue growth.”

What you can A/B test: Prompts, models, and agents

Some changes affect just what can be measured in your traces. Others matter most if they affect your conversions, revenue, or customer satisfaction. GrowthBook handles both.

When the answer is in your traces and evals

Managing costs without sacrificing quality: Shift your summarization feature to a cheaper model to bring down LLM costs per user, and switch only if the eval score for summary quality and error rate stay steady or improve.

Improve prompt quality to improve helpfulness: Rewrite the system prompt for your support assistant, and test whether its helpfulness score improves. Guard against token usage ballooning and latency increases, since more thorough answers could easily get longer and slower.

Dynamically adjust traffic to multiple prompts: Suppose you have several prompts that all seem viable. You can run a multi-armed bandit with helpfulness (as defined by an LLM judge) as your primary metric, and GrowthBook will allocate more users to the most helpful prompt as evidence comes in.

When the answer rests in your business

Ensure that larger models actually sell more: Using a larger model for your shopping assistant costs more for every request and response. Does it actually sell more? Test with revenue per user as your primary goal, and evaluate revenue lift alongside token spend.

Find sharp edges before your entire user base does: Release your new onboarding agent to internal users first, then ramp up from 2 to 5 to higher percentages of users. Measure their activation or retention rate after a set period, like 7 days, with error rates and latency as guardrail metrics. If your agent negatively impacts these metrics, turn it off via flag.

Turn LLM traces into experiment metrics

Here’s how a single trace tag turns your observability data into experiment data:

When someone runs an experiment, GrowthBook decides which version of a model, prompt, or parameter each user should see, then tags that user’s trace with the assignment. Your tracing tool, like Langfuse or Arize Phoenix, records that tag right alongside the normal trace data it already collects, such as latency, cost, and errors.

GrowthBook then reads those tagged traces back out of your tracing tool and groups them by which version each user saw. That lets it compare how each version performed on the metrics you care about, so you can see which one actually wins before rolling it out to everyone.

Langfuse and Arize Phoenix are our first two integrations. More are on the way.

Setting up an experiment with trace data

1. Tag each trace with the version the user saw. The GrowthBook JavaScript SDK 1.8 includes a tracing plugin that records each assignment as a tag, such as gb.exp:support-model=small. Pass the tags to your tracing SDK at the start of each request. With Python and other SDKs, you add the tag yourself.

   (import GrowthBook and plugins code example...)

2. Connect GrowthBook to your trace data. GrowthBook sets up six metrics for you: LLM cost per user, p95 LLM latency, LLM error rate, tokens per LLM call, LLM calls per user, and traces per user. Add metrics for the eval scores and user feedback you already record.

3. Run the experiment. Choose who's included, how much traffic each version gets, and your goal and guardrail metrics. You can assign versions per user, per session, or per request. Frequentist or Bayesian statistics tell you when a difference is real.

   (Experiment results figure caption: Experiment results: The cheaper model cut LLM costs by 58%, but quality fell and twice as many users needed a human agent.)

4. Analyze the results. GrowthBook shows how each version performed on every metric and whether the difference is real. Check your goal metric first, then your guardrails: a cheaper model that hurts quality isn't a win. When the answer is clear, roll out the winner or roll it back, and take what you learned into the next test.

Get started with LLM experiments in GrowthBook

LLM trace experiments are available now in beta on GrowthBook Cloud for Langfuse and Arize Phoenix.

To learn more, check out our docs:

• Experimenting on LLM features: how it works, and how to plan your first test
• Setup reference for Langfuse and Arize Phoenix

Pick the model or prompt change you’ve been hesitant to ship, and test it safely with real users.

Original source

GrowthBook 5.1 includes over 400 commits touching almost every part of the product. Below are some of the highlights.

Highlights

• Contextual Bandits (beta) - One size doesn’t fit all. Contextual Bandits let you run personalization experiments to find the best performing variant for each group of users. The bandit continuously learns and updates weights as it runs and helps you pick out the signal from the noise.

• Saved Learnings - Document deeper learnings about your users that you’ve discovered through experimentation. Let our agent automatically scan your past tests to get you started or use our new API endpoints and agent skills to build your own workflows around this invaluable data.

• Funnel Metrics - Easily measure funnel completion in your experiments and see where users are dropping off. Perfect for testing marketing funnels, onboarding flows, and anything else where users progress through a series of steps.

• Hosted MCP + OAuth - Users on GrowthBook Cloud can now connect to our hosted MCP server at mcp.growthbook.io and incorporate our 30+ agent skills into your workflows. Pull GrowthBook experiment results into Notion, create feature flags from Jira tickets, query product analytics data from Claude Desktop, and so much more.

• Slack App (beta) - Our official Slack App is now available! Get rich notifications, full control over channels and filtering, and the ability to mention @GrowthBook to talk to your data and use our agent skills. We have a lot more coming soon and would love to get your feedback!

• User Journey Explorer - In GrowthBook product analytics, you can now easily see how users flow through your app. Pick a starting (or ending) step and see the actions the user does immediately before/after. Click through to continue following users deeper into your product funnel. Find an interesting path? Switch over to our Funnel Explorer to do a deeper dive.

• AI-Generated Dashboards - Creating product analytics (or experiment) dashboards used to be a very manual and tedious process. Now, with our new agent skill, just describe what you want and see it magically appear before your eyes. Call this skill from our in-app assistant, MCP server, or wherever else your agents live.

• EU Ingestion Server - Organizations on GrowthBook Cloud can now use our Managed Warehouse or Event Forwarder in the eu-west-1 region (Dublin). Take advantage of our realtime data ingestion and ETL pipelines while keeping your data stored securely within the EU. The first 1 million events per month are free so try it out today!

• Targeting Projects - Deliver one Feature Flag into several projects without duplicating it. Add Targeting Projects and the flag is included in those projects' SDK payloads, while ownership stays with its primary project.

• New SQL Explorer - Our SQL Explorer in product analytics got a big upgrade. Besides a bunch of UX improvements, all filtering and grouping now happen within SQL directly, so many of the previous restrictions (like a 1,000 row limit) no longer apply.

• Composable Permissions - Users and teams can now have multiple roles assigned that are merged to determine their final permissions. In addition, Custom Roles now have more fine-grained control over every action in GrowthBook. For example, grant edit permission without also granting create or delete permission.

• Atomic Publishing (beta) - There's a new REST endpoint (POST /api/v1/releases/publish-revisions) that lets you ship coordinated changes across several flags in one atomic transaction.

• Adobe Experience Platform (AEP) Data Source - GrowthBook can now connect to your Adobe data and use it as a source for both experiment metrics and product analytics. This is an early preview release to get feedback from the community, so let us know what you think!

Full Changelog: v5.0.0...v5.1.0

Contributors

Thanks to all of our existing contributors: @Kevin-Chant, @bryce-fitzsimons, @ahdriel, @lukesonnet, @anna-yn, @mknowlton89, @jdorn, @msamper, @Auz, @tzjames, @nhat-growthbook, @oelshaikh, @gazzdingo, @teresayung, @alyssamichelle, @lillialjackson, @madhuchavva, @lukebrawleysmith, @itsgrimetime, @johnham-ant, @HampusPoppius, @natasha-growthbook, @dlin-growthbook, @CedricConday, @AnkittChauhan and a big thanks to everyone who made their first contribution!

• @najito made their first contribution in #6502
• @Whatsonyourmind made their first contribution in #6145
• @LegendKaito-Q made their first contribution in #6577
• @benmarks-ant made their first contribution in #6759
• @R167 made their first contribution in #6860
• @avionicharshit-byte made their first contribution in #6827
• @mukmookk made their first contribution in #6876
• @EmmS21 made their first contribution in #6598
• @OnkarDsharma made their first contribution in #6904
• @andywhite37 made their first contribution in #6967

Original source

Helping product teams build, ship, and improve at scale, with AI built into every step.

Every company is trying to do the same thing: build a better product and move faster than their competitors. The way to do that is to learn faster, so more decisions are made from evidence instead of guesses.

But learning faster takes more than the ability to run an A/B test.

Your experimentation platform should help you run experiments quickly and rigorously, capture what you learn, and identify opportunities to apply those learnings to the next decision.

GrowthBook 5.1 brings the entire learning loop together, with AI across every step. It’s now available to all cloud and self-hosted users. Check out the full release notes for everything that shipped.

Scale testing without sacrificing rigor

GrowthBook 5.1 helps teams scale experimentation, both in volume and in what you can test, like measuring funnel completion or optimizing with contextual bandits. AI-powered workflows remove friction and built-in rigor ensures you can move faster without sacrificing confidence in your results.

Contextual bandits personalize which variation a user sees at the individual user level, learning which variant performs best based on their context and automatically shifts traffic accordingly. They’re especially useful for time-sensitive campaigns, high-variant tests, or personalization where the best experience varies by user.

Funnel metrics let you measure funnel completion in your experiments and see where users are dropping off. They are especially useful for testing marketing funnels, onboarding flows, and other multi-step experiences.

AI lets you scale experimentation by turning the workflow into something fully programmable, giving agents the ability to publish flags, create experiments, and more. Our new Hosted MCP + OAuth server, and an expanding AI skills library of 30+ skills make it faster and easier for teams to build and run experiments.

Nothing you learn gets lost

Every experiment creates knowledge, even the losses. The challenge is making sure that knowledge doesn’t disappear into static documents, Slack threads, or the heads of the people who ran the experiment.

GrowthBook 5.1 helps capture what you learn and makes it easier to analyze more data with AI, uncover deeper insights, and share them across your organization.

Learnings gives you a living knowledge library to document everything you’ve discovered through experimentation, so your entire organization can access and build on it. GrowthBook’s agent can automatically scan your past tests to get you started or you can use our new API endpoints and agent skills.

The Slack App (Beta) brings your GrowthBook data into the conversations where your team is already working. Tag @growthbook to ask questions about your data or interact with the GrowthBook AI assistant directly from Slack. You can also send rich, customizable notifications and daily or weekly digests to keep your team informed about what’s happening across your projects and organization.

Product Analytics closes the loop

GrowthBook’s Product Analytics became generally available in 5.0, and 5.1 builds on this foundation making it easier to understand how users move through your product, where they encounter friction, and identify opportunities to test. This gives a clearer view of where to focus your experimentation efforts next.

User Journeys help to understand what happens before and after key moments in the user experience. Pick a starting or ending step so you can see the actions users take immediately before and after. Follow users deeper into your product or switch over to Funnel Explorer to do a deeper dive.

With a clearer view of how users navigate your product, you can spot friction, uncover opportunities, and make more informed decisions about what to test next.

AI-powered dashboards leverage AI skills to turn plain-language prompts into shareable product analytics or experiment dashboards. Describe the views you need through GrowthBook’s in-app assistant, MCP server, or wherever your agents live, and get the dashboard you need in moments, ready to share org-wide.

We rebuilt SQL Explorer to be easier to use for both humans and agents, so you can do richer explorations across your entire data warehouse without needing to predefine metrics. Use GrowthBook’s AI assistant or your preferred agent to query your data directly and ask questions that don’t map to existing metrics. It's another tool in the agent's kit for deeper, more flexible data exploration.

The full loop with GrowthBook 5.1

Together, these capabilities turn experimentation from a testing function into a continuous learning loop for the entire company.

Understand your product. Run more experiments. Learn from every result. Use what you learn to make better decisions. Then do it again.

See the full 5.1 release notes for everything else that shipped, or get started with GrowthBook today.

Original source

What stays in the EU and what doesn’t

GrowthBook Cloud now supports an EU data region. When you set up a Managed Warehouse, choose AWS eu-west-1 (Ireland) and your event data is ingested and stored in the EU.

GrowthBook’s warehouse-native architecture has always let you keep your event data in the EU, whether you bring an EU-based warehouse or fully self-host the platform.

Now, you have a new option. Choose a GrowthBook Managed Warehouse and keep your event data in the EU while getting the easy setup and low maintenance of a managed data warehouse. What crosses the border is configuration metadata and aggregate results.

• In the EU: event ingestion and event storage in your managed ClickHouse warehouse.
• Still in the US: the GrowthBook application itself: login, the UI, your configuration, and computed experiment results.
• Already covered: if you connect your own warehouse, GrowthBook never receives your event data in the first place. This release is for teams that want us to host it.

What you get with a Managed Warehouse

• One click to provision. There is no warehouse to procure, no cluster to size, and no pipeline to build before your first experiment.
• Configured for experimentation on arrival. You get tables for events, experiment exposures, and feature flag usage, a pre-built Events fact table, three starter metrics, and default identifiers and dimensions for country, browser, OS, device type, and UTM parameters.
• Tracking built into the SDKs. Tracking plugins ship with the JavaScript, React, Node.js, Python, Java, PHP, Go, and Flutter SDKs, or you can post to the ingestion API directly. Events are enriched with geoIP and user agent data and are queryable within seconds.
• Raw SQL access. Query your event data in SQL Explorer and write your own metrics with SQL, the same as you would against a warehouse you run yourself.

How to get started

When you create a Managed Warehouse or set up an Event Forwarder, pick the EU data region. The setup snippets in the app will point your SDK at the EU ingestion endpoint.

Your Data Protection Addendum and Standard Contractual Clauses remain unchanged. The EU region is available for every GrowthBook Cloud plan.

If you’ve been waiting on data residency to move forward with GrowthBook, talk to us. We’d love to help you out.

Original source

Running an experiment gives you an answer to a question. Running thousands of experiments gives you a lot of answers, but also something much more valuable: a body of evidence about how your product, users, and business actually behave.

The problem is that this knowledge is surprisingly difficult to use in practice.

A PM working on onboarding might not know that another team tested a similar idea six months ago. An engineer building a new checkout flow might not know which patterns have consistently helped conversion on other parts of the product. Even when people remember that relevant experiments exist, reading through dozens or hundreds of them to find the important patterns is rarely practical.

Today, we are launching Learnings in GrowthBook to help solve this problem.

Learnings let teams capture what they have learned across experiments, user research, and other sources of evidence, then make that knowledge available to both people and AI agents when they are building something new.

Learnings: Turn experiment learnings into a living knowledge library.

Experiments produce more than winners

Experiments produce more than winners

The most obvious output of an experiment is a decision. Those decisions create incremental gains, and over time those gains compound.

But there is another output from experimentation that is easier to overlook: knowledge. Every experiment produces it, including the ones that lose or move nothing at all.

You might learn that:

• Showing pricing earlier in the funnel consistently improves qualified conversions.
• Simplifying onboarding helps new users but hurts activation for experienced users.
• Social proof matters on acquisition pages but has little effect inside the product.
• Asking users to configure everything upfront creates friction, while progressive configuration performs better.

None of these conclusions necessarily come from a single experiment. They emerge after five, twenty, or a hundred experiments, once somebody notices the pattern.

This is where an experimentation program becomes more powerful than a sequence of isolated A/B tests: individual tests give you answers, but the program gives you a model of how your users behave. You are gradually identifying patterns and putting your learnings to work for future growth.

Learnings compound your experimentation program

Learnings compound your experimentation program

If an experiment improves conversion by 2%, that improvement can continue generating value for as long as the change remains in the product (novelty effects aside). That’s real compounding, and it’s the return most programs measure.

But that win only compounds one thing: a metric. A learning acts on something different: the quality of the next decision.

Imagine your team learns through repeated experiments that users perform better when complex actions are introduced progressively rather than all at once. That insight might influence your next onboarding flow. Then your settings experience. Then a new AI feature. Then the way an agent designs a workflow six months later.

It doesn’t stay with one team either. An insight can travel to whoever picks your onboarding feature or settings work next. Your experimentation program can widen, since everyone starts from organizational knowledge.

The value is not limited to the experiment that produced the learning. It changes the starting point of future work. Instead of beginning every project from first principles, your team starts with a set of evidence-backed assumptions about what tends to work (and what doesn’t).

Learnings in GrowthBook

Learnings in GrowthBook

GrowthBook Learnings are designed to capture this organizational knowledge explicitly.

A learning can reference evidence from multiple experiments, rather than being tied to the result of a single test. That matters because many useful conclusions only become visible across a collection of experiments.

The New Learning form in GrowthBook, with fields for title, description, status, tags, projects, and supporting and contradicting experiments.

Every learning can cite the experiments that support it and the ones that don't, then be scoped to the projects and tags where the pattern actually held

You can use Learnings to document things like:

• Patterns that repeatedly improve a metric
• Approaches that consistently fail
• Differences between user segments
• Design principles supported by experimentation
• Unexpected behaviors observed across multiple tests
• Areas where the evidence is contradictory or uncertain

The same change isn’t universally applicable, though. Streamlining a flow can lift conversion in one part of your product and lower it in another, and the right amount of friction depends on what the user is trying to do. Learnings can be scoped to specific projects or tags, so that patterns that have been tested for your self-serve signup aren’t applied to your enterprise onboarding flow.

And learnings do not have to come exclusively from experiments either. You can capture qualitative findings from user research, customer interviews, support conversations, or other sources and combine them with quantitative evidence.

The goal is not to turn every observation into an immutable rule.

It is to give your organization a shared, evidence-backed memory. Each learning can be updated if new evidence comes in, and also have a specific status for when the learning is not verified yet, or if it’s no longer relevant. Statuses for learnings are entirely customizable. Once captured this way, that memory becomes something both people and AI agents can draw on, which raises the question of how much of it to hand an agent at once, and in what form.

The context window problem for organizations

The context window problem for organizations

There is a useful analogy to working with AI coding tools.

If you give an agent every line of code your company has ever written, you have technically given it more information. But you have not necessarily given it better context.

The useful question is:

what does the agent actually need to know to make this decision well?

Organizations have the same problem. After thousands of experiments, nobody should need to read thousands of experiment reports before starting a project. They need the relevant conclusions.

Learnings act as a compressed context layer over your experimentation history. The underlying experiments are still there as evidence, but people and agents can work from the higher-level patterns that those experiments have established.

For example:

Learning:
Users are more likely to complete complex setup flows when advanced configuration is deferred until after initial success.

Evidence:
Seven onboarding experiments across three product areas.

A PM planning a new onboarding experience can start with that knowledge instead of rediscovering it. An engineer can incorporate it while designing the implementation. The same applies to agents, even more strongly. An agent without access to your evidence will still produce a confident answer, but it will be generic and maybe an approach you’ve already disproved. Point your agents at your Learnings, and they start from what you already know.

Learnings are available through GrowthBook's APIs and MCP support, just like your experiments and other experimentation data. Through GrowthBook Skills, you can instruct agents to retrieve relevant Learnings before they design or implement something.

Instead of giving agents generic product-development best practices, you can give them exactly what they need to know to make this decision well: your company’s own compressed, decision-relevant knowledge, grounded in real outcomes and updated as new evidence comes in.

AI can help find the patterns humans miss

AI can help find the patterns humans miss

As experimentation programs grow, manually identifying patterns becomes harder if not impossible. A team running ten experiments a year can probably remember most of them. A company running thousands cannot. GrowthBook can use AI to analyze your experiment history and surface commonalities across results.

GrowthBook's Find Learnings panel proposing a learning about friction reduction in conversion flows, citing three supporting experiments.

GrowthBook proposes candidate learnings from your experiment history, with the supporting evidence and a suggested next step attached. You decide which ones to keep.

Perhaps a certain type of messaging consistently works for new users but not existing customers. Maybe several unrelated experiments show that reducing perceived commitment improves activation. Maybe a UI pattern that teams keep proposing has actually failed in four different areas of the product.

These patterns are easy to miss when every experiment is analyzed independently.

AI makes it possible to search across a much larger body of evidence, while Learnings give teams a place to review, refine, and preserve the conclusions that matter.

Good experiment hygiene becomes even more valuable

Good experiment hygiene becomes even more valuable

There is an important prerequisite.

AI cannot infer very much from an experiment called "Homepage test 7" with no hypothesis, description, or conclusion.

The better your experiment documentation, the more useful your accumulated knowledge becomes.

This is one reason GrowthBook has increasingly invested in experiment quality and hygiene, including checklists and workflows that encourage teams to document the hypothesis, context, results, and conclusions of an experiment. Good documentation has always made individual experiments easier to understand.

With Learnings, it also makes the entire experimentation history more valuable. Every well-documented experiment becomes another piece of evidence that can contribute to future decisions.

From experimentation history to organizational memory

From experimentation history to organizational memory

The long-term value of experimentation is not just making better decisions today. It is making every future decision from a stronger starting point.

Experiments that win improve the product. All your experiments improve the ideas, assumptions, and decisions that come next, increasingly including the ones your agents make. That’s the part that really compounds. Firmer footing leads to better experiments, which produce better evidence, which produces better judgment. Over time, your experimentation program is not only improving your product, it’s improving your organization’s ability to build one.

Experiments should not disappear into a results archive once a decision has been made. The best ones should keep teaching you.

Original source

Security Patch Release

Fixes critical auth vulnerability affecting self-hosted non-SSO deployments with publicly accessible /auth/* endpoints

Switches to Docker Hardened base images to reduce exposure to 3rd party vulnerabilities

Bump dependency versions to address various security vulnerabilities

New Databricks OAuth M2M option for increased security

New org setting to completely disable all Personal Access Tokens

Various performance and bug fixes throughout the app

We recommend all self-hosted users update as soon as possible.

This is also a great time to read through our production hardening docs and ensure you are following all best practices for security.

Original source

Starting an experiment should be easy

Every team that runs experiments wants to run more, faster. The difference between teams is where friction lives.

Consider two teams. The first team is finishing its first dozen experiments. Their process works, technically, but they run all experiments through two or three technical staff they trust. Experiments feel complex and high-stakes, and they worry that a bad customer experience could set the company back. The second team runs hundreds of experiments every day, against a warehouse with petabytes of data. They have the opportunity of fast, high-scale experimentation, but every analysis run has compute costs that equal real time and money. They need infrastructure to match their opportunity.

Different stages produce different friction.

GrowthBook 5.0 meets friction at every stage, making it easier to experiment when you’re building the habit, faster and more efficient at the frontier, and safer all along.

One of the biggest barriers to early teams is an empty experiment creation screen, especially when it’s long and involves more complex, technical options.

In 5.0, we cut the experiment creation flow from 23 fields to 5. The rest of the options move to the experiment overview page. You can write a hypothesis, set up experiment assignment, and share the draft to your team in the time it used to take to scroll through the previous version.

The streamlined experiment creation flow

We ran an experiment as we rolled this out, and there’s a surprisingly large effect. More people can create an experiment without feeling like they need to be an expert, and with sensible defaults, starting doesn’t mean shipping something accidentally.

Making experiment creation “cheaper,” with less time and expertise invested, makes it easier to imagine running more experiments and building a broader culture of experimentation. A thin experiment, with just the minimum fields, becomes a shared surface your team can edit and learn in together. Experimentation begins as collaboration rather than a handoff.

More hands, same standards

As the team grows and experimentation velocity increases, more and more people kick off experiments. You have an experimentation process that works, and you want more of it. More teams want to experiment, but a small handful of experts is still a bottleneck. Ideas for experiments might abound, but the organization is short on the people needed to push experiments from beginning to end.

Scaling experimentation means handing more people, more operations, the keys without giving up control of what ships. GrowthBook 5.0 helps.

More people can create. AI agents can now operate GrowthBook, which means anyone, through their code editor or with our new in-app AI Assistant, can brainstorm and create experiments, launch them, and check results with natural language. The new AI Visual Editor opens another door for teams, like growth and marketing, who prefer a point, click, and prompt experience. With the slim experiment creation flow and reusable templates, it’s so much easier to set up an experiment now and build on an existing experimentation program.

Creating an experiment through Claude

Guardrails travel with tests. Opening the door for more experimentation only helps your org if your best practices and processes stay in place for everyone. Our new custom hooks let teams codify their own rules and run checks for every experiment before it starts, automatically. Mandatory custom fields make sure every experiment is categorized and filled before it’s ever created. Linked feature flags mean a teammate still reviews production changes before launch. These checks live with the experiment, and are present and documented in GrowthBook.

Shared understanding builds shared commitment. Experiments that finish and features that roll out without others knowing can help a business, but they don’t help build shared knowledge and experimentation culture. We now have new meta-analysis experiment blocks for dashboards, so your team can have better oversight of what’s running, win percentages, lift, and scaled impact. Everyone in the org can learn, and, hopefully, be inspired to experiment also.

Using experiment meta blocks to understand impact on a metric

You don’t have to be at your desk to launch. GrowthBook 5.0 supports scheduled starts for experiments. You can kick off a test without being live at your computer. It sounds like a small thing, but as you scale and coordinate more and more experiments, control like this is what keeps a program manageable, right up until the next constraint takes over: compute.

Solve for people and trust, though, and a new limit appears: the volume of experiments you can now run starts to outgrow the infrastructure running them, and the bottleneck shifts from who can experiment to what your compute can afford.

Where compute is the constraint

At the frontier of experimentation scale, the bottleneck becomes compute. Data-rich environments give you the raw material for fast, accurate results, but can come with a bill to match. Teams that run hundreds of experiments a day against high-volume warehouses need infrastructure that meets their opportunity without equally large bills or compromises on velocity.

We think two techniques are highly relevant for these teams: quantile treatment effects (like the effect of a change on your p99 latency) and CUPED, which uses pre-experiment behavior to cut noise and bring results faster. Neither technique is new, but there’s a challenge to running them efficiently with a warehouse-native platform when data is large and quickly changing.

GrowthBook 5.0 includes major performance improvements with both approaches. For quantiles, we use KLL sketches to gather an event-level histogram into a single column that doesn’t grow as events pile up, which keeps quantiles cheaper at volume and even allows for pre-aggregations in the warehouse to be consumed by GrowthBook. For CUPED, we can now run a nightly pre-aggregation of each experimentation unit’s history, and since GrowthBook holds metric definition in our semantic layer, it refreshes only summaries that go stale when a definition changes.

We’ve seen >80% reduction in wall time for an experiment update, faster individual runtimes for experiments, and overall reduction in compute, which leads to lower warehouse bills. We’ll write about this in more detail later, but if you’re experimenting and analyzing at petabyte scale, come talk to us.

A platform you never outgrow

Everything in this post moved as you grew: the friction of starting, the bottleneck of people, the ceiling of compute. Safety is the one thing that didn't.

With GrowthBook 5.0, you can run experiments a little more easily, a little faster, with as much safety as ever, so you can make more chances to really learn about your product and users. That’s the real goal of experimentation: knowing instead of guessing, and building a better product for the people who use it.

Want to hear from our co-founders and engineers how we’ve made feature flagging and experimentation better? Come to our live Office Hours on July 30, 9am PT, and we’ll answer any questions you have.

Original source

Governance, for those unaccustomed to this buzzy word, is simply referring to guardrails.

With feature flags, it can be really easy to work yourself into a pickle. Our latest 5.0 release focused on many cool things, but one of the big ones was protecting you and your co-workers from yourselves. So you can work faster while still shipping safely.

As AI speeds up how fast code can be written and large organizations release more changes across more teams, the challenge is no longer simply getting work out the door. It is vital to make sure every change is valid, behaves as expected alongside everything else, and reaches production with the right context.

With this in mind, there are three areas in which we focused our feature flag governance in 5.0:

1. Catch problems while someone is making the change
2. Catch problems created by the full rule set
3. Make the final decision with context

Catch problems while someone is making the change

For this category of features, GrowthBook is checking whether the change itself is valid, sensible, and no larger than it needs to be. The best time to catch a bad flag change is before it becomes a review comment, a Slack thread, or a production scavenger hunt.

Schema validation for string and number flags

GrowthBook could already validate the shape of JSON flag values. Now you can also set rules for string and number flags.

For example, you can now limit a checkout layout flag to classic, compact, or express. GrowthBook will reject anything else, including typos.

["classic", "compact", "express"]

For number flags, now you can set a minimum and maximum, such as allowing results-per-page to be anywhere from 10 to 100.

It is basically type safety for remote config, because TypeScript cannot save you from someone entering "expres" in a dashboard. Invalid values can now be caught before they are saved or published.

Feature-scoped Custom Hooks

Custom Hooks let your team write its own rules for what counts as a valid flag change.

For example, you could require a description, prevent targeting by email address, or make sure every rollout uses userId.

Custom Hooks already existed, but they previously applied to every feature in an organization or project. Now you can attach one to a single feature that needs its own rules.

• Organization-wide: Every feature flag must have an owner and at least one tag.
• Project-wide: Every rollout in the checkout project must use userId for hashing.
• Single feature: Only the checkout-config flag must include a Jira ticket before it can be changed.

Soft warnings

Not every questionable choice deserves the full red-screen treatment.

Custom Hooks can now raise a warning instead of blocking the save:

addWarning("Consider adding a ticket number");

The person editing can review it and choose Save anyway.

So now you have two volumes:

• addWarning() says, “Are you sure about this?”
• throw says, “Absolutely not.”

Sparse patches for JSON rules

Suppose a JSON flag has ten fields, but a rule only needs to change one.

Instead of copying the entire object, you can save just the keys and values you want to update:

{
  "theme": "dark"
}

A sparse patch preview showing only the changed field before it merges onto the default value.

GrowthBook merges that onto the default value, which means smaller changes, cleaner diffs, and fewer stale copied fields.

One important caveat: the merge is shallow. It only merges top-level keys, not deeply nested objects.

Together, these features make the editor feel less like a blank text box with consequences and more like a development environment that knows what “valid” means.

The value can be checked against an expected shape, custom rules can catch requirements unique to your team, warnings can flag questionable choices without blocking every save, and sparse patches keep changes focused on the fields someone actually meant to touch. By the time the change reaches review, many of the easiest mistakes have already been caught, while they are still cheap to fix.

Catch problems created by the full rule set

A rule can be perfectly valid on its own and still cause trouble once it joins the group chat.

GrowthBook evaluates rules from top to bottom. An earlier rule can serve a user before a later rule ever gets the chance.

For example:

1. Force a value for everyone in the US.
2. Force a different value for Pro users in the US.

The second rule will never run. Pro users in the US already matched the first rule and left the building.

GrowthBook already warned when a rule was completely unreachable. In 5.0, that detection expands to catch more ways rules can compete for the same traffic.

The warnings now have three levels:

• Unreachable: No matching traffic will reach the rule.
• Will not reach: Some matching traffic will definitely be served by an earlier rule.
• May not reach: An earlier rule might serve some of the same traffic, but we cannot say exactly how much.

GrowthBook flags a rule as unreachable when an earlier rule already matches the same traffic.

That last distinction matters for partial rollouts. A 90% rollout above another rule does not completely block the rule below it, but it does take a large bite out of the traffic before it gets there.

The warning also points to the earlier rule causing the conflict, so you can reorder the rules, narrow the targeting, or confirm that the overlap is intentional.

This catches a different class of problem than schema validation or Custom Hooks. Each rule may be valid, but the full rule set may not behave the way you pictured it.

Make the final decision with context

Automated checks can catch a lot, but eventually a human still has to decide: Is this change ready to go live?

GrowthBook 5.0 adds a dedicated Review & Publish tab that brings the scattered pieces of that decision into one place. It replaces separate publishing, review, and conflict-resolution flows with one shared workspace.

The Conversation view summarizes what changed and lets you publish the draft directly.

The Conversation view gives you the readable version of the story: what changed, why it changed, who contributed, any comments or reviews, and what needs to happen next.

When you need the technical receipts, the Changes view shows the detailed diff and lets people comment on the specific changes.

If Approval Flows are enabled, reviewers can leave a comment, request changes, or approve the draft before it is published. Without required approvals, someone with permission can still review the same context and publish directly. Approval Flows are a commercial feature.

The goal is not to make every flag change pass through a courtroom. It is to put the diff, discussion, reviewers, conflicts, and final action in the same room, so the person clicking Publish knows exactly what they are sending out the door.

Guardrails not stop signs

Good governance is not about slowing creators down. It is about making the work they publish quality and catching problems early before they hit users.

By adding governance while changes are created, when rules interact, and before publishing, teams will catch mistakes earlier and ship with more confidence. I'm so excited for what 5.0 at GrowthBook has brought to feature flags. If you'd like to learn more or hear from the engineers behind all of our newly released features, you can join us for Office Hours Live on Thursday, July 30 at 9 a.m. PT. See you online and happy experimenting!

Original source

AI-powered analytics

A native AI chat agent is built directly into Product Analytics. This opens up analytics to any user, turning a few prompts into actionable insights without needing to know the schema or rely on a data analyst for answers.

Ask questions in plain language, such as “Chart the number of daily users and conversions for the past 30 days” and the agent will build the exploration, render the chart, and surface insights behind the data.

In-app AI assistant

GrowthBook 5.0 also includes a platform-wide AI assistant available from any page in the app. In addition to taking action and supporting workflows across feature flags and experiments, it can also pull up analytics and surface trends from wherever you're working. This assistant pulls from 25+ open-source skills spanning feature flag management, experiment design, and product analytics.

The Metric Explorer: visualize and explore your data

The Metric Explorer lets you visualize any metric your team has defined in GrowthBook without needing to write SQL. These are the same metric definitions powering your experiments, so there's no custom SQL to write and no risk of metric drift between your analytics and your experiment results. This lets teams go quickly from question to chart in seconds.

The Metric Explorer supports a range of chart types (line, area, bar, stacked bar, horizontal bar, stacked horizontal bar, timeseries table, table, and big number) and the ability to segment by dates, dimensions, and filters.

If your team hasn't fully defined metrics yet, the Explorer also supports querying fact tables directly or even raw data source tables in your warehouse, so you can start exploring immediately and promote what you find to reusable metrics over time.

Because GrowthBook generates the SQL behind the scenes, it works with GrowthBook's Managed Warehouse, BigQuery, Snowflake, Databricks, Redshift, ClickHouse, Postgres, and more. Your data never leaves the warehouse.

SQL Reports

The SQL Explorer lets you write, save, and share queries directly within GrowthBook. No external BI tool needed. Pin results to any dashboard alongside your metric explorations and experiment data.

Write a query in the built-in editor with schema browsing and autocomplete, or describe what you want in plain language and let AI generate the SQL from your warehouse schema. Run the query, then layer on the types of visualizations you’d like to see: bar, line, area, scatter, pivot table, or big value (KPI). Configure axes, aggregations, dimensions, and filters visually without touching the SQL again.

Save reports, refresh them on demand, and pin individual visualizations to any dashboard alongside your metric explorations.

Funnel analysis

Define step sequences to visualize conversion rates between each step and understand where users fall out of the flow. Break funnels down by any dimension to find where specific segments convert differently.

For example, you might define a checkout funnel and break it down by device type. You notice mobile users drop off at the payment step at twice the rate of desktop. That's a clear signal. From the same platform, you can launch an experiment to test a simplified mobile payment flow and measure whether it closes the gap.

Whether it's your onboarding flow, checkout, or activation sequence, funnel analysis turns drop-off points into experiment hypotheses you can act on immediately.

Dashboards

Dashboards let you tell a story with your data. Create custom dashboards tailored to your north star metrics so they remain front and center. Arrange the KPIs that matter most to you on a flexible grid with drag-and-drop, and set a refresh schedule to keep everything current, and share with your team.

GrowthBook dashboards support a range of block types, from metric explorations and saved SQL queries to rich text, so you can build exactly the narrative your team or stakeholders need to get the full picture.

A typical dashboard might include your north star metric trend, a product funnel showing where users drop off, and the scaled impact from all your experiments pertaining to the relevant metrics.

One source of truth

Product Analytics is an extension of the work your data team has already done. The metrics are defined. The warehouse is connected. Now those same definitions power dashboards, funnels, and ad-hoc exploration, not just experiment results.

For teams that want programmatic access, the REST API exposes endpoints for running explorations, and every exploration gets a shareable URL encoding its complete configuration.

Product Analytics is available now. Get started or book a demo to see it in action.

Original source

TL;DR: GrowthBook 5.0 ships with an AI Visual Editor that lets anyone build and launch a live experiment on their website from a plain-language prompt, no engineering ticket required.

Growth and marketing teams rarely suffer from a shortage of ideas.

There is always another headline to test, another landing page to improve, another audience that may respond to different messaging, or another campaign that could convert more effectively.

The problem is getting those ideas into production. The reality for many marketing and growth teams is that testing capacity is capped by engineering bandwidth.

The GrowthBook AI Visual Editor unlocks this entire process. For the first time, anyone can vibe code a new home page or product page and deploy a rigorous experiment in minutes without engineering expertise. The AI Visual Editor allows users to move sections, change text and colors, and even swap out images with just a series of prompts. Once a new variation is built, these same users can kick off rigorous experiments using the same metrics and templates created by your data science team. So anyone can run experiments you can trust.

See the visual editor in action here:

Run experiments without waiting for engineering

The most immediate benefit of a visual experimentation system is straightforward: growth and marketing teams can move from an idea to a live experiment without waiting for an engineer to implement every variation.

Using GrowthBook’s AI Visual Editor, teams can describe a change in plain English or make it directly through a WYSIWYG interface. They can update text, modify styles, rearrange content, replace imagery, hide elements, or create more substantial page variations.

The editor then turns those changes into an experiment that can be previewed, reviewed, and launched through GrowthBook.

This removes a significant source of friction from the experimentation process.

Engineering teams no longer need to spend time implementing every headline test, campaign-specific landing page, image variation, or call-to-action adjustment. Growth teams no longer need to wait for an open sprint before learning whether an idea works.

And GrowthBook’s AI Visual Editor keeps engineering teams happy. The AI Visual Editor, like all of GrowthBook, is built on transparency so the technical teams can still review exactly what the experiment is doing, audit the results, look at the metrics, etc. Visual experiments also run on the same SDK used for other parts of GrowthBook, and even be flicker-free.

The difference is that engineering is no longer required for every step of every experiment.

What you can do with the AI Visual Editor

Many visual editors fall short and break on modern sites, and quietly push you back into writing CSS or HTML. We fully rebuilt our new AI Visual Editor from scratch to fix these issues.

The AI Visual Editor lets anyone describe the change they want in plain language and get a working variation without writing code. Use manual mode or enter a prompt to do things like:

• Generate images with AI: Use AI to generate and modify hero images, product photos, background visuals, and more.
• Change headlines and copy: Manually update copy to test different messaging.
• Generate new copy ideas: Prompt the AI to write different headlines, CTAs, or copy variations to test.
• Run multi-arm bandits: Use the AI Visual Editor to make changes to your site and run it as a multi-arm bandit to dynamically allocate traffic to the highest performing variant.
• Update designs and layouts: Adjust fonts, padding, button styles, restructure layouts, and more.
• Import Figma frames or mockups: Bring in a design straight from Figma to test actual user interaction without rebuilding it from scratch, not just as a static image.
• Import image files: Pull in your own images or brand assets.

The variation is built directly in the editor so you can see exactly how all your changes will look to your end users.

Test more ideas and learn faster

Reducing implementation work changes more than test speed. It changes which ideas are worth testing at all.

When every experiment requires engineering time, teams naturally reserve experimentation for larger ideas. Smaller questions remain unanswered because the expected value of the result does not justify the cost of implementation. A visual editor lowers the incremental cost of answering them, resulting in teams running more experiments.

The real advantage is that teams can explore more ideas, test smaller assumptions, iterate on promising concepts, and build a clearer understanding of what customers respond to.

Instead of spending weeks debating which message should become the new default, teams can put several credible alternatives in front of real users and measure the result. You can even run a multi-arm bandit directly from the AI Visual Editor. The new workflow becomes:

1. Identify an opportunity.
2. Create a high-quality variation.
3. Launch it safely.
4. Measure its effect.
5. Use the result to inform the next decision.

The faster that loop becomes, the faster a team can improve.

Personalize messaging for different audiences

Most websites present a single version of the company to every visitor.

But not every visitor arrives with the same problem, the same level of familiarity, or the same reason for evaluating the product.

Someone arriving from an AI-focused campaign may care about evaluating nondeterministic product experiences. An enterprise buyer may care more about security, governance, and deployment flexibility. A developer may care about SDK performance and implementation details. A marketing leader may care about conversion rates and how quickly their team can launch tests.

Sending all of these visitors to the same generic page often means presenting each of them with a diluted version of the message they actually need.

Client-side experimentation gives growth and marketing teams a practical way to test more relevant experiences for different audiences. The objective is not personalization for its own sake. Every additional experience creates complexity, and not every audience needs its own version of a website.

The value comes from being able to test whether a more relevant message actually improves the outcome.

Validate ideas before investing in permanent development

Some ideas require substantial engineering work to implement correctly.

A redesigned pricing page may need new components. A different onboarding flow may require backend changes. A personalized experience may eventually need to be integrated deeply into the application.

But teams do not always need to build the complete version before learning whether the underlying idea has value.

A visual experiment can serve as a lightweight production prototype.

A growth team can create a realistic variation, expose it to a controlled audience, and measure whether it changes customer behavior. If the experiment performs poorly, the company avoids investing in a larger implementation. If it performs well, the team has evidence that can justify and guide the permanent build.

Not every experiment can or should be implemented through a visual editor. Changes involving application logic, backend systems, authentication, pricing calculations, or complex product behavior will still require engineering.

But even in those cases, a client-side test may help validate the customer-facing premise before the company commits to the full investment.

Turn experimentation into a fun part of your work

Growth and marketing teams should not need to choose between moving quickly and running rigorous experiments. But more than that, GrowthBook’s AI Visual Editor allows your team to express their creativity while measuring quantifiable results.

Because the goal is not simply to change the website faster.

It is to learn what works, and have fun while doing it. The new AI Visual Editor is a Chrome extension. You can add it to your browser, open up the extension, connect to your GrowthBook account, and create experiments. Read the Visual Editor docs to see how it fits your setup.

Original source

Despite the major version bump, GrowthBook 5.0 does not have any breaking changes and can be upgraded to safely.

A year ago when we released version 4.0, the world of product development looked completely different. Claude Code had just launched, agent skills didn't exist yet, engineers were still writing code by hand. The world today is almost unrecognizable. GrowthBook too has changed rapidly in that time and we wanted to signify the massive improvements over the past year with a new major version.

Agentic Experience

Everything a human can do in the GrowthBook UI, an Agent should be able to do programatically. We aren’t 100% there yet, but this release pushes us much closer to that goal:

• Official Skills for common workflows like starting an experiment, summarizing results, or cleaning up stale flags. Use these in Claude, Cursor, Codex, or wherever else your agents live.
• In-App Assistant with access to the same set of Official Skills, plus context about what page you are currently viewing. Use this to quickly automate tasks in the UI or ask questions about your flags or experiments without leaving GrowthBook.
• GrowthBook CLI - Brand new, with 100% coverage of our public REST API endpoints and a much better agent (and developer) experience.

Feature Flag Governance

Moving at AI speed requires strong guardrails and governance for feature flag changes. GrowthBook already had best-in-class capabilities here, but this release takes it to the next level:

• Custom Hooks V2 can now be configured for individual features and have improved performance, security, and the ability to differentiate between soft warnings and hard blockers.
• JSON Schema validation for string/number flags to enforce min/max values, static enum options, and more.
• Unreachable Rule Detection highlights in the UI when a feature rule is fully or partially unreachable due to conflicting rules above it
• JSON Sparse Patching lets you do partial updates to JSON feature flag values without copy/pasting the entire value.
• Constants let you define a single source of truth for feature values and reference them easily from multiple features and rules.
• Configs are a brand new composable and strongly typed way to build complex JSON flags for remote configuration.
• New Draft Review UX in a dedicated tab on feature pages help you quickly review proposed draft changes

Product Analytics

We launched Product Analytics in beta in GrowthBook 4.2. Since then, we’ve been hard at work fixing bugs, adding new features, and improving the UX. We still have a lot more planned, but we’re excited in this release to remove the “beta” tag and mark Product Analytics as generally available.

• Funnel Analysis lets you understand how users flow through your product. Define steps and see the drop-off rates as users progress through, filter to specific segments and date ranges, break out by dimensions, and more.
• Resizable Dashboard Blocks let you have full control over the grid in dashboards, including the ability to stack graphs side-by-side.
• Global Date Filters in dashboards and a way to easily compare to past date periods
• Meta Analysis Dashboard Blocks with data about your experimentation program. View your experiment velocity, win rate, or cumulative metric impact side-by-side with all of your other Product Analytics data.

Visual Editor

We built a brand new AI-native Visual Editor from scratch.

• Modern Chrome Extension runs in a dedicated side bar so it doesn’t conflict with your site and has a sleek modern design.
• Prompt-based Experiments let you explain what you want to test on your page and an agent will implement and configure everything for you. It feels like magic.
• Image Hosting on our global CDN to easily test AI-generated image variations on your site.
• Figma Integration to automatically implement designs. Go from mock-up to live in minutes.

Faster, Easier, Safer Experiments

Our goal is to reduce the cost of running an experiment down to zero. To that end, we’ve been hard at work making experiments easier to set up, faster to run, and safer to do at scale:

• Experiment Creation went from 23 (!!!) form fields down to just 5. We also redesigned the experiment draft page to make it easier to see what’s remaining and gain confidence before starting.
• Experiment Scheduling to start an experiment automatically at a future date.
• Query Performance has improved drastically for huge datasets, resulting in faster queries and lower compute costs. If you are analyzing experiment data at the petabyte scale, reach out to us so we can help you take advantage of all of these recent improvements.
• Experiment Custom Hooks let you write custom javascript snippets to validate experiments before save. Use this to enforce company (or project) wide standards and best practices. Currently only enabled for self-hosted Enterprise deployments.

Contributors

Thanks to all of our existing contributors: @jdorn, @Kevin-Chant, @mknowlton89, @ahdriel, @gazzdingo, @lukesonnet, @msamper, @bryce-fitzsimons, @nadapzy, @olu-an, @tzjames, @Auz, @oelshaikh, @nhat-growthbook, @csbailey5t, @teresayung, @anna-yn, @johnham-ant, @august-growthbook, @lillialjackson, @madhuchavva, @lukebrawleysmith and a big thanks to everyone who made their first contribution!

• @akramcodez made their first contribution in #6048
• @gerami-ant made their first contribution in #6072
• @alyssamichelle made their first contribution in #6194
• @ilyausorov made their first contribution in #6195
• @Sambhram1 made their first contribution in #5822
• @AnkittChauhan made their first contribution in #5523
• @CedricConday made their first contribution in #6238
• @dlin-growthbook made their first contribution in #6377

Original source

How agents operate GrowthBook

The Fyxer team ran 541 experiments last year with a small team. They didn’t just get faster at using their tools. They put agents in the loop to run the workflow itself.

This is the workflow they shared with us: someone fills out a form with a hypothesis and target metrics. This triggers an agent to create a flag and experiment in GrowthBook and publish to a company-wide experiment index. Someone starts the experiment with a “launch” message in Slack. Only 25% of their experiments won, but that fast iteration and learning loop helped drive ARR growth from $1M to $35M.

Fyxer wired that together themselves. GrowthBook 5.0 makes this agentic experience first-class and accessible for more users and teams natively. Now, agents can operate GrowthBook: create flags, set targeting rules, brainstorm and create and launch experiments, with a consistent experience across interfaces.

Agents can now run GrowthBook from the places you work. Picture one experiment over the course of a week.

You start a morning in Claude Desktop brainstorming your next experiment. The GrowthBook skills ground your ideas in your own history: what you’ve run, what succeeded, and how metrics moved.

You pick a direction, switch to Cursor and build it. Your agent creates the feature flag, sets up the variations, and configures the experiment alongside the code changes. Our skills carry guardrails, so the experiment lands as a draft for a teammate to review rather than a live test. Review, launch, and ship it.

Create an experiment with GrowthBook Skills in Claude

Later in the week, you’ve got results. You open the GrowthBook app and ask the new AI Assistant how the test did and whether you should ship. You want to dig deeper into how feature usage differs across segments, so you work with the AI analyst to build out a dashboard to share with the team.

You change tools, but the platform and the experience stay the same.

We built this consistency by building reusable foundation elements:

• 25 open-source skills that teach an agent how to use GrowthBook effectively across flags, experiments, and product analytics.
• A CLI rebuilt with Speakeasy that covers 100% of our REST API and regenerates automatically from our OpenAPI spec. It won’t drift, and it returns typed output with errors an agent can use effectively.
• A comprehensive REST API underneath that fuels the skills and the CLI. If you’d rather see it than read about it, watch here.

This foundation powers new ways you and your agents can run GrowthBook: the in-app AI Assistant, a reworked MCP server that integrates the skills, and a native Slack app (coming soon!).

How to trust your agents

When agents are part of your team, they should follow your team’s standards and processes, just like anyone else shipping flags or experiments. Agents can make mistakes, but we’ve built our skills and Assistant so that agent-driven changes land as drafts and a person reviews before anything publishes. The same approval policies, audit trails, and guardrails to catch bad flags before they ship apply to both humans and agents. Your team maintains judgment and governance.

We’ll dive more into the improvements we’ve made to governance, especially for features flags, on Thursday.

One platform for humans and agents

Whether you and your agents are in the terminal, the editor, or the app, you’re working on the same GrowthBook platform, with your flags, experiments, and warehouse data. We’ll keep evolving interfaces; you should never feel like you’ve outgrown the platform.

Connect your agent and run your first skill.

Sign up and join us for a live Office Hours Thursday, July 30, at 9am PT and tell us what to build next.

Tomorrow: the new AI Visual Editor, rebuilt from scratch to make experimentation easier in the browser.

Original source

GrowthBook 5.0 ships today

It’s not enough to write code and ship at the speed of AI. Companies that win consistently make their products better. GrowthBook 5.0 enables companies to build, ship, and improve their product at any scale.

Our last major release (v4) shipped a year ago. Since then, we’ve rewritten feature flags from scratch, built Product Analytics, made experimentation significantly faster, and integrated AI throughout.

GrowthBook 5.0 crystallizes the last year of work, and it’s big enough that a minor version number just wouldn’t do. We've touched nearly every corner of the platform, from how experiments are built to how flags are governed. And we’ve opened experimentation to your whole team, not just engineers. More people can ship flags, run tests, and make decisions from shared data, wherever they work: in the app, terminal, code editor, or browser.

There’s far more to cover than we can fit into one post, so we’re covering something new every day, all week:

• Monday: Agents. Official skills, a new in-app assistant, and a CLI that covers our entire API. Your agents can operate GrowthBook directly: ship flags, launch experiments, analyze results, and clean up after. → Read today's post
• Tuesday: The new AI Visual Editor. Rebuilt from scratch, AI-native experimentation from your browser, with image generation and Figma support. Your growth team can ship tests without waiting on an engineer.
• Wednesday: Product Analytics hits GA. Warehouse-native product analytics for engineers and experimenters, out of beta. Built on the same metrics your experiments already use, now with funnels, composable dashboards, and experiment meta-analysis.
• Thursday: Governance for feature flags. Customizable guardrails that catch bad flags before they ship, protecting rollouts whether they come from humans or AI agents.
• Friday: Faster experiments. Streamlined experiment setup, scheduled starts, and faster, cheaper warehouse queries. Designed for running experiments at scale.

GrowthBook 5.0 is live on Cloud now and available for self-hosted deployments. Check out the full release notes.

Sign up and join us for a live Office Hours on Thursday, July 30, at 9am PT. Bring your questions and tell us what we should build next.

Original source

GrowthBook’s AI Visual Editor lets anyone on your team go from idea to live experiment in minutes, without touching code. It's a way to scale experimentation beyond one team and across your whole organization.

Just describe the change you want in plain language. The editor handles the rest. No code, no dev ticket, no flicker. The result is a fully configured A/B test ready to launch from your GrowthBook account.

The AI Visual Editor is available on GrowthBook Pro and Enterprise plans.

How does GrowthBook’s new AI Visual Editor work?

The AI Visual Editor is a Google Chrome extension. Open it, connect to your GrowthBook account, and immediately get started. The extension stays in the sidebar and doesn’t overlap your page.

Describe the change you want, such as “make the headline larger and move the CTA button directly beneath,” and the editor will generate a variant in seconds.

There's no code to write. The editor understands the structure of your page, applies the change, and connects it directly to a GrowthBook experiment. You prompt, then preview your changes in real time without ever leaving the browser. If you want more control, you can use the manual editor to do fine adjustments.

Key features

AI-generated image creation and visual testing

The AI Visual Editor is a powerful creative tool. Describe the image you want and the editor generates it in real time, along with options you can place into the right spot on your page and size to fit exactly. Test hero images, product photos, background visuals, and more, iterating until you get what you want without a designer or a design file.

It’s a quick way to immediately see changes in context and visually brainstorm live before you build anything. Once you’re aligned on variations, publish and A/B test new designs in minutes.

Images are stored in GrowthBook’s image storage bucket and served from a CDN-fronted URL so SDKs can fetch them efficiently when delivering variations.

Design updates and layout changes

Beyond text and images, the AI Visual Editor also lets you adjust fonts, colors, padding, button styles, layouts, and more all through prompts or via the manual editor.

Make design decisions without mocking anything up or writing a line of code. Try it, see how it looks in context, and decide if it's worth testing before it goes live.

Import from Figma or an image design

You can quickly turn a Figma frame or mockup image into a testable variation. Import the file into the AI Visual Editor and it will rebuild it as a new component, placing it on the page as a variation. You can also add additional context as to how the AI is to implement the design. This makes it easy to test designs your team has mocked up, such as a new hero, redesigned pricing card, modal window, or promo banner.

What use cases does this work well for?

Landing page optimization and headline testing

The AI Visual Editor is ideal for landing page optimization, such as testing headlines, messaging, copy order, and structure. Use AI to generate variant ideas, preview them directly on the page, then launch the test in minutes.

Promotional banner and offer testing

Test things like the impact of a promotional banner on bookings to Hawaii. The AI Visual Editor lets you build and swap promotional messaging directly on the page. Run the experiment, read the results, and roll out the winner.

With GrowthBook’s feature targeting capabilities, you can deliver different promotions to different audiences based on the criteria you choose, personalizing as you see fit.

Experimentation for every team

The AI Visual Editor expands experimentation across your organization by putting the ability to build and launch tests directly in the hands of the people with ideas, regardless of technical skillset.

• Marketing and growth teams can independently run their own tests on landing pages, campaigns, and offers.
• Teams that want to move fast can go from idea to live experiment in minutes without touching a line of code.
• Product and design teams can validate new layouts, messaging, and user flows before investing engineering time.
• Developers can stay focused on higher-complexity work instead of implementing every copy or design test.

By unlocking experimentation across your organization, you get more tests, more learning, and faster iteration for everyone. It also improves collaboration by giving marketing, growth, and product teams shared visibility into what's working, so no one operates in a silo.

Your existing guardrails stay in place

The AI Visual Editor handles the creative execution by generating variants, applying changes, and wiring up the experiment, but everything still runs through the GrowthBook platform. Your approval and review workflows, as well as existing processes, remain in place, so your team maintains governance and control.

Get more out of your experimentation platform

The ability to go from idea to experiment in minutes, without engineering support, means more people can run experiments than ever before. And when more people can run experiments, it results in more learnings, faster and more informed decisions, and improvements that compound over time.

Try out the AI Visual Editor (beta)

The AI Visual Editor is currently in beta. Try it today, share your feedback directly with our team, and connect with other users in our community Slack channel.

Download the Chrome extension

Original source