Las pruebas A/B deben ser la última arma del diseño basado en datos. Cambie el color del botón, ajuste el título y deje que los números le muestren el camino.
Pero si su prueba A/B es realmente ¿Solo un glorioso juego de conjeturas? Si agregar más cambios a través de las pruebas A/B/C/D solo empeorará el problema.
El problema no es la prueba en sí, sino el hecho de que la mayoría de los diseñadores y empresas lo ven como la fuente absoluta de la verdad, cuando de hecho, todo el sistema está lleno de defectos.
Significación estadística Compromiso falso
La prueba A/B supone un entorno controlado, pero la red solo está controlada. La prueba se realiza en el contexto de las tendencias estacionales, los cambios en la estrategia de la competencia, los cambios en el algoritmo de anuncios y las actualizaciones impredecibles de Google.
Sin embargo, el diseñador insiste en las pruebas A/B porque Sentir ciencia. El intervalo de confianza y el valor p dan la ilusión de determinismo.
Pero la significación estadística no significa lo que la mayoría de la gente piensa. Un nivel de confianza del 95% no significa que su diferencia ganadora sea 95% correcta. Esto solo significa que bajo ciertas condiciones, si realiza 100 pruebas, obtendrá el mismo resultado 95 veces.
Eso supone que sus condiciones de prueba son sólidas, y en la mayoría de los casos no lo son.
El problema del pequeño tamaño de la muestra
La mayoría de las pruebas A/B son inadecuadas porque carecen de tráfico suficiente para producir resultados significativos. Si no usa cada variante para miles de pruebas de conversión, los datos no son confiables. Las muestras pequeñas significan que si vuelve a probar con otros audiencias, su versión «ganadora» se pierde fácilmente.
Es por eso que los gigantes tecnológicos como Google y Amazon pueden extraer información de las pruebas A/B, mientras que las empresas más pequeñas a menudo terminan persiguiendo fantasmas estadísticos.
Para empeorar las cosas, muchos equipos detuvieron sus pruebas cuando vieron resultados prometedores. Este error se llama Peeping, haciendo que la prueba sea completamente inválida. Las pruebas A/B apropiadas requieren paciencia, pero pocas compañías están dispuestas a esperar cuando sus líderes solicitan respuestas inmediatas.
Prueba de A/B/C/D: más variantes, más preguntas
Si las pruebas A/B son defectuosas, entonces es importante probar más variantes a la vez para resolver el problema, ¿verdad? No exactamente. La prueba A/B/C/D en realidad magnifica el problema. Cuantos más cambios pruebe, mayores serán las posibilidades de obtener un falso positivo.
Esto se llama un problema de comparación múltiple. Los estadísticos modifican esto con técnicas como las correcciones de Bonferroni, pero hagamos que esto suceda, y casi nadie lo hará correctamente.
Lo más importante, las pruebas A/B/C/D rara vez tienen un efecto sobre las interacciones. Un botón verde puede superar un botón rojo en una prueba univariada, pero combinarlo con un diseño o título diferente y el resultado puede voltearse por completo. Las pruebas A/B están aisladas de los cambios, pero los usuarios no experimentarán el sitio web de forma aislada.
Costos ocultos de sobrevaluación
Excepto por los resultados defectuosos, probar todo viene con un precio oculto: fatiga de decisión. Cuando los equipos son adictos al refinamiento interminable de micro, pierden el tiempo persiguiendo mejoras progresivas en lugar de tomar decisiones de diseño estratégico audaz.
Si bien las empresas más pequeñas están ocupadas para afinar los colores de los botones, los líderes de la industria como Amazon y Google han ganado invirtiendo en mejores productos, no solo diseños mejor probados.
Estas compañías han realizado miles de pruebas, pero también tienen acceso a una profunda comprensión del comportamiento del usuario que las empresas más pequeñas simplemente no tienen. Para la mayoría de los equipos, las pruebas A/B son una mala alternativa a las estrategias de diseño confiables.
Cuando las pruebas A/B realmente tienen sentido
Las pruebas A/B son útiles cuando el tráfico es lo suficientemente alto como para respaldar resultados estadísticamente significativos. Sin una muestra lo suficientemente grande, la mayoría de las pruebas producen ruido en lugar de información. Las pruebas también son valiosas al evaluar las principales decisiones de diseño, como estructuras de precios, diseños de páginas o estrategias de mensajería.
Sin embargo, la prueba solo funciona si se ejecuta lo suficiente. Puede ser satisfactorio anunciar al ganador demasiado temprano, al igual que jugar baloncesto después del primer trimestre, pero los resultados son engañosos.
La prueba A/B también es más efectiva cuando se dirige por supuestos fuertes en lugar de conjeturas aleatorias. Si solo cambia las cosas arbitrariamente y quiere el ascensor, eso no es una prueba, eso es un juego.
Qué hacer en lugar de confiar ciegamente en las pruebas A/B
El equipo debe centrarse en Verdadera visión del usuario. Hablar directamente con los usuarios, analizar mapas de calor y ver grabaciones de sesión a menudo revela información más valiosa que cualquier prueba A/B única.
Experimento longitudinalSeguimiento de cambios en meses en lugar de días, permite una comprensión más clara de las tendencias a largo plazo. Los modelos de comportamiento generados por IA pueden simular las interacciones del usuario a escala, proporcionando ideas más profundas que las pruebas A/B de baja muestra.
En última instancia, los mejores diseñadores no confían en las pruebas A/B para validar cada decisión. Combinan la intuición, la experiencia y la psicología para crear una gran experiencia de usuario.
Las pruebas A/B no te ahorrarán
Después de que la prueba A/B se completa correctamente, es una herramienta poderosa para refinar ideas. Pero esto no los producirá. No hay una pequeña cantidad de pruebas divididas que puedan ahorrar en la experiencia de los productos malos o la reparación de productos rotos.
Demasiados equipos pierden el tiempo ajustando los detalles cuando todo el enfoque debe repensarse.
En lugar de dejar que los datos lo guíen, escuchen al usuario, tomen riesgos y prueben solo cuando sea realmente importante.
