La propuesta de Informes de atribución sufrió varios cambios para abordar los comentarios de la comunidad, desde cambios en el mecanismo de la API hasta nuevas funciones.
Registro de cambios
- 7 de febrero de 2022: Se agregó la sección sobre el redireccionamiento del activador de encabezado.
- 27 de enero de 2022: Primera publicación del artículo.
¿Para quién es esta publicación?
Esta publicación es para ti en los siguientes casos:
- Si ya comprendes la API, por ejemplo, si observaste o participaste en los debates del repositorio de WICG y quieres comprender el lote de cambios que se realizaron en la propuesta en enero de 2022.
- Si usas la API de Attribution Reporting en una demostración o en un experimento en producción.
Si estás empezando a usar esta API o aún no la has probado, ve directamente a la introducción a la API.
Próxima migración
Una vez que se implementen estos cambios en Chrome, si usas informes a nivel del evento de la API de Attribution Reporting en una demostración o en un experimento en producción (prueba de origen), deberás editar tu código para que la API siga funcionando. También puedes considerar usar las funciones nuevas.
En este artículo, también se enumeran los cambios para los informes agregables. Sin embargo, si se implementan, estos cambios no requerirán ninguna acción ni migración, ya que, en el momento de la redacción de este documento, aún no hay una implementación del navegador para los informes agregables.
Cambios de nombre
Informes de resumen y agregables
Lo que podrías haber visto descrito como informes agregados ahora se denominará informes de resumen.
Los informes de resumen son el resultado final de la agregación de varios informes agregables, que antes se denominaban contribuciones o contribuciones de histogramas.
Cambios en el mecanismo de la API
Registro de fuentes basado en encabezados (informes a nivel del evento)
¿Qué cambiará y por qué?
Cuando el usuario ve un anuncio o hace clic en él, el navegador (de forma local en el dispositivo del usuario) registra este evento junto con parámetros específicos de los informes de atribución (como attributionsourceeventid, attributiondestination, attributionexpiry y otros). AdTech establece los valores de estos parámetros.
Cambiará la forma en que se configuran estos parámetros.
En la propuesta anterior, los parámetros debían incluirse del lado del cliente: ya sea en las etiquetas de ancla como atributos HTML o como argumentos de una llamada basada en JS. Los parámetros debían conocerse en el momento del clic o la vista.
En la nueva propuesta, el valor de estos parámetros se define en el servidor de AdTech.
Esto tiene varias ventajas, en particular en términos de seguridad: el mecanismo de encabezado le otorga al origen de los informes (por lo general, una AdTech) el control directo sobre si una fuente de atribución está registrada en su alcance. Esto mitiga parcialmente las preocupaciones sobre el fraude, ya que, con este cambio, un navegador genuino nunca registrará una fuente sin la habilitación del origen de los informes.
¿Cómo funciona el registro de fuentes?
- Para un anuncio determinado, la tecnología publicitaria ahora debería definir un atributo del cliente específico
attributionsrc. El valor de este atributo es una URL a la que el navegador enviará una solicitud. Esta solicitud incluirá un nuevo encabezado HTTPAttribution-Reporting-Source-Infocuyo valor,navigationoevent,, especifica si la fuente fue un clic o una vista, respectivamente. - Cuando recibe esta solicitud, el servidor de seguimiento de clics o vistas debe responder con un encabezado HTTP,
Attribution-Reporting-Register-Source, que contiene los parámetros de atribución deseados. El origen que muestra este encabezado ahora es el origen de los informes (antes definido como
attributionreportto).Encabezado de respuesta HTTP
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Obtén más información en la explicación técnica
Registra fuentes de atribución
Únete al debate público
Activador de atribución basado en el encabezado (informes a nivel del evento)
¿Qué cambiará y por qué?
Al igual que el registro de clics o vistas, la nueva propuesta cambia el activador de atribución (cuando una tecnología publicitaria le indica al navegador que registre una conversión) a un enfoque basado en encabezados.
Este mecanismo está alineado con el registro de fuentes basado en encabezados y es más convencional que el mecanismo de redireccionamiento que se usaba anteriormente.
Además, en la nueva propuesta, se necesita el atributo attributionsrc en la página de conversión.
El motivo es una cuestión de permisos: en la propuesta anterior, el sitio del activador (por lo general, un sitio del anunciante) tenía control general sobre la función a través de un encabezado Permissions-Policy, pero no tenía control detallado a nivel del elemento sobre si un elemento puede enviar una solicitud a una parte que, en última instancia, activaría una atribución. attributionsrc cambia esto: este marcador obligatorio le brinda al anunciante la capacidad de supervisar y, por lo tanto, controlar qué elementos pueden activar una atribución.
Ten en cuenta que, en el lado de la fuente (por lo general, un sitio del publicador), hay un control de toda la página a través de Permissions-Policy, así como un control de todo el elemento a través de attributionsrc.
¿Cómo funciona el activador de atribución?
Cuando recibe una solicitud de píxeles y decide que debe clasificarse como una conversión, una AdTech debe responder con un nuevo encabezado HTTP
Attribution-Reporting-Register-Event-Trigger.
El valor de este encabezado especifica cómo tratar el evento activador como un objeto JSON. Esta es la misma información que se definió como parámetros de consulta en la propuesta anterior.
Encabezado de respuesta HTTP Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
Redireccionamiento (opcional)
De forma opcional, el servidor de AdTech puede hacer que la respuesta que contiene Attribution-Reporting-Register-Event-Trigger sea una respuesta de redireccionamiento.
De esta manera, permite que los terceros observen el evento de conversión y le indiquen al navegador que lo atribuya.
El redireccionamiento es opcional y no es necesario cuando tanto una tecnología publicitaria como un tercero tienen píxeles en la página.
Obtén más información en Informes de terceros.
Obtén más información en la explicación técnica
Únete al debate público
No hay worklets (informes agregables)
¿Qué cambiará y por qué?
En la propuesta anterior de informes agregables, se requería acceso a JavaScript para invocar una worklet (un mecanismo basado en JavaScript) que generaría estos informes.
En la nueva propuesta, no se requiere ninguna tarea. En cambio, una AdTech definiría de forma declarativa, a través de encabezados HTTP, las reglas que el navegador debe usar para generar informes agregables.
La nueva propuesta ofrece varios beneficios:
- Implementación en el navegador: A diferencia del diseño de worklet, el nuevo diseño es mucho más simple porque no requiere un nuevo entorno de ejecución en los navegadores.
- Experiencia del desarrollador: El nuevo diseño se basa en encabezados, que los desarrolladores suelen usar y conocer, a diferencia de los worklets. También se alinea estrechamente con la plataforma de la API para el registro de fuentes, lo que facilita el aprendizaje y el uso de la API.
- Adopción: El nuevo diseño permite que más sistemas de medición existentes usen informes agregables. Muchas soluciones de medición solo son HTTP: dependen de solicitudes de imagen (solicitudes de píxeles) que no requieren acceso a JavaScript. Sin embargo, como el enfoque de worklet sí requiere acceso a JavaScript, es posible que haya sido difícil migrar desde algunos sistemas de medición existentes.
- Robustez: El nuevo diseño ayuda a mitigar la pérdida de datos porque es más fácil integrarlo con la semántica de
keepalive, por ejemplo, si se registra un clic o una vista cuando un usuario abandona una página.
¿Cómo funciona el mecanismo sin worklets?
Este mecanismo declarativo se basa en encabezados HTTP, al igual que el registro de fuentes a nivel del evento y el encabezado del activador de atribución. Obtén más detalles sobre esto en las siguientes secciones.
Únete al debate público
Registro de fuentes basado en encabezados (informes agregables)
Se propone un nuevo mecanismo para registrar una fuente para un informe agregable, que es el mismo que el registro de fuentes a nivel del evento.
Solo el nombre del encabezado es diferente: Attribution-Reporting-Register-Aggregatable-Source.
Obtén más información en la explicación técnica
Registro de la fuente de atribución
Activador de atribución basado en encabezados (informes agregables)
Se propone un nuevo mecanismo para registrar una fuente para un informe agregable, que es el mismo que el activador de atribución a nivel del evento.
Solo el nombre del encabezado es diferente: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Obtén más información en la explicación técnica
Registro del activador de atribución
Nuevas funciones
Informes de terceros (informes a nivel del evento y agregables)
¿Qué cambiará y por qué?
Dos aspectos de la nueva propuesta ayudan a admitir mejor los casos de uso de informes de terceros:
- De forma opcional, las AdTechs pueden redireccionar las solicitudes de red a otros servidores de AdTech, lo que permite que esas otras AdTechs realicen su propio registro de fuente y activador. Esta es una forma común de configurar a los terceros en la actualidad. Esto facilita la adopción de la API, entre otros sistemas de informes de terceros existentes.
- Los orígenes de los informes (por lo general, las tecnologías publicitarias) ya no comparten la mayoría de los límites de privacidad. Esto admite casos de uso en los que varias tecnologías publicitarias trabajan con los mismos publicadores o anunciantes.
¿Cómo funcionan los informes de terceros?
En la nueva propuesta, el registro y el activador de fuentes basados en respuestas dependen de los encabezados HTTP. Una tecnología publicitaria puede aprovechar los redireccionamientos HTTP para estas solicitudes.
Si una solicitud de clic o vista en el sitio de un publicador (registro de la fuente) se redirecciona posteriormente a varias partes, cada una de ellas puede registrar esta vista o clic (evento de fuente).
Del mismo modo, una plataforma de tecnología publicitaria puede redireccionar una solicitud de atribución específica realizada desde un sitio del anunciante, lo que permite que varias otras partes registren una conversión (activador de atribución).
Cada parte puede acceder a sus informes independientes y configurarlos con datos independientes.
Registra varios activadores sin redireccionamientos
También es posible registrar varios activadores de atribución sin usar redireccionamientos. Para ello, agrega varios elementos de píxeles en el lado de la conversión (uno por activador).
Únete al debate público
Medición de vistas (informes a nivel del evento y agregables)
¿Qué cambiará y por qué?
En la nueva propuesta, la medición de impresiones y la medición de clics funcionan de manera unificada:
registerattributionsrc, el atributo específico de la vista que le indicaba al navegador que registrara las vistas junto con los clics, ya no forma parte de la propuesta.- Los mecanismos de privacidad ahora están unificados en las vistas y los clics. Para obtener más información, consulta Ruido y transparencia.
Se propone este cambio para alinearse con el nuevo mecanismo de registro basado en encabezados. También simplifica la experiencia de los desarrolladores cuando se pretende admitir la medición de clics y vistas.
¿Cómo funciona la medición de vistas?
La medición de conversiones posimpresión y la medición de clics se basan en el registro basado en encabezados.
Obtén más información en la explicación técnica
Informes a nivel del evento (para clics y vistas)
Únete al debate público
Depuración o análisis de rendimiento (informes a nivel del evento y agregables)
¿Qué cambiará y por qué?
Se agregó un mecanismo de depuración a la propuesta para ayudar a los desarrolladores a detectar errores y comparar el rendimiento de los informes de atribución con las soluciones de medición existentes basadas en cookies.
¿Cómo funciona la depuración?
Tanto el registro de fuente como el de activador aceptarán un nuevo parámetro debug_key, un número entero sin firmar de 64 bits (es decir, un número grande).
Si se crea un informe con claves de depuración de fuente y de activador, y si hay una cookie Samesite=None ar_debug=1 en el contenedor de cookies del origen de informes en el momento del registro de la fuente y del activador, se enviará un informe de depuración (JSON) a un extremo .well-known/attribution-reporting/debug:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Los informes a nivel del evento y los agregables también incluirán estos dos parámetros nuevos para que se puedan asociar con el informe de depuración correcto.
Obtén más información en la explicación técnica
Opcional: Informes de depuración extendidos
Únete al debate público
Funciones de filtrado (informes a nivel del evento y agregables)
¿Qué cambiará y por qué?
Debido a que admiten casos de uso importantes en el ecosistema publicitario actual, ahora se admitirán varios casos de uso en los informes agregables y a nivel del evento:
- Filtrado de conversiones: Filtra una conversión según la información del lado del código fuente. Por ejemplo, selecciona diferentes datos del activador (datos de conversiones) para los clics y las vistas de anuncios.
- Discrepancias en la atribución: Filtra las conversiones que se atribuyeron de forma incorrecta. Este es un tipo específico de filtrado de conversiones. Por ejemplo, filtra las conversiones que coinciden con el clic o la vista de anuncio incorrectos debido al alcance de destino de etld+1 en la API.
¿Cómo funcionan las funciones de filtrado? (para informes a nivel del evento)
Un campo source_data opcional en el objeto JSON del lado del código fuente puede definir elementos que el navegador usará posteriormente en el momento de la conversión para aplicar la lógica de filtrado.
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
El registro del activador ahora aceptará un encabezado opcional Attribution-Reporting-Filters.
Encabezado de respuesta HTTP Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
Como alternativa, el encabezado Attribution-Reporting-Register-Event-Trigger se puede extender con un campo filters para realizar un filtrado selectivo y establecer trigger_data en función de source_data.
Si las claves del JSON de los filtros coinciden con las claves de source_data, el activador se
ignora por completo si la intersección está vacía.
Obtén más información en la explicación técnica
Filtros de atribución opcionales
Únete al debate público
Cambios en la protección de la privacidad
Ruido y transparencia (informes a nivel del evento y agregables)
¿Qué cambiará y por qué?
En la nueva propuesta, se mejoró uno de los mecanismos de privacidad de los informes: estos están sujetos a una respuesta aleatoria.
Esto significa que algunas conversiones reales se registrarán correctamente y, en un porcentaje determinado del
tiempo, se suprimirán algunas conversiones reales o se agregarán algunas conversiones falsas.
Esta nueva técnica tiene algunos beneficios:
- Unifica el mecanismo de privacidad para los clics y las vistas.
- Es más sencillo razonar sobre este mecanismo que sobre uno en el que se separarían los datos del activador (datos de conversiones) y el ruido del vínculo entre el activador y la fuente.
- Establece un marco de trabajo de privacidad que, con la configuración de ruido adecuada, podría garantizar que ninguna parte pueda confiar en la API para saber con certeza si un usuario individual realizó una conversión (o no) para un anuncio determinado.
Este nuevo mecanismo reemplaza al mecanismo anterior en el que, en el 5% de los casos, los datos del activador (datos de conversión) se reemplazaban por un valor aleatorio.
Además, se agregó el valor de probabilidad de respuesta aleatoria al cuerpo del informe (campo randomized_trigger_rate). Este campo especifica la probabilidad (de 0 a 1) de que una fuente esté sujeta a una respuesta aleatoria.
Esto tiene dos beneficios principales:
- Hace que el comportamiento subyacente del navegador sea transparente para las partes que recibirán los informes (por lo general, las tecnologías publicitarias).
- Es útil para un futuro en el que la API sea compatible con todos los navegadores: los diferentes navegadores pueden decidir aplicar diferentes niveles de ruido según sus objetivos de privacidad, y las partes que controlarán el informe necesitarán visibilidad sobre esto.
¿Cómo funciona el ruido?
En la nueva propuesta, en el momento en que se registra una fuente (es decir, se registra un clic o una vista de anuncio), el navegador decide de forma aleatoria si atribuirá las conversiones de forma veraz y enviará informes para este clic o vista de anuncio, o si, en su lugar, generará un resultado falso.
El resultado falso puede ser:
- No se genera ningún informe, independientemente de si el usuario genera una conversión.
- Uno o varios informes falsos, independientemente de si el usuario genera una conversión.
En los informes falsos, los datos del activador (datos de conversión) son aleatorios: un valor aleatorio de 3 bits para los clics (cualquier número entre 0 y 7) y un valor aleatorio de 1 bit para las vistas (0 o 1).
Al igual que los informes reales, los informes falsos no se envían inmediatamente después de que el usuario realiza una conversión. Se envían al final de una ventana de informes aleatoria.
Existen tres ventanas de informes para los clics (2 días, 7 días o 30 días después del clic). Cada informe falso se asigna de forma aleatoria a una de las ventanas de informes.
Por otro lado, como se indicó en la propuesta anterior, el orden de los informes dentro de un período es aleatorio.
Obtén más información en la explicación técnica
Ejemplos de conversiones falsas con ruido
Únete al debate público
Limitaciones de los informes (informes a nivel del evento y agregables)
Límites de origen de los informes
¿Qué cambiará y por qué?
La nueva propuesta limita de forma explícita la cantidad de partes que pueden medir eventos entre dos sitios.
- Se propone que la cantidad máxima de orígenes de informes únicos (por lo general, AdTech) que pueden registrar fuentes por {publisher, advertiser} se limite a 100 por 30 días. Este contador se incrementará por cada clic o vista del anuncio (evento de origen), incluso aquellos que no se atribuyan.
- Se propone que la cantidad máxima de orígenes de informes únicos (por lo general, tecnologías publicitarias) que pueden enviar informes por {publisher, advertiser} se limite a 10 por 30 días. Este contador aumentará por cada conversión atribuida.
El objetivo de estos límites es que sean lo suficientemente altos como para no limitar la capacidad de ningún actor de medir las conversiones, pero lo suficientemente bajos como para ayudar a mitigar algunas formas de abuso de la API.
Informe de límites de inactividad o frecuencia
¿Qué cambiará y por qué?
El tiempo de inactividad de los informes es un mecanismo de privacidad que limita la cantidad total de información que se envía a través de esta API en un período determinado para un usuario.
En la nueva propuesta, se pueden programar 100 informes por {source site, destination, reporting origin} (por lo general, {publisher, advertiser, adtech}) en un período de 30 días.
Más allá de este límite, el navegador dejará de programar informes que coincidan con este {source site, destination, reporting origin} determinado (por lo general, {publisher, advertiser, adtech}), hasta que el recuento de informes continuos de 30 días sea inferior a 100 para ese {source site, destination, reporting origin}.
Obtén más información en la explicación técnica
Informes de inactividad o límites de frecuencia
Limitación de destinos (solo informes a nivel del evento)
¿Qué cambiará y por qué?
Se modifica el límite de destinos para incluir el origen de los informes (por lo general, una tecnología publicitaria) en el alcance: Se permiten 100 destinos pendientes únicos (por lo general, sitios del anunciante o sitios en los que se espera que se produzcan conversiones) por {publicador, tecnología publicitaria}.
Esta es una protección de la privacidad para limitar la reconstrucción del historial de navegación.
Obtén más información en la explicación técnica
Limita la cantidad de destinos únicos cubiertos por fuentes pendientes
Todos los recursos
- Consulta Informes de atribución.
- Lee Qué debes saber sobre la API.
La imagen del encabezado es de Diana Polekhina en Unsplash.