Product Updates

The Java SDK adds evalFeatures for evaluating several feature keys for the same user. Instead of calling the single-feature API repeatedly, pass a list of keys and receive a map of individual FeatureResult objects.

Get results by feature key

Both the single-user and multi-user clients use one evaluation context for the batch. The result map preserves the first appearance of each key and deduplicates repeated top-level keys. Use Object.class when the requested flags contain different value types.

For an initialized multi-user client and an existing userContext, a call can look like this:

Map<String, FeatureResult<Object>> results = gb.evalFeatures(
    Arrays.asList("new-checkout", "button-color"),
    Object.class,
    userContext
);

Inspect each result by its feature key. If evaluating a key throws a RuntimeException, that key receives an UNKNOWN_FEATURE result with a null value, while the remaining keys can still be evaluated. This does not turn the batch into a single success-or-failure result.

Getting started

Follow the Java SDK setup guide, confirm your installed package exposes evalFeatures, and try it with a small set of flags for one user. Check result handling and tracking callbacks before replacing existing single-feature calls.

GrowthBook adds more query-level diagnostics to help you investigate the warehouse work behind an analysis. The update expands statistics for Snowflake and Athena, corrects collection for BigQuery, Presto and ClickHouse, and adds query audit-log recording.

Investigate the query behind an analysis

Use View Queries to inspect the available warehouse statistics alongside the generated SQL. For example, when an analysis takes longer than expected, start with its queries to identify which work needs closer investigation before changing your metric definitions.

The updated SQL execution path records diagnostic metadata for both successful and failed queries. Failed-query records can include the warehouse's error message and code, helping distinguish a database failure from an unexpected analysis result.

Available statistics depend on the warehouse and its monitoring response. Treat the audit records as diagnostic context rather than a guarantee that every query path has complete statistics.

Getting started

Open View Queries for an analysis and inspect the statistics available for your data source. Use the query optimization guide to investigate relevant changes to SQL templates, fact tables or pipeline settings.

Experiment results now give you more context for understanding adjusted estimates. Explanations beside CUPED and post-stratification settings point you toward the metric drilldown, where an adjustment summary helps you investigate the differences.

Follow the explanation into the result

For applicable analyses, the summary highlights the influence of CUPED, post-stratification, Bayesian priors and capping. Select an adjustment to jump to its existing detailed section rather than searching through the drilldown yourself.

For example, if an adjusted revenue estimate looks different from the raw variation averages, open that metric and inspect the relevant adjustment. The summary's small, moderate and large labels describe differences between analytical estimates; they do not measure additional business impact or introduce a new statistical method.

The explanations appear when the analysis contains the relevant data and uses the adjustment. Available details depend on the analysis and statistical engine.

Getting started

Open an experiment's Results tab and select a metric row to open its drilldown. Use the Debug tab to inspect applicable adjustments, following the experiment results guide.

Saved Group references let you reuse targeting definitions without copying each group's contents into every rule. Enterprise teams can send each group once in an SDK payload, then reference it wherever it is needed.

Configure references and check targeting health

The SDK Connection offers ID Lists only and All Saved Groups formats. The broader format requires a compatible SDK, so check every application consuming the connection before changing it. Updating the connection does not upgrade the SDKs in those applications.

Broken-reference diagnostics help identify targeting that points to missing or invalid groups. For example, if a rule references a group that has been removed, inspect the flagged condition and repair its reference before relying on that rule for a rollout.

Missing references, nested conditions and exclusions can behave differently across payload formats and SDK versions. Review those cases when adopting reference-based targeting rather than assuming every SDK handles them identically.

Getting started

Review the Saved Group reference options, confirm compatible SDK versions across the connection, and select the appropriate format. Check affected targeting and any broken-group health warnings before rolling the change out.

GrowthBook's beta LLM-tracing integrations connect experiment assignments with the observability data you already collect. Compare prompt or model variations using latency, token cost, errors and evaluation scores, alongside relevant business metrics.

Tie a trace to the variation a user saw

Attach an assignment tag such as gb.exp:support-prompt=variant-b to the trace. The JavaScript tracing plugin collects assignment tags; your application passes them to its tracing SDK before the trace or root span starts. The recorded user or session identifier must match the identifier used for assignment.

The generated integrations target self-hosted Langfuse v3 on ClickHouse and Arize Phoenix backed by Postgres. Langfuse Cloud requires exporting data into a warehouse and adapting the SQL. These trackers are in beta, and their underlying database schemas can change.

For example, test a revised support prompt with helpfulness as a goal and latency or cost as guardrails. Trace metrics tell you how the model behaved; business metrics help assess the product outcome.

Getting started

Follow the LLM experimentation setup guide to tag assignments, connect the appropriate tracing database and validate the generated queries. The public announcement introduces this workflow as a GrowthBook Cloud beta.

The GrowthBook Wizard hands SDK setup to the coding agent you already use. Choose your SDK language and agent, run one command in your project, and the wizard handles sign-in and the SDK Connection. Your agent then plans the application changes and asks you to approve that plan before it edits anything.

From connection to application code

The manual setup path is still available, and it has you follow the installation steps for your language yourself. With the wizard, the work is divided between the wizard and your agent:

