Growth Experimentation para SaaS: Playbook PLG

Growth experimentation es la disciplina de correr tests controlados a lo largo de todo el embudo de un producto, desde el primer clic en un sitio web hasta la expansión de una cuenta paga, con la activación (no la tasa de conversión de una sola landing page) como la métrica que decide el resultado. En un producto PLG (product led growth, crecimiento liderado por el producto), el embudo de marketing clásico (visitante, lead, venta) se convierte en uno más largo y mejor instrumentado: visitante, registro, activación, trial o plan gratuito, conversión a pago, expansión y retención. Cada etapa tiene sus propios experimentos característicos, cada etapa tiene una muestra disponible distinta, y tratar a todas como “solo otro test A/B de landing page” es el error que desperdicia el rigor estadístico que este blog defiende en cada artículo. Esta guía cubre lo que de verdad cambia: cómo definir la activación, cómo formar y priorizar hipótesis de growth, la estadística que se vuelve más exigente cuanto más profundo pruebas en el embudo, y cómo organiza ese trabajo un equipo de growth real.

Growth experimentation no es el CRO tradicional

El CRO (optimización de tasa de conversión) tradicional se construyó para páginas de marketing: una landing page, un checkout, un formulario de captura de leads. La métrica que decide el test es objetiva y rápida de medir (hizo clic, compró, completó el formulario), y el volumen de tráfico suele ser lo bastante alto para una muestra generosa en cuestión de días.

Growth experimentation hereda el mismo rigor estadístico que el CRO (una hipótesis escrita, una muestra calculada, un test de significancia real, cuidado con el peeking), pero aplica ese rigor a un territorio distinto: el producto después del registro. En la práctica, eso cambia tres cosas.

Dimensión	CRO tradicional	Growth experimentation en PLG
Dónde corre el test	Landing page, checkout, formulario	Onboarding, mensajería dentro del producto, paywall, email de reactivación, pantalla de upgrade
Métrica primaria típica	Conversión de visita a lead o de visita a venta	Tasa de activación (aha moment), conversión de trial a pago, expansión de cuenta
Volumen disponible	Alto, el tráfico de marketing llega directo	Se reduce en cada etapa, la etapa más profunda tiene la muestra más pequeña
Quién instrumenta el test	Equipo de marketing, tag manager, pixel	Equipo de producto, eventos de uso ya instrumentados en la app
Duración típica del ciclo	Días a pocas semanas	Semanas a meses, porque las métricas de retención necesitan tiempo para revelarse

Ningún enfoque es “mejor”, responden preguntas distintas. La mayoría de los productos PLG necesitan ambos: CRO en la puerta de entrada (el sitio que trae el registro) y growth experimentation dentro del producto (lo que convierte ese registro en uso real e ingreso recurrente). Esta guía se enfoca en la segunda parte, que es donde la mayoría de los equipos de producto tropiezan por falta de un embudo bien definido y estadística honesta.

El embudo PLG, del visitante a la expansión

Antes de cualquier hipótesis, necesitas mapear el embudo que realmente estás optimizando. En un producto self-service, el embudo típico tiene seis etapas, y cada una tiene su propia pregunta y su propio tipo de experimento:

La caída más pronunciada del embudo casi siempre ocurre entre el registro y la activación, no entre el visitante y el registro. Es intuitivo si lo piensas: crear una cuenta no cuesta casi nada (un email y una contraseña), pero llegar al punto en que el producto realmente entrega valor exige que el usuario configure algo, entienda qué hacer y vuelva al menos una segunda vez. Ese tramo exacto del embudo, de registro a activación, es donde se concentra la mayoría de los experimentos en un programa de growth PLG maduro.

Qué significa “activación” en realidad (el aha moment)

La activación es el evento, o la combinación de eventos, que marca el momento en que un usuario experimenta por primera vez el valor central del producto, comúnmente llamado el aha moment. La definición se remonta a un framework de tres pasos enseñado por Reforge (Setup, Aha, Habit): un usuario primero completa la configuración necesaria para recibir valor, luego experimenta el valor central por primera vez (aha), y solo después construye un hábito recurrente alrededor de ese valor (habit), siendo la etapa de hábito la que realmente predice la retención de largo plazo, según la propia guía de Reforge sobre cómo definir momentos de activación del cliente.

