GrowthBook: Análisis 2026 (Funciones, Precio y Límites)

GrowthBook es la opción más seria de la categoría para quien quiere auditar su propia estadística, y el precio de eso no está en la licencia: está en necesitar un data warehouse y alguien que escriba SQL. Es una plataforma open source de feature flags y experimentación con arquitectura warehouse-native, lo que significa que lee los datos donde ya están en lugar de copiarlos a un servidor del proveedor. Este análisis cubre lo que hace bien, lo que cobra, dónde están las limitaciones reales y para qué tipo de operación eso cierra la cuenta. Para el panorama completo de la categoría, mira la comparación de herramientas de test A/B open source.

Aviso de transparencia antes de cualquier línea: Donnu es una herramienta de test A/B y, por lo tanto, compite con GrowthBook en parte del alcance. Este texto fue escrito para ser útil incluso para quien va a elegir GrowthBook al final, y la sección sobre dónde es claramente la elección correcta está aquí exactamente por eso.

Qué es GrowthBook, en una frase por pieza

Pieza	Qué hace	A quién suele importarle
Feature flags	Activación y rollout controlado de funcionalidad por SDK	Ingeniería y producto
Experimentación	Test A/B y A/B/n conectados a las mismas flags	Producto, growth e ingeniería
Capa warehouse-native	Consulta métricas directo en tu data warehouse	Equipo de datos, compliance y finanzas
Motor estadístico	Bayesiano y frecuentista, con secuencial y CUPED por franja de plan	Quien lee el resultado y decide el rollout
Editor visual	Montaje de variación sin deploy (planes pagos)	Marketing, cuando existe

La elección entre GrowthBook y una herramienta comercial cerrada raramente es sobre la calidad del test A/B en sí. Es sobre dónde viven tus datos y quién consigue tocarlos. Quien ya tiene warehouse, modelado y un equipo de datos encuentra aquí un ahorro real y un nivel de auditabilidad que una herramienta cerrada no ofrece. Quien no lo tiene está comprando un proyecto de infraestructura junto con la herramienta, y ese proyecto suele costar más que la licencia que ahorra.

Precio: aquí, al contrario de la categoría, existe tabla pública

Este es un punto en el que GrowthBook se separa de la mayor parte de los competidores: los valores están publicados. Según la página oficial de precios, los caminos son:

Camino	Precio	Qué entra
Open source, self-hosted	Gratuito	Usuarios, flags, experimentos y tráfico ilimitados en tu infraestructura, 1 proyecto, soporte por la comunidad, sin los recursos avanzados listados en el Pro
Nube Starter	Gratuito	Hasta 3 usuarios, 1 proyecto, flags y experimentos ilimitados
Nube Pro	40 dólares por asiento por mes	Hasta 50 usuarios y 3 proyectos, editor visual, bandits, rollouts seguros, permisos avanzados, calculadora de potencia, test secuencial, CUPED, soporte premium
Enterprise (nube o self-hosted)	Bajo consulta	SSO y SCIM, registro de auditoría, flujos de aprobación, ambientes personalizados, SLA y soporte dedicado

El precio por asiento tiene una consecuencia de gestión que vale anticipar: penaliza el modelo “todo el mundo tiene acceso de lectura”. En un programa de experimentación maduro, mucha gente necesita ver resultados sin necesitar configurar nada, y en un modelo por asiento cada una de esas personas cuesta. Vale diseñar la política de acceso antes de contratar, no después.

Y la salvedad más importante de esta sección: gratuito no quiere decir sin costo. La versión open source es honestamente gratuita, pero correrla significa mantener servidor, mantener actualizaciones y pagar las consultas al warehouse, que en bases grandes no son baratas. Suma el tiempo de quien modela las métricas en SQL y la cuenta real aparece. Eso no es crítica al producto, es la naturaleza de la elección: cambias mensualidad por control y por trabajo interno.

