Pérdida de Seguimiento en Test A/B: el dato que desaparece

La pérdida de seguimiento no sesga un test A/B por ser grande, lo sesga por ser diferencial. Si las dos variantes pierden la misma fracción de eventos, el experimento se queda con menos dato, pierde poder y sigue siendo honesto; si la variante nueva pierde más que la antigua, el número leído está equivocado y ningún tamaño de muestra lo arregla. Esta guía muestra las tres capas que borran dato hoy, con las fechas y los límites oficiales, un ejemplo trabajado en el que un 8 por ciento de conversiones no registradas borra una ganancia real del 10 por ciento, y lo que cambia cuando la pérdida toca el denominador en vez del numerador. Forma parte de nuestra guía completa de test A/B y es el hermano de recogida del sesgo de instrumentación: allí el instrumento mide mal, aquí el instrumento no mide.

Tres capas borran dato, por motivos diferentes

Vale la pena separar las capas porque tienen remedios distintos y plazos distintos.

Capa 1, consentimiento. Donde la base legal exige consentimiento previo para la medición, el visitante que rechaza no debe ser medido. Eso no es un fallo técnico a sortear, es el funcionamiento correcto del sistema. Lo que le interesa al experimento es el tamaño del agujero y su simetría.

Capa 2, bloqueadores. Extensiones y listas de bloqueo impiden la carga del script o el envío del evento. La pérdida aquí es selectiva por dominio, por nombre de archivo y por patrón de petición, lo que la vuelve estructuralmente asimétrica: un script nuevo, alojado en una ruta nueva, es más fácil de bloquear que uno que lleva un año en producción.

Capa 3, políticas del navegador. Esta es la que más sorprende a quien monta experimentos, porque afecta a la cookie propia. WebKit anunció el 21 de febrero de 2019, con Intelligent Tracking Prevention 2.1 en iOS 12.2 y Safari 12.1, que todas las cookies persistentes escritas por el cliente, es decir, creadas a través de document.cookie, pasan a tener validez limitada a siete días. El 24 de marzo de 2020, con iOS y iPadOS 13.4 y Safari 13.1 en macOS, WebKit fue más allá y pasó a bloquear por defecto las cookies para recursos de otros sitios, además de borrar todo el almacenamiento grabable por script (IndexedDB, LocalStorage, claves de medios, SessionStorage y registros de Service Worker) después de siete días de uso de Safari sin interacción del usuario en el sitio. Mozilla, el 14 de junio de 2022, pasó a distribuir Total Cookie Protection por defecto para más usuarios de Firefox en todo el mundo, en Windows, Mac, Linux y Android, creando un tarro de cookies separado para cada sitio visitado.

capa	mecanismo	qué se pierde	escala de tiempo
Consentimiento	base legal, banner	todo lo de ese visitante	inmediato
Bloqueador de contenido	script o petición bloqueada	eventos, a veces la atribución entera	inmediato
Validez de cookie escrita por script	7 días en Safari desde ITP 2.1	la identidad entre visitas	a partir del 8º día
Limpieza de almacenamiento grabable por script	7 días sin interacción, desde marzo de 2020	identidad guardada fuera de la cookie	a partir del 8º día
Aislamiento por sitio	tarro de cookies por sitio en Firefox	costura entre dominios	inmediato

La tercera y la cuarta fila merecen atención especial de quien ejecuta test A/B, porque no borran un evento, borran la identidad. Un visitante que vuelve al décimo día no es reconocido como el mismo, se aleatoriza de nuevo y puede caer en la otra variante. El efecto práctico no es solo pérdida de dato: es dilución del efecto medido, porque parte de las personas asignadas al tratamiento pasa a ver el control. El tratamiento correcto de la unidad aleatorizada está en unidad de aleatorización.

Sobre el cerco a las cookies de terceros, una corrección de rumbo importante: el 22 de abril de 2025, Anthony Chavez, vicepresidente de Privacy Sandbox, publicó que Google decidió mantener el enfoque actual de ofrecer elección al usuario sobre cookies de terceros en Chrome y que no lanzará un nuevo aviso dedicado para eso. Para experimentación, eso cambia poco, porque un test A/B bien montado nunca dependió de cookies de terceros. Lo que aprieta al experimento es el límite de validez sobre la cookie propia escrita por JavaScript, y ese límite sigue en pie.