Los dos ejemplos más citados en la literatura de growth ilustran por qué la métrica correcta rara vez es obvia al primer intento:

• Facebook, “7 amigos en 10 días”. El número se atribuye ampliamente al equipo temprano de growth de Chamath Palihapitiya, que trabajó hacia atrás desde un corte transversal amplio de usuarios comprometidos para encontrar el comportamiento que separaba a los que se quedaban de los que se iban, no a partir de un único hallazgo científico. Una retrospectiva ampliamente citada de Mode Analytics agrega una advertencia que suele faltar al recontar la historia: el número funciona como un promedio memorable calculado sobre un conjunto muy diverso de usuarios, no como un punto de inflexión preciso que aplica igual a cada individuo, y la verdadera ventaja de Facebook fue menos la precisión estadística del número y más el foco organizacional que creó.
• Slack, 2.000 mensajes de equipo. Según un estudio de caso ampliamente citado de GrowthHackers sobre Slack que cita directamente al fundador Stewart Butterfield, los equipos que intercambiaron 2.000 mensajes internos mostraron aproximadamente 93% de retención, un salto claro comparado con los equipos por debajo de ese volumen. El onboarding de Slack se diseñó posteriormente para llevar a los equipos a ese volumen de mensajes lo más rápido posible (invitando compañeros, creando canales, conectando integraciones), no para maximizar registros aislados.

El hilo común entre ambos ejemplos, y la razón de citarlos aquí, no es el número en sí (7 amigos o 2.000 mensajes no significan nada fuera del contexto de cada producto), es el método: ambos números salieron de comparar cohortes retenidas contra cohortes que abandonaron y encontrar el comportamiento que las distinguía, no de una suposición sobre qué métrica “se siente” importante. Ese método exacto, aplicado a tu propio producto, es lo que define tu métrica de activación, no copiar un número que funcionó en otro lado.

Una forma estructurada de elegir esa métrica, usada por equipos de producto maduros, es el North Star Metric: según el framework de Amplitude, un indicador adelantado que captura el valor que los clientes obtienen del producto, que está dentro de la esfera de influencia de producto y marketing, y que predice los resultados de negocio a largo plazo. La activación suele ser el primer escalón que alimenta esa North Star, el evento que tiene que ocurrir antes de que exista cualquier retención real.

Activación por tipo de producto

Lo que cuenta como “valor central” cambia según la categoría de producto, y la métrica de activación cambia con ella. Algunos arquetipos comunes de la literatura de growth, sin números fijos de mercado (cada producto igual necesita validar el suyo, mediante la misma comparación de cohortes descrita arriba):

Tipo de producto	Qué suele señalar la activación	Por qué ese evento, no el registro en sí
Colaboración y mensajería (tipo Slack)	Volumen de mensajes intercambiados por el equipo, no solo cuentas creadas	El valor solo existe una vez que todo el equipo lo usa, una sola cuenta nunca experimenta el producto real
Red social (tipo Facebook)	Conexiones hechas con otras personas dentro del producto	Una red social sin conexiones nunca entrega su valor central, que es la red
Herramienta para developers o API	Primera llamada de API exitosa en producción, no solo una API key creada	Copiar una key no prueba nada sobre si el producto resolvió el problema real del developer
Herramienta de productividad o datos (dashboards, BI)	Crear, y sobre todo compartir, un primer artefacto (reporte, dashboard)	Un reporte que nadie más que su creador ve rara vez construye el hábito de volver
Marketplace de dos lados	Primera transacción completada en cada lado (comprador y vendedor)	El registro sin transacción no valida que la oferta y la demanda de verdad se encuentren

El patrón que se repite en la tabla: la activación casi nunca es “creó la cuenta”. Es el primer momento en que el comportamiento de un usuario empieza a parecerse al de alguien que ya es un cliente satisfecho, no al de alguien que todavía solo está probando el producto.

Cómo escribir hipótesis de growth

La estructura de una hipótesis de growth es exactamente la misma que se usa en cualquier test A/B: evidencia, cambio, efecto esperado y métrica primaria, ya detallada en la guía sobre cómo escribir una hipótesis de test A/B. Lo que cambia en un contexto PLG es de dónde viene la evidencia (datos de producto y de uso, no solo analítica de marketing) y qué métrica ataca cada hipótesis, según la etapa del embudo que enfrenta.