Warehouse-native: qué cambia cuando la métrica es una consulta tuya

En una herramienta tradicional, el script recolecta los eventos y los envía a la base del proveedor, que calcula y devuelve el informe. En el modelo warehouse-native, el camino es otro: los eventos ya están en tu data warehouse, y la herramienta genera consultas SQL contra él para producir los números.

Tres consecuencias prácticas, todas verificables:

• Sin duplicación de datos. No pagas para almacenar dos veces la misma cosa ni necesitas reconciliar dos fuentes que discrepan.
• Reaprovechamiento de definición. Si “usuario activo” ya está definido en tu modelo, el experimento usa esa definición, no una paralela creada dentro de la herramienta.
• Auditabilidad real. La plataforma expone el SQL detrás de cada número, así que el equipo de datos consigue reproducir, auditar y depurar un resultado extraño sin pedirle soporte a nadie.

El tercer punto es lo que más separa esta herramienta de las competidoras cerradas. En casi toda plataforma comercial, cuando el número parece equivocado, el camino es abrir un ticket. Aquí, el camino es leer la consulta.

Y ahí aparece la contrapartida honesta: quien escribe la consulta decide el resultado. Eso no es un defecto, es una transferencia de responsabilidad, y es lo bastante grande como para merecer el ejemplo trabajado entero de este análisis.

El ejemplo trabajado: la misma recolección, dos denominadores, dos tests diferentes

Una tienda testea un cambio en un bloque de la página de producto. Detalle importante: solo cerca del 40% de los visitantes desplazan la página lo suficiente para ver ese bloque. El otro 60% nunca es expuesto al cambio, pero sigue entrando en la página y comprando normalmente, a una tasa del 1,5%.

Entre los expuestos, el cambio funciona: la tasa sube de 7,5% a 8,4%, una ganancia relativa del 12%. Ahora, las dos formas de escribir la métrica en SQL:

Definición 1, “todos los visitantes de la página”: la tasa general del control es 0,4 x 7,5% más 0,6 x 1,5%, es decir, 3,90%. La de la variación es 0,4 x 8,4% más 0,6 x 1,5%, es decir, 4,26%. La ganancia relativa cae al 9,23%, porque el 60% de la muestra no podía moverse.

Definición 2, “solamente quien fue expuesto al bloque”: 7,5% contra 8,4%, ganancia relativa del 12%, el efecto real y sin dilución.

El tamaño de muestra que exige cada definición, con 95% de confianza y 80% de potencia:

Definición de la métrica en SQL	Tasa base	Efecto a detectar	Muestra por variación	Tráfico semanal disponible	Duración
Todos los visitantes de la página	3,90%	+9,23% relativo	47.410	30.000	23 días
Solamente los expuestos al bloque	7,50%	+12,00% relativo	14.182	12.000	17 días

Muestra por aproximación normal de dos proporciones, 95% de confianza, 80% de potencia, bilateral; duración para 2 variaciones.

Corre las dos líneas tú mismo:

Tasa de conversión actual%Efecto mínimo detectablerelativo (%)absoluto (pp)Confianza909599%Poder8090%Visitantes por semana (total)Testbilateralunilateral

-Visitantes por variación

-Total (2 variaciones)

-Duración estimada

Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.

La definición diluida exige 3,3 veces más gente por variación para probar el mismo efecto real. Y fíjate en el detalle que suele pasar desapercibido: como el segmento expuesto también tiene menos tráfico semanal, la diferencia de calendario queda bastante menor que la diferencia de muestra, 23 días contra 17. No es un ahorro de tiempo espectacular, es un ahorro de potencia: con la misma ventana, la lectura sobre los expuestos ve efectos que la lectura diluida dejaría pasar como empate.

Ahora la lectura observada. Supón que el test corrió los 23 días necesarios por la definición más exigente, acumulando cerca de 49.000 visitantes por variación en la página, de los cuales 19.600 por variación fueron efectivamente expuestos al bloque. Los mismos eventos, leídos por las dos definiciones:

Lectura	Visitantes por variación	Conversiones A	Conversiones B	Puntaje z	Valor p	Veredicto
Todos los visitantes	49.000	1.911 (3,90%)	2.087 (4,26%)	2,84	0,0045	Significativo, B gana
Solo los expuestos	19.600	1.470 (7,50%)	1.646 (8,40%)	3,29	0,0010	Significativo, B gana

Comprueba las dos líneas en la calculadora:

Control (A)

VisitantesConversiones

Variación (B)

VisitantesConversiones

Confianza90%95%99%

Control (A) · Tasa-

Variación (B) · Tasa-

Mejora relativa-

valor-p-

IC 95% de la diferencia-

Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.

Las dos lecturas concuerdan, y es así como suele pasar cuando el efecto es lo bastante grande y el test corrió hasta el final: el denominador diluido llega, solo que gastando mucha más gente. El peligro vive en el caso vecino y más común, el del efecto menor: si la lectura diluida hubiera parado en la muestra que basta para la lectura expuesta (19.600 por variación), su potencia estadística sería de apenas 43,7%, es decir, tendría menos de la mitad de probabilidad de detectar un efecto que existe de verdad. En ese escenario, el mismo cambio sería archivado como “no funcionó” a causa de una elección de SQL.

La conclusión práctica no es “mide siempre solo a los expuestos”. Las dos lecturas responden preguntas legítimas y diferentes: la expuesta responde “ese cambio funciona para quien lo ve”, y la diluida responde “ese cambio mueve el número de la página entera”. La regla es elegir qué pregunta estás haciendo antes de correr, registrar esa elección junto con la hipótesis, y nunca cambiar de denominador después de ver el resultado. La guía de cómo escribir una hipótesis de test A/B tiene el formato que vuelve natural ese registro.

Análisis de GrowthBook: puntos fuertes reales

• Auditabilidad sin precedentes en la categoría. Poder leer el SQL que generó cada número transforma una discusión de confianza en una discusión técnica, que sí es resoluble.
• Rigor estadístico documentado, con alcance por plan. Los motores bayesiano y frecuentista aparecen en todas las franjas, y el test secuencial y CUPED entran a partir del Pro de nube, según la página oficial de precios consultada el 13 de agosto de 2026. Es un conjunto que muchas suites caras no ofrecen, pero confirma en qué plan está cada método antes de asumir que el gratuito cubre todo.
• Precio público. En una categoría en la que casi todo el mundo esconde el valor detrás de una llamada, publicar tabla es un diferencial concreto de tiempo de evaluación.
• Sin duplicación de datos. Para operaciones con exigencia de compliance sobre dónde viven los datos del usuario, el modelo warehouse-native resuelve por arquitectura lo que otras herramientas resuelven por contrato.
• Feature flag y experimento en la misma herramienta. Evita la costura entre dos plataformas, que es donde la instrumentación suele romperse.

Limitaciones y puntos de atención

• Exige data warehouse y SQL. Es el filtro que decide la mayor parte de los casos. Sin warehouse funcionando y sin alguien cómodo con consultas, la herramienta no sale del lugar.
• Costo real fuera de la licencia. Infraestructura, consultas al warehouse y tiempo de modelado. Comparar solo la licencia con una suite comercial es comparar cosas diferentes.
• La responsabilidad de la métrica es tuya. Como muestra el ejemplo de arriba, un denominador mal elegido produce un test válido que responde a la pregunta equivocada. Una herramienta cerrada esconde esa decisión; aquí es tuya, con el bono y la carga de eso.
• No es una suite de comportamiento. No sustituye mapa de calor, grabación de sesión ni investigación con usuarios. Si necesitas la hipótesis antes del test, necesitas otra herramienta al lado.
• El precio por asiento penaliza el acceso amplio. En un programa maduro, mucha gente solo necesita leer el resultado, y en el modelo por asiento eso cuesta.

