Diseño de Experimentos de Crecimiento: De la Hipótesis al MDE y la Lectura de Resultados

La primera vez que publiqué un "ganador" que nos costó el 3% de las pruebas fue una prueba de CTA en la página de precios. Tres días, 240 visitantes, la variante B con un 6,2% de ventaja. El PM reaccionó en Slack con el emoji del trofeo. Dos semanas después el volumen de pruebas de la semana parecía raro, rehíce la matemática y el "ganador" original estaba dentro del rango de ruido todo el tiempo. Habíamos publicado nada, excepto un trimestre de roadmap construido sobre una corazonada.

Así es el trabajo, honestamente. No la parte de las pruebas. La parte de no dejarse engañar.

Esta guía es el playbook que desearía que alguien me hubiera dado el primer día: cómo escribir una hipótesis que pueda ser refutada realmente, cómo hacer la matemática del tamaño de muestra en una servilleta, cómo elegir entre ICE y RICE sin mentirse a sí mismo, y cómo escribir una lectura de resultados que su CFO realmente abra. Si se lleva una sola cosa de aquí, llévese esta: la prueba no es el entregable. La lectura de resultados lo es. La mayoría de los trimestres, eso son 4 lecturas, no 40.

Por qué la mayoría de los experimentos B2B fallan

He auditado quizás 60 experimentos de crecimiento en empresas SaaS y PLG en los últimos años. Los modos de fallo se agrupan en cinco cosas, y cuatro de ellas se deciden antes de que la prueba se active.

1. Insuficiencia de potencia desde el primer día. El equipo ejecuta una prueba de 5 días en 800 usuarios con un 8% de tasa de conversión base, ve un incremento de 0,4 puntos porcentuales y lo llama ganador. El MDE real en ese tamaño de muestra es algo así como 3 puntos porcentuales relativos a la base. Cualquier cosa más pequeña es estadísticamente indistinguible del azar. No ejecutaron un experimento malo. Ejecutaron una prueba incapaz de detectar el efecto que esperaban.

2. Hipótesis escrita como una tarea. "Probaremos un nuevo titular en la página de precios." Eso no es una hipótesis. Una hipótesis predice qué cambia, cuánto, para quién y por qué. Si su hipótesis no puede ser refutada por los datos, la prueba producirá una historia sin importar lo que suceda.

3. Sin plan de reversión. Se publica la variante, la conversión baja un 4%, nadie es dueño de la decisión de reversión, la variante sigue funcionando durante otras 6 semanas porque "queremos más datos." No necesita más datos. Necesita una regla de parada pre-registrada.

4. Sin métrica primaria pre-registrada. A los tres días, la conversión es plana pero el tiempo en página subió un 22%, por lo que de repente el tiempo en página es la métrica. Esto tiene un nombre: HARKing (formular hipótesis después de conocer los resultados, por sus siglas en inglés). Todos los equipos lo hacen. Todos los equipos que lo hacen producen lecturas de resultados poco confiables.

5. El PM mira el gráfico el día 3. Miraje anticipado. Las pruebas secuenciales existen exactamente por esta razón, y la mayoría de los equipos no las usa. Una prueba de horizonte fijo estándar pierde sus garantías estadísticas en el momento en que toma decisiones basadas en miradas intermedias.

Los primeros cuatro se resuelven con una plantilla de hipótesis. El quinto se resuelve con una calculadora de tamaño de muestra y la disciplina de dejar el dashboard tranquilo.

La plantilla de hipótesis

Copie esto. Péguelo en el rastreador de experimentos de su equipo. Conviértalo en la única plantilla que alguien tiene permitido usar.

EXPERIMENTO: [nombre corto, p. ej. "Bloque de prueba social en página de precios"]

PROBLEMA (lo que observamos en los datos):
  Vemos el comportamiento X en el segmento Y. Específicamente:
  - Punto de datos 1: [de analítica, tickets de soporte, llamadas de ventas, datos cualitativos]
  - Punto de datos 2: [confirmando o triangulando]

CAMBIO PREDICHO (qué haremos, para quién):
  Para [segmento], haremos [cambio], porque [mecanismo que creemos está en juego].

MÉTRICA DE ÉXITO:
  Primaria:  [una métrica, con el número base actual]
  Control 1: [no debe moverse peor que X]
  Control 2: [no debe moverse peor que Y]

MDE (el efecto más pequeño sobre el que actuaríamos):
  Necesitamos detectar un incremento relativo de [N%] en la métrica primaria.
  Por debajo de eso, el cambio no vale el costo de ingeniería / riesgo de marca / enfoque.