• Create an SDK Connection for your chosen environment, or reuse one with matching settings.
• Install GrowthBook Agent Skills so your agent can keep working with flags and experiments later.
• Connect the SDK and check that your project builds.
• Add the targeting attributes you select, such as user ID or plan.
• Flag a behavior you choose, or finish without a flag.
• Open a setup report so you can review created items and failed required checks.

What setup confirms

The report's checks inspect your code. Your SDK Connection shows as connected only after your application requests features from GrowthBook. A/B tests still need metrics and a data source, which setup does not create.

If work is interrupted, your agent can continue from GROWTHBOOK_SETUP.md in your repository root.

Getting started

Use Node.js 22.20.0 or newer and a supported coding agent, such as Claude Code, Cursor, Codex, opencode, Gemini CLI, or Antigravity. In GrowthBook, open Get Started → Connect Your SDK. Select your SDK language and coding agent on the AI-assisted tab. Run the copied command from your repository root, then review your agent's plan.

GrowthBook shows this flow for organizations whose creator selected Engineering at signup. Vercel-managed organizations have their own flow. No-code platforms, Roku, and generic script tags use manual setup. Self-hosted instances need browser sign-in.

Follow the Setup Wizard guide for prerequisites and agent-specific instructions.

User Journeys lets you explore the actions people take around an event in your product. Start with a step you care about, then follow the actions immediately before or after it to discover paths worth investigating.

Follow the paths around an event

Choose a starting or ending step and click through neighboring actions to follow a journey further. For example, start with account creation to explore what people do next, or work backward from a conversion to examine the paths leading to it.

When a path deserves a closer look, you can switch to Funnel Explorer for a focused follow-up analysis. Funnel Builder access depends on your plan, even though User Journeys is listed across GrowthBook's Cloud and self-hosted tiers.

Getting started

Choose an event and explore its preceding or following actions. Use the GrowthBook 5.1 overview for the announced workflow and check Product Analytics plan availability before moving into Funnel Builder.

SQL Explorer has been rebuilt around a query-to-chart workflow in Product Analytics. You can write SQL against your warehouse, preview the results, then filter, group, and chart those rows without defining a GrowthBook metric first.

From query to exploration

Start with the rows you want to analyze, then configure the view:

• Browse your warehouse schema and write a read-only SELECT query.
• Run the query to preview up to 100 rows. Switch to Explore Dataset to configure values, filters, groupings, and chart type.
• Choose a raw table for unaggregated rows or a chart for an aggregated view.

A timestamp column is optional. Date filtering, period comparisons, and time-series charts require one. If you change the SQL, run the query again to update the available columns.

Keep a useful view

You can save a SQL exploration to a dashboard. Saving requires Pro or Enterprise, the Product Analytics Dashboards entitlement, and permission to create or edit the destination dashboard.

Existing Custom SQL Reports remain accessible through the legacy-reports banner in SQL Explorer.

Getting started

Open Product Analytics → SQL Explorer and choose a data source on Build Dataset. You need the Run SQL Explorer Queries permission. Select Run Query, check the preview, then switch to Explore Dataset.

Follow the SQL Explorer guide for the query and chart setup.

Connect your Slack workspace to GrowthBook once, then choose the notifications each channel receives. Experiment and feature flag updates reach the channels where teams already discuss that work, including people who rarely open GrowthBook.

What changed

Before the app, a Slack connection meant creating your own Slack app and entering its app ID, signing key, and incoming webhook URL in GrowthBook. Now you approve the GrowthBook app for your workspace and add channels from GrowthBook.

Choose what each channel receives

You configure each channel separately:

• Choose recommended events, all events, or a custom selection for each event category.
• Limit notifications to selected projects, environments, and tags.
• Pause a channel without losing its settings.

Send a test notification to check its format and delivery. The test is labeled as sample data and doesn't create a real event, so it doesn't confirm that your filters match live events.

Existing incoming webhook connections keep working. Once the app is posting to a channel, remove any old webhook that posts there so people don't get every notification twice.

Getting started

The Slack app is in beta. You need the manageIntegrations permission in GrowthBook, which the Admin role includes, and permission to install apps in your Slack workspace.

• Go to Settings → Slack, click Connect to Slack, and approve the app for your workspace.
• Click Add channel, choose its events and scope, then click Save settings.
• For a private channel, run /invite @GrowthBook in that channel first.

Follow the Slack app setup guide for prerequisites, channel settings, and test notifications.

GrowthBook Cloud has a hosted MCP server at https://mcp.growthbook.io/mcp. Add that URL to an AI tool such as Cursor, VS Code, or Claude, then sign in through your browser. You don't run a local process or paste an API key into the tool's configuration.

Work from your AI tool

The server loads GrowthBook agent skills, which hold the workflows and guardrails for common tasks. It also makes authenticated calls to the GrowthBook REST API. Once you're connected, you ask for an outcome and the agent loads the matching skill. For example, you can ask it to:

• Create a boolean feature flag that defaults to false.
• List stale feature flags that are safe to clean up.
• Summarize an experiment's results and recommend whether to ship the winner.