Pérdida de seguimiento simétrica y diferencial

Existe una trampa de razonamiento común aquí. Alguien observa que se pierde el 30 por ciento de los eventos, concluye que el dato es basura y deja de testear. Si esa pérdida es simétrica, la conclusión está equivocada: con un 30 por ciento menos de dato necesitas más tiempo, no otra decisión. Y existe la trampa opuesta, más cara: alguien observa que la pérdida es de apenas el 5 por ciento, la considera despreciable y no comprueba la simetría. Un cinco por ciento concentrado en un solo brazo basta para dar la vuelta a un resultado, como muestra el ejemplo siguiente.

Ejemplo trabajado: un 8 por ciento que borra una ganancia del 10 por ciento

Todos los números salieron de la calculadora de significancia incrustada más adelante, con test bilateral. Puedes pegar los recuentos y reproducir cada fila.

El escenario: la variante B mueve el botón de compra a un componente nuevo, y la conversión de esa variante se registra con un evento nuevo, servido desde una ruta nueva de tu dominio. Esa ruta está en una lista de bloqueo popular. El evento del control, que existe desde hace dos años, no lo está.

La verdad. A recibió 30.000 visitantes y 1.500 pedidos, tasa del 5,000 por ciento. B recibió 30.000 visitantes y 1.650 pedidos, tasa del 5,500 por ciento. La calculadora devuelve un lift relativo del 10,00 por ciento, z igual a 2,7457 y valor p de 0,006039, con intervalo de 0,143 a 0,857 punto porcentual. B gana.

Lo que muestra el panel. Un ocho por ciento de las conversiones de B nunca se registraron. B aparece con 1.518 pedidos sobre los mismos 30.000 visitantes, tasa del 5,060 por ciento. La calculadora devuelve un lift relativo del 1,20 por ciento, z igual a 0,3362 y valor p de 0,736707, con intervalo de menos 0,290 a 0,410 punto porcentual. Inconcluyente.

lectura	pedidos A	pedidos B registrados	tasa B	lift relativo	z	valor p	veredicto
Nada perdido	1.500	1.650	5,500%	+10,00%	2,7457	0,006039	B gana
4% de las conversiones de B perdidas	1.500	1.584	5,280%	+5,60%	1,5530	0,120415	inconcluyente
8% de las conversiones de B perdidas	1.500	1.518	5,060%	+1,20%	0,3362	0,736707	inconcluyente

Fíjate en que en ninguna fila el panel grita. No aparece error, no aparece alarma, y la variante B nunca llega a “perder”: simplemente deja de ganar. Ese es el formato más peligroso de fallo de dato, porque el desenlace es indistinguible de una hipótesis que no funcionó. La maldición del ganador trata el error en la dirección opuesta, el de sobrestimar al ganador; aquí el error es borrar al ganador.

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.

Cuando la pérdida toca el denominador

El caso anterior es pérdida en el numerador: la conversión ocurrió y no fue registrada. Existe un caso peor de diagnosticar y más fácil de detectar: pérdida en el denominador, cuando la propia exposición del visitante a la variante no llega al servidor.

La pérdida en el denominador es más fácil de detectar porque deja una marca aritmética: la proporción observada de visitantes entre los brazos deja de coincidir con la asignación configurada. Es exactamente lo que mide el test de reparto desigual de tráfico, y los números siguientes salieron del verificador de SRM, en un test de bondad de ajuste chi cuadrado contra la asignación esperada del 50 por ciento para cada lado.

exposiciones en A	exposiciones en B	fracción observada de B	chi cuadrado	valor p	¿pasa el guardrail de 0,01?
30.000	29.700 (1% perdido)	49,749%	1,51	0,2195	sí
30.000	29.400 (2% perdido)	49,495%	6,06	0,0138	sí, al límite
30.000	28.800 (4% perdido)	48,980%	24,49	0,00000075	no
30.000	27.600 (8% perdido)	47,917%	100,00	por debajo de 0,000001	no