Un ejemplo aplicado a la etapa de activación: “Porque los datos de uso muestran que la mayoría de los usuarios de trial nunca conecta una fuente de datos en su primera sesión (evidencia), creemos que reemplazar el formulario de configuración inicial por un asistente guiado de tres pasos (cambio) va a aumentar la proporción de cuentas que llegan al aha moment dentro de los primeros 7 días (efecto), medido por la tasa de activación a 7 días (métrica).” Nota que la métrica no es “clics en el botón de configurar”, es la métrica de activación real, definida antes de correr cualquier test.

Otro ejemplo, esta vez en la etapa de conversión a pago: “Porque los datos de embudo muestran que las cuentas que alcanzan el 80% del límite de uso del plan gratuito convierten seis veces más que el promedio (evidencia), creemos que un aviso dentro de la app cuando una cuenta cruza ese umbral, con un camino directo de upgrade (cambio), va a aumentar la conversión de trial a pago entre esas cuentas (efecto), medido por la tasa de conversión de trial a pago de ese segmento (métrica).”

Cómo priorizar experimentos de growth: ICE aplicado al embudo

Un equipo de growth rara vez tiene la capacidad de probar todo lo que sugiere el backlog. El framework más citado para ordenar ese backlog, creado por Sean Ellis mientras dirigía growth en LogMeIn y Dropbox, es ICE: cada idea recibe un puntaje de 1 a 10 en tres ejes, Impact, Confidence y Ease (el inverso del esfuerzo), y el promedio de los tres produce el puntaje que ordena el backlog.

Experimento (etapa del embudo)	Impact	Confidence	Ease	ICE (promedio)
Checklist de progreso en el onboarding (activación)	8	7	8	7,7
Asistente guiado de configuración inicial (activación)	9	6	4	6,3
Aviso dentro de la app cerca del límite del plan gratuito (conversión)	8	8	7	7,7
Rediseño completo del paywall (conversión)	9	4	3	5,3
Email de reactivación para trials inactivos (activación tardía)	5	6	9	6,7
Prompt de invitación al equipo en la primera sesión (activación, productos colaborativos)	7	7	7	7,0

El patrón que expone la tabla es intencional: la idea con el mayor impacto teórico (rediseñar todo el paywall) tiene el peor puntaje, porque la confianza en la hipótesis es baja y el esfuerzo es alto. Eso no significa “nunca hagas el gran rediseño”, significa “prueba primero las apuestas de alta confianza y bajo esfuerzo, y guarda la gran apuesta para cuando tengas suficiente evidencia que justifique el esfuerzo”. Esa es la misma lógica que protege contra el error más común de los equipos de growth sin experiencia: probar el cambio más ambicioso posible antes de validar los pequeños.

El puntaje ICE no es una verdad fija, es una opinión estructurada del equipo en el momento en que se revisa el backlog. La Confidence tiende a subir una vez que ya corrió un experimento similar (aunque sea en otra etapa del embudo), y la Ease cambia una vez que ingeniería ya construyó parte de la infraestructura que necesita una idea vecina. Por eso vale la pena revisar el puntaje en cada ciclo, no solo al crear la idea: una apuesta que hoy puntúa bajo en Confidence puede escalar en el backlog en cuanto el primer test relacionado produzca un dato real en vez de una suposición.

La estadística se vuelve más difícil cuanto más profundo pruebas en el embudo

Este es el punto en el que la mayoría de las guías de growth dejan de hablar de estadística y vuelven a hablar de ideas, y es exactamente donde este blog insiste en no saltarse nada. Cada etapa de un embudo PLG tiene una muestra disponible más pequeña que la etapa anterior, porque el propio embudo va filtrando gente en cada paso. Un test en la home tiene todo el tráfico del sitio; un test en la pantalla de upgrade solo tiene a quien se acercó al límite del plan gratuito, una fracción pequeña de eso.

La matemática de fondo no cambia (es el mismo test de dos proporciones cubierto en la guía de significancia estadística), pero la consecuencia práctica cambia mucho: una muestra pequeña no es solo “un test más lento”, es un test que invita a revisar el dashboard todos los días y parar en cuanto “parece que funcionó”. Y como detalla esa guía, espiar y parar antes de tiempo puede inflar la tasa de falsos positivos del 5% a algo cercano al 25% o 30%, exactamente el riesgo que más aparece cuando un equipo está ansioso por un resultado en una etapa de bajo volumen.