If you bring your own skills, connect to https://mcp.growthbook.io/mcp/api instead. That endpoint exposes only the API read and write tools.

What the connection can do

The hosted server acts with your own GrowthBook permissions, so an agent reaches only what your account can already see. When you sign in, the consent page asks what the connection may do, such as Read only or Full access. The choices depend on your plan. On Enterprise, Human-in-the-Loop holds risky changes until a person confirms them.

Getting started

• Use a client that supports remote HTTP MCP with OAuth.
• In the client's MCP server settings, add https://mcp.growthbook.io/mcp.
• Complete the GrowthBook sign-in in your browser and choose the connection's permissions. Then ask your agent for an experiment's results.
• If you self-host GrowthBook, run the official MCP Docker image against your own API instead. Your API must expose its OAuth Authorization Server. On older GrowthBook versions, set OAUTH_AS_ENABLED=1 on the API to turn it on.

The MCP setup guide covers each client and the self-hosted options.

Funnel metrics measure a multi-step journey inside an experiment, such as viewing a product, adding it to a cart, and purchasing. One metric gives you the end-to-end completion rate for each variation. You can expand it to see where units drop off at each step.

Define the journey once

Before this, a funnel in an experiment relied on legacy metrics, where a binomial denominator metric acted as a filter on the numerator. Funnel metrics replace that approach. A funnel metric is a Fact Table metric with an ordered list of steps instead of a numerator:

• Define each step with a Fact Table, row filters, and an optional conversion window.
• Point steps at different Fact Tables in the same Data Source, such as product views in an events table and purchases in an orders table.
• Mark a step optional when skipping it should not block later steps.

Read it in your results

In the results table, the funnel is one row you can expand into a row per step, with each step's conversion rate and lift. Each step uses all exposed units as its denominator, not only units who reached the previous step. The metric's own value is the share of units who reach the last step.

This makes funnel metrics a fit for testing marketing funnels, onboarding flows, and other multi-step experiences. For ad-hoc funnel analysis outside an experiment, use the Funnel Explorer in Product Analytics.

Getting started

Funnel metrics are available on Pro and Enterprise Cloud plans, and on Enterprise when self-hosted. They need a supported data source, and each step's Fact Table must share an identifier with your experiment's assignment data. Funnel metrics don't yet work with Incremental Refresh, and CUPED is off for a funnel and its steps.

• In Metrics, click Add Metric, choose your Data Source, then select Funnel.
• Add at least 2 steps, save the metric, and add it to an experiment.

Follow the funnel metric setup guide for step settings, optional steps, and the API.

Contextual bandits learn which variation works best for each kind of user, not only which one works best overall. You personalize on attributes such as country, device, or plan. Traffic weights then adapt within each context toward one decision metric.

From one winner to a winner per segment

A multi-armed bandit shifts traffic toward a single winner for everyone. A standard experiment can show in its dimension breakdowns that segments preferred different variations. You still have to build and ship those targeting rules by hand. A contextual bandit shifts traffic within each segment during the run and keeps adapting after you would have stopped an experiment.

How it learns within each context

GrowthBook fits a decision tree over your context attributes, grouping users who share similar context. Within each group, Thompson sampling balances trying variations with sending more traffic to better performers. Every variation keeps at least a small share of traffic in each context.

• Personalize on attributes your SDK knows when it assigns a variation.
• Choose one Fact Metric as the decision metric.
• Watch current weights and per-context results on the bandit's page.

When to use one

Contextual bandits fit when you expect the best variation to differ by segment. Examples include checkout copy that lands differently by country, or a layout that helps on mobile but not on desktop. They also suit short-lived tests, such as promotional copy, when performance likely varies by context. Each segment needs enough traffic to learn, and GrowthBook pools smaller segments with similar users. For unbiased effect estimates or several outcome metrics, run a standard experiment.

Getting started

Contextual bandits are a beta feature on Enterprise plans.

• Under SDK Configuration → SDK Connections, check that the connection uses a supported SDK language and a compatible version.
• Log the context attributes used for assignment, and include matching columns in your Contextual Bandit Assignment Query.
• Create a bandit under Experiments → Contextual Bandits and link at least one feature flag. Starting the bandit automatically publishes pending drafts on its linked flags.

Follow the contextual bandit setup guide for supported SDK versions and the full launch steps.

GrowthBook Managed Warehouse supports event ingestion and storage in AWS's EU region in Ireland (eu-west-1). Teams that need their collected event data to stay in the EU can choose that region when creating a Managed Warehouse data source.

Choose the region for your event data

The EU option covers event ingestion and storage in the managed ClickHouse warehouse. GrowthBook's application, login, configuration and computed experiment results remain hosted in the US. This is an event-data residency option, rather than a move of the entire GrowthBook platform to the EU.

Your SDK must send events to the ingestor that matches the data source. The EU endpoint is https://eu-west-1.gb-ingest.com; an SDK left on the default US endpoint will not deliver events to an EU warehouse. For example, a team creating an EU data source should configure the matching host before checking that its first events arrive.

Getting started

Create a Managed Warehouse data source under Metrics and Data → Data Sources, choose the EU region, and configure the corresponding ingestion host. Follow the Managed Warehouse setup guide for your SDK and verify incoming events in SQL Explorer.

