Herramientas de Test A/B Open Source: GrowthBook y Más
Panorama de herramienta de test a/b open source: GrowthBook, PostHog, Unleash y Flagsmith comparadas por self-hosting, licencia y rigor estadístico.
📚 Este artículo es parte de la guía Herramientas de CRO Comparadas: Guía Neutral (2026).
Una herramienta de test a/b open source entrega el mismo tipo de resultado que cualquier plataforma de experimentación (atribución de variación, recolección de conversión, veredicto estadístico), pero con el código fuente abierto para inspección y, en la mayoría de los casos, la opción de correr todo dentro de tu propia infraestructura en vez de la de un proveedor. GrowthBook y PostHog ya tienen una comparación dedicada aquí en el blog porque son las dos opciones más citadas de la categoría; esta guía amplía la mirada hacia el panorama entero, incluyendo Unleash y Flagsmith, los motivos reales para elegir open-source, el peso operacional de mantener cada camino en pie, y por qué el rigor estadístico varía más entre herramientas abiertas que entre plataformas propietarias maduras.
Panorama rápido
| Herramienta | Enfoque principal | Self-hosted | Cloud gestionado | Motor estadístico nativo | Licencia del núcleo |
|---|---|---|---|---|---|
| GrowthBook | Feature flags + experimentación | Sí, stack liviano (app + MongoDB) | Sí, GrowthBook Cloud | Sí: bayesiano por defecto, frecuentista y secuencial disponibles | MIT en el núcleo, capa Enterprise aparte |
| PostHog | Product analytics con experimentación integrada | Sí, stack pesado (ClickHouse, Kafka, Postgres, Redis) | Sí, PostHog Cloud | Sí: bayesiano por defecto, frecuentista disponible | Open-source en parte, capa paga aparte |
| Unleash | Feature flags primero | Sí, stack liviano (app + PostgreSQL) | Sí, versión gestionada | Limitado: soporte básico a A/B, sin motor estadístico dedicado | AGPL-3.0-or-later en el núcleo |
| Flagsmith | Feature flags + remote config | Sí, stack liviano (app + PostgreSQL, Docker Compose) | Sí, versión gestionada | Limitado: variación vía flag multivariada, estadística a cargo de analítica externa | BSD-3-Clause en el núcleo, Enterprise Edition aparte |
El resto de esta guía detalla los motivos para elegir este camino, lo que cada herramienta realmente resuelve, el peso de operar cada una, y cómo validar el rigor estadístico de cualquiera de ellas por cuenta propia antes de confiar en el veredicto de un test.
Por qué un equipo elige una herramienta open-source
Cuatro motivos aparecen con más frecuencia cuando un equipo decide ir hacia el lado open-source en vez de una plataforma propietaria cerrada.
Control de datos. Cuando autohospedas, el dato de comportamiento del visitante (quién vio qué variación, quién convirtió) nunca sale de tu propia infraestructura para llegar al servidor de un proveedor externo. Esto es relevante en Brasil por la LGPD: mantener el dato dentro de tu propio entorno simplifica el control sobre dónde queda físicamente y reduce la superficie de compartición con terceros. Vale la salvedad: eso no es sinónimo automático de conformidad, es una pieza del rompecabezas, las demás obligaciones de la ley (base legal, minimización, retención, seguridad de acceso) siguen siendo tu responsabilidad independientemente de dónde esté el servidor.
Sin lock-in de proveedor. Migrar de una plataforma propietaria cerrada a otra suele significar reconstruir la integración desde cero, porque el formato de dato y la API son propietarios. Con una herramienta open-source, el código está ahí para ser leído, exportado o incluso bifurcado (fork) si el proveedor cambia de dirección de un modo que ya no sirve a tu equipo.
Personalización de código. Equipos de ingeniería con una necesidad específica (un algoritmo de bucketing diferente, una integración interna, un requisito de compliance fuera del estándar) pueden alterar el comportamiento directo en el código, algo imposible en una plataforma cerrada, donde solo puedes pedir la funcionalidad y esperar el roadmap del proveedor.
Costo cero de licencia, pero no costo cero. El núcleo de código no cuesta nada para correr, pero no corre solo: alguien necesita aprovisionar servidor, base de datos, backup, monitoreo y tiempo de ingeniería para mantener la versión actualizada. Cambiar costo de licencia por costo de operación es un intercambio real, no un ahorro automático, y el resto de esta guía trata exactamente de ese trade-off.
Panorama de las herramientas
GrowthBook nació como plataforma de feature flagging y experimentación, sin intentar ser nada más que eso. El motor estadístico es bayesiano por defecto, con opción de cambiar a frecuentista y a test secuencial, y el self-hosting es relativamente liviano: la aplicación principal más una base de datos MongoDB, generalmente levantada vía Docker Compose. Es la opción más citada por equipos dev-first que ya tienen (o van a construir) su propio warehouse de datos y quieren un motor de experimentación dedicado encima de él.
PostHog nació como suite de product analytics open-source y fue creciendo hasta incorporar experimentación como un módulo más dentro de un producto bastante más amplio, junto a embudo, grabación de sesión, encuestas y feature flags. El motor de experimentación también es bayesiano por defecto, con opción frecuentista, y usa el mismo pipeline de eventos que ya alimenta el resto de la suite. El self-hosting es la operación más pesada de las cuatro herramientas de esta guía: el stack completo incluye ClickHouse, Kafka, Postgres y Redis, y la propia documentación de la empresa recomienda la versión cloud para producción en la mayoría de los casos.
Unleash es feature flags primero, punto final: el producto fue diseñado para reducir el riesgo de lanzar funcionalidades nuevas (rollout gradual, canary release, kill switch), no para decidir victorias de test A/B. Tiene algún soporte a A/B testing, pero eso significa enrutar una fracción del tráfico hacia variaciones distintas de una flag, sin un motor estadístico dedicado calculando significancia por detrás. El self-hosting pide un servidor Node.js más una base de datos PostgreSQL, un stack relativamente delgado. Un detalle de licenciamiento vale la pena registrar: el núcleo del repositorio principal está bajo AGPL-3.0-or-later, una licencia copyleft más restrictiva que la MIT usada por el núcleo de GrowthBook o la BSD-3-Clause usada por el núcleo de Flagsmith, lo que puede importar dependiendo de cómo tu equipo pretenda modificar o redistribuir el código.
Flagsmith también es feature flags primero, con remote config y flags multivariadas como el camino para testear variaciones. Igual que Unleash, no tiene un motor de significancia estadística nativo: el estándar documentado por la propia empresa es usar la flag multivariada para enrutar el tráfico y enviar el evento de conversión hacia una herramienta de analítica externa (Amplitude, Mixpanel, o equivalente) que calcula el resultado. El self-hosting es liviano: Docker Compose levanta la aplicación y una base de datos PostgreSQL junto, sin exigir infraestructura de streaming de eventos como la de PostHog. El núcleo está licenciado bajo BSD-3-Clause, una licencia permisiva, con las funciones de Enterprise Edition (RBAC, SSO/SAML) cerradas aparte.
Si tu comparativa es específicamente entre GrowthBook y PostHog, mira la comparación dedicada entre las dos, con framework de decisión por perfil de equipo. Si quieres el panorama completo incluyendo herramientas propietarias como VWO y Optimizely, mira la comparación neutral de herramientas de test A/B.
Trade-offs de self-hosting: lo que nadie pone en el anuncio de “gratis”
El núcleo de código de cualquiera de las cuatro herramientas listadas arriba es gratuito para correr, pero autohospedar cambia costo de licencia por costo de operación, y ese segundo costo raramente aparece en las comparaciones rápidas. Un self-hosting sano de verdad pide, como mínimo, tiempo dedicado para aprovisionar y mantener el servidor y la base de datos, aplicar parches de seguridad apenas salen (bases de datos y proxies expuestos a internet son blanco constante), actualizar la versión de la herramienta sin romper experimentos en curso, y monitorear disponibilidad, porque una caída en el servicio de flag o experimentación puede trabar la atribución de variación para visitantes reales en medio de un test.
Ese peso no es igual entre las cuatro herramientas. GrowthBook, Unleash y Flagsmith piden un stack relativamente delgado (aplicación más una única base de datos relacional), el tipo de cosa que se levanta vía Docker Compose en pocos minutos y que un equipo pequeño de ingeniería consigue mantener sin que se vuelva un trabajo de tiempo completo. PostHog pide una operación de datos bastante más pesada, porque fue diseñado para procesar gran volumen de eventos: ClickHouse, Kafka, Postgres y Redis, entre otros componentes, lo que explica por qué la propia empresa recomienda la versión cloud para la mayoría de los equipos en producción.
El camino cloud gestionado de la misma herramienta (GrowthBook Cloud, PostHog Cloud, o las versiones gestionadas de Unleash y Flagsmith) le quita esa carga operacional a tu equipo, pero la cambia por una suscripción recurrente y, en la mayoría de los casos, por dato saliendo de tu infraestructura hacia la del proveedor, el mismo modelo de cualquier SaaS propietario. Ninguno de los dos caminos es “mejor” de forma absoluta: es una elección entre gastar tiempo de ingeniería o gastar presupuesto recurrente, y entre mantener el dato dentro de casa o aceptar que quede con un tercero.
| Herramienta | Stack mínima self-hosted | Peso operacional | Licencia del núcleo |
|---|---|---|---|
| GrowthBook | Aplicación + MongoDB | Liviano a medio | MIT (Enterprise aparte) |
| PostHog | Aplicación + ClickHouse + Kafka + Postgres + Redis | Pesado | Open-source en parte |
| Unleash | Aplicación Node.js + PostgreSQL 15+ | Liviano | AGPL-3.0-or-later |
| Flagsmith | Aplicación + PostgreSQL (Docker Compose) | Liviano | BSD-3-Clause (Enterprise aparte) |
Rigor estadístico en herramientas open-source: verifica antes de confiar
En una plataforma propietaria madura y cara, el motor estadístico suele ser un producto probado durante años y por miles de clientes pagantes, con poco espacio para divergencia entre lo que la interfaz muestra y lo que la matemática realmente calcula. En el universo open-source, esa garantía es menos uniforme: cada proyecto tiene su propio equipo, su propio ritmo de revisión y su propia elección de método, y la profundidad del motor varía bastante más de herramienta a herramienta de lo que suele variar entre competidores propietarios del mismo porte.
Esto queda claro en las cuatro herramientas de esta guía. GrowthBook y PostHog tienen un motor de experimentación dedicado, pensado específicamente para calcular significancia, con opción bayesiana y frecuentista documentada. Unleash y Flagsmith no tienen esa pieza nativa: son excelentes atribuyendo tráfico hacia variaciones de forma confiable, pero el cálculo estadístico de “esta diferencia es real o es ruido” típicamente ocurre en una herramienta de analítica conectada por fuera, no dentro del producto de flag en sí. Usar Unleash o Flagsmith para correr un test A/B sin también tener una capa de análisis estadístico serio detrás es el error más común: la flag funciona perfectamente, pero nadie garantizó que la muestra sea suficiente o que el resultado no sea peeking disfrazado de victoria.
La recomendación práctica, para cualquiera de las cuatro: no confíes ciegamente en el veredicto que muestra la interfaz, especialmente en una herramienta menos madura o con un equipo de mantenimiento más chico. Toma los mismos números de visitantes y conversiones que usó la herramienta y reproduce el cálculo de forma independiente. La calculadora de abajo, de nuestra guía de significancia estadística en test A/B, hace exactamente eso: pega visitantes y conversiones de cada variación y compara el valor-p, el lift y el veredicto con lo que tu herramienta open-source reportó para el mismo experimento.
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
Si los dos números coinciden, gran señal de que el motor está calculando correctamente. Si divergen por un margen grande, vale la pena investigar antes de tomar la decisión de negocio sobre el resultado, ya sea revisando la documentación del método estadístico de la herramienta, ya sea abriendo un issue en el repositorio, un lujo que existe justamente porque el código es abierto.
Cuándo tiene sentido NO ir con open-source
Open-source no es la elección correcta por defecto para todo equipo. Vale la pena considerar el camino propietario gestionado cuando al menos una de estas condiciones es verdadera:
- El equipo no tiene capacidad de DevOps disponible. Si nadie en el equipo puede responder con confianza “¿quién se encarga del parche de seguridad de la base de datos a las 2h de un viernes?”, autohospedar cualquiera de estas cuatro herramientas es asumir un riesgo operacional que nadie está preparado para cargar.
- La urgencia no permite una sprint de ingeniería. Un test A/B que necesita empezar mañana no combina con aprovisionar servidor, configurar base de datos, probar backup y validar SDK antes de que corra el primer experimento.
- El volumen de tráfico no justifica mantener infraestructura propia. Para un sitio pequeño o mediano, el costo de ingeniería de mantener un stack en pie frecuentemente supera, en salario y atención, lo que una suscripción gestionada cobraría por el mismo volumen.
- El equipo prefiere no convertirse en operador de base de datos. Incluso las opciones más livianas (GrowthBook, Unleash, Flagsmith) piden a alguien dispuesto a aprender a operar Docker, PostgreSQL o MongoDB en producción; esto es una elección de dónde invertir tiempo de ingeniería, no un detalle menor.
En esos casos, la capa cloud gestionada de la propia herramienta open-source (GrowthBook Cloud, PostHog Cloud) ya resuelve buena parte del problema sin abandonar el producto. Y una herramienta propietaria, gestionada de principio a fin, sigue siendo la opción más directa para quien quiere testear sin pensar en ninguna infraestructura.
Hazlo automático en Donnu
Si el motivo de mirar hacia open-source es escapar de una herramienta cara u opaca, pero el motivo de dudar es el peso de montar y mantener un self-hosting (servidor, base de datos, parches, backup, monitoreo), vale la pena considerar a Donnu como una opción más sobre la mesa: un SaaS gestionado, sin infraestructura propia que operar, con estadística bayesiana honesta y aislamiento de datos por cuenta desde el inicio. No es sustituto del feature flagging de producto al estilo Unleash o Flagsmith, ni de la suite completa de analítica de PostHog, y no es la elección correcta para quien realmente necesita personalizar el código fuente o mantener todo dentro de su propia infraestructura por exigencia interna. Pero para quien quiere dejar de sopesar Docker Compose contra una suscripción mensual y solo correr el test, es una alternativa gestionada y más delgada que un contrato enterprise.
Comienza una prueba gratis y mira si prescindir del self-hosting compensa para tu caso, especialmente si el tiempo de ingeniería de tu equipo está más escaso que el presupuesto.
Lee también
Mira también la comparación dedicada entre GrowthBook y PostHog para un framework de decisión por perfil de equipo entre las dos herramientas más citadas de esta categoría, la comparación neutral de herramientas de test A/B para el panorama completo incluyendo opciones propietarias, la guía de significancia estadística en test A/B para la mecánica completa detrás de cualquier motor bayesiano o frecuentista, y la guía sobre herramientas de test A/B realmente gratis para separar open-source de trial disfrazado de gratis.
Referencias
- GrowthBook. Documentación oficial y licenciamiento. docs.growthbook.io y github.com/growthbook/growthbook
- PostHog. Documentación oficial y guía de self-hosting. posthog.com/docs
- Unleash. Documentación oficial y repositorio open-source. docs.getunleash.io y github.com/unleash/unleash
- Flagsmith. Documentación oficial, licenciamiento y guía de self-hosting. docs.flagsmith.com y github.com/Flagsmith/flagsmith
Preguntas frecuentes
- ¿Qué diferencia a una herramienta de test a/b open source de una propietaria?
- La diferencia central no es el precio, es el control: una herramienta open-source publica el código fuente, así que puedes inspeccionar exactamente cómo el motor estadístico calcula un resultado, modificar el comportamiento y, en la mayoría de los casos, autohospedar la aplicación entera dentro de tu propia infraestructura. Una herramienta propietaria entrega solo la interfaz y la API, el código queda cerrado, y siempre dependes de que el servidor del proveedor esté funcionando. El costo de licencia cero del open-source es real, pero se transforma en costo de operación, ingeniería y mantenimiento cuando decides autohospedar.
- ¿GrowthBook, PostHog, Unleash y Flagsmith son todas gratuitas de verdad?
- El núcleo de código de las cuatro puede autohospedarse sin pagar licencia de software, pero "gratuito" ahí significa gratuito de licencia, no gratuito de operación: igual pagas el servidor, la base de datos y el tiempo de ingeniería para mantener todo funcionando. Las cuatro también venden una capa paga, ya sea en nube gestionada (GrowthBook Cloud, PostHog Cloud), ya sea como funciones enterprise cerradas encima del núcleo abierto (RBAC avanzado, SSO/SAML, soporte). Confirma siempre los límites actuales en la página de precios de cada una antes de planificar capacidad, porque esos números cambian con frecuencia.
- ¿El self-hosting de una herramienta de experimentación open-source resuelve la LGPD por sí solo?
- No por sí solo. Autohospedar mantiene el dato dentro de tu propia infraestructura en vez de salir hacia el servidor de un proveedor externo, lo que ayuda al control de dónde queda el dato físicamente y reduce la superficie de compartición con terceros, dos puntos relevantes para la LGPD. Pero eso no sustituye las demás obligaciones de la ley: base legal para el tratamiento, minimización del dato recolectado, política de retención, seguridad de acceso al propio servidor que estás operando. El self-hosting resuelve "dónde vive el dato", no "si tratas el dato de forma correcta".
- ¿Qué herramienta open-source de test A/B tiene el motor estadístico más robusto?
- No existe una respuesta única, porque las cuatro herramientas citadas aquí no compiten exactamente en la misma categoría. GrowthBook y PostHog tienen un motor de experimentación dedicado, con soporte a test bayesiano y frecuentista, pensado específicamente para decidir victorias de test A/B. Unleash y Flagsmith nacieron como plataformas de feature flag: consiguen enrutar tráfico hacia variaciones, pero el cálculo de significancia estadística típicamente queda a cargo de una herramienta de analítica externa conectada por fuera, no de un motor nativo de ellas. Antes de confiar ciegamente en el veredicto de cualquiera de ellas, vale la pena reproducir el cálculo por cuenta propia.
- ¿Cuándo tiene más sentido no usar una herramienta de test A/B open-source?
- Principalmente cuando el equipo no tiene capacidad real de DevOps disponible para instalar, actualizar y monitorear un stack propio. El peso operacional varía mucho entre las opciones (un stack de GrowthBook autohospedado es bastante más simple de mantener que un stack completo de PostHog, por ejemplo), pero ninguna de ellas es "instala y olvídate". Un equipo pequeño sin nadie dedicado a infraestructura, o que necesita algo funcionando mañana sin sprint de ingeniería dedicado, normalmente sale ganando con una herramienta gestionada, ya sea la capa cloud de la propia herramienta open-source, ya sea una alternativa propietaria.