TAMAÑO DE MUESTRA Y DURACIÓN:
  Por grupo: [N] usuarios
  Duración estimada al tráfico actual: [N semanas]

CRITERIOS DE REVERSIÓN:
  Cerramos la variante inmediatamente si:
  - La métrica primaria empeora más de [X]
  - Cualquier métrica de control supera su umbral durante más de 48h
  - Ingeniería encuentra un error P0/P1

FECHA DE DECISIÓN: [una fecha real, no "cuando tengamos suficientes datos"]
RESPONSABLE: [una persona]

Dos notas. Primero, la línea del MDE no es un deseo. Es el umbral por debajo del cual no publicaría el cambio de todos modos, incluso si fuera "real." Si un 1,5% de incremento en activación no vale el costo de mantenimiento de llevar la variante en código para siempre, entonces ese 1,5% no es su MDE. Su MDE es el número que realmente supera el costo. Sea honesto ahí.

Segundo, la fecha de decisión elimina más zombies que cualquier otra cosa en esta plantilla. Sin ella, cada prueba funciona eternamente.

La matemática del MDE que puede hacer en una servilleta

Aquí está la fórmula que uso para planificación, ante la cual un estadístico real objetaría levemente pero que le acerca a menos del 10% de la verdad y es lo suficientemente rápida como para que realmente la use:

n por grupo  ≈  16 × p × (1 - p) / MDE²

Donde:

• p es su tasa de conversión base (como decimal, p. ej. 0,08 para el 8%)
• MDE es el incremento absoluto que quiere detectar (como decimal, p. ej. 0,008 para un movimiento del 8,0% al 8,8%, que es un 10% de incremento relativo)
• 16 incorpora un poder del 80% y un nivel de confianza del 95% (bilateral)

Eso es todo. No se necesita software. Hagamos uno real.

Ejemplo resuelto: una conversión de prueba a pago del 8%

Su empresa B2B SaaS tiene 600 registros semanales. La conversión de prueba a pago es del 8% (entonces p = 0,08). Quiere detectar un 10% de incremento relativo, es decir, del 8,0% al 8,8% absoluto (entonces MDE = 0,008).

n por grupo  =  16 × 0,08 × 0,92 / (0,008)²
             =  16 × 0,0736 / 0,000064
             =  1,1776 / 0,000064
             ≈  18.400 usuarios por grupo

Dos grupos = 36.800 usuarios. Con 600 registros por semana divididos al 50/50 en la prueba, eso son aproximadamente 6 a 8 semanas de tráfico para un experimento. No 5 días.

Ahora, si quiere detectar un 25% de incremento relativo (del 8,0% al 10,0%), la matemática se vuelve más amigable:

n por grupo  =  16 × 0,08 × 0,92 / (0,02)²
             =  1,1776 / 0,0004
             ≈  2.944 por grupo

Aproximadamente 6.000 usuarios en total. Con 600 por semana, aproximadamente 2 semanas. El problema: los incrementos relativos del 25% en conversión de prueba a pago son prácticamente unicornios en embudos B2B maduros. Tendrá uno o dos al año si lo hace bien. La mayoría de las victorias reales son del 3 al 8% relativo, lo que significa que la mayoría de sus pruebas necesitan meses de tráfico, no días.

Esta es la parte que nadie quiere escuchar: su embudo no se mueve un 25%, así que sus experimentos necesitan estar dimensionados para los incrementos que realmente existen. Pase esto por alto y cada prueba se convierte en un test de Rorschach.

Cuándo "simplemente lo ejecutaremos más tiempo" está mal

Si una prueba tenía potencia insuficiente desde el primer día, ejecutarla más tiempo con configuraciones de horizonte fijo no lo arregla. Infla su tasa de falsos positivos, porque en efecto está mirando de antemano. Si genuinamente necesita flexibilidad en la duración, cambie a:

• Pruebas secuenciales (msPRT, p-values siempre válidos): le permite parar antes o extender sin romper la matemática. Statsig, GrowthBook y Eppo lo admiten nativamente.
• CUPED (reducción de varianza usando datos pre-experimento): puede reducir el tamaño de muestra requerido en un 30 a 50% en métricas con fuerte señal pre-período. Vale la pena activarlo para cualquier prueba importante.

No intente implementar estos a mano. Use la plataforma.

Diagnósticos comunes que hay que conocer por nombre

Si puede nombrar el modo de fallo, puede argumentar en contra en una revisión de resultados. Los cinco que veo más:

• HARKing: elegir la métrica después de ver el resultado. Se resuelve pre-registrando la primaria y los controles antes del lanzamiento.
• Miraje anticipado: tomar decisiones en miradas intermedias de pruebas de horizonte fijo. Se resuelve con pruebas secuenciales o genuinamente sin mirar hasta la fecha de decisión.
• Efecto de novedad: la variante gana durante dos semanas porque es nueva, luego retrocede. Se resuelve extendiendo las pruebas en cambios de interfaz y observando el comportamiento de la semana 3 en adelante.
• Paradoja de Simpson: la variante gana globalmente pero pierde en cada segmento, porque la mezcla cambió. Se resuelve pre-segmentando siempre su lectura (nuevos vs. recurrentes, por plan, por fuente).
• Sesgo de supervivencia en métricas de cohorte: medir "retención en la semana 4" solo en usuarios que llegaron a la semana 4 infla el número. Se resuelve anclando cohortes en el evento de entrada.

Priorización: ICE vs. RICE vs. PIE

Tres frameworks, ingredientes ligeramente diferentes, todos mintiéndole de maneras diferentes.

Mi opinión honesta: ICE está bien para un equipo de 2 personas y miente para uno de 20. Cuando el equipo es lo suficientemente pequeño para que todos hayan leído cada documento, ICE es solo una manera de escribir una conversación que se tendría de todos modos. Una vez que el equipo es lo suficientemente grande para que la puntuación ICE sea el único artefacto que lee un interesado, todos los PMs la manipulan.

La trampa con los tres: usted está puntuando sus propios experimentos. Los responsables sobrevaloran la Confianza en sus propias ideas. Los ingenieros subestiman la Facilidad en las ideas de otro. La puntuación se convierte en un proxy de la política de oficina.

Lo que ejecuto en su lugar a escala: una cuadrícula 2x2 de Confianza x Alcance sin matemática. Arriba a la derecha (alta confianza, alto alcance) se publica ahora. Arriba a la izquierda (alta confianza, alcance reducido) se publica si es barato. Abajo a la derecha (baja confianza, amplio alcance) se convierte en una inversión de investigación de pago. Financiaremos la prueba sobre la base del valor de aprendizaje, no del incremento esperado. Abajo a la izquierda muere. Se revisa semanalmente, en una reunión de 30 minutos, con el responsable de crecimiento sosteniendo el marcador.

No es un número. Es un mecanismo de forzamiento para una conversación honesta.

Límite de trabajo en curso: máximo 3-5 pruebas activas

Para la mayoría de los equipos B2B con menos de 500 empleados, el número correcto de experimentos concurrentes es de 3 a 5. Por encima de eso, consume su propio tráfico, los efectos de interacción se vuelven inrastreables y el equipo no puede prestar atención real a las lecturas de resultados. La restricción no es la velocidad de ingeniería. Es el tráfico y la atención.

El documento de lectura de resultados (este es el entregable real)

Cada prueba publicada, cerrada o inconclusa obtiene una lectura de resultados de una página. No un dashboard. Un documento. Guardado en la misma carpeta para siempre.

LECTURA DE RESULTADOS: [nombre del experimento]
FECHAS: [inicio] a [fin]
RESPONSABLE: [nombre]
ESTADO: Publicado / Cerrado / Inconcluso

QUÉ SE PUBLICÓ
  La variante B reemplazó [X] con [Y] en [página/flujo], para [segmento], del [fecha] al [fecha].

QUÉ MEDIMOS
  Primaria:    [métrica], control [N], variante [N], delta [+X% / -Y%], p = [N], IC [N, N]
  Control 1:   [métrica], plano / superado
  Control 2:   [métrica], plano / superado
  Muestra:     [N por grupo], dimensionado para un [MDE]% de incremento relativo

QUÉ APRENDIMOS
  - Interpretación del resultado en 2-3 oraciones. Sin "lo aplastamos." Sí "conversión de
    prueba a pago se movió +4,2% (IC 1,1-7,3%), dentro de nuestro MDE pre-registrado del 4%,
    así que publicamos."
  - Divisiones por segmento: [dónde fue más fuerte / más débil el efecto]
  - Algo raro: [señal de novedad? ruido en métricas de control? calidad de datos?]

QUÉ HAREMOS DESPUÉS
  - Plan de publicación / mantenimiento de la variante
  - Pruebas de seguimiento (máximo 2)
  - Cualquier cosa que necesite atención de ingeniería, producto o diseño