Learnings let you save conclusions from multiple experiments and bring that evidence into future work. Capture a pattern once, keep supporting and contradicting experiments attached, and make the conclusion available to teammates and agents planning the next change.

Keep the evidence with the conclusion

Each learning can carry the context needed to interpret it:

• Link experiments that support or contradict the conclusion.
• Scope the learning to projects and tags.
• Use a customizable status to mark unverified or outdated conclusions.
• Update the learning when new evidence arrives.

You can also capture qualitative findings alongside experiment evidence. Keep the conclusion's scope clear so a pattern from one workflow doesn't become a rule for every part of your product.

Bring past evidence into new work

Learnings are accessible through GrowthBook's API and MCP support. Agents can retrieve relevant conclusions before designing or implementing a change, with the underlying experiments still available as evidence.

Getting started

Open the Learnings page and add a conclusion with its supporting and contradicting experiments. For API creation and updates, your plan must include Learnings. Semantic search also requires AI access and available embedding capacity.

See the Learning record reference for the fields a learning can contain.

GrowthBook adds Adobe Experience Platform Query Service as a data source, released as an early preview. If your event data lives in Adobe XDM datasets, you can define assignment queries and metrics against it. GrowthBook runs read-only queries on that data to build experiment results.

Connect with Adobe credentials

An Adobe System Admin first configures the required sandbox and Query Service permissions. You then connect with a non-expiring OAuth Server-to-Server credential and the connection values Adobe provides.

The connector reaches Query Service through its PostgreSQL-compatible interface, but it generates SQL tailored to Adobe. Treat it as its own connection type rather than a generic PostgreSQL source. Adobe's interactive-query timeout, result caps, and license-specific concurrency limits still apply.

Check the supported scope

Some GrowthBook capabilities are currently unavailable on this connection, so plan your analysis around them:

• Schema browsing doesn't suggest tables or columns while you write queries.
• Funnel metrics and funnel explorations are unavailable.
• Incremental refresh is unavailable.

If one of these blocks your team, contact GrowthBook support.

Getting started

In Metrics and Data → Data Sources, add a data source and choose Manual Set Up. Select Experience Platform, enter Adobe's connection details, and save. GrowthBook tests the connection when you save. Then create assignment queries and fact tables for your XDM datasets. Follow the Adobe Query Service setup guide for field mapping and current limits.

GrowthBook's Swift and Kotlin SDK changes add typed helpers for feature values, with defaults chosen in application code. Swift uses an explicit type argument. Kotlin's companion module keeps a feature key and default together. The fallback rules differ by API.

Choose values and defaults

Use the helper that matches the value your application expects:

• Swift's getFeatureValue(feature:as:default:) adds an explicit as: label. The Int overload returns your default when integer conversion is unavailable. The existing JSON-returning getter remains.
• Kotlin's GrowthBookExt module adds Flag<T> declarations and value(flag). Supported defaults are Boolean, String, Int, Long, Float, and Double. Other types throw.

A Kotlin flag's default covers missing or unreadable values. The separate FAIL_OPEN and FAIL_CLOSED policies apply only to unknown features. Before the first payload loads, a feature may be unknown, so choose startup behavior deliberately.

Decode Kotlin configuration models

For custom Kotlin models, decodeAs<T>() uses the optional GrowthBookKotlinxSerialization module. Its default decoder ignores unknown fields, and you can supply custom Json settings.

Caught decoding exceptions return null, so handle that result in your application. Serialization happens before that catch.

Getting started

Compare the helper signatures with your installed SDK before changing feature reads. Check the expected value type and fallback for one feature, including its behavior before definitions load. Review the Swift SDK setup or Kotlin serialization guide.

Feature flags can reach multiple projects while keeping one primary project for ownership. You can share a flag with the projects that need it, then scope individual rules within that delivery set. You manage one shared flag instead of copying it into each project.

Separate ownership from delivery

A flag used to belong to a single project. If your projects map to services, apps, or teams, a flag that several of them needed didn't fit that model. Feature-level targeting now controls where the flag is delivered:

• Editing and publishing permissions stay tied to the primary project.
• Add specific Targeting Projects, or target all projects.
• SDK connections scoped to the primary project or a targeted project receive the flag.

Scope individual rules

A rule's project scope limits that rule to selected projects within the flag's delivery set. Leave the rule unscoped to cover the full set. Its environment scope and targeting conditions still apply.

A rule scoped to a project outside the flag's delivery set has no effect.

Getting started

Sharing needs at least two projects. On current plans, Free includes one project and Pro includes three.

• Open a feature and choose its destinations with Targeting Projects.
• To narrow a rule, set its project scope beneath the rule's environment scope.
• Before publishing, check that you can target each destination project and whether its approval requirements apply.

Read the cross-project delivery guide.

GrowthBook extends schema validation to string and number flags and lets you attach Custom Hooks to a single feature. You can limit a flag to the values your code expects and give one flag its own checks, alongside broader organization and project rules.

Set boundaries for flag values

GrowthBook could already validate the shape of JSON flag values. Schema validation now covers string and number flags too, and is available with GrowthBook Enterprise. With validation enabled, you can:

• Restrict a string flag to approved values, such as classic, compact, or express.
• Set minimum and maximum values for a number flag, such as 10 to 100 results per page.

This is useful when several people edit a flag and only a few values are safe to serve. When someone tries to save a value that doesn't match the schema, GrowthBook shows an inline error with the reason it failed. Boolean flags can't have a schema.

Apply checks to one flag

Custom Hooks previously applied to every feature in an organization or project. On self-hosted GrowthBook Enterprise, you can now attach a hook to a single flag for rules that a schema can't express. For example, require a description before that flag is enabled in production.

The flag's Validation tab also lists the organization and project hooks that apply to it. Keep hooks fast and free of side effects, because a hook can run more than once during a save.

Getting started

• Open a string or number flag, go to its Validation tab, and click Enable under Schema Validation. Define the allowed values or numeric bounds, then try a value against them.
• To add a hook for one flag, you need edit access to that flag. Create the hook from the flag's Validation tab, and use the built-in test interface to run it before saving.
• Follow the Custom Hooks guide for hook types, scopes, and examples.

Databricks data sources in GrowthBook can authenticate with OAuth machine-to-machine (M2M) using a service principal. You enter the service principal's Client ID and OAuth secret instead of a personal access token. Databricks recommends OAuth over personal access tokens for stronger security.

How authentication works

GrowthBook exchanges the service principal's Client ID and OAuth secret for short-lived access tokens at query time and refreshes them automatically. The connection doesn't need a long-lived personal access token.

• Personal access token (PAT) authentication remains supported, and existing Databricks connections keep using their token.
• If you switch an existing connection from a token to OAuth, GrowthBook asks for the new OAuth secret before you save.

Prepare the connection

Create or reuse a Databricks service principal and generate an OAuth secret for it. Grant the service principal permission to use your SQL Warehouse and access the data you want to query. Then have these values ready:

• The SQL Warehouse's server hostname, port, and HTTP path, from its Connection Details page in Databricks.
• The service principal's Client ID and OAuth secret. Databricks shows the secret only once, so copy it when you generate it.

Getting started

On the Data Sources page under Metrics and Data, add a data source and choose Databricks. Set Authentication method to OAuth (machine-to-machine), then enter the warehouse details, Client ID, and OAuth secret. The Databricks setup guide walks through each step, including service principal permissions.

Product Analytics is generally available with GrowthBook 5.0. You can explore product trends and build dashboards from the warehouse data and metrics you already use for experiments. That lets you investigate a KPI without starting an experiment.

Use the definitions you already have

If you run experiments in GrowthBook, your data source is connected and your metrics are defined. Product Analytics reuses those definitions, so a KPI chart and an experiment result draw on the same metric. Use it to look for what to test next, or to keep watching a KPI after a change ships.

Choose the manual explorer that fits your question:

• Chart a metric over time using its existing definition.
• Aggregate a fact table by counts, distinct units, or sums.
• Explore a timestamped warehouse table without first defining a fact table.

Put findings in one view

Build a dashboard from explorations, saved SQL results, and Markdown notes. In edit mode, drag and resize blocks to arrange related charts side by side.

Dashboard date filters coordinate supported exploration blocks, while individual blocks can keep their own range. Follow any refresh prompt after changing the filter before reading the updated results.

Getting started

With a connected data source and defined metrics, open Product Analytics and choose Metrics. Select a metric and date range, then click Update to inspect the chart.

Manual metric, fact table, and data source explorations are available on all plans. Private dashboards require Pro or Enterprise; organization sharing requires Enterprise. Saving an exploration also needs permission to create or edit the destination dashboard.

Use Save to Dashboard to keep the chart, and follow the Product Analytics guide for setup.

GrowthBook's rebuilt AI Visual Editor lets you create website experiment variations from a Chrome side panel. Describe a change in plain language or edit elements by hand. You can also generate images or start from a Figma frame, then review each change before it reaches visitors.

Build and review variations

Open the side panel next to the page you want to test, and work from an idea or an existing design:

• Describe edits in plain language, or use manual controls for individual elements.
• Preview each suggested change on the page, then accept it, reject it, or fine-tune it in Manual mode.
• Generate replacement imagery, or turn a Figma frame or mockup into a page component.

This lets you try a different headline or hero design without building each variation into your application. Design import handles one component at a time, not whole-page redesigns, so review generated designs before you accept them.

Prepare your site

The editor builds variations in your browser. To show them to real visitors, your site needs a GrowthBook front-end SDK, such as the Script Tag, JavaScript, or React SDK, or an Edge SDK. Turn on Include Visual Experiments on that SDK Connection. Without it, visual experiments are left out of the SDK payload and don't render.

GrowthBook Cloud Pro and Enterprise include the AI Visual Editor. AI mode also needs your organization's AI configuration. Design import needs a compatible GrowthBook server and a vision-capable model, and importing from Figma requires a Figma connection.

Getting started

• Install the AI Visual Editor extension from the Chrome Web Store, open its side panel, and click Connect with GrowthBook.
• Open the page you want to test, describe an edit, and review the proposal.
• Follow the AI Visual Editor setup guide to install the extension and connect your account.

