Dominios de tracking first-party: verificación, lo que ITP sigue limitando y lo que un dominio propio no arregla

Lo que cambia un dominio first-party

Las peticiones a t.shop.example son same-site con shop.example. De ahí se derivan tres cosas:

1. Las listas de bloqueo no coinciden. La mayoría de los bloqueadores de contenido comparan nombres de host; un subdominio de tu propio sitio no está en ellas. No se trata de eludir una decisión del usuario — la decisión de consentimiento sigue condicionando cada finalidad —, sino de eliminar el bloqueo colateral de peticiones first-party consentidas.
2. Las restricciones a las cookies de terceros no se aplican. Los navegadores que particionan o bloquean las cookies de terceros dejan en paz el almacenamiento same-site.
3. Tu política de seguridad sigue siendo estricta. Un host adicional en script-src y connect-src, sin dominios comodín de proveedores para la vía del collector.

La configuración

• Añade el dominio en los ajustes del sitio. Track emite un token de verificación; demuestra el control con un registro TXT de DNS, un archivo en el dominio o una etiqueta meta. El dominio solo se activa cuando la verificación tiene éxito, de modo que nadie puede apuntar a tu sitio un dominio que no controla.
• Crea t.shop.example como CNAME hacia el host del collector que se muestra en los ajustes. La página del dominio registra cuándo se superó por última vez la comprobación del CNAME.
• El TLS del host de tracking lo termina el edge de la plataforma en cuanto el CNAME resuelve.
• Actualiza tu Content Security Policy: script-src y connect-src necesitan el host de tracking. No hace falta unsafe-inline, porque el loader es un script externo.
• El loader del SDK se sirve entonces a través del host de tracking junto con la configuración firmada del sitio.

Lo que almacena el SDK y lo que ITP sigue limitando

Track escribe tres cosas en el navegador, cada una solo después del consentimiento correspondiente:

Los IDs de clic de la URL de aterrizaje se guardan en localStorage bajo _ts_cid, solo con consentimiento de marketing y solo durante el TTL de IDs de clic del sitio (90 días por defecto); se adjuntan a cada evento posterior de la visita y se borran cuando se retira el consentimiento de marketing.

Ambos identificadores los escribe JavaScript. La Intelligent Tracking Prevention de Safari limita las cookies y el almacenamiento escritos por script a 7 días (24 horas cuando la URL de aterrizaje llevaba un parámetro de tracking conocido), y un dominio first-party no elimina ese límite. El collector no establece cookies mediante respuestas HTTP, así que un visitante de Safari que vuelve pasada más de una semana es un nuevo ID anónimo. Firefox y Brave aplican heurísticas comparables; Chrome conserva el almacenamiento first-party durante toda su vigencia.

El resumen honesto: el dominio propio protege la entrega de las peticiones; no amplía la vida útil de los identificadores en Safari.

Lo que un dominio first-party no arregla

• No restaura las finalidades denegadas. Sin consentimiento de marketing no se captura ningún ID de clic y ningún destino publicitario recibe eventos, sea cual sea el dominio.
• No convierte los píxeles de los proveedores en first-party. fbevents.js sigue cargándose desde Meta y establece _fbp; solo la vía del collector es tuya.
• No oculta nada al visitante. El host de tracking, el origen del SDK y los endpoints del collector son visibles en las herramientas de desarrollo, y la página de privacidad los enumera.

Lista de comprobación

• Pendiente: Dominio verificado (TXT, archivo o etiqueta meta) y comprobación del CNAME superada
• Pendiente: CSP actualizada para script-src y connect-src
• Pendiente: El snippet hace referencia al host de tracking, no al predeterminado de la plataforma
• Pendiente: La página de calidad de datos muestra eventos del navegador que llegan desde el nuevo host