A/B Testing: Qué probar y cómo

El A/B testing es el metodo cientifico aplicado al marketing. En lugar de adivinar que funciona mejor, lo pruebas con datos reales y dejas que tu audiencia te diga la respuesta.

Por que el A/B testing es esencial

Sin A/B Testing	Con A/B Testing
Opiniones de equipo	Datos de usuarios reales
Cambios basados en intuicion	Mejoras validadas
Riesgo de empeorar metricas	Cambios controlados
Aprendizaje lento	Iteracion rapida
Discusiones interminables	Decisiones objetivas

Anatomia de un A/B test

Los elementos fundamentales:

COMPONENTES DE UN TEST A/B

CONTROL (Version A):
└── Tu version actual
└── La linea base de comparacion
└── Lo que ya sabes que funciona

VARIANTE (Version B):
└── La nueva version a probar
└── Un solo cambio vs. control
└── Tu hipotesis en accion

METRICAS:
└── Metrica primaria (lo que quieres mejorar)
└── Metricas secundarias (efectos colaterales)
└── Metricas de guardia (asegurar no romper nada)

AUDIENCIA:
└── Division aleatoria 50/50
└── Mismo periodo de tiempo
└── Mismas condiciones externas

Que testear primero: La jerarquia de impacto

Orden de prioridad para tests:

ALTO IMPACTO (testear primero)
├── 1. Propuesta de valor / Headlines
├── 2. Call-to-action (texto y ubicacion)
├── 3. Oferta / Precio
└── 4. Formularios (campos, longitud)

IMPACTO MEDIO
├── 5. Imagenes / Videos
├── 6. Layout de pagina
├── 7. Copy de soporte
└── 8. Colores de botones

BAJO IMPACTO (testear despues)
├── 9. Tipografia
├── 10. Iconos
└── 11. Microinteracciones

El principio de maxima friccion:

TESTEA DONDE ESTA LA MAYOR PERDIDA

Funnel de conversion:
Landing page: 1000 visitas
    ↓ (30% continuan)
Pagina de producto: 300
    ↓ (20% agregan al carrito)
Carrito: 60
    ↓ (50% inician checkout)
Checkout: 30
    ↓ (60% completan)
Compra: 18

MAYOR OPORTUNIDAD:
- Landing → Producto: 70% se van
- Producto → Carrito: 80% se van

Testea primero donde pierdes mas gente.

Significancia estadistica: La base cientifica

Que significa "estadisticamente significativo":

SIGNIFICANCIA ESTADISTICA EXPLICADA

Nivel de confianza: 95% (estandar industria)

Significa: Hay un 95% de probabilidad de que
la diferencia observada sea real y no casualidad.

O dicho de otra forma: Solo 5% de probabilidad
de que sea un "falso positivo".

CUIDADO: Un test "significativo" NO significa:
✗ Que el cambio es grande
✗ Que vale la pena implementar
✗ Que el resultado se mantendra siempre

SI significa:
✓ La diferencia probablemente es real
✓ Puedes confiar en el resultado
✓ No fue solo suerte

Calculando el tamano de muestra necesario:

FORMULA SIMPLIFICADA

Tamano de muestra por variante:
n = 16 × p × (1-p) / MDE²

Donde:
p = tu tasa de conversion actual
MDE = minimo efecto detectable (mejora que quieres detectar)

EJEMPLO PRACTICO:

Tasa de conversion actual: 5% (0.05)
Quiero detectar mejora de 20% relativo (MDE = 0.01 absoluto)

n = 16 × 0.05 × 0.95 / 0.01²
n = 16 × 0.0475 / 0.0001
n = 7,600 visitantes por variante
n = 15,200 visitantes totales

Con 1,000 visitas/dia = 15 dias de test

Tabla de referencia rapida:

Conversion actual	Mejora a detectar	Muestra por variante
1%	20% relativo	76,000
2%	20% relativo	37,000
5%	20% relativo	14,400
10%	20% relativo	6,800
5%	10% relativo	58,000
5%	50% relativo	2,300

Framework para crear hipotesis de test

Estructura de una buena hipotesis:

TEMPLATE DE HIPOTESIS

Si [hacemos este cambio]
entonces [esperamos este resultado]
porque [razonamiento basado en datos/insights]