The in-app AI Assistant brings flag, experiment, and analytics workflows into the GrowthBook app. Ask how an experiment performed, get help with targeting rules, or explore product trends without leaving the place where you manage your tests and releases.

What you can ask for

Describe the task in plain language:

• Ask for help creating a feature flag or setting its targeting rules.
• Ask how an experiment performed before deciding what to ship.
• Ask about product trends using your GrowthBook data.

How it works

The Assistant uses the same shared GrowthBook skills that cover flag management, experiment design and analytics. It loads the workflow it needs for a request and makes API calls inside your signed-in session. Name the flag, experiment or metric you mean so the request has a clear target, and review any suggested change before you let it proceed.

Getting started

Your plan needs to include AI features, and an admin must turn them on for your organization under Settings → General → AI. Self-hosted deployments also need a configured AI provider key. Then open the Assistant from GrowthBook's top navigation and ask about an experiment by name. Log in to GrowthBook to try it.

GrowthBook's existing MCP server is now complemented by official agent skills and a rebuilt CLI. Use task-specific playbooks in your coding agent, or manage flags and experiments through terminal commands built on the REST API.

Choose how you work

• Use agent skills to create flags, configure targeting, and design or analyze experiments.
• Use CLI commands to inspect flags, list experiments, and return JSON for shell pipelines.

The skills are task-specific playbooks. They give your agent a defined GrowthBook workflow to follow, rather than relying on a one-off prompt. The CLI is generated from GrowthBook's OpenAPI specification, with command groups for API resources. You can use those commands directly in scripts instead of asking an agent to interpret a task. The CLI is a rewrite of the earlier GrowthBook npm package, and the CLI guide covers importing your existing profiles.

Keep review in the workflow

The skills guide flag changes through draft, review, and publish steps. Review the prepared targeting and experiment variations before approving publication. The playbooks guide the agent, but they don't prevent every mistaken action. The CLI also includes write commands, so not every command is read-only.

Getting started

For terminal access, install the CLI with Node.js 16 or newer. Then authenticate with a GrowthBook Secret Key or Personal Access Token:

npm install -g growthbook
growthbook auth login
growthbook features list

Check that the list contains flags from the organization you intended to access. Self-hosted servers need GrowthBook 4.4.0 or newer for the full CLI command set. Follow the CLI setup guide for server configuration and other authentication options.

For agent skills, use a compatible agent that can run shell commands, and Node.js 18 or newer. Follow the Agent Skills installation and credential setup.

You can create an experiment draft from the Experiments page before choosing every analysis setting. The creation form asks only for the essentials, then takes you to Overview to finish setup. You can write the hypothesis, pick the assignment attribute and share the draft while you work out the data source, assignment table and metrics.

Finish setup on Overview

Options that used to sit in the creation form now live on the experiment's Overview page. For a standard experiment, the pre-launch checklist guides you through the remaining configuration:

• Select a data source and experiment assignment table.
• Add at least one goal metric.
• Link a feature flag, Visual Editor change or URL redirect, depending on how you deliver the experiment.

Most configuration happens after creation, so you can come back to the draft as each decision is made. Enterprise customers can customize the pre-launch checklist.

Review automatic selections

When possible, GrowthBook fills in the data source and experiment assignment table for you. Before launch, check those selections against your assignment attribute. Automatic selection doesn't confirm that the assignment table matches that attribute's identifier type, so take a closer look when you start from a template.

Getting started

Go to Experiments, click Add → Create New Experiment, and enter the experiment details. Create the draft, then complete setup on Overview. The experiment configuration guide covers each field and the remaining settings.

Custom Hooks now check experiments as well as feature flags. A validateExperiment hook runs your team's JavaScript against the proposed experiment, including its custom field values. It can warn about or reject a creation, edit, start, or stop that breaks your rules.

Put your requirements into code

Use a validateExperiment hook to apply checks such as:

• Require a hypothesis before an experiment starts.
• Require a linked ticket when a checkout surface is selected.
• Check one custom field against another.

A hook can raise a warning that a person reviews before saving. It can also throw an error that blocks the action.

Let people finish their drafts

An experiment created in the app starts as a draft. Metrics, variations, and other settings are often added later. The hook still runs at creation, so a rule that needs those later fields could stop someone from creating the draft. If a check only matters at launch, skip drafts in your hook.

The hook also runs when an experiment stops. Check that your rules won't prevent someone from ending an experiment.

Getting started

Custom Hooks require self-hosted GrowthBook Enterprise. You also need the Custom Hooks permission to configure global or project rules.

• Open Settings → Custom Hooks and create a global or project-scoped validateExperiment hook.
• Use the built-in test interface to try draft and running inputs, then enable the hook.

Read the experiment validation hook docs.

A monitored ramp watches guardrail metrics as it moves through its steps, and its status updates as new results come in. Scheduled refreshes no longer skip a monitored ramp solely because it lacks a separate Safe Rollout rule. The ramp's own monitoring interval now sets when the next analysis attempt is scheduled.

What changed

Before this fix, the scheduled refresh job looked for a classic Safe Rollout rule that a monitored ramp doesn't have. It could skip the ramp, so the ramp kept waiting for fresh analysis. The job now passes that check for monitored ramps, and the rollout's monitoring interval takes precedence over the organization's experiment update schedule.

