Cómo PostHog convierte cada release en una pregunta medible, y por qué en growth casi nadie lo hace

Una marca cambia el copy del checkout, sube el precio del envío gratis de $15.000 a $20.000 y esa misma semana el proveedor de ads ajusta el algoritmo de puja. La conversión baja tres puntos. ¿Cuál de las tres cosas la movió? En la mayoría de los equipos, la respuesta se decide en una reunión, por la persona que habla con más convicción. Nadie construyó el mecanismo que permitiría contestar esa pregunta con datos, así que la contestan con intuición y la llaman análisis.

Ese es el problema que resuelve, o intenta resolver, la otra mitad de lo que ya escribimos sobre el modo self-driving de PostHog. Esa nota cubría quién propone un cambio y quién lo aprueba: agentes que observan señales de producto, arman un pull request, un humano lo revisa antes de que salga a producción. Lo que quedó afuera, a propósito, fue la parte que hace que ese circuito no sea una apuesta a ciegas: el mecanismo que decide, después de que el cambio salió, si funcionó o no. Sin ese juez, aprobar el PR de un agente es un acto de fe con pasos extra.

Un flag no es un truco de desarrollador, es una forma de decidir

La documentación de PostHog es explícita en una distinción que la mayoría de los equipos no hace en la práctica: deploy no es lo mismo que release. Deploy es cuando el código nuevo está en producción. Release es cuando alguien lo experimenta. Un feature flag separa esas dos cosas: el código puede estar viviendo en producción y visible solo para el 5% del tráfico, con la posibilidad de subir ese porcentaje de forma gradual o apagarlo por completo sin tocar el código otra vez. La frase que usa PostHog para esto es directa: cuando algo se rompe, se apaga; cuando funciona, se expande y se mide el impacto.

Eso convierte cada lanzamiento en algo reversible por diseño, no en un evento de todo o nada. Pero un flag por sí solo solo controla exposición. Lo que lo conecta con la pregunta de si funcionó es el experimento que se arma sobre él.

Crear un experimento en PostHog es un flujo de tres pasos y el primero ya obliga a algo que la mayoría de los equipos se salta: escribir la hipótesis antes de lanzar. El experimento se apoya en un feature flag, que PostHog puede generar automáticamente o reusar uno existente si ya tiene al menos dos variantes, una llamada "control". El segundo paso reparte el tráfico entre variantes, con hasta nueve variantes de test además del control. El tercero es el que importa para esta nota: ahí se define qué evento marca que un usuario quedó "expuesto" al cambio, y se agregan las métricas primarias (las que deciden si la hipótesis se sostiene) y las secundarias (las que avisan si el cambio rompió algo que no se estaba mirando). Solo los eventos posteriores a la exposición cuentan para el resultado, así que el experimento no puede contaminarse con comportamiento previo al cambio.

Las métricas en sí no son un solo tipo. PostHog soporta métricas de funnel (una secuencia de pasos, típico para onboarding o checkout), de media (por ejemplo, revenue promedio por usuario), de ratio (revenue por compra, ítems por sesión) y de retención. La elección de qué tipo de métrica usar es, en la práctica, la decisión más importante del experimento, porque de ahí sale qué se considera "funcionó".

La estadística que se lee sin traductor

La parte que más distingue a PostHog de otras herramientas de experimentación es cómo presenta el resultado. Por default usa estadística bayesiana en lugar de frecuentista: en vez de un p-valor que hay que interpretar contra un umbral arbitrario de significancia, el sistema calcula la probabilidad de que una variante sea mejor que otra y lo comunica en lenguaje llano, del tipo "hay 96% de probabilidad de que la variante B mejore la conversión". También ofrece intervalos creíbles alrededor del efecto estimado y, opcionalmente, CUPED para reducir varianza cuando hay métricas ruidosas.

Es una decisión de producto tanto como estadística: un número de "probabilidad de ganar" se lee en una reunión de founders más rápido que un intervalo de confianza al 95%. Pero facilidad de lectura no es certeza. Un 87% de probabilidad de que algo funcione sigue dejando un 13% de que no, y esa lectura la sigue haciendo una persona, no el dashboard. La estadística bayesiana no elimina el juicio humano en el gate, lo hace más accesible.

Lo que el gate no resuelve solo

PostHog también ofrece experimentos sin código, en beta: se editan textos, botones o estilos desde una barra de herramientas visual, sin tocar el repositorio. La propia documentación es honesta sobre el límite: funciona bien en sitios renderizados del lado del servidor con cambios simples de texto o formato, y no se recomienda para aplicaciones de una sola página con mucho re-render, donde el cambio visual se puede perder. No es una promesa de que cualquiera arme un experimento sin ingeniería; es una herramienta para un subconjunto acotado de cambios.

El otro límite es de pricing, y vale la pena tenerlo en la cabeza antes de asumir que esto es gratis para siempre: feature flags se cobra por request procesado (desde $0,0001 por request, con tiers que bajan según volumen) y los experimentos se facturan junto con los flags, no aparte. El plan gratuito incluye un millón de requests de flags al mes, que alcanza para bastante, pero el modelo es de uso, no plano, así que escala con el tráfico igual que cualquier otro costo de infraestructura.

La disciplina que falta en paid media

Casi ningún equipo de growth o paid media tiene este reflejo. Se cambia el copy del ad, se sube el creativo nuevo, se ajusta la puja, y todo pasa en la misma semana sin flag, sin variante de control ni métrica primaria declarada de antemano. Cuando el número se mueve, se le atribuye la causa al último cambio que alguien recuerda haber hecho. Eso no es medición, es memoria selectiva con gráfico.

Por eso vale la pena mirar el patrón de PostHog más allá de si se usa esa herramienta puntual: la idea de que cada release lleva atada una métrica y una forma explícita de leerla, antes de lanzar, es lo que permite después aceptar una propuesta de cambio con algo de confianza, venga de un analista senior o de un agente que la generó a partir de datos de producto. Ese es el hilo que conecta esta nota con el modo self-driving: un agente puede proponer con la disciplina que quiera, pero si nadie construyó el gate que mide si el cambio funcionó, la aprobación humana en el medio no está evaluando nada, solo está firmando.

Queda abierta una pregunta que no pudimos verificar con la documentación pública: cómo se comporta el enfoque bayesiano de PostHog en experimentos con muestras chicas y tráfico estacional, el escenario típico de una cuenta de paid media en LATAM y no el de un producto SaaS con millones de eventos por semana. Es un punto que recomendamos validar caso por caso antes de asumir que el mismo umbral de confianza aplica igual en ambos contextos.