EJEMPLO BUENO:
Si cambiamos el CTA de "Enviar" a "Obtener mi descuento"
entonces aumentara el CTR del formulario en 15%
porque los datos de heatmap muestran que usuarios
dudan en el boton actual y "descuento" es su motivador #1.

EJEMPLO MALO:
Si cambiamos el color del boton a verde
entonces convertiremos mas
porque el verde es mejor que el azul.
(No hay insight, es opinion)

Fuentes de hipotesis validas:

DE DONDE SACAR IDEAS PARA TESTS

DATOS CUANTITATIVOS:
├── Google Analytics (donde se van los usuarios)
├── Heatmaps (donde hacen click, scroll)
├── Grabaciones de sesiones (donde se frustran)
└── Embudos de conversion (donde abandonan)

DATOS CUALITATIVOS:
├── Encuestas on-site (por que no compraron)
├── Entrevistas de usuarios
├── Reviews y testimonios
├── Tickets de soporte (quejas comunes)
└── Chat de ventas (objeciones frecuentes)

BENCHMARKS:
├── Competidores (que hacen diferente)
├── Mejores practicas de industria
└── Casos de estudio documentados

El calendario de testing

Estructura de un programa de tests:

CALENDARIO DE TESTING MENSUAL

SEMANA 1: Planeacion
├── Lunes: Revisar resultados del mes anterior
├── Martes: Analizar datos para nuevas hipotesis
├── Miercoles: Priorizar hipotesis (PIE framework)
├── Jueves: Documentar tests a ejecutar
└── Viernes: Preparar variantes

SEMANA 2-3: Ejecucion
├── Lanzar Test A (landing page principal)
├── Lanzar Test B (email subject lines)
├── Monitoreo diario de anomalias
└── Documentar observaciones

SEMANA 4: Analisis
├── Lunes-Martes: Calcular resultados
├── Miercoles: Validar significancia
├── Jueves: Documentar aprendizajes
└── Viernes: Implementar ganadores

Framework PIE para priorizar tests:

PIE = Potential + Importance + Ease

POTENTIAL (1-10):
¿Cuanto puede mejorar esta pagina/elemento?
- Baja conversion actual = alto potencial
- Alta visibilidad = alto potencial

IMPORTANCE (1-10):
¿Cuan valioso es el trafico de esta pagina?
- Paginas de alta conversion = alta importancia
- Trafico de calidad = alta importancia

EASE (1-10):
¿Que tan facil es ejecutar este test?
- Cambio simple = alta facilidad
- No requiere desarrollo = alta facilidad

SCORE = (P + I + E) / 3

Ejecuta primero los tests con mayor score.

Ejemplo de priorizacion:

Test	P	I	E	Score	Prioridad
Nuevo headline landing	8	9	9	8.7	1
Rediseno checkout	9	10	4	7.7	3
Color boton CTA	3	7	10	6.7	4
Simplificar formulario	7	8	7	7.3	2

Errores comunes en A/B testing

Errores que invalidan resultados:

ERRORES CRITICOS A EVITAR

1. DETENER EL TEST DEMASIADO PRONTO
   ✗ "Ya tenemos 90% de confianza, paremos"
   ✓ Espera al tamano de muestra predefinido

2. TESTEAR MULTIPLES CAMBIOS A LA VEZ
   ✗ Cambiar headline + imagen + CTA
   ✓ Un cambio por test (o usar test multivariado)

3. IGNORAR LA ESTACIONALIDAD
   ✗ Comparar lunes vs domingo
   ✓ Correr ambas variantes al mismo tiempo

4. MIRAR EL TEST CONSTANTEMENTE
   ✗ Revisar resultados cada hora
   ✓ Definir fecha de revision y respetarla

5. NO SEGMENTAR RESULTADOS
   ✗ Solo mirar el resultado general
   ✓ Revisar por dispositivo, fuente, ubicacion

6. DECLARAR EMPATE SIN DATOS SUFICIENTES
   ✗ "No hay diferencia, descartemos la variante"
   ✓ Puede que necesites mas muestra

Herramientas para A/B testing

Por nivel de complejidad:

HERRAMIENTAS RECOMENDADAS

PRINCIPIANTE (gratis o bajo costo):
├── Google Optimize (descontinuado, usar alternativas)
├── Microsoft Clarity + experimentos manuales
├── VWO Starter
└── Optimizely (plan gratuito)