How a scheduled refresh behaves

• If an analysis is already running, GrowthBook defers the next attempt instead of starting another.
• A missing or archived feature still stops the refresh.
• A refresh is an attempt to update results. It doesn't mean the analysis has completed or that the ramp has advanced, so review results and step progress separately.

Getting started

• In the feature's rule editor, choose Monitored Ramp-up as the release plan, or turn on Monitor this release on a ramp schedule.
• Use Refresh results every to set how often GrowthBook re-analyzes your metrics, then publish the revision to start the schedule.
• After it starts, check the status and progress shown on the rule. The ramp schedules guide covers monitored steps and guardrails.

You can use remote evaluation from the Python, PHP and Java SDKs. Send targeting attributes to your evaluation endpoint and use the returned features instead of loading the full feature payload into the calling SDK. Each SDK has its own configuration, so use the option for your language.

Choose the SDK path

• Python supports remote evaluation in synchronous and asynchronous clients through remote_eval.
• PHP uses remoteEval with initialize, a client key and your proxy URL.
• Java supports remoteEval(true) on GrowthBookClient and GBContext. Leave refreshStrategy unset for the basic configuration.

Configure the evaluation backend

Use a self-hosted proxy or edge endpoint, including when your GrowthBook account runs in Cloud. These remote modes reject a local decryption key or sticky-bucket service.

Remote evaluation adds a network dependency and infrastructure to maintain. Local evaluation remains the usual choice for an application running on a trusted backend.

Getting started

Enable remote evaluation in your SDK Connection settings, then configure your endpoint and client key in the SDK. Test a known flag with the targeting attributes your application sends. Follow the remote evaluation setup guide.

Saved Group revisions support review and scheduled publication. You can prepare a targeting change, request feedback, and choose a future publication date. For groups reused across features or experiments, this puts review and publication timing around a shared targeting change.

Review a proposed change

Saved Group revisions let you:

• Submit a draft for review.
• Revise a draft after changes are requested, then submit it again.
• Require approval through your organization's Saved Groups approval flow.

Required approvals depend on an Enterprise entitlement and your organization's approval settings.

Choose when to publish

You can schedule a revision for a future date. When the date arrives, a background job can attempt publication if automatic publication is still enabled and the revision remains active.

A scheduled date does not guarantee publication at that exact instant.

Getting started

Open organization settings and review the Saved Groups approval controls before preparing a revision. Check which approval requirements apply to your organization. If you're setting up GrowthBook, get started with the platform.

You can change selected fields in a JSON flag rule without copying the flag's entire default object. The rule stores only the keys you override, and GrowthBook fills in the unchanged top-level fields from the default. On a large configuration flag, each rule then holds only what it changes.

Keep the change small

For example, start with this default:

{"theme":"light","pageSize":20}

A sparse rule value needs only:

{"theme":"dark"}

The resolved value is {"theme":"dark","pageSize":20}. The editor displays this expanded value, so you can check the combined configuration.

Each sparse value merges onto the flag's default, not onto the values of other rules. If you turn sparse mode on for an existing rule, the editor keeps only the keys that differ from the default.

Know what gets replaced

• Use a JSON flag whose default is a plain object. Arrays, null, and primitive defaults do not support sparse merging.
• Overrides replace top-level properties. If a property contains a nested object, include every nested field you need in the replacement.
• Safe Rollout rules and holdout values are outside this change. A configured JSON schema takes precedence over sparse editing.

Getting started

Open a JSON flag with an object default, edit a forced-value rule, and enable sparse mode. Enter the changed keys and inspect the expanded value before saving.

Get started with GrowthBook.

Snowflake experiments can use incremental refresh to reuse intermediate results across updates. GrowthBook scans new assignments and metric facts using the previous update's recorded timestamps, then adds those rows to intermediate warehouse tables. You can start with one compatible experiment before applying incremental refresh more broadly.

Start with selected experiments

Incremental refresh is in beta on Enterprise plans. You can opt selected experiments into incremental refresh while retaining ephemeral mode as your data source's default. This lets you evaluate the pipeline on one compatible experiment first.

Check the data pipeline

GrowthBook needs a write-enabled destination schema and intermediate tables retained beyond 24 hours. Before starting, check that:

• Your experiment uses metrics defined from fact tables.
• Assignment and fact sources are partitioned on timestamp.
• Metric conversion windows include in-progress conversions.

This beta does not support activation metrics or dimension breakdowns in Experiment Dashboards. Restated data and late arrivals with older timestamps need a full refresh.

Getting started

On your Snowflake data source, open Data Pipeline Settings. Enable pipeline mode, choose Incremental refresh (Recommended), and set the destination schema and retention. Save, then test one compatible experiment and inspect its queries for intermediate tables. Follow the Snowflake pipeline setup guide.

Multi-armed bandits no longer require sticky bucketing. You can start a bandit without first setting up assignment storage in your SDK, then decide whether returning users keep their original variation. The bandit still shifts traffic based on performance against a single decision metric.

Choose the assignment behavior

