Pruebas A/B en un sitio: definir una hipótesis y una regla de decisión

8 lectura mínima

Una prueba A/B en un sitio web compara variantes en un dispositivo preparado, con una hipótesis, una distribución de visitantes y una regla de análisis definidas antes de la prueba. No consiste en cambiar una página, esperar un aumento y luego asignarla al nuevo texto. Comience con un problema documentado, elija un cambio interpretable y verifique la medida del resultado. Prepare también los criterios técnicos de parada y los límites estadísticos con una persona competente. Si el tráfico o la recaudación no permiten llegar a una conclusión fiable, prefiera una prueba cualitativa o una corrección obvia en lugar de un veredicto experimental falso.

Recuerde: una variante aún no es un experimento

El resultado puede variar según el canal, la hora o el perfil del visitante. El NIST explica que los factores secundarios pueden afectar la medición y deben identificarse, controlarse o considerarse en el diseño experimental.^[29] Su comparación debería abordar este problema, no solo producir dos versiones visualmente diferentes.

Formule la hipótesis para la prueba A/B de su sitio web

Describa el problema encontrado: una condición de oferta no encontrada, una acción ambigua o un formulario difícil de entender. Confíe en las observaciones disponibles, sin inventar un punto de partida. "El botón no convierte" es demasiado vago si no sabes qué paso está fallando.

Escriba una hipótesis que vincule el cambio y el resultado: hacer que la condición del servicio sea más visible podría ayudar a los visitantes afectados a enviar una solicitud válida. La palabra "podría" refleja la incertidumbre que la prueba busca examinar. No convierta esta suposición en una promesa de aumento.

Elija una variación cuyo significado sea interpretable. Si cambias título, precio, forma y elementos visuales al mismo tiempo, una diferencia en el resultado no permitirá identificar el elemento responsable. Un conjunto coherente de cambios se puede probar como una oferta completa, pero luego se debe anunciar este alcance y abstenerse de atribuir el resultado a un detalle aislado.

Definir resultado principal y barreras de seguridad

El resultado principal debe corresponder a una acción validada: solicitud aceptada, comando u otro evento definido con precisión. Una progresión como el clic principal puede ayudar con el diagnóstico, pero no demuestra automáticamente la finalización exitosa del viaje. Consulta el evento en el sistema final.

Agregar barreras técnicas y comerciales. Una variación no debe aumentar los errores de forma, degradar el acceso a la información ni generar solicitudes fuera de oferta para mejorar una métrica superficial. W3C recomienda instrucciones, validaciones y notificaciones para comprender y corregir errores de formulario.^[33]

El 4SYSTEM guía de la página de inicio ayuda a comprobar la coherencia entre la promesa y la acción. Esta coherencia debe seguir siendo cierta en todas las variaciones. Una versión que elimina una condición esencial no es una optimización aceptable, incluso si más visitantes hacen clic.

Prepare la tarea y los factores de confusión

La comparación debe distribuir las unidades según una regla diseñada para la pregunta y mantener una exposición consistente. Examine la persistencia de la variante para una persona o una sesión, según su dispositivo. La alternancia involuntaria entre versiones puede dificultar la interpretación del resultado.

NIST resume su principio experimental controlando factores controlables y aleatorizando otros; también describe el bloqueo de ciertos factores parásitos.^[29] Esta guía no es un manual de instrucciones listo para usar para ningún sitio. Proporciona una base para diseñar una comparación que no confunda variante y composición de poblaciones.

Documente las fuentes de contaminación: cambios de campaña, visitantes internos, reanudación de sesión, caché o integración externa. Una versión que se muestra principalmente en dispositivos móviles y la otra principalmente en computadoras no crea una comparación clara simplemente mostrando dos tarifas. Haga revisar el dispositivo antes de exponer a visitantes reales.

Escribir protocolo antes del lanzamiento

Defina la unidad, el resultado principal, las exclusiones, el modo de asignación y la regla de análisis. Estime las necesidades de datos en función del nivel observado, el efecto que se busca detectar y el método elegido. Aquí no se ofrece un número universal de visitas o días.

Planifique para un resultado “no concluyente”. La falta de prueba de diferencia no demuestra la equivalencia de las versiones. Una muestra insuficiente, una recogida interrumpida o un efecto demasiado incierto deben seguir describiéndose como tales. Este resultado es un resultado honesto del dispositivo, no un fracaso para ocultarlo.

Distinguir entre parada de emergencia y fin de análisis. Un error funcional o una exposición inapropiada pueden justificar el apagado inmediato según sus criterios. Por otra parte, detenerse tan pronto como un gráfico parece favorable puede hacer que la interpretación sea engañosa si el método no ha previsto este examen. Escribe la regla antes de ver los resultados.