ESTÁBAMOS EQUIVOCADOS EN ___
  Una oración. La cosa que creíamos al entrar que los datos refutaron (o se negaron a confirmar).

La línea "estábamos equivocados en" es el arma secreta. Hace tres cosas:

1. Genera confianza en el equipo. Los líderes ven que no está empaquetando pérdidas como victorias.
2. Acumula aprendizajes. A lo largo de un año tiene más de 30 líneas de "estábamos equivocados," y emergen patrones ("seguimos sobreestimando el impacto de los cambios en la página de precios").
3. Calibra las puntuaciones de Confianza futuras. Sus priors se vuelven más agudos.

Si sus lecturas de resultados no tienen una línea de "estábamos equivocados" para al menos el 60% de las pruebas completadas, o está probando solo cosas seguras o está reescribiendo la historia. Ambas son malas.

De dónde vienen las hipótesis del backlog

Un pipeline de pruebas se agota si el equipo no tiene una manera estructurada de generar ideas. Cinco fuentes en las que confío, aproximadamente en orden descendente de señal:

1. Diferencias de embudo: el segmento X convierte al doble de la tasa del segmento Y en el mismo paso. Averigüe por qué. Aquí viven las victorias más grandes y defendibles.
2. Entrevistas cualitativas: 5 clientes que abandonaron, grabados y transcritos. Escuchará el mismo punto de fricción en 3 de ellos. Esa fricción es su próxima hipótesis.
3. Grabaciones de llamadas de ventas: Gong/Chorus es una mina de oro. Busque "ojalá pudiera" o "lo que me confundió." Cada uno es una hipótesis con confianza pre-incorporada.
4. Tickets de soporte: misma idea, embudo inferior. Agrúpelos por tema. El grupo más grande suele ser una corrección de 2 semanas de ingeniería que eleva la activación más que sus últimas 6 pruebas combinadas.
5. Análisis de la competencia: útil pero peligroso. Sobrevalorará la novedad. Etiquete estos como Confianza baja por defecto.

Puntúe cada idea contra la plantilla de hipótesis antes de que entre en la cola de priorización. Si no puede completar la sección Problema con dos puntos de datos reales, la idea no está lista. Es una suposición. Devuélvala para investigación.

Eliminar experimentos zombie

Cada equipo de crecimiento que he visto los tiene: pruebas que siguen sirviendo tráfico a una variante que nadie es dueño, detrás de una bandera que nadie recuerda, en una página que nadie audita. Tres reglas:

• La regla de los 90 días. Si una prueba ha estado activa más de 90 días sin una lectura de resultados, se cierra por defecto en la próxima revisión trimestral. Sin excepciones por "estamos esperando más datos." Si una prueba necesita 4 meses para alcanzar significancia, tenía potencia insuficiente en el lanzamiento y la respuesta correcta es parar y rediseñar.
• Revisión trimestral del cementerio. Una vez por trimestre, audite cada bandera activa en su plataforma de experimentación. Empareje cada una con un responsable y un documento de lectura. Todo lo que esté huérfano vuelve al control y la bandera se elimina del código.
• La auditoría de "todavía sirve tráfico." Extraiga la lista de todas las URLs elegibles para experimentos y compárela con las pruebas activas en la plataforma. Cada brecha es un error de configuración o un zombie. Corrija ambos.

El equipo que ejecute esta auditoría honestamente descubrirá que el 30 al 40% de sus pruebas "activas" son peso muerto. Eliminarlas libera tráfico y atención para pruebas que pueden aprender realmente.

El trabajo real del growth IC

Cerrará donde abrí. El trabajo del IC no es publicar más pruebas. Es publicar más aprendizajes. La mayoría de los trimestres, eso son 4 pruebas bien diseñadas, correctamente dimensionadas y honestamente leídas, no 40 encogiéndose de hombros.

Una buena práctica de experimentación parece lenta desde fuera. El equipo está ejecutando 3 pruebas, no 30. La mitad de las lecturas dicen "estábamos equivocados." Se le da respuesta al PM que defiende el miraje anticipado. El CFO realmente abre el documento de lectura y hace una pregunta sobre la métrica de control.

Ese es el trabajo funcionando. Los trofeos en Slack llegan después, y son reales porque la matemática fue real.

Aprenda más

• Descripción del Puesto de Growth Marketing Manager
• Diagnóstico del Embudo PLG para el Growth IC
• Selección de Métricas de Activación: Elegir el Único Número
• Cómo Leer una Curva de Retención de Cohortes sin Engañarse a Sí Mismo