Bandits used to list sticky bucketing as a setup prerequisite. Now it's a choice you make for each bandit, based on the experience you're testing:

• Leave sticky bucketing disabled when switching variations is acceptable. Returning users can move between variations as weights change.
• Use sticky bucketing when repeat visits should show the same experience, such as a promotional offer.

Sticky bucketing keeps the experience consistent, but it also keeps users in their first variation. That can limit how much traffic the bandit moves toward better-performing variations.

Align measurement and weight updates

When sticky bucketing is disabled, analysis uses a user's first exposure and its conversion window. A returning user may see a different variation later, while conversions can still count toward the original variation.

Match your conversion window to how long users take to convert, and choose an update cadence that accommodates that window. Your SDK also needs to receive weight updates promptly. Review SDK caches and any CDN or proxy caches against your update cadence.

Getting started

Multi-armed bandits are included in GrowthBook Cloud Pro and Enterprise, and Self-Hosted Enterprise. Bandits use the Bayesian engine.

In the bandit creation flow, choose your assignment attribute and Decision Metric, then enable or disable sticky bucketing for the bandit. If you enable sticky bucketing, also enable it for your organization and configure a sticky-bucketing service and assignment storage in a compatible SDK. Follow the bandit setup guide.

GrowthBook 4.4 brings Product Analytics explorations to MCP and the REST API. You can ask an agent or a script for a chart, such as daily signups by country, and get the data back without building a dashboard first. A deep link opens the same chart in GrowthBook when you want to look closer.

Choose what to explore

Run explorations against:

• Existing fact metrics, using your metric definitions.
• Fact tables, to analyze data from a configured fact table.
• Data-source tables, to analyze a table from your SQL data source.

Responses include the exploration configuration, date range, status, and result rows. The API also returns the first associated query when available. Inspect the returned configuration and dates alongside the values.

Getting started

Use a configured SQL data source and an account that can run its queries.

• For REST, create a personal access token under your user menu. Send a valid configuration to POST /api/v1/product-analytics/metric-exploration, then inspect the response.
• For MCP, connect your client and ask for a chart using your metric, date range, and breakdown. Open the returned exploration link to review the chart.

Use the current MCP setup guide to connect your client.

GrowthBook 4.4 introduced the AI Data Analyst beta for conversational product analytics. You can ask about your metrics in plain language and get charts and insights using the metrics, fact tables, and data sources already configured in GrowthBook.

Explore a question, then refine the chart

The analyst uses GrowthBook's exploration tools to help you:

• Find metrics and fact tables relevant to your question.
• Inspect columns and sample values before running an exploration.
• View a chart in the conversation, then open it in the Explorer for further editing.

For example, ask how daily active users vary by country. You can investigate that product question without writing a SQL query.

Getting started

To use AI Chat today, you need Pro or higher with AI Suggestions and a connected data source. Your organization must enable AI under Settings → General → AI. Ask an organization admin if AI is disabled. Self-hosted installations also need a configured provider API key.

Open Product Analytics in the sidebar and submit a question through AI Chat. Click the returned chart to review and adjust the exploration. Follow the AI Chat documentation for the workflow.

Ramp schedules let you plan a feature rollout before it starts. You set traffic and targeting for each stage and decide where a teammate must approve the next step. GrowthBook then carries out the stages for you, and you can save the plan to reuse.

Choose exposure and checkpoints

Each stage controls who gets the feature and when the rollout moves on:

• Set a rollout percentage and a wait time for each stage.
• Change targeting as the audience grows.
• Add an approval checkpoint so the schedule waits for a teammate before advancing.

A common pattern is to widen the audience in circles. Release to your own team first, then your whole company, then 10% of all users, and increase from there. An approval checkpoint gives someone a chance to check how the release is going before more people see it.

You can save the plan as a template and apply it to another feature. Before starting, review who receives the feature at each stage.

Add Safe Rollouts monitoring

Ramp schedules control timing, targeting, and approvals. Add Safe Rollouts monitoring when you also want metric checks as exposure grows. Monitoring is optional and configured separately.

Getting started

Ramp schedules currently require an Enterprise plan.

• Add a targeting rule to a feature, choose Ramp-up as its release plan, and configure the steps.
• Publish the revision to arm the schedule. A schedule saved inside a draft waits until you publish.
• Follow the ramp schedule setup guide for step options, approvals, and templates.

GrowthBook’s expanded REST API lets you manage experiments from setup through conclusions in your own tools. A script or agent can create experiments, check launch readiness, read results, and record decisions. You choose which steps to automate and where a person reviews the work.

Work through the lifecycle

The API covers an action at each stage of an experiment:

• Create an experiment and use its pre-launch checklist to see what still needs attention.
• Mark manual checklist items complete after you finish those checks.
• Retrieve the latest results for many experiments in one call, with metric and variation names alongside their IDs when names are available.
• Record a result status, the winning variation, and an analysis summary.

Pulling results across experiments in one request makes a recurring status check practical, such as a daily summary of the latest results across your experiments.

Getting started

Create a Secret Key under Settings → API Keys, using a role with the experiment permissions your workflow needs. Use the experiment API reference to create a draft experiment, then read back its saved configuration before adding launch actions.