Datos Propios y Test A/B en un Mundo Sin Cookies de Terceros
Datos propios y test a/b: qué cuestan los límites de almacenamiento y el consentimiento, cómo la pérdida de identidad alarga el test y qué arreglar antes.
📚 Este artículo es parte de la guía GA4 y Test A/B: la Guía Completa de Integración.
El test A/B nunca dependió de cookies de terceros, así que el giro de privacidad no rompió el método; rompió la contabilidad a su alrededor. La división ocurre en tu propio dominio, con tus propios visitantes, medida contra tus propias conversiones, lo que es de datos propios por construcción. Lo que se degradó es la durabilidad de la identidad que transporta la asignación de una visita a la siguiente, y la completitud de la analítica que describe a los visitantes asignados. Este artículo es hijo de la guía completa de GA4 y test A/B y responde una pregunta práctica: qué tiene que cambiar un programa de testing cuando una parte relevante de sus visitantes no puede ser medida, o no puede ser reconocida en su segunda visita.
La versión corta: tu muestra necesaria no se mueve, tu denominador semanal sí, y casi todos los problemas prácticos aguas abajo vienen de equipos que no rehicieron esa segunda cuenta.
Qué cambió, con precisión
Tres cosas distintas suelen empaquetarse bajo “el apocalipsis de las cookies”, y tienen consecuencias muy distintas para un experimento.
| Cambio | A qué afecta | Efecto en un test A/B |
|---|---|---|
| Cookies de terceros bloqueadas por defecto en Safari y Firefox | Rastreo entre sitios y medición publicitaria | Casi ninguno: la división y la conversión son del mismo sitio |
| Almacenamiento propio del cliente con vida útil limitada | Cuánto sobrevive una asignación | Real: los visitantes que vuelven se reasignan, diluyendo el efecto medido |
| Consentimiento exigido antes de que disparen las etiquetas de medición | Quién aparece en la analítica | Real: la población medida se vuelve un subconjunto autoseleccionado |
La primera fila es la que se lleva los titulares y la que menos importa aquí. Google anunció en abril de 2025 que Chrome no lanzaría un aviso independiente para cookies de terceros y que mantendría la elección ya existente del usuario, mientras Safari y Firefox las bloquean por defecto desde hace años. En cualquier caso, nada de eso toca un experimento del mismo sitio.
La segunda fila es donde vive el daño. La Prevención Inteligente de Rastreo de Apple limita la vida útil de las cookies escritas por JavaScript en el cliente, documentado por el equipo de WebKit desde ITP 2.1 en 2019, con un límite adicional sobre el almacenamiento escribible por script después de navegaciones entre sitios con decoración de enlace. Un test cuya asignación se guarda así pierde visitantes recurrentes según un calendario fijado por el navegador, no por ti.
La tercera fila es una decisión de diseño que controlas, y la que más a menudo se aplica de forma inconsistente.
La pérdida de identidad diluye el efecto, no lo sesga
Vale ser preciso con esta distinción, porque los dos modos de fallo piden respuestas distintas.
Cuando un visitante que vuelve se re-aleatoriza, aproximadamente la mitad de las veces cae en el mismo lado y no pasa nada, y aproximadamente la mitad de las veces cruza. Los cruces no favorecen sistemáticamente a ninguna variación, así que no crean un ganador falso; mezclan las dos poblaciones y empujan la diferencia observada hacia cero. Una mejora real del 10% se mide como algo menor, y un test dimensionado para el 10% queda con menos potencia de la que necesita para lo que ahora puede detectar.
El sesgo, en cambio, viene de cualquier cosa que trate distinto a las dos ramas: un flujo de consentimiento que bloquea un lado y no el otro, una etiqueta que dispara antes del renderizado en una rama, un bloqueador de scripts que golpea la petición extra de la variación y no la del control. Eso produce respuestas equivocadas en vez de respuestas débiles.
La aritmética: misma muestra, calendario más largo
Aquí es donde los equipos se equivocan. La muestra necesaria por variación es una propiedad de la estadística, no de tu rastreo, así que no se mueve cuando cae la visibilidad. Lo que se mueve es la velocidad con la que la acumulas.
Toma una base del 4% y el objetivo de detectar una mejora relativa del 10% (de 4,0% a 4,4%), al 95% de confianza y 80% de potencia. La matemática devuelve 39.475 visitantes por variación. Ahora varía solo el tráfico medible semanal:
| Visitantes medibles por semana | Qué representa | Días para llenar las dos variaciones |
|---|---|---|
| 25.000 | Todos medibles | unos 23 días |
| 17.500 | 30% de los visitantes no medibles | unos 32 días |
| 12.500 | La mitad no medible | unos 45 días |
Pasa tu propia base y tu tráfico por la calculadora antes de comprometerte con una fecha:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
La versión peligrosa de este error no es el calendario más largo, es mantener el original. Un equipo que planeó 23 días, perdió el 30% del tráfico medible y paró igual el día 23 termina con cerca de 28.750 por variación en vez de 39.475. Con esa muestra, la potencia para detectar el mismo efecto relativo del 10% cae a cerca del 67%, lo que significa que, si la mejora es real, el test la pierde una vez de cada tres. El resultado no es un hallazgo negativo, es la ausencia de hallazgo, reportada como si fuera uno.
Dónde debería vivir la asignación
Cuatro lugares, en orden creciente de durabilidad y costo.
- Cookie o almacenamiento local escritos por JavaScript. Lo más simple y común, y lo más afectado por los límites de vida útil del almacenamiento del cliente. Sirve para experimentos cortos sobre tráfico de alta frecuencia, y es débil para cualquier cosa que dependa de reconocer a un visitante semanas después.
- Cookie propia puesta por tu propio servidor, con el atributo HttpOnly. No la escribe un script, así que no está sujeta a los límites del almacenamiento escribible por script, y no es legible ni eliminable por bloqueadores a nivel de página. Este es el cambio individual de mayor valor que la mayoría de los equipos puede hacer.
- Asignación atada a una cuenta con sesión iniciada. La identidad más estable que existe, y la única que sobrevive a un cambio de dispositivo. Solo cubre la parte del embudo con sesión, así que los tests que empiezan antes del login siguen necesitando alguna de las anteriores.
- Asignación calculada en el edge o en el servidor para cada petición. Elimina casi por completo la cuestión del almacenamiento, a costa de esfuerzo de ingeniería y de una estrategia de caché, porque una página cacheada no puede variar por visitante sin una clave de caché que incluya la variación. La comparación client-side vs server-side cubre ese intercambio en detalle.
Una advertencia sobre la segunda opción, porque suele venderse de más: una cookie propia con HttpOnly hace durable la asignación, no la hace consentida. Si puedes ponerla antes del consentimiento depende de cómo tu jurisdicción y tu propia política clasifiquen una cookie que existe para correr un experimento y no para entregar el servicio. Decide eso con tu responsable legal, documenta la decisión y aplícala de forma idéntica a las dos ramas.
Consentimiento, aplicado con simetría o no aplicado
La única regla que mantiene honesto a un experimento con consentimiento es la simetría. Haga lo que haga el banner, tiene que hacérselo a las dos ramas exactamente en el mismo punto del flujo. Si el control se renderiza de inmediato mientras la variación espera una devolución de llamada de consentimiento, ya no estás comparando dos diseños de página, estás comparando una página contra una página más un retraso, y el retraso suele valer más puntos de conversión que el cambio de diseño que querías testear.
De ahí salen dos consecuencias que conviene escribir en el plan del test en lugar de descubrirlas después:
- Declara la población. Si la medición empieza después de la aceptación, el hallazgo se aplica a los visitantes que consienten. Esa es una población legítima y una frase honesta en el reporte. Presentarlo como “nuestros visitantes” es donde se vuelve engañoso.
- No compares a través de un cambio de consentimiento. Un test que corrió antes de un rediseño de banner y otro que corrió después están midiendo poblaciones distintas. Trata el cambio de banner como la frontera de una era de medición, igual que tratarías una migración de rastreo.
Qué te da realmente el dato propio
El encuadre hasta aquí ha sido defensivo, lo que subestima la oportunidad. Una identidad propia que controlas, sobre todo una con sesión iniciada, habilita lecturas que el rastreo de terceros nunca sostuvo bien.
- Ventanas de resultado más largas. Una identidad durable te deja atribuir una conversión que ocurre tres semanas después de la exposición, lo que importa en cualquier producto de compra considerada. Un almacenamiento efímero te obliga a medir el resultado rápido y superficial en vez del que te importa.
- Segmentación que sobrevive. Nuevo contra recurrente, nivel de plan, etapa de ciclo de vida: todo eso es tuyo, no depende de un tercero, y te permite comprobar si un resultado agregado se sostiene dentro de los segmentos que importan, que es la defensa práctica contra la paradoja de Simpson.
- Métricas guardia más abajo en el embudo. Con identidad que persiste, puedes ver si una subida en registros aparece como subida en activación o si se la come una peor retención. Sin ella, optimizas el primer paso y esperas.
Un ejemplo trabajado: leer un test con visibilidad reducida
Una página de precios convierte al 4,00% entre los visitantes medibles. El equipo corre el test hasta 20.000 visitantes por variación y cierra con 800 conversiones en el control y 880 en la variación (4,40%). Pasando esos cuatro números por la misma matemática de dos proporciones usada en todo este blog: z = 1,99, valor p de cerca de 0,046, un lift relativo observado de +10,0%, y un intervalo de confianza del 95% de la diferencia de +0,007 a +0,793 puntos porcentuales.
Significativo, y por poco. El límite inferior del intervalo está siete milésimas de punto porcentual por encima de cero, que es otra forma de decir que un poco más de ruido habría dado vuelta el veredicto. Esa es exactamente la posición en la que un programa con identidad degradada se encuentra una y otra vez: la dilución encoge la brecha observada, la brecha aterriza cerca del umbral, y la decisión descansa sobre los últimos cientos de visitantes. Pega tus propios números abajo para ver dónde está tu test:
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
La respuesta correcta no es anunciar la victoria más fuerte. Es señalar que la estimación es compatible con cualquier cosa entre una ganancia despreciable y una sólida, y decidir si el cambio es lo bastante barato como para subirlo con un positivo débil o lo bastante importante como para merecer una corrida de confirmación con mejor persistencia de identidad.
Qué no hacer
- Fingerprinting para reemplazar una cookie. Un riesgo de cumplimiento y una identidad inestable al mismo tiempo, ya que las huellas derivan con cambios de navegador y dispositivo, lo que puede mover a la misma persona entre variaciones a mitad del experimento.
- Unir identidades entre sitios que no son tuyos. Lo llame como lo llame el proveedor, esto es justo lo que el giro de privacidad existe para frenar, y no hace falta para un experimento del mismo sitio.
- Culpar a la privacidad por un resultado plano. La dilución debilita efectos; no borra los reales. Antes de concluir que la medición tiene la culpa, revisa primero las explicaciones aburridas: ¿el cambio era realmente visible?, ¿la muestra se alcanzó de verdad?, ¿la división quedó realmente pareja?
- Reconstruir un grafo de identidad entre dispositivos para testear un botón. La identidad que necesitas debe corresponder al tamaño de la pregunta. La mayoría de los tests no necesita reconocer al mismo humano en tres dispositivos.
Hazlo automático con Donnu
El modo de fallo descrito en este artículo rara vez es una funcionalidad que falta; es un paso aritmético que nadie rehízo. La visibilidad del tráfico cayó, el requisito de muestra se mantuvo igual, la fecha de parada no se movió, y un test que nunca tuvo potencia para responder la pregunta se reportó como respuesta.
Donnu se encarga de la mitad web y client-side de esto: un snippet propio servido desde tu propio dominio, dimensionamiento de muestra calculado a partir de tu base real en lugar de un valor por defecto, y estadística honesta que muestra el intervalo de confianza junto al veredicto en vez de un único número verde. No te construye un grafo de identidad entre dispositivos y no finge hacerlo; lo que hace es negarse a llamar ganador a un resultado diluido y sin potencia. Empieza una prueba gratis y mira el intervalo, no solo la flecha.
Lee también: GA4 y Test A/B: la guía completa de integración · Test A/B Client-Side vs Server-Side · CRO para sitios de bajo tráfico · Errores comunes en tests A/B · Read in English
Referencias
- The Privacy Sandbox. A new path for Privacy Sandbox on the web. Anuncio de abril de 2025 de que Chrome mantendría la elección ya existente del usuario sobre cookies de terceros en lugar de lanzar un aviso independiente. privacysandbox.com/news/privacy-sandbox-next-steps.
- WebKit. Intelligent Tracking Prevention 2.1. Límite a la vida útil de las cookies escritas por script en el cliente. webkit.org/blog/8613/intelligent-tracking-prevention-2-1.
- WebKit. Intelligent Tracking Prevention 2.3. Límites adicionales al almacenamiento escribible por script tras navegación entre sitios con decoración de enlace. webkit.org/blog/9521/intelligent-tracking-prevention-2-3.
- Mozilla. Enhanced Tracking Protection. Cookies de rastreo de terceros bloqueadas por defecto en Firefox. support.mozilla.org/kb/enhanced-tracking-protection-firefox-desktop.
- Ayuda de Google Analytics. Consent mode. Cómo cambia el comportamiento de las etiquetas antes y después del consentimiento. support.google.com/analytics/answer/9976101.
- MDN Web Docs. Set-Cookie: el atributo HttpOnly. Por qué una cookie puesta por el servidor no es alcanzable desde los scripts de la página. developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie.
- Kohavi, R., Tang, D. y Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Capítulos sobre dilución y sobre triggering. Material de apoyo en experimentguide.com.
Preguntas frecuentes
- ¿El fin de las cookies de terceros rompió el test A/B?
- No, y vale aclarar la confusión. El test A/B siempre fue una actividad de datos propios: divides a tus propios visitantes en tu propio dominio y mides tus propias conversiones, así que nunca hizo falta una cookie de terceros para la división en sí. Lo que cambió con el giro de privacidad es la fiabilidad de la identidad que transporta la asignación, y la completitud de la analítica que reporta sobre ella. El experimento sigue funcionando; la contabilidad a su alrededor se vuelve más ruidosa.
- ¿Qué se rompe realmente cuando se restringe el almacenamiento del navegador?
- La persistencia de la asignación, no la aleatorización. Cuando un navegador caduca o borra la clave que guarda "este visitante está en la variación B", el visitante que vuelve es tratado como nuevo y se aleatoriza otra vez, lo que puede poner a la misma persona en los dos lados del test entre visitas. Eso diluye la diferencia medida hacia cero y, en el peor caso, rompe la proporción de división. La estadística sigue siendo válida; lo que se degrada es el supuesto de que un visitante equivale a una exposición consistente.
- ¿Un banner de consentimiento invalida mi test A/B?
- Lo vuelve parcial, que es distinto de inválido. Si la medición solo empieza después del consentimiento, estás corriendo el experimento sobre el subconjunto de visitantes que aceptan, y ese subconjunto no es una muestra aleatoria de tu tráfico. El resultado sigue siendo válido para esa población, y deberías decirlo al reportarlo. Lo que sí es inválido es aplicar el consentimiento de forma asimétrica, por ejemplo dejando que la rama de la variación corra antes del banner mientras la rama de control espera, porque entonces el propio banner pasa a formar parte de lo que estás midiendo.
- ¿Debería mover mis tests A/B al servidor por los cambios de privacidad?
- Solo si la restricción que te está frenando es la persistencia de identidad, y solo con los ojos abiertos sobre el costo. Una asignación hecha en el servidor y escrita en una cookie propia con el atributo HttpOnly sobrevive mejor a las restricciones de almacenamiento del cliente que una clave escrita por JavaScript, y no puede ser eliminada por un bloqueador de scripts. A cambio, renuncias a la iteración rápida de un snippet, necesitas ingeniería para cada cambio, y ahora el problema de la caché es tuyo, porque una página cacheada no puede variar por visitante sin trabajo extra en el edge.
- ¿Cuánta muestra extra me cuesta la pérdida de identidad?
- No es muestra extra, es tiempo extra, y ahí está la trampa. La muestra necesaria por variación no cambia: con una base del 4% y el objetivo de detectar una mejora relativa del 10% al 95% de confianza y 80% de potencia, son 39.475 por variación, puedas medir a todo el mundo o no. Lo que cambia es el denominador semanal que la llena. Con 25.000 visitantes medibles por semana el test tarda unos 23 días; si el 30% de ellos deja de ser medible, el mismo test tarda unos 32 días; con la mitad, unos 45 días. Los equipos que no rehacen esta aritmética terminan parando en la fecha original con una fracción de la muestra que planearon: cerca de tres cuartos si el 30% del tráfico dejó de ser medible, y cerca de la mitad si fue la mitad.
- ¿El fingerprinting es un sustituto legítimo de las cookies en un test?
- No, por dos motivos independientes. Legalmente, identificar un dispositivo sin consentimiento se trata como tratamiento de dato personal bajo el RGPD y bajo la ley brasileña, y hacerlo específicamente para eludir una restricción de almacenamiento es difícil de defender como interés legítimo. Técnicamente, es inestable justo en la dimensión que aquí importa, porque una huella deriva con actualizaciones del navegador, cambios de pantalla y condiciones de red, así que la misma persona puede migrar entre variaciones a mitad del experimento. Una identidad frágil que además es un riesgo de cumplimiento es un mal negocio para un experimento.