La lectura útil de esa tabla es la segunda fila. Una pérdida del 2 por ciento en el registro de exposición produce un valor p de 0,0138, que pasa el umbral convencional de 0,01 usado como guardrail de reparto desigual, y aun así ya basta para mover la tasa observada. Es decir: la alarma de reparto desigual es un suelo, no un techo. Detecta el fallo grosero y deja pasar el fallo lo bastante pequeño para ser silencioso y lo bastante grande para importar.

Por qué la variante nueva casi siempre pierde más

La asimetría no es mala suerte, es consecuencia estructural de cómo se implementa un test. Conviene tener la lista a mano porque funciona como guion de revisión antes de lanzar el experimento.

1. Script nuevo en ruta nueva. Los dominios y rutas recién creados no tienen historial y son más fáciles de casar con reglas genéricas de bloqueo.
2. Evento nuevo con nombre nuevo. El evento del control sobrevivió a dos años de ajustes de seguimiento; el de la variante nació ayer.
3. Una etapa más en el embudo. Si la variante inserta una pantalla, cada pantalla adicional es una oportunidad más de que el visitante salga antes del disparo.
4. Momento del disparo. Un evento disparado en la descarga de la página, o después de una navegación, pierde más que uno disparado en el clic.
5. Peso y tiempo de carga. Una variante más pesada llega a registrar menos porque parte de los visitantes abandona antes de que el script termine de cargar.
6. Cambio en el consentimiento. Cualquier variante que toque el banner altera la propia tasa de consentimiento, y ahí la pérdida es diferencial por construcción.
7. Dominio de terceros en la conversión. Si la variante lleva a un proveedor de pago diferente, la conversión cruza una frontera de dominio más.

Los puntos 1, 2 y 7 caen enteros dentro del territorio de datos propios, y el punto 5 es una de las razones por las que una variante con peor rendimiento de carga puede parecer peor de conversión sin que el cambio visual tenga nada que ver.

Lo que efectivamente reduce el problema

En orden de impacto, para quien necesita elegir dónde invertir primero:

1. Registrar la exposición en el servidor. Estabiliza el denominador y es el único movimiento que ataca el reparto desigual en el origen. El camino está en test A/B en el servidor y la comparación entre las dos arquitecturas en cliente contra servidor.
2. Usar identificador propio con validez definida en el servidor. Una cookie definida por el servidor no cae en la regla de siete días que afecta a las cookies escritas por document.cookie.
3. Mantener la recogida de la variante idéntica a la del control. Mismo script, misma ruta, mismo momento de disparo. Solo cambia lo que aparece en pantalla.
4. Medir la tasa de pérdida como métrica de guardrail. Registra la razón entre eventos esperados y eventos recibidos, por variante, junto al resultado. El papel de esos frenos está en métricas de guardrail.
5. Elegir la unidad de aleatorización compatible con la durabilidad real de la identidad. Si la identidad no sobrevive siete días en ese navegador, un test de cuatro semanas midiendo comportamiento por usuario no está midiendo lo que promete.
6. Declarar la política de consentimiento en el plan de análisis. Quién entra en el cálculo y quién no es una decisión de diseño, no de análisis, y está en el plan de análisis preregistrado.

Checklist antes de leer el resultado

1. ¿La tasa de eventos recibidos sobre eventos esperados está medida por variante?
2. ¿El reparto de tráfico observado coincide con el configurado, y miraste el valor p y no solo la diferencia porcentual?
3. ¿La variante usa el mismo script, la misma ruta y el mismo momento de disparo que el control?
4. ¿La variante toca el banner de consentimiento de alguna forma?
5. ¿La duración del test es compatible con la durabilidad de la identidad en el navegador dominante de tu público?
6. ¿La tasa de rechazo de consentimiento es parecida en los dos brazos?
7. ¿Existe alguna métrica leída en el servidor, como pedido pagado, para comparar con la métrica leída en el navegador?

El punto 7 es el más subestimado. Comparar el recuento de pedidos de tu base de datos con el recuento de conversiones de tu rastreador, por variante, es la auditoría más barata que existe y resuelve la mayoría de los casos en una consulta.

Errores comunes

