Conversion Optimization
GrowthBook
Rest of world Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 1 of 4 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by GrowthBook, Inc. · www.growthbook.io
Compare with Statsig → Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
GrowthBook is an open-source, warehouse-native experimentation and feature-flag platform from GrowthBook, Inc. of Anaheim, California. The bench scores it highest on data and integrations, 8 to 9, and statistical rigour, 8 to 9: metrics are defined in SQL and computed in the customer's own Snowflake, BigQuery, Databricks or Redshift, every query is visible, the implementation is open source under MIT, and both Bayesian and frequentist engines are documented. Experimentation scope and pricing transparency cluster at 7. The low is sovereignty at 2 to 3: the contracting entity is a California company, hosting is stated as AWS, the privacy notice states information is held at service providers located in the United States, and we found no public information on an EU residency option or a published subprocessor list; self-hosted, air-gapped deployment is the documented mitigation. Consent and tracking splits the judges, 4 to 7: the data protection officer judge scores 4, unable to confirm from the pages whether tracking waits for consent, while higher scores credit the documented setting that delays cookie persistence until consent.
Speaks for it
- Warehouse-native by design: metrics are defined in SQL and computed in your own Snowflake, BigQuery, Databricks or Redshift, with every query visible and no PII leaving the warehouse.
- Both Bayesian and frequentist engines are documented down to their priors and tests, with CUPED on both engines, sample ratio mismatch detection, guardrail metrics and minimum-data checks.
- The statistics implementation is open source under MIT, so a data team can audit and reproduce a result.
- Consent-aware mechanics are documented: a NO_AUTO_COOKIES setting plus a growthbookpersist event can hold cookie persistence until consent, assignment runs on stateless hashing with no cookie, and sticky bucketing can be gated per user on consent.
- Seat pricing is public: Starter is free with no credit card required, Pro is $40 / seat / month for up to 30 users, and overage rates for managed warehouse events, CDN requests and CDN bandwidth are stated.
Held against it
- Sovereignty scores cluster at 2 to 3: the contracting entity is GrowthBook, Inc. of Anaheim, California, hosting is stated as AWS, and the privacy notice states information is held at service providers located in the United States.
- We found no public information on an EU residency option for the hosted service, a published subprocessor list, or a data processing agreement covering the cloud path; US AI providers are named as subprocessors for optional features without stated server regions.
- The privacy notice states DNT signals are not responded to or honored, and we found no public information on consent-management-platform integrations, cookie lifetimes or IP anonymisation.
- Multiple-testing corrections apply only to the frequentist engine, and adjusted p-values are available in the UI and CSV downloads but not exportable via the API.
- We found no published script-size or Core Web Vitals figures; the pages carry only the relative claim of 50% smaller SDKs.
Best for
- You want experiment metrics computed inside your own data warehouse, with visible SQL your team can audit and reproduce.
- You run server-side and edge experiments and want broad SDK coverage — 24+ SDKs across server, client, mobile and edge, including a documented Cloudflare edge pattern.
- You plan to self-host, including air-gapped deployment, so visitor data stays on infrastructure you control.
- You prefer published seat pricing with stated overage rates over per-visitor metering.
Avoid if
- You need EU data residency or a European contracting entity for the hosted service — the captured pages state a California entity, AWS hosting and United States processing.
- Your privacy commitments include honoring Do Not Track — the privacy notice states DNT signals are not responded to or honored.
- You are located outside the United States — the website terms state the site is provided for use only by persons located in the United States.
The scores
Experiment types & delivery
Show reasoningHide reasoning
How this is scored
What can be tested and where: client-side changes through an editor, server-side and feature experiments through SDKs, multivariate and multi-page tests, and personalisation — judged on what the documentation shows rather than on the feature grid.
0 — Simple A/B split of one page element through a visual editor; no server-side option, no targeting beyond URL.
3 — Client-side A/B and split-URL tests with basic audience targeting, and no SDK or server-side delivery.
5 — Client-side and server-side experiments through documented SDKs for common languages, multivariate and multi-page tests, audience targeting on behaviour and attributes, and rule-based personalisation.
8 — Feature-flag-based experiments sharing one audience and metric model with web tests, mutually exclusive experiment groups, holdouts, edge or CDN delivery, and personalisation that can itself be tested against a control.
10 — One experimentation programme across every surface: web, app, server and edge from the same platform, experiment interactions managed, a documented experiment lifecycle from hypothesis to archived result, and a library of past results a team can search.
The Growth Lead
Everything my team needs is evidenced: a no-code visual editor, server-side and feature-flag experiments sharing the same model, namespaces for mutually exclusive tests, holdouts, multivariate, sequential and bandit tests, and edge delivery of visual and URL-redirect experiments that cuts flicker before HTML ships. Targeting runs well beyond the URL — device type, browser, UTM parameters and custom attributes are captured automatically. We found no public information on a personalisation capability or on personalisation that can itself be tested against a control. 1 6 7 11 12
The E-Commerce Manager
Flags, the visual editor and URL redirects can all run as experiments through the same feature and metric model, with namespaces for mutually exclusive tests, holdouts, bandits and a Cloudflare edge app that rewrites visual changes into the HTML before the browser sees it. We found no public information on personalisation as a named capability that can itself be tested against a control group, which is the one gap against the top of this scale. 6 7 11 12
The Product Engineer
Experiments are defined on feature flags and delivered through 24+ SDKs across server, client, mobile and edge, with inline server-side tests that need no third-party requests, mutual exclusion through namespaces, holdouts, sticky bucketing, bandits and multivariate tests, and visual and URL-redirect tests that can be evaluated at the edge before HTML ships. That is most of a modern programme from one platform. We found no public information on personalisation that can itself be tested, or on a documented lifecycle from hypothesis to archived result with a searchable library of past experiments, which is what holds this below the top of the scale. 1 6 7 11 12
The CRO Consultant
Feature-flag experiments, a visual editor, URL redirects and even custom assignment from third-party systems all feed one results model, with namespaces for mutually exclusive tests, holdouts, sticky bucketing and multivariate, sequential and bandit test types documented. Edge delivery on Cloudflare Workers is documented in detail, and 24+ SDKs cover server, client, mobile and edge. We found no public information on personalisation that can itself be tested against a control, which keeps this just under the top band. 1 6 7 12
The Data Protection Officer
Feature-flag experiments, a visual editor, URL redirects and inline server-side tests run through 24+ SDKs across server, client, mobile and edge, with mutual exclusion via namespaces, holdouts, sticky bucketing and a Cloudflare edge app that evaluates flags and rewrites variations before HTML reaches the browser. We found no public information on a personalisation capability that can itself be tested against a control, a documented experiment lifecycle from hypothesis to archived result, or a searchable library of past results. 1 6 7 12
The Skeptic
Visual editor and URL redirects, server-side experiments through feature-flag rules or inline SDK code, custom assignment analysis, holdouts and namespaces for mutual exclusion, 24-plus SDKs spanning server, client, mobile and edge, and a documented edge app on Cloudflare and other providers that evaluates flags before HTML ships. We found no public information on rule-based personalisation that can itself be tested against a control, nor a searchable library of past experiment results, which is what holds this back. 1 6 7 11 12
Statistical method & guardrails
Show reasoningHide reasoning
How this is scored
Which statistics decide the winner and what protects the customer from misreading them. Scored on what the vendor documents: the method by name, how peeking and multiple comparisons are handled, and whether sample ratio mismatch is detected.
0 — A "winner" or "probability to beat" figure with no documented method, no stated sample-size guidance and no warning against stopping early.
3 — The method is named (frequentist or Bayesian) but its assumptions are not documented, and nothing prevents a test from being called while it is still underpowered.
5 — Documented method with confidence or credible intervals, a sample-size or test-duration calculator, and stated guidance on when a result may be read.
8 — Sequential testing or an equivalent documented protection against peeking, correction for multiple metrics or variants, sample ratio mismatch detection, variance reduction such as CUPED, and guardrail metrics that can stop a harmful test.
10 — The statistics are auditable: methodology published in enough detail to reproduce a result, the choice of method explained per use case, raw per-visitor data available for independent re-analysis, and the interface refuses to present an underpowered result as a conclusion.
The Growth Lead
Both statistics engines are documented by name — Bayesian by default with a stated prior, frequentist two-sample t-tests — alongside CUPED in both engines, sample ratio mismatch detection, guardrail metrics, minimum-data settings against early calls, and a choice of Holm-Bonferroni or Benjamini-Hochberg corrections on the frequentist engine, plus a power calculator on Pro. Because metrics are computed in our own warehouse with every query visible in SQL, these are numbers I can defend to the board. Corrections apply only to the frequentist engine and sequential testing is named without documented peeking protection, which is what keeps it off the very top. 1 2 7 8 9
The E-Commerce Manager
Both a Bayesian and a frequentist engine are documented by name with priors spelled out, plus sequential and multivariate tests, CUPED, sample ratio mismatch detection, multiple-testing corrections with the family of tests defined, guardrail metrics and a minimum-data floor so you aren't drawing conclusions too early. The implementation is open source and every query is visible SQL in my own warehouse, so I can re-run the numbers myself before shipping a price change. 8 9 7
The Product Engineer
Both engines are documented down to the mechanics — a Bayesian default with an improper prior you can switch for a proper Normal prior, two-sample t-tests for relative change on the frequentist side, and your choice of Holm-Bonferroni or Benjamini-Hochberg correction with the test family spelled out. Guardrails are real: CUPED on both engines, sample ratio mismatch detection, multiple-exposure and suspicious-uplift checks, guardrail metrics, power analysis and minimum data requirements so an early read cannot be dressed up as a conclusion. The implementation is open source and every query is visible SQL in your own warehouse, so a result is reproducible; the gaps are small — corrections exist only for the frequentist engine, and adjusted p-values come out in the UI and CSV rather than through the API. 6 7 8 9
The CRO Consultant
Both Bayesian and frequentist engines are documented down to default priors, two-sample t-tests and correction families (Holm-Bonferroni and Benjamini-Hochberg), with SRM detection, CUPED, guardrail metrics, minimum-data checks against reading 5-vs-2 results, and suspicious-uplift and multiple-exposure alerts. Analysis runs in visible SQL on the customer's own warehouse with only aggregates accessed, and the implementation is open source under MIT, so a client's data team can audit a result end to end. Corrections apply only to the frequentist engine and adjusted p-values export to CSV but not the API — minor caveats on an otherwise reproducible setup. 8 9 5 7
The Data Protection Officer
Both engines are documented by name — Bayesian by default with an improper uninformative prior and a switchable proper prior, frequentist two-sample t-tests for relative percent change — alongside Holm-Bonferroni and Benjamini-Hochberg corrections across goal metrics and variations, sample ratio mismatch detection, CUPED on both engines, guardrail metrics, minimum-data checks against reading results too early, and the whole implementation open source under MIT so a result can be reproduced. The captured pages do note that adjusted p-values are available in the interface and CSV downloads but not through the API. 7 8 9
The Skeptic
Both engines are on the record with their assumptions — Bayesian with a documented default improper prior and an optional proper Normal prior, frequentist as two-sample t-tests on relative change — alongside sample ratio mismatch detection, CUPED, guardrail metrics, minimum data rules and a power calculator, with an open-source implementation a result can be checked against. My reservations: the multiple-comparison corrections exist only for the frequentist engine while Bayesian is the default, sequential testing appears as a listed test type without the peeking mathematics documented, and adjusted p-values can be exported only as CSV, not through the API. 2 6 7 8 9
Consent & visitor tracking
panel disagrees
Show reasoningHide reasoning
How this is scored
Whether the test script respects §25 TDDDG and the ePrivacy rules as evidenced on the vendor's own pages: when the script runs relative to consent, what it stores on the device, whether a cookieless or consent-free mode exists, and how visitor identifiers are handled.
0 — Nothing on the vendor's pages says what the script stores on the device or whether it runs before consent; consent is described as the customer's problem.
3 — Cookies or local storage are listed, and a consent integration is mentioned, but the documentation does not say what the script does before consent is given.
5 — Documented behaviour before and after consent, integration with common consent management platforms, a published list of cookies and storage keys with their lifetime, and IP anonymisation described.
8 — A documented consent-pending mode that holds tracking until consent while variants can still be served, a cookieless or first-party-only option, retention of visitor data stated, and guidance on the legal basis for testing in the EU.
10 — Built for §25 TDDDG: the default configuration stores nothing on the device without consent, a server-side or cookieless mode documented end to end, per-visitor data deletable on request, and the vendor states in writing how each mode maps to consent requirements.
The Growth Lead
The edge documentation shows a real consent-pending pattern: the visitor cookie is not persisted until a growthbookpersist event fires after consent, assignment runs on stateless hashing with no cookie needed, and sticky bucketing can be enabled per visitor only once the consent cookie is present. For my §25 TDDDG review the rest is silent — we found no public information on consent management platform integrations, cookie lifetimes, IP anonymisation, or guidance on the legal basis for testing in the EU, and the website terms state the service is for use only by persons located in the United States. 3 4 6 11 12
The E-Commerce Manager
The consent mechanics are documented where I'd need them: persisting the gbuuid identifier cookie can be held back until the visitor consents via a setting plus a "growthbookpersist" event, assignment itself runs on stateless hashing with no cookies needed, and sticky bucketing can be enabled per user only after consent. We found no public information on consent-management-platform integrations, IP anonymisation or EU legal-basis guidance for testing, and the privacy notice states DNT signals are not honoured. 11 12 6 3
The Product Engineer
The mechanics are genuinely consent-aware: assignment is stateless consistent hashing so variants serve with no cookie at all, a documented setting defers writing the first-party visitor cookie until consent, a custom event triggers persistence once consent is given, and sticky bucketing can be enabled per visitor only when consent is observed. Against that, the visitor cookie is persisted on page load by default, the privacy notice states Do Not Track signals are not honored, and we found no public information on consent management platform integrations, cookie lifetimes, or IP anonymisation. 3 6 11 12
The CRO Consultant
The gbuuid identifier is a first-party cookie whose persistence can be held until consent via a documented setting and a page event, assignment itself is stateless hashing that needs no cookie, and sticky bucketing can be gated per user on consent having been given. For a DPO sign-off I still miss the rest: we found no public information on consent-management-platform integrations, a published cookie and storage list with lifetimes, IP anonymisation, or guidance on the legal basis for testing in the EU. 11 12 6
The Data Protection Officer
The gbuuid cookie is named, first-party and configurable, assignment is documented as stateless hashing that needs no cookie, an environment variable delays writing the cookie until a consent event fires from the page, and sticky bucketing is documented as consent-gated — yet from these pages I still cannot answer whether the exposure tracking callback or the payload fetch waits for the consent banner, and we found no public information on consent-management-platform integrations, cookie lifetimes, IP anonymisation, or guidance on the legal basis for testing in the EU. The privacy notice further states that DNT signals are not responded to or honored. 3 6 11 12
The Skeptic
The consent mechanics are documented in implementable detail: a first-party identifier cookie the edge server does not write by default, a documented setting plus a JavaScript event that delay cookie persistence until consent, and hash-based assignment that works with no cookie at all. Less complete: we found no published cookie lifetimes, nothing on IP anonymisation or consent management platform integration, and the privacy notice states DNT signals are not honored. 3 6 11 12
Snippet performance & flicker
Show reasoningHide reasoning
How this is scored
The cost the client-side snippet imposes on the page it tests: blocking load, flicker of original content, script weight and the effect on Core Web Vitals — scored on what the vendor measures and publishes, not on "lightning fast".
0 — A synchronous snippet with no stated size, no flicker handling and no mention of performance.
3 — An anti-flicker snippet that hides the page until the test loads, with a timeout, and no published figures for script size or load cost.
5 — Script size and loading behaviour documented, asynchronous loading option, flicker handling explained with its trade-off, and CDN delivery of the snippet.
8 — Published performance figures including impact on Core Web Vitals, a self-hosting or first-party-domain option for the script, per-project bundles containing only active experiments, and a server-side or edge alternative for flicker-sensitive tests.
10 — Performance is a stated commitment: measured overhead published and maintained, flicker eliminated by edge or server-side rendering as a documented path, and tooling that shows the customer what their own configuration costs the page.
The Growth Lead
The trade-offs are documented honestly: the edge app's default makes a blocking call on each request that delays page delivery, with a push model to Cloudflare KV or a just-in-time cache to eliminate it, visual and redirect experiments running at the edge without flicker, SDK endpoints served from a global CDN, and a self-hosted proxy or own-CDN option. We found no published figures for script weight or impact on Core Web Vitals — '50% smaller SDKs' is a comparison rather than a number — so I cannot yet quantify the cost to our pages. 1 5 11 12 14
The E-Commerce Manager
Flicker is addressed where it counts: the edge app evaluates flags and runs visual experiments on Cloudflare Workers to cut flicker before HTML ships, URL redirects run without flicker, the SDK payload is served from a global CDN, and self-hosters can run their own proxy or CDN. The docs are honest that the default edge setup makes a blocking call on every user request unless you build the KV push model — but we found no published figures for script weight or Core Web Vitals impact, which is what I'd want before a peak-season sale. 11 12 14
The Product Engineer
The edge path is documented end to end — flags and visual experiments evaluated on the edge so variations ship before the browser paints, URL redirects without flicker, SDK injection with a hydrated payload so the front-end makes no extra network calls — and the docs are unusually honest that the default edge setup makes a blocking payload fetch per request, with two documented ways to remove it: a webhook push into an edge key-value store or a just-in-time payload cache. Self-hosters can run the proxy on their own CDN, and SDK endpoints are scoped to a project and environment. We found no published figures for script weight or Core Web Vitals impact, which is what keeps this from scoring higher. 1 5 11 12 14
The CRO Consultant
The documentation is unusually honest that the Edge App's default mode makes a blocking API call on every request, and spells out the fixes: a KV push model or just-in-time payload cache to eliminate it, plus edge-rendered visual and redirect experiments that cut flicker before HTML ships. Self-hosting with your own CDN or the Proxy server is documented, and the SDKs are claimed 50% smaller with zero network calls. We found no published figures for script weight or Core Web Vitals impact, only relative claims. 11 12 14 1
The Data Protection Officer
The documentation is candid that the edge app's default is a blocking API call that delays page delivery, and publishes two elimination paths — a webhook push model to an edge key-value store and a just-in-time payload cache — plus CDN delivery of SDK payloads, a proxy server with caching for self-hosters, and edge evaluation that runs visual and redirect experiments into the HTML before it ships to cut flicker. We found no public information on absolute script size figures or measured Core Web Vitals impact. 1 11 12 14
The Skeptic
To its credit the edge documentation states plainly that the default mode makes a blocking API call on every user request, then documents two ways to remove it — a push model into an edge key-value store or a just-in-time payload cache — plus a self-hosted proxy with your own CDN and payload endpoints scoped to a single environment or project; edge and hybrid delivery is documented as eliminating redraw flicker for visual and redirect tests. What is missing for a higher mark: no published script sizes or Core Web Vitals figures, only a relative claim of fifty percent smaller SDKs. 1 11 12 14
Analytics, data export & integrations
Show reasoningHide reasoning
How this is scored
Getting results and raw data out: integration with analytics and tag management, export of visitor-level results, warehouse-native analysis, and an API — because an experiment result that cannot be checked in the customer's own data is a claim, not a finding.
0 — Results visible in the vendor's dashboard only; no export, no analytics integration, no API.
3 — CSV export of aggregated results and one analytics integration, with no visitor-level data and no documented API.
5 — Integrations with common analytics and tag managers, export of results, and a documented API for managing experiments and reading results.
8 — Visitor-level raw data export or streaming to a data warehouse, warehouse-native analysis on the customer's own metrics, CDP integration for audiences, and an API with stated limits.
10 — The platform treats the customer's warehouse as the source of truth: metrics defined once and computed there, full historical experiment data exportable in open formats, and a versioned API a team can build its own programme tooling on.
The Growth Lead
This is the standout: metrics are defined in SQL and computed in our own warehouse (Snowflake, BigQuery, Databricks, Redshift) with no PII leaving it, results are reproducible, and there is a full REST API across experiments, fact metrics, segments and per-experiment results, plus CSV download, an MCP server, webhooks, and tracking that integrates with Segment.io, GA4 and Google Tag Manager. We found no public information on stated API rate limits, and adjusted p-values are available only in the UI or CSV downloads rather than through the API. 5 7 9 11 14
The E-Commerce Manager
Warehouse-native is real here: metrics are built with SQL and computed in my own Snowflake, BigQuery, Databricks or Redshift with the statement that no PII ever leaves the warehouse, and a documented REST API covers experiments, results, features and segments. Slack, Shopify, Datadog and Segment tracking are listed and results export as CSV — though we found no public information on stated API limits or full historical export in open formats. 7 5 14 13
The Product Engineer
This is the model I want: metrics are SQL against Snowflake, BigQuery, Databricks or Redshift, every query is visible and reproducible, no personal data leaves the warehouse, and results are computed in the warehouse the team already trusts rather than in a black box. The REST API is versioned and deep enough to build internal tooling on — create experiments, toggle features from a deploy script, pull the latest analysis into your own reporting, define fact metrics, segments and saved groups — with webhooks and an MCP server on top. We found no public information on stated API rate limits or CDP integrations. 5 7 13 14
The CRO Consultant
Warehouse-native is the architecture, not a connector: metrics are defined in SQL and computed on Snowflake, BigQuery, Databricks or Redshift with no PII leaving the warehouse, every query is visible, and a versioned REST API includes a per-experiment results endpoint for pulling analysis into our own reporting. Results including adjusted p-values export to CSV, and native integrations cover Slack, Datadog, Shopify, WordPress and more. We found no published API rate limits and no CDP integration for audience syncing, which keeps it a notch below fully self-serve. 7 14 9 13 5
The Data Protection Officer
Warehouse-native is the core promise: metrics defined once in SQL and computed in the customer's own Snowflake, BigQuery, Databricks or Redshift with every query visible and no PII leaving the warehouse, alongside a full REST API covering experiments, per-experiment results, fact tables and saved groups, and named integrations including Segment.io, GA4, Google Tag Manager, Slack and Shopify. We found no public information on stated API rate limits or streaming export of raw event data. 5 7 13 14
The Skeptic
Warehouse-native is the design, not a bolt-on: metrics are defined in SQL and computed in the customer's own Snowflake, BigQuery, Databricks or Redshift, every query is visible, results are described as reproducible, and a full REST API with versioned endpoints covers experiments, results, fact metrics, segments and feature toggles. The nits: adjusted p-values are exportable only as CSV rather than through the API, and we found no stated API rate limits or a CDP audience integration. 2 5 7 9 13 14
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where visitor data is processed and stored and who the contracting entity is. Independently sourced by the sovereignty pipeline; weighted higher here than in categories that hold only the customer's own data, because the script runs on every visitor to the customer's site and their behaviour is what the platform records.
0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and visitor data leaving the EU without a stated safeguard.
3 — EU data residency offered as an option or an enterprise add-on while the contracting entity is non-EU, or the subprocessor list is absent.
5 — EU processing of visitor data as standard and an EU contracting entity, but parts of the chain — CDN, support access, analytics — are non-EU without an explained safeguard.
8 — EU hosting on named infrastructure including the delivery of the snippet, EU contracting entity, subprocessor list published, and a DPA covering the visitor data the script collects.
10 — Sovereign end to end and evidenced: vendor, entity, hosting, snippet delivery and every subprocessor European, certification published, and no visitor data reaching a non-EU party at any point.
The Growth Lead
The contracting entity is GrowthBook, Inc. of Anaheim, California, the privacy notice has visitors consent to their information being transferred to and processed in the United States, US AI providers (Anthropic, Google, OpenAI, xAI) are named as sub-processors without stated server regions, and the website terms restrict use to persons located in the United States. The self-hosted, air-gapped deployment where no data or PII leaves our system is the one real mitigation, but we found no public information on EU hosting, an EU contracting entity, a published subprocessor list, or a DPA covering the cloud path — for a German team running tests on every visitor, that is nearly disqualifying. 3 4 5 10 14
The E-Commerce Manager
The contracting entity is GrowthBook, Inc. of Anaheim, California, hosting is stated as GrowthBook on AWS with information processed in the United States, and the privacy notice has visitors consent to US transfer while the website terms say the site is for persons located in the United States. US AI providers are named for optional features, but we found no public information on an EU residency option, a published subprocessor list or a DPA covering the visitor data; the documented mitigations are self-hosting and warehouse-native mode, where no visitor-level data leaves my systems. 3 4 5 10
The Product Engineer
Hosted is American end to end: a California entity with Santa Clara venue, AWS hosting, a privacy notice that says information is held by providers in the United States and asks users to consent to transfer and processing there, US AI providers as subprocessors, and website terms offering the service only to persons located in the United States. The escape hatch is real and documented — full self-hosting including air-gapped deployment, and warehouse-native mode where no personal data leaves your infrastructure — but the contracting entity is a California company, and we found no public information on EU data residency for the hosted service or a data processing agreement covering the visitor data the script collects. 3 4 5 14
The CRO Consultant
GrowthBook, Inc. of Anaheim, California is the contracting entity, cloud hosting is stated as AWS in the United States, the privacy notice asks users to consent to transfer and processing in the United States, and the terms say the website is for use only by persons located in the United States. US AI providers are named as subprocessors for optional features, but we found no public information on a published subprocessor list, EU data residency, or a transfer safeguard such as adequacy or standard contractual clauses. Self-hosting air-gapped, where no data leaves the customer's system, is the only documented path that keeps visitor data off US infrastructure. 3 4 5
The Data Protection Officer
The contracting entity is GrowthBook, Inc. of Anaheim, California, the privacy notice states personal information is held and processed in the United States by consent-through-use, hosting is on AWS, and I found no public information on an EU residency option for the cloud service, on a published subprocessor list that includes the CDN at cdn.growthbook.io, or on server regions for the named AI sub-processors (Anthropic, Google, OpenAI, xAI) and the ClickHouse managed warehouse. Self-hosted, air-gapped deployment is the only documented path that keeps data on infrastructure the customer controls. 3 4 5 14
The Skeptic
A California contracting entity under California law, processing described as held in the United States with visitors consenting to that transfer, US AI providers named as subprocessors for optional features, no published subprocessor list and no stated transfer safeguard. The sole mitigation on the vendor's pages is the self-hosted, air-gapped deployment where no data leaves your own system; everything captured about the hosted offering points away from European sovereignty. 3 4 5 10
Pricing transparency
Show reasoningHide reasoning
How this is scored
A category priced by traffic — monthly tracked users, visitors or impressions — where the tier a site lands in depends on numbers the buyer has to estimate. Whether a buyer can compute the real annual cost including traffic limits, overage, server-side or personalisation modules and seats — from public pages alone.
0 — No public prices at all; every tier is a sales conversation.
3 — A starting price or a free tier exists, but the traffic metric, the limits and what happens above them are unstated — the invoice is unknowable.
5 — Tier prices public with the traffic metric and its limits defined, but at least one commonly needed piece (server-side SDKs, personalisation, overage) is unpriced or "contact sales".
8 — Every tier priced publicly with the traffic metric defined, limits, overage rates, module prices, minimum term and VAT treatment stated.
10 — Complete price computability: annual invoice derivable for a given traffic volume, set of modules and team size, with overage and every add-on published.
The Growth Lead
Public tiers are priced per seat rather than per visitor — Starter free, Pro at $40 / seat / month with unlimited experiments, feature flags and traffic — and the traffic-like limits that do exist are published with overage rates: managed-warehouse events at 1M or 2M per month then $30/M, CDN bandwidth then $1/GB, CDN requests then $10/M. Most of an annual invoice is therefore computable, but Enterprise is 'custom' and we found no public information on VAT treatment or minimum term. 2 7
The E-Commerce Manager
Starter is free and Pro is "$40 / seat / month" with published usage limits and overage rates — managed warehouse "2M events/mo (then $30/M)", CDN bandwidth "20GB/mo (then $1/GB)" and CDN requests "2M/mo (then $10/M)" — so a December traffic spike costs extra at a stated rate rather than jumping a tier. Enterprise is custom, and we found no public information on minimum term or VAT treatment, which keeps the annual invoice from being fully computable from the public pages alone. 2 7
The Product Engineer
Seat pricing with published usage ceilings and overage rates makes the cloud invoice derivable: Starter is free, Pro is $40 / seat / month for up to 30 users, CDN requests are 2M/mo (then $10/M), bandwidth is 20GB/mo (then $1/GB), and the managed warehouse is 2M events/mo (then $30/M), with experiments and feature flags unlimited on every plan. Enterprise is a sales conversation, and we found no public information on minimum term or VAT treatment, so full annual computability stops at the Pro tier. 2 7
The CRO Consultant
The seat model is public and computable: Starter free with one project and up to three users, Pro at $40 per seat per month up to 30 users and three projects, with published overage rates for managed warehouse events ($30 per million above the tier), CDN requests ($10 per million) and CDN bandwidth ($1 per GB) — plus unlimited traffic and unlimited experiments on every tier. The traffic meter here is events and CDN usage rather than monthly tracked users, which I can still estimate before a contract. Enterprise is custom-priced, and we found no public information on minimum term or VAT treatment. 2 7
The Data Protection Officer
Starter is free with up to 3 users and 1 project, Pro is "$40 / seat / month" with up to 30 users and 3 projects, and the usage-based pieces carry published limits and overage — managed warehouse events 1M/mo and 2M/mo "then $30/M", CDN requests 1M/mo and 2M/mo "then $10/M", CDN bandwidth 5GB/mo and 20GB/mo "then $1/GB" — with unlimited feature flags, experiments and traffic. Enterprise is priced only as Custom, and we found no public information on minimum term or VAT treatment. 2 7
The Skeptic
Starter is free without a credit card, Pro is published at $40 per seat per month for up to 30 users, and — unusually for this category — traffic is published as unlimited, so the invoice hinges on seats and the metered extras. Those extras carry published limits and overage figures for managed warehouse events, CDN bandwidth and CDN requests, but Enterprise is a sales conversation and we found no public information on minimum term or VAT treatment. 2 7
European sovereignty — proven facts
1 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined ⚠ unverified | — | uncited Report an error |
| Subprocessors | US CLOUD Act reach ⚠ unverified | 0/2 pts | 5 Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 22 Sep 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Data residency. Not confirmed on the vendor’s own pages as captured.
- Weak sourcing — Subprocessors. The privacy notice also names US AI providers (Anthropic, Google, OpenAI, xAI) as sub-processors for optional AI features, and the managed warehouse stores event data on 'ClickHouse infrastructure', all without stated server regions.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 17 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 5 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 pricing facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 support fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 sovereignty dimension could not be confirmed on the vendor’s own pages and is shown as unknown. Know more? Tell us
Sources (14)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage www.growthbook.io Checked 22 Sep 2026 Details →
- 2 Pricing page www.growthbook.io Checked 22 Sep 2026 Details →
- 3 Privacy policy www.growthbook.io Checked 22 Sep 2026 Details →
- 4 Terms of service www.growthbook.io Checked 22 Sep 2026 Details →
- 5 Security / trust page www.growthbook.io Checked 30 Sep 2026 Details →
- 6 Experiment types & delivery — found from sitemap docs.growthbook.io Checked 1 Oct 2026 Details →
- 7 Experiment types & delivery — found from sitemap www.growthbook.io Checked 1 Oct 2026 Details →
- 8 Statistical method & guardrails — found from sitemap docs.growthbook.io Checked 1 Oct 2026 Details →
- 9 Statistical method & guardrails — found from sitemap docs.growthbook.io Checked 1 Oct 2026 Details →
- 10 Consent & visitor tracking — found from sitemap www.growthbook.io Checked 1 Oct 2026 Details →
- 11 Snippet performance & flicker — found from sitemap docs.growthbook.io Checked 1 Oct 2026 Details →
- 12 Snippet performance & flicker — found from sitemap docs.growthbook.io Checked 1 Oct 2026 Details →
- 13 Analytics, data export & integrations — found from sitemap docs.growthbook.io Checked 1 Oct 2026 Details →
- 14 Analytics, data export & integrations — found from sitemap docs.growthbook.io Checked 1 Oct 2026 Details →