Ejemplo resuelto: un test de onboarding en la etapa de activación

Un escenario común de growth: la tasa de activación actual (la proporción de nuevos trials que llegan al aha moment dentro de 7 días) está en 22%. La hipótesis es que un flujo de onboarding guiado aumenta esa tasa en al menos 18% relativo (de 22% a cerca de 25,96%), la menor ganancia que el equipo considera que vale el esfuerzo de reconstruir el flujo de onboarding (el MDE, efecto mínimo detectable).

Con 95% de confianza y 80% de poder (el estándar de mercado, bilateral), el mismo motor de cálculo de tamaño de muestra usado en todo este blog devuelve 1.824 usuarios por variación. Si el producto recibe 650 trials nuevos por semana, un test con dos variaciones (control y nuevo onboarding) necesita cerca de 40 días para acumular esa muestra, más del doble del tiempo que necesitaría un test comparable de landing page con todo el tráfico del sitio.

Ajusta tu propia tasa de activación, el efecto que quieres detectar y tu volumen semanal de nuevos trials o registros, para ver cuánto tiempo necesita realmente tu propio test de onboarding:

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.

Al final de esos 40 días, digamos que el control registró 401 activaciones en 1.824 trials (21,98%, esencialmente la tasa base) y la variación registró 474 activaciones en 1.824 trials (25,99%). El test de significancia devuelve un valor p de aproximadamente 0,0046 (bien por debajo de 0,05), un z-score de cerca de 2,83, una mejora relativa de +18,2%, y un intervalo de confianza del 95% para la diferencia de aproximadamente +1,2 a +6,8 puntos porcentuales. Como todo el intervalo está por encima de cero, incluso el escenario plausible más conservador sigue favoreciendo al nuevo onboarding: el resultado es significativo, con la variación B como ganadora.

Pega los mismos números (o los de tu propio test) para verificar el cálculo:

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.

El punto de este ejemplo no es el número 22% ni el 18%, que cambian de un producto a otro. Es mostrar, con la misma matemática que corre cada calculadora de este blog, que probar en lo profundo del embudo exige más paciencia (semanas, no días) y más disciplina contra el peeking, precisamente porque la muestra disponible es más pequeña. Los equipos que ignoran esto declaran ganadores de rutina en la etapa de trial a pago después de unos pocos días, con docenas de conversiones de cada lado, un escenario en el que el “resultado” tiene una posibilidad real de ser puro ruido.

Client-side o server-side: dónde correr el experimento dentro del producto

La misma decisión de arquitectura que existe para el testing de landing pages aparece dentro del producto, con un peso extra: los experimentos de activación y paywall suelen tocar lógica de negocio (quién ve qué límite, quién tiene acceso a qué funcionalidad), no solo el aspecto visual de una página.

Client-side, en el navegador o la app, se mantiene más simple de instalar y es común para probar cambios visuales de onboarding y mensajería dentro de la app. Server-side es el default recomendado cuando el experimento decide el acceso a una funcionalidad, un límite de plan, o cualquier dato que no debería poder inspeccionarse en el DevTools de un usuario, el mismo razonamiento que ya aplica a los flags de permisos. La comparación completa entre los dos enfoques, con los trade-offs en latencia, complejidad y riesgo de fuga de lógica, vive en la guía de test A/B client-side vs. server-side, y la línea entre “esto es un flag” y “esto es un experimento” se cubre en detalle en la guía de feature flags.

Freemium vs. trial gratuito: qué dicen realmente los datos de benchmark

Elegir entre un plan freemium y un trial gratuito por tiempo limitado (con o sin tarjeta de crédito) es una de las decisiones estructurales de growth más grandes que toma un producto PLG, y moldea cada experimento que sigue, ya que fija la tasa de conversión base contra la que se mide cada test de activación y paywall.

Los datos agregados de la industria en 2026 del SaaS Conversion Report de ChartMogul, basados en cerca de 200 productos de software B2B, ubican la tasa mediana general de conversión de gratis a pago en aproximadamente 8%, pero ese único número esconde una dispersión amplia según el modelo:

Modelo	Rango “bueno” comúnmente reportado	Rango “excelente” comúnmente reportado	Qué optimiza
Freemium (registro normal, sin tarjeta)	~3% a 5%	~8% a 12%	Alcance: la mayor parte superior de embudo posible, al costo de una tasa de conversión menor
Trial gratuito, sin tarjeta de crédito requerida	~4% a 6%	~10% a 15%	Un punto medio: todavía baja fricción para empezar, con un vencimiento natural que fuerza una decisión
Trial gratuito, tarjeta de crédito requerida desde el inicio	~25% a 35%	~50% a 60%	Calidad de conversión: muchos menos registros, pero cada uno es una señal de compra mucho más fuerte

El mismo reporte señala que los trials que exigen tarjeta de crédito desde el inicio convierten en alrededor de 30%, casi cinco veces más alto que los trials que no la exigen, según las cifras agregadas de los productos analizados. Esa brecha es un trade-off, no un veredicto a favor de exigir siempre una tarjeta: una barrera de tarjeta de crédito filtra una gran parte del volumen de la parte superior del embudo antes de que nadie llegue siquiera a tus experimentos de activación, así que un producto que depende del boca a boca amplio o de una audiencia direccionable grande puede perder más por la reducción de alcance de lo que gana por un porcentaje de conversión más alto. La elección correcta depende de qué lado del embudo es en realidad tu cuello de botella, baja calidad de activación o bajo volumen de la parte superior del embudo, una pregunta que se responde mejor mirando los datos de tu propio embudo antes de copiar un modelo que funcionó para otro producto.

Errores comunes de los equipos de growth

Un puñado de errores aparece con la frecuencia suficiente en los equipos de growth como para merecer atención explícita, porque cada uno invalida o retrasa el aprendizaje que un experimento se supone que debe producir:

Error	Por qué ocurre	Solución
Probar cambios demasiado grandes a la vez	La ambición de “arreglar todo” lleva a agrupar cambios de onboarding, mensajería y paywall en la misma variación	Aísla un cambio por experimento; si no puedes saber qué pieza funcionó, no puedes reusar el aprendizaje
No aislar la variable	Dos equipos cambian cosas distintas en el mismo flujo, al mismo tiempo, sin coordinar	Mantén un único calendario de experimentos compartido por área de producto, con un dueño y una ventana claros
Ignorar el efecto novedad en usuarios recurrentes	Un cambio de interfaz produce un pico de engagement solo porque es nuevo, no porque sea mejor	Mide el efecto de nuevo después de que la novedad se disipe, con una ventana de observación más larga para las métricas de retención
Perder de vista el embudo completo	Optimizar solo la parte superior (registros) sin verificar si la activación y la conversión se sostienen	Trata el embudo como un sistema: una ganancia de registros que perjudica la activación puede reducir el número total de clientes pagos
Confundir correlación de activación con causalidad	Un hallazgo de cohorte (como “7 amigos en 10 días”) muestra correlación, no prueba que forzar ese número cause retención	Valida la hipótesis con un test controlado antes de reorganizar todo el onboarding alrededor de un solo número

El último error merece énfasis, porque es común recontar la historia de Facebook como si “forzar a cada usuario a agregar 7 amigos” fuera la lección. La crítica más citada de esa lectura, incluso de analistas de growth que revisan el caso, hace exactamente este punto: el número fue una señal de correlación encontrada en un análisis de cohortes, y el equipo de Facebook lo trató como una hipótesis a validar mediante trabajo de producto (facilitando hacer conexiones relevantes), no como una meta a empujar a cualquier costo.

Cómo opera de verdad un equipo de growth

Un equipo de growth, en la descripción más citada de la literatura de growth (el libro Hacking Growth, de Sean Ellis y Morgan Brown), es un equipo multifuncional dedicado a un embudo o métrica específica, con la autonomía de correr experimentos sin pasar por el backlog normal de producto. La composición típica combina un dueño del proceso (el “growth lead”, en el término de Ellis), un growth engineer, un data analyst, un product designer y, según la etapa del embudo, alguien de marketing o customer success.