• Concluir que el dato es inútil porque la pérdida es alta. La pérdida simétrica cuesta poder, no conclusión.
• Considerar despreciable un 5 por ciento de pérdida sin comprobar la simetría. Un cinco por ciento concentrado en un brazo cambia al ganador.
• Testear cambios en el banner de consentimiento y leer el resultado por el evento del navegador. La pérdida ahí es diferencial por construcción.
• Confiar en que el guardrail de reparto desigual lo detecta todo. Pasó con holgura la pérdida del 2 por ciento de la tabla anterior.
• Tratar la política de Safari como un asunto de cookies de terceros. La regla de siete días afecta a la cookie propia escrita por script.
• Creer que la decisión de Chrome de mantener las cookies de terceros resolvió la cuestión. Nunca fue sobre eso, para experimentación.
• Comparar solo totales y nunca la razón entre esperado y recibido por variante. El total esconde exactamente la asimetría que importa.

Hazlo automático en Donnu

El agujero raro es técnico. El agujero común es organizativo: la pérdida de dato la conoce quien cuida el seguimiento, el resultado del test lo lee quien cuida el producto, y las dos informaciones nunca aparecen en la misma pantalla.

En Donnu, el reparto observado de visitantes por variante queda al lado del resultado desde el primer día, con el valor p del ajuste, porque la desviación de asignación es el síntoma común de pérdida en el denominador, de error de aleatorización y de tráfico de bots. La aleatorización y el registro de exposición pueden hacerse en el servidor, sin depender de cookies escritas por script, y la misma calculadora de significancia acepta los recuentos de tu base de datos para que compares la lectura del navegador con la lectura del servidor antes de decidir nada.

Referencias

• WebKit. Intelligent Tracking Prevention 2.1. 21 de febrero de 2019. Fuente del límite de siete días: con ITP 2.1, en iOS 12.2 y Safari 12.1, todas las cookies persistentes escritas por el cliente, esto es, cookies persistentes creadas a través de document.cookie, pasan a tener validez limitada a siete días, restricción que no afecta a cookies de sesión ni a cookies de autenticación marcadas como Secure y HttpOnly. webkit.org.
• WebKit. Full Third-Party Cookie Blocking and More. 24 de marzo de 2020. Fuente del bloqueo por defecto de cookies para recursos de otros sitios en iOS y iPadOS 13.4 y en Safari 13.1 de macOS, y de la extensión de la limpieza de siete días a todo el almacenamiento grabable por script, incluidos IndexedDB, LocalStorage, claves de medios, SessionStorage y registros de Service Worker, después de siete días de uso de Safari sin interacción del usuario en el sitio. webkit.org.
• Chavez, A. Next steps for Privacy Sandbox and tracking protections in Chrome. Blog de Privacy Sandbox, 22 de abril de 2025. Fuente de la decisión de mantener el enfoque actual de elección del usuario sobre cookies de terceros en Chrome y de no lanzar un nuevo aviso dedicado para cookies de terceros. privacysandbox.google.com.
• Mozilla. Firefox rolls out Total Cookie Protection by default to more users worldwide. 14 de junio de 2022. Fuente del mecanismo de aislamiento: Total Cookie Protection funciona creando un tarro de cookies separado para cada sitio visitado, y pasó a distribuirse por defecto para más usuarios de Firefox en todo el mundo, en Windows, Mac, Linux y Android. blog.mozilla.org.
• Crook, T., Frasca, B., Kohavi, R. y Longbotham, R. Seven Pitfalls to Avoid when Running Controlled Experiments on the Web. KDD 2009. Fuente de la orientación de auditoría de la recogida: validar la captura del comportamiento del usuario, la atribución a las variantes y el cálculo de las métricas, comparando el dato recibido por el sistema de experimentación con el sistema de registro existente, registro por registro cuando sea posible, y de la observación de los autores de que esas auditorías encontraron problemas serios incluso en sistemas de registro consolidados. exp-platform.com.

Lee también: Sesgo de instrumentación · Reparto desigual de tráfico (SRM) · Unidad de aleatorización · Test A/B en el cliente o en el servidor · Datos propios · Verificador de SRM · Leia em português