Persistencia de variante: por qué un visitante debe ver siempre la misma versión

La persistencia es la parte menos lucida de un motor de experimentación y la que más a menudo resulta estar rota. Además es invisible: una plataforma con asignación inconsistente produce resultados que parecen completamente normales y no significan nada.

Qué tiene que cumplirse#

Una vez que un visitante queda asignado a una variante, esa asignación debe sobrevivir a: recargar la página, navegar a otra página, cerrar la pestaña y volver mañana, y moverse entre páginas del mismo sitio.

Si no lo hace, se rompen dos cosas a la vez.

Se rompe la experiencia. Un cliente ve una presentación de precio, vuelve al día siguiente y la página es distinta. Para cualquier cosa con una ventana de consideración mayor que una sesión —que es la mayoría de compras por encima del precio de impulso— esto hace daño de verdad. La gente se da cuenta, y se lee como poco fiable.

Se rompe la medición. Tu conversión se atribuye a la variante en la que el visitante estuviera en el momento de convertir, no a la que hizo el trabajo de convencer. Si alguien vio la B cuatro veces y la A una, y convirtió en la visita con A, la variante A se lleva el mérito del trabajo que hizo la B. A lo largo de miles de sesiones esto no se promedia hacia algo con sentido: simplemente añade ruido escorado hacia la variante que la gente ve en su última visita.

Cómo debe funcionar la asignación#

La forma correcta es determinista: coger un identificador estable de visitante, hashearlo junto con el identificador del experimento y derivar la variante del hash. El mismo visitante y el mismo experimento producen siempre la misma variante, sin necesidad de consultar nada.

Esto tiene una propiedad que importa más de lo que suena: no hay estado guardado que se pueda perder. No necesitas una consulta a base de datos en cada página vista, y un visitante cuyo registro haya desaparecido se resuelve igual a la variante que ya tenía.

Hashear el identificador del experimento junto con el del visitante es lo que mantiene independientes dos experimentos simultáneos. Si hashearas solo el visitante, la misma gente caería siempre en el "primer" cubo de todos los experimentos, y tus experimentos quedarían correlacionados de una forma que sesga todo en silencio.

Esto es ingeniería normal, estricta y testeable, y por eso la asignación de Bixlow vive en el motor determinista y no cerca de la capa de IA. La interfaz puede ser un modelo de lenguaje; el árbitro no.

Dónde falla la persistencia de verdad#

Borrado de cookies y navegación privada. Algo de pérdida es inevitable. Suele ser pequeña y más o menos igual entre variantes, así que añade ruido en vez de sesgo.

Entre dispositivos. Quien navega en el móvil y compra en el portátil es un visitante distinto para tu motor. Salvo que puedas unir identidades tras el login, puede ver las dos variantes. Es una limitación real, no un bug, y conviene conocer tu tasa entre dispositivos antes de sobreinterpretar efectos pequeños.

Cambiar el reparto de tráfico a mitad de experimento. Pasar de 50/50 a 80/20 mientras corre reasignará a algunos visitantes en casi cualquier implementación ingenua. El hash determinista con fronteras de cubo estables evita lo peor, pero la respuesta honesta es: no cambies el reparto de un experimento en marcha.

Añadir una variante sobre la marcha. Esto baraja a todo el mundo. No lo hagas nunca: para y empieza un experimento nuevo.

Qué comprobar en cualquier herramienta#

Tres preguntas que merece la pena hacer antes de fiarte de los números de una plataforma:

¿La asignación sobrevive a reiniciar el navegador por completo? Abre la web, anota la variante, cierra el navegador, vuelve.

¿El mismo visitante es consistente entre páginas? Recorre el funnel entero y confirma que la variante no cambia entre la ficha y el carrito.

¿Cambiar el reparto de tráfico reasigna a los visitantes existentes? Si la herramienta te deja cambiarlo en un test vivo, pregunta qué pasa con quien ya está dentro.

Claves#

• Un visitante debe conservar su variante entre recargas, páginas, sesiones y días, o se rompen la experiencia y la medición.
• El hash determinista de visitante más experimento elimina el estado guardado y mantiene independientes los experimentos paralelos.
• El salto entre dispositivos es una limitación real, no un bug. Conoce tu tasa antes de sobreleer efectos pequeños.
• Nunca cambies el reparto de tráfico ni añadas una variante en un experimento en marcha.