La cadencia es el segundo elemento estructural, junto con los roles. Los equipos de growth maduros mantienen un ritual semanal (o, como máximo, quincenal): revisar los resultados de la ronda anterior de experimentos, decidir qué continúa, qué se descarta y qué se aprendió incluso de los tests inconclusos, y luego elegir los próximos experimentos del backlog priorizado por ICE. Según el propio relato de Ellis, los equipos de growth maduros a escala corren experimentos en las decenas por semana en paralelo, cada uno pequeño y aislado, precisamente para evitar apostar todo a un solo cambio grande sin validar.

Lo que sostiene esa cadencia, en cualquier etapa del embudo, es una infraestructura de experimentación que no se traba con volumen bajo: un motor que calcula el tamaño de muestra y la duración antes de empezar, que prueba significancia sin dejar que quien mira el dashboard se engañe a sí mismo, y que señala cuándo un resultado todavía carece de evidencia suficiente para convertirse en una decisión, en vez de dejar que la propia impaciencia del equipo decida mediante el peeking.

Vale la pena señalar una diferencia de escala respecto a un equipo de marketing tradicional: un equipo de growth maduro, apoyado en el volumen de la parte superior del embudo de una empresa grande, puede correr docenas de experimentos por semana porque la mayoría prueba cambios pequeños y aislados en paralelo, en distintas partes del embudo. Un producto SaaS PLG en etapa temprana, con una fracción de ese tráfico, no debería intentar copiar el número de experimentos simultáneos, debería copiar el método: una hipótesis escrita, un tamaño de muestra calculado antes de empezar, y una decisión tomada solo cuando la estadística la respalda, aunque eso signifique correr un puñado de experimentos al mes en vez de decenas por semana. El rigor no escala con el tamaño del equipo, escala con la disciplina de nunca saltarse el paso del cálculo antes de declarar un ganador.

Haz esto automático en Donnu

La parte práctica más difícil de growth experimentation rara vez es la falta de ideas, es correr experimentos honestos en las etapas del embudo donde la muestra semanal es naturalmente pequeña (upgrade, expansión, una funcionalidad usada por una porción del producto). Es exactamente ahí donde la tentación de revisar el dashboard todos los días y declarar un ganador antes de tiempo es más fuerte, porque esperar duele más. Para ser directos sobre el alcance: Donnu A/B es una herramienta de test A/B client-side y bayesiana para páginas web y UI dentro de la app, no una plataforma completa de analítica de growth o de uso de producto, no reemplaza tu tracking de eventos ni tu dashboard de North Star Metric. Lo que hace es dimensionar un test correctamente antes de que empiece, mostrar honestamente cuánto tiempo más necesita un resultado, y declarar un ganador solo cuando la estadística realmente lo respalda, con el mismo motor usado en todo este blog y con aislamiento de datos por cuenta.

Empieza una prueba gratuita de 14 días y lleva el mismo rigor estadístico que ya aplicas (o deberías aplicar) a una landing page a las partes de tu producto que deciden la activación y la conversión a pago. Para profundizar primero en la base estadística, consulta la guía de significancia estadística y la calculadora de tamaño de muestra.

Referencias

• ProductLed. Product-Led Growth (PLG): What it means, examples, and why it’s taking off. Referencia sobre el modelo autoservicio en el que el propio producto conduce adquisición, activación y conversión. productled.com/blog/product-led-growth-definition.
• Reforge. Define Customer Activation Moments (el framework Setup, Aha, Habit). reforge.com/guides/define-customer-activation-moments.
• Mode Analytics. Facebook’s “Aha” Moment Was Simpler Than You Think. mode.com/blog/facebook-aha-moment-simpler-than-you-think.
• GrowthHackers. How Slack Became One of the Fastest-Growing B2B SaaS Businesses Ever. growthhackers.com/growth-studies/slack.
• Amplitude. North Star Playbook. amplitude.com/north-star-hub.
• ChartMogul. The SaaS Conversion Report. chartmogul.com/reports/saas-conversion-report.
• Miller, E. How Not To Run an A/B Test (el problema del peeking), 2010. evanmiller.org.
• Ellis, S. & Brown, M. Hacking Growth: How Today’s Fastest-Growing Companies Drive Breakout Success. Currency, 2017.

---

Lee también: la guía completa de significancia estadística en tests A/B y cómo hacer un test A/B paso a paso. Para el lado de páginas de marketing de la misma disciplina, consulta la guía completa de CRO.

Léelo en inglés: Growth Experimentation for SaaS: The Complete PLG Playbook