INTERMEDIO:
├── VWO
├── AB Tasty
├── Convert.com
└── Kameleoon

AVANZADO:
├── Optimizely Full Stack
├── Adobe Target
├── Amplitude Experiment
└── LaunchDarkly (feature flags)

PARA EMAIL:
├── Mailchimp (A/B nativo)
├── Klaviyo
├── ActiveCampaign
└── HubSpot

Documentando tus tests

Template de documentacion:

FICHA DE TEST A/B

TEST ID: [2024-01-001]
NOMBRE: [Headline landing page principal]
FECHA INICIO: [2024-01-15]
FECHA FIN ESTIMADA: [2024-01-29]

HIPOTESIS:
Si [cambiamos el headline de X a Y]
entonces [aumentara la conversion en 15%]
porque [razon basada en datos]

CONTROL (A):
[Descripcion + screenshot]

VARIANTE (B):
[Descripcion + screenshot]

METRICAS:
- Primaria: Tasa de conversion a signup
- Secundaria: Tiempo en pagina, bounce rate
- Guardia: Carga de pagina

TAMANO DE MUESTRA REQUERIDO: [15,000]
NIVEL DE CONFIANZA: [95%]

RESULTADO:
[A completar al finalizar]

APRENDIZAJE:
[Que aprendimos, aplica a futuros tests?]

SIGUIENTE ACCION:
[Implementar ganador / Nuevo test iterativo]

Ejercicio practico

Crea tu primer plan de A/B testing:

EJERCICIO: PLAN DE TESTS PARA 30 DIAS

PASO 1: Identifica tu embudo
Mapea las 5 etapas principales de tu embudo de conversion.
Identifica la tasa de conversion de cada etapa.

PASO 2: Encuentra la mayor oportunidad
¿Donde pierdes mas usuarios?
¿Que datos tienes sobre por que se van?

PASO 3: Genera 5 hipotesis
Usa el framework: Si [cambio], entonces [resultado], porque [razon]

PASO 4: Prioriza con PIE
Calcula el score PIE para cada hipotesis.
Ordena de mayor a menor.

PASO 5: Planifica el primer test
- ¿Que vas a probar?
- ¿Cual es tu metrica de exito?
- ¿Cuanta muestra necesitas?
- ¿Cuanto tiempo tomara?

PASO 6: Define tu calendario
Bloquea tiempo para lanzar, monitorear y analizar.

ENTREGA:
Documento con tus 5 hipotesis priorizadas
y el plan detallado de tu primer test.

Checklist de lanzamiento de test

ANTES DE LANZAR

□ Hipotesis documentada con razonamiento
□ Control y variante claramente definidos
□ Tamano de muestra calculado
□ Duracion estimada del test
□ Metricas primarias y secundarias definidas
□ QA completado (ambas versiones funcionan)
□ Tracking verificado (eventos, goals)
□ Division de trafico configurada (50/50)
□ Stakeholders informados

DURANTE EL TEST

□ No mirar resultados constantemente
□ Monitorear errores tecnicos solamente
□ No hacer cambios al sitio que afecten el test
□ Documentar cualquier anomalia externa

DESPUES DEL TEST

□ Verificar significancia estadistica
□ Revisar resultados por segmento
□ Documentar aprendizajes
□ Planificar siguiente iteracion
□ Implementar ganador (si aplica)

Puntos clave de esta leccion

• A/B testing elimina las opiniones y las reemplaza con datos
• Testea primero donde tienes mayor friccion/perdida de usuarios
• Significancia estadistica del 95% es el estandar de la industria
• Una buena hipotesis incluye cambio, resultado esperado y razonamiento
• Usa el framework PIE para priorizar que testear primero
• Documenta todo: tanto exitos como fracasos son aprendizajes

Proxima leccion

Aprenderemos a optimizar campanas en tiempo real, ajustando presupuestos, audiencias y creativos mientras tus campanas estan activas.

---

Quiz de comprension

1. ¿Por que es importante no detener un test antes del tamano de muestra calculado?
2. ¿Que significa el framework PIE y como ayuda a priorizar tests?
3. ¿Cual es la estructura correcta de una hipotesis de A/B testing?
4. ¿Por que debemos testear un solo elemento a la vez en un A/B test simple?