La propuesta de Attribution Reporting experimentó una serie de cambios para abordar los comentarios de la comunidad, desde cambios en el mecanismo de la API hasta funciones nuevas.
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: Artículo publicado por primera vez.
¿A quién está dirigida esta publicación?
Esta publicación es para ti:
- Si ya comprendes la API, por ejemplo, si observaste o participaste en los debates sobre el repositorio de WICG y deseas 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 un experimento en producción.
Si recién comienzas a usar esta API o aún no has experimentado con ella, ve directamente a la introducción a la API.
Migración por delante
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 el código para que la API siga funcionando. También puedes considerar el uso de las funciones nuevas.
En este artículo, también se enumeran los cambios de los informes agregables. Sin embargo, si se implementan estos cambios, no requerirán ninguna acción ni migración, ya que, al momento de redactar este documento, aún no se ha implementado ninguna implementación en los navegadores para los informes agregables.
Cambios de nombre
Informes de resumen e informes agregables
Lo que quizás hayas descrito como informes agregados ahora se denominan 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 (localmente en el dispositivo del usuario) registra este evento junto con los parámetros específicos de los informes de atribución (como attributionsourceeventid, attributiondestination, attributionexpiry y otros parámetros). La AdTech establece los valores de estos parámetros.
La forma en que se establecen estos parámetros está cambiando.
En la propuesta anterior, los parámetros debían incluirse del lado del cliente, ya sea en las etiquetas de anclaje como atributos HTML o como argumentos de una llamada basada en JS. Los parámetros debían conocerse al momento del clic o de 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 otorga al origen de los informes (por lo general, una AdTech) control directo sobre si una fuente de atribución se registra en su alcance. Esto mitiga parcialmente los fraudes, ya que, con este cambio, un navegador genuino nunca registrará una fuente sin la habilitación del origen del informe.
¿Cómo funciona el registro de fuentes?
- Para un anuncio determinado, la AdTech ahora debería definir un atributo específico
attributionsrcdel cliente. 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. - Después de recibir esta solicitud, el servidor de seguimiento de clics o vistas debe responder con un encabezado HTTP,
Attribution-Reporting-Register-Source, que contenga 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" }
Obtenga más información en la explicación técnica
Registra fuentes de atribución
Únete al debate público
Activador de atribución basada en 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 AdTech le indica al navegador que registre una conversión) a un enfoque basado en el encabezado.
Este mecanismo está alineado con el registro de fuente basado en encabezados y es más convencional que el mecanismo de redireccionamiento usado con anterioridad.
Además, en la nueva propuesta, se necesita el atributo attributionsrc en la página de conversión.
La lógica es una cuestión de permisos: en la propuesta anterior, el sitio orientado al activador (por lo general, el sitio de un anunciante) tenía un control general sobre la función mediante un encabezado Permissions-Policy, pero no tenía un 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 código fuente (por lo general, el sitio de un publicador), hay un control para toda la página mediante Permissions-Policy, así como un control para todo el elemento a través de attributionsrc.
¿Cómo funciona el activador de atribución?
Cuando recibe una solicitud de píxel y decide que se debe categorizar como una conversión, una AdTech debería responder con un encabezado Attribution-Reporting-Register-Event-Trigger HTTP nuevo.
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 manera opcional, el servidor de AdTech puede hacer que la respuesta que contiene Attribution-Reporting-Register-Event-Trigger sea una respuesta de redireccionamiento.
De esta forma, permite que los terceros observen el evento de conversión y le indiquen al navegador que lo atribuya.
El redireccionamiento es opcional. No es necesario cuando una AdTech y un tercero tienen píxeles en la página.
Obtén más detalles en Informes de terceros.
Obtenga más información en la explicación técnica
Únete al debate público
Sin worklet (informes agregables)
¿Qué cambiará y por qué?
En la propuesta anterior para los informes agregables, se requería acceso a JavaScript para invocar un worklet (un mecanismo basado en JavaScript) que generaría estos informes.
En la nueva propuesta, no se requiere ningún worklet. En su lugar, una AdTech definiría de forma declarativa (a través de encabezados HTTP) las reglas que el navegador debería usar para generar informes agregables.
La nueva propuesta ofrece varios beneficios:
- Implementación en el navegador: El nuevo diseño, a diferencia del diseño del worklet, 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 ampliamente, a diferencia de los worklets. También se alinea estrechamente con la plataforma de la API para el registro de la fuente, lo que hace que la API sea más fácil de aprender y usar.
- Adopción: El nuevo diseño permite que más sistemas de medición existentes usen informes agregables. Muchas soluciones de medición son solo HTTP: dependen de solicitudes de imágenes (solicitudes de píxeles) que no requieren acceso a JavaScript. Sin embargo, debido a que el enfoque de worklet requería acceso a JavaScript, puede haber sido difícil migrar desde algunos sistemas de medición existentes.
- Robustitud: El nuevo diseño ayuda a mitigar la pérdida de datos, ya que es más fácil de integrar 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 worklet?
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. Se brindarán más detalles sobre este tema en las siguientes secciones.
Únete al debate público
Registro de fuentes basadas en encabezados (informes agregables)
Se propone un mecanismo nuevo para registrar una fuente para un informe agregable. Este mecanismo es igual al registro de fuentes a nivel del evento.
Solo el nombre del encabezado es diferente: Attribution-Reporting-Register-Aggregatable-Source.
Obtenga más información en la explicación técnica
Registro de la fuente de atribución
Activador de atribución basada en encabezado (informes agregables)
Se propone un mecanismo nuevo para registrar una fuente para un informe agregable. Este mecanismo es igual al activador de atribución a nivel del evento.
Solo el nombre del encabezado es diferente: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Obtenga más información en la explicación técnica
Registro del activador de atribución
Funciones nuevas
Informes de terceros (informes a nivel del evento e informes agregables)
¿Qué cambiará y por qué?
Hay dos aspectos de la nueva propuesta que ayudan a respaldar mejor los casos de uso de informes de terceros:
- De manera opcional, las AdTech pueden redireccionar las solicitudes de red a otros servidores de AdTech, lo que les permite realizar su propio registro de fuente y activador. Esta es una forma habitual de configurar terceros. Esto hace que la API sea más fácil de adoptar, entre otras cosas en los sistemas de informes de terceros existentes.
- Los orígenes de los informes, que suelen ser las AdTech, ya no comparten la mayoría de los límites de privacidad. Esto admite casos de uso en los que varias AdTech trabajan con los mismos publicadores o anunciantes.
¿Cómo funcionan los informes de terceros?
En la nueva propuesta, el registro de la fuente basada en la respuesta y el activador se basan en los encabezados HTTP. Una AdTech puede aprovechar los redireccionamientos HTTP para estas solicitudes.
Si una solicitud de clic o vista en el sitio de un editor (registro de fuente) se redirecciona posteriormente a varias partes, cada una de ellas puede registrar esta vista o clic (evento de origen).
De manera similar, una AdTech puede redireccionar una solicitud de atribución específica realizada desde un sitio desviador, 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 separados.
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 posimpresión (informes a nivel del evento e informes agregables)
¿Qué cambiará y por qué?
En la nueva propuesta, la medición posimpresión y la de clics funcionan de una manera unificada:
registerattributionsrc, el atributo específico de la vista que le indicó al navegador que registrara 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. En esto, consulta los detalles en 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 de vista completa.
¿Cómo funciona la medición posimpresión?
Tanto la medición posimpresión como la medición de clics dependen del registro basado en encabezados.
Obtenga 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 y análisis de rendimiento (informes a nivel del evento e informes 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 Attribution Reporting con las soluciones de medición existentes basadas en cookies.
¿Cómo funciona la depuración?
El registro de la fuente y del activador aceptará un nuevo parámetro debug_key, un número entero sin firma 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 almacén de cookies del origen de los informes en el momento de registro del activador y de la fuente, 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 agregables y a nivel del evento también incluirán estos dos parámetros nuevos para que se puedan asociar con el informe de depuración correcto.
Obtenga más información en la explicación técnica
Opcional: Informes de depuración extendidos
Únete al debate público
Capacidades de filtro (informes a nivel del evento e informes agregables)
¿Qué cambiará y por qué?
Debido a que admiten casos de uso importantes en el ecosistema publicitario actual, una serie de casos de uso ahora se admitirán en los informes agregables y a nivel del evento:
- Filtrado de conversiones: Filtra una conversión en función de la información del código fuente. Por ejemplo, selecciona diferentes datos de activadores (datos de conversiones) para los clics y las vistas de anuncios.
- Discrepancias en la atribución: Filtra las conversiones atribuidas incorrectamente. Este es un tipo específico de filtro de conversiones. Por ejemplo, filtra las conversiones que coinciden con la vista o el clic en el anuncio incorrectos debido al alcance del destino etld+1 en la API.
¿Cómo funcionan las capacidades 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 a fin de configurar trigger_data en función de source_data.
Si las claves de los filtros JSON coinciden con las claves de source_data, el activador se
ignora por completo si la intersección está vacía.
Obtenga 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 e informes agregables)
¿Qué cambiará y por qué?
En la nueva propuesta, se mejoró uno de los mecanismos de privacidad para los informes: los informes están sujetos a respuestas aleatorias.
Esto significa que algunas conversiones reales se registrarán correctamente y, durante un determinado porcentaje de las veces, se suprimirán algunas conversiones reales o se agregarán otras falsas.
Esta nueva técnica tiene algunos beneficios:
- Unifica el mecanismo de privacidad para los clics y las vistas.
- Es más sencillo razonar que un mecanismo en el que se separarían los datos del activador (datos de conversión) y el ruido del vínculo de la fuente del activador.
- 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 generó una conversión (o no) para un anuncio determinado.
Este mecanismo nuevo reemplaza al anterior en el que, el 5% del tiempo, los datos del activador (datos de conversión) se reemplazaron 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 (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 transparent para las partes que recibirán los informes (por lo general, las AdTech).
- Resulta útil para un futuro en el que la API sea compatible con todos los navegadores: diferentes navegadores pueden decidir aplicar diferentes niveles de ruido según sus objetivos de privacidad, y las partes que manejarán el informe necesitarán visibilidad sobre esto.
¿Cómo funciona el ruido?
En la propuesta nueva, en el momento en que se registra una fuente (es decir, se registra una vista o un clic en el anuncio), el navegador decide de forma aleatoria si atribuirá conversiones y enviará informes de forma veraz, o si generará un resultado falso.
El resultado falso puede ser el siguiente:
- Ningún informe, independientemente de que el usuario genere una conversión
- Uno o varios informes falsos, independientemente de que el usuario genere 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 falsos no se envían inmediatamente después de que el usuario genera una conversión. Se envían al final de una ventana de informes aleatoria.
Existen tres ventanas de informe 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 informe.
Por otro lado, como ya indicó en la propuesta anterior, el orden de los informes dentro de una ventana es aleatorio.
Obtenga más información en la explicación técnica
Ejemplos de conversiones falsas ruidosas
Ú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 cada 30 días. Este contador aumentará por cada clic o vista en el anuncio (evento de fuente), incluso aquellos que no se atribuyen.
- Se propone que la cantidad máxima de orígenes de informes únicos (por lo general, AdTech) que pueden enviar informes por {publicador, anunciante} se limite a 10 por 30 días. Este contador aumentará por cada conversión atribuida.
Estos límites están diseñados para ser lo suficientemente altos como para que no limiten 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.
Período de inactividad de los informes / límites de frecuencia
¿Qué cambiará y por qué?
El período 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}) para que se programen en un plazo de 30 días.
Si superas este límite, el navegador dejará de programar informes que coincidan con {source site, destination, reporting origin} (generalmente {publisher, advertiser, adtech}) hasta que el recuento continuo de informes de 30 días sea inferior a 100 para ese {source site, destination, reporting origin}.
Obtenga más información en la explicación técnica
Período de inactividad y límites de frecuencia de los informes
Limitación del destino (solo informes a nivel del evento)
¿Qué cambiará y por qué?
La limitación de destinos se modifica para incluir el origen de los informes (por lo general, una AdTech) en el alcance: se permiten 100 destinos pendientes únicos (por lo general, sitios de anunciantes o sitios en los que se espera que se realicen conversiones) por {publisher, adtech}.
Esta es una protección de la privacidad para limitar la reconstrucción del historial de navegación.
Obtenga más información en la explicación técnica
Limitar la cantidad de destinos únicos que abarcan las fuentes pendientes
Todos los recursos
- Consulta Attribution Reporting.
- Lee Lo que debes saber sobre la API.
La imagen del encabezado es de Diana Polekhina, de Unsplash.