Hoja de protocolo para compartir

Un protocolo completo permite distinguir la experiencia real de una demostración gráfica. Mantenga las versiones y configuraciones de la página correspondientes a la prueba: sin estos elementos, el resultado no se puede vincular a un cambio específico.

Receta técnica y marco de recopilación

Pruebe versiones en dispositivos, teclados y rutas de error relevantes. Verificar la distribución, el mantenimiento de la variante y la activación del resultado. Una página que aparece correctamente aún puede enviar un evento diferente según la versión.

Rastreadores de reseñas utilizados para asignar o medir visitantes. La CNIL recuerda el principio del consentimiento previo para determinados depósitos y lecturas de trazadores, con excepciones limitadas.^[31] Una herramienta presentada como “prueba A/B” no exime de analizar su funcionamiento y sus propósitos.

Prepárese para eliminar cambios. Pausar la prueba debería dejar un sitio funcional y no dejar scripts innecesarios. Acceso a documentos, versión de devolución y control post-apagado. El protocolo experimental y la seguridad del sitio deben abordarse juntos.

Ejemplo ficticio: hacer visible una condición B2B

Una empresa imaginaria recibe solicitudes fuera del área de intervención. Se supone que la condición geográfica es difícil de detectar en una página de oferta. Prepara una variación que presenta esta condición cerca de la acción principal, sin cambiar la oferta ni añadir una falsa promesa.

En el escenario ilustrativo, el equipo elige solicitudes válidas según su definición como resultado principal y monitorea las solicitudes fuera de alcance y los errores de formulario. Tiene verificado el método de asignación y análisis antes del lanzamiento. El número de clics sigue siendo una señal secundaria.

Si la variación atrae menos clics pero solicitudes más personalizadas, la decisión debe seguir los criterios planificados, no un objetivo de clic agregado después del hecho. Si los datos son insuficientes, la prueba no es concluyente. No se inventan números, niveles de confianza ni ganancias para los clientes; El ejemplo solo muestra la lógica del protocolo.

Lee el resultado y decide sin historias oportunistas

Mantener volúmenes, exclusiones, incidentes y límites de métodos. Busque diferencias de exposición y pausas en la colección antes de elegir una versión. Un resultado favorable no autoriza a ignorar una salvaguardia degradada.

Preparar tres posibles decisiones: adoptar según los criterios, mantener el sistema anterior o concluir que la prueba no permite tomar una decisión. Si implementa una versión, verifique la operación después de detener la prueba. Las configuraciones, cachés y scripts experimentales pueden diferir de la versión final.

En un sitio con poco tráfico, una observación cualitativa, una receta de accesibilidad o una aclaración de contenido pueden ser más útiles que una prueba larga sin la potencia adecuada. No convierta un error obvio en un experimento para retrasar su corrección. La prueba sirve para una incertidumbre real y una decisión factible.

Preguntas frecuentes

¿Cuánto tiempo debe durar una prueba?

La duración depende de las necesidades de datos, el tráfico, la variabilidad y el método de análisis. Defina estos antes del lanzamiento, con una regla final explícita. Ningún marco temporal universal demuestra la fiabilidad. Un período transcurrido no elimina una asignación defectuosa o una recopilación inconsistente entre variantes.

¿Podemos probar solo un botón?

Sí, si tiene una hipótesis sobre su comprensión o función y un resultado medido correctamente. Sin embargo, compruebe que las versiones sean coherentes con la oferta y accesibles. Un cambio de color sin un problema identificado puede producir una comparación difícil de interpretar y distrae la atención de un obstáculo más concreto en el recorrido.

¿Qué hacer si los resultados siguen siendo similares?

Aplique el método y la regla proporcionados, luego mantenga la incertidumbre cuando los datos no permitan tomar una decisión. No elija otra métrica después del hecho para crear un ganador. Se pueden examinar los límites del dispositivo y preparar una prueba diferente, pero ésta debe partir de una nueva hipótesis claramente anunciada.

Siguiente paso: validar el protocolo

Elaborar una hipótesis, una ficha completa y variantes funcionales antes de cualquier exposición. el Servicios 4SYSTEM puede ayudar a enmarcar el rumbo y la medición. Califique el análisis estadístico de acuerdo con su pregunta; ningún botón de “ejecutar prueba” garantiza una conclusión viable.

Fuentes

• 5.3.3.2. Randomized block designs (consultado 2026-10-08)
• Cookies et traceurs : que dit la loi ? | CNIL (consultado 2026-10-08)
• Forms Tutorial | Web Accessibility Initiative (WAI) | W3C (consultado 2026-10-08)