Cómo evaluar GrowthBook en un piloto, sin perder tiempo

Chequeo	Cómo hacerlo	Qué revela
Costo de consulta	Correr un experimento de prueba y medir el costo de las consultas en el warehouse por una semana	Cuál es la mensualidad invisible del modelo warehouse-native
Definición de métrica	Escribir la misma métrica con dos denominadores y comparar los resultados	Si el equipo entiende el impacto de la elección antes de decidir con ella
División real de tráfico	Correr un test A/A por algunos días y comprobar la proporción	Si la atribución de variación está estable y sin desvío de muestra
Latencia del informe	Cronometrar cuánto tarda desde el evento hasta aparecer en el panel	Si el ritmo de decisión del equipo cabe en el ritmo del pipeline de datos
Quién consigue operarlo	Pedirle a un perfil no técnico del equipo que monte y lea un test solo	Si la herramienta sirve al equipo entero o solo al equipo de datos

La última línea es la más decisiva y la menos testeada. Una herramienta que solo el equipo de datos consigue operar transforma cada experimento de marketing en un pedido interno, y una cola interna es la forma más cara de fricción organizacional, como detalla la guía de cultura de experimentación.

El test A/A de la tercera línea merece una nota aparte: las dos variaciones son idénticas, así que cualquier “ganador” que aparezca es ruido por definición. Es la auditoría más barata que existe, y vale correrla en cualquier herramienta que estés evaluando, incluida la nuestra.

Para quién tiene sentido GrowthBook

Tiene sentido para equipos que ya tienen data warehouse en uso y alguien cómodo con SQL, para operaciones que necesitan mantener los datos en infraestructura propia por compliance o por costo, para equipos de ingeniería que quieren feature flag y experimentación en la misma herramienta, y para quien quiere auditar la estadística en lugar de confiar en un sello de ganador.

Tiene menos sentido para un equipo de marketing sin apoyo de datos, para quien necesita empezar a testear esta semana sin abrir un proyecto de infraestructura, y para quien necesita mapa de calor, grabación de sesión e investigación con usuarios en la misma plataforma, escenario cubierto en la comparación con suites comerciales.

Si tu caso es el segundo, Donnu es una de las opciones más ligeras de la categoría, con precio previsible, sin llamada para descubrir el valor y sin exigir data warehouse ni SQL para empezar. No sustituye a GrowthBook en arquitectura warehouse-native, auditoría del SQL, self-hosting ni feature flag por SDK, y decir lo contrario sería deshonesto: si necesitas esas piezas, la comparación correcta no es con Donnu. Si no las necesitas, empieza una prueba gratis y compara lo que de hecho importa para tu caso.

---

Lee también: GrowthBook vs PostHog: qué open source elegir · Herramientas de test A/B open source · Qué es CUPED · Test secuencial explicado · Leia em português

Referencias

• GrowthBook. Pricing. Planes, valores por asiento y alcance de cada plan, incluida la versión open source self-hosted. growthbook.io/pricing.
• GrowthBook. Experimentation and A/B testing platform. Página oficial del producto, con la descripción de la arquitectura warehouse-native y de los motores estadísticos. growthbook.io/products/experimentation.
• GrowthBook. Best warehouse-native A/B testing tools. Material de la propia empresa sobre la categoría warehouse-native. Fuente interesada, usada aquí solo para la descripción de la arquitectura. growthbook.io/insights.
• Deng, A., Xu, Y., Kohavi, R. y Walker, T. Improving the Sensitivity of Online Controlled Experiments by Utilizing Pre-Experiment Data. WSDM, 2013. Artículo original de CUPED. exp-platform.com.
• Kohavi, R., Tang, D. y Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Capítulos sobre definición de métrica, dilución y potencia estadística. Material de apoyo en experimentguide.com.