La propuesta de informes de atribución se sometió a una serie de cambios para abordar comentarios de la comunidad, desde cambios en el mecanismo de la API hasta nuevas funcionalidades.
Registro de cambios
- 7 de febrero de 2022: Se agregó la sección sobre el redireccionamiento del activador de encabezados.
- 27 de enero de 2022: Fecha de publicación del artículo por primera vez.
¿A quién está dirigida esta publicación?
Esta publicación es para ti:
- Si ya conoces la API, por ejemplo, si observaste o que participa en los debates sobre el repositorio de WICG y quieren entender el lote de cambios realizados 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 recién comienzas a usar esta API o si aún no la has probado, accede directamente al Introducción a la API en su lugar.
Migración futura
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 te recomendamos usar las funciones nuevas.
En este artículo, también se enumeran los cambios de los informes agregables. Sin embargo, estos cambios, si se implementan, no requerirán ninguna acción ni migración, ya que aún no se implementó el navegador para los informes agregables al momento de redactar este documento.
Cambios en el nombre
Informes de resumen e informes agregables
Lo que quizás viste descrito como informes agregados ahora se denominará como informes de resumen.
Los informes de resumen son el resultado final de la agregación de varios informes agregables. que antes se llamaban 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 (a nivel local en el dispositivo del usuario) registra este evento,
junto con los parámetros específicos de los informes de atribución (como el
attributionsourceeventid, attributiondestination, attributionexpiry y otros parámetros). El
la AdTech establece los valores de estos parámetros.
La forma en que se configuran 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 de hacer clic o ver tiempo.
En la propuesta nueva, el valor de estos parámetros se define en el servidor de AdTech.
Esto tiene una serie de ventajas, sobre todo en términos de seguridad: el mecanismo del encabezado le da a la (por lo general, una AdTech) controla directamente si una fuente de atribución está registrada en su del proyecto. Esto mitiga parcialmente las preocupaciones de fraude, 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 necesitaría definir un atributo específico del cliente
attributionsrcEl valor de este atributo es una URL a la que el navegador enviará un solicitud; esta solicitud incluirá un encabezado HTTP nuevoAttribution-Reporting-Source-Info, cuyo 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/vistas debe responder con una solicitud
encabezado,
Attribution-Reporting-Register-Source, que contiene la atribución deseada parámetros. El origen que devuelve este encabezado ahora es el origen de los informes (anteriormente definido como
attributionreportto).Encabezado de respuesta HTTP
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Más información en la explicación técnica
Registrar fuentes de atribución
Unirse al debate público
Activador de atribución basado en encabezados (informes a nivel del evento)
¿Qué cambiará y por qué?
Al igual que el registro de vistas o clics, la propuesta nueva cambia el activador de atribución, cuando se
La AdTech indica al navegador que registre una conversión a un enfoque basado en encabezados.
Este mecanismo está alineado con el registro de la fuente basado en encabezados y es más
convencional que el mecanismo de redireccionamiento utilizado anteriormente.
Además, en la propuesta nueva, 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 del activador, por lo general,
un sitio de anunciante; tenía control general sobre la función a través de un encabezado Permissions-Policy, pero
no tenía un control detallado a nivel de los elementos sobre si un elemento puede enviar una solicitud a una parte.
que finalmente activarían una atribución. attributionsrc cambia esto: este marcador obligatorio.
Permite al anunciante supervisar y, por lo tanto, controlar qué elementos pueden activar una
atribución.
En el lado del código fuente (por lo general, en el sitio de un publicador) se aplica un control de toda la página
Se incluyen Permissions-Policy, así como un control de todo el elemento a través de attributionsrc.
¿Cómo funciona un activador de atribución?
Cuando se recibe una solicitud de píxel y se decide que debe clasificarse como conversión, una AdTech
debería responder con un nuevo mensaje HTTP
encabezado Attribution-Reporting-Register-Event-Trigger.
El valor de este encabezado especifica cómo tratar el evento activador como un objeto JSON. Esto es igual 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 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.
Obtenga más detalles en Informes de terceros.
Más información en la explicación técnica
Unirse al debate público
Sin worklet (informes agregables)
¿Qué cambiará y por qué?
En la propuesta anterior de informes agregables, se requería el acceso a JavaScript para invocar un worklet, un mecanismo basado en JavaScript, que generaría estos informes.
En la nueva propuesta, no se requiere un worklet. En cambio, una AdTech definiría de forma declarativa, a través de encabezados: las reglas que el navegador debe utilizar para generar informes agregables.
La nueva propuesta ofrece varios beneficios:
- Implementación del navegador: El nuevo diseño, a diferencia del diseño del worklet, es sustancialmente. 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 son de uso general y ampliamente conocidos por los desarrolladores, a diferencia de los worklets. También se alinea estrechamente con la plataforma de la API para registro de fuente, 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 utilicen informes. Muchas soluciones de medición son solo HTTP: dependen de solicitudes de imágenes, píxeles que no requieren acceso a JavaScript. Pero, como el enfoque del worklet requería acceso a JavaScript, puede haber sido difícil migrar desde algunos sistemas de medición existentes.
- Solidez: El nuevo diseño ayuda a mitigar la pérdida de datos porque 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 sale de ella una página.
¿Cómo funciona el mecanismo sin worklet?
Este mecanismo declarativo se basa en encabezados HTTP, al igual que el registro de fuente a nivel del evento. y el encabezado del activador de atribución. Encontrarás más detalles al respecto en las siguientes secciones.
Unirse al debate público
Registro de fuente basado en encabezados (informes agregables)
Se propone un nuevo mecanismo para registrar una fuente en un informe agregable. este mecanismo es el lo mismo que el registro de la fuente a nivel del evento.
Solo el nombre del encabezado es diferente: Attribution-Reporting-Register-Aggregatable-Source.
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 en un informe agregable. este mecanismo es el que el activador de atribución a nivel del evento.
Solo el nombre del encabezado es diferente: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
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é?
La nueva propuesta ayuda a admitir mejor los casos de uso de informes de terceros:
- De forma opcional, las AdTech pueden redireccionar las solicitudes de red a otros servidores de AdTech, lo que permite que esas otras para que las AdTech realicen su propio registro de fuente y activador. Esta es una forma común en que terceros se configuran hoy mismo. Esto hace que la API sea más fácil de adoptar, sistemas de informes externos.
- Los orígenes de los informes (por lo general, las AdTech) ya no comparten la mayoría de los límites de privacidad. Esto permite usar en los que varias AdTech trabajan con los mismos publicadores o anunciantes.
¿Cómo funcionan los informes de terceros?
En la propuesta nueva, el registro de la fuente y el activador basados en respuestas encabezados HTTP. Una AdTech puede aprovechar los redireccionamientos HTTP para estas solicitudes.
Si una solicitud de clic/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).
Del mismo modo, una AdTech puede redireccionar
una solicitud de atribución específica realizada desde un sitio diferente
Permitir 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, debes agregar varios elementos de píxeles en el lado de la conversión (uno por activador).
Unirse al debate público
Medición posimpresión (informes a nivel del evento, además de informes agregables)
¿Qué cambiará y por qué?
En la nueva propuesta, la medición posimpresión y la medición de clics funcionan de forma unificada:
registerattributionsrc, el atributo específico de la vista que le indicó al navegador lo siguiente: registrar vistas junto con los clics ya no forma parte de la propuesta.- Los mecanismos de privacidad ahora están unificados a través de clics y vistas. Consulta los detalles en Ruido y transparencia.
Este cambio se propone en consonancia con el nuevo mecanismo de registro basado en encabezados. También simplifica la experiencia del desarrollador cuando se pretende admitir los anuncios de clic y posimpresión. de medición.
¿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.
Más información en la explicación técnica
Informes a nivel del evento (para clics y vistas)
Unirse al debate público
Análisis de depuración y rendimiento (informes a nivel del evento, además de 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. comparar el rendimiento de Attribution Reporting con las soluciones de medición existentes basadas en cookies
¿Cómo funciona la depuración?
Tanto el registro de la fuente como el del activador aceptarán un nuevo parámetro debug_key, un archivo de 64 bits sin firma
un número entero (es decir, un número grande).
Si se crea un informe con claves de depuración de fuente y activador, y si se trata de una cookie Samesite=None ar_debug=1
está presente en el archivo jar de cookies del origen de los informes en la fuente y el momento de registro del activador, un grupo de
El informe (JSON) se enviará 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, asociado con el informe de depuración correcto.
Más información en la explicación técnica
Informes de depuración extendidos (opcional)
Unirse al debate público
Capacidades de filtrado (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, varios casos de uso ahora se admitirán tanto en los informes a nivel del evento como en los agregables:
- Filtro de conversiones: Filtra una conversión según la información de la fuente. Para Por ejemplo, selecciona diferentes datos de activadores (datos de conversiones) para las vistas y los clics en el anuncio.
- Discrepancia en la atribución: Filtra las conversiones que se atribuyeron incorrectamente. este es un un tipo específico de filtrado de conversiones. Por ejemplo, excluya las conversiones que coinciden con Ocurre un clic o una vista en el anuncio incorrectos debido al alcance de destino de etld+1 en la API.
¿Cómo funcionan las capacidades de filtrado? (para informes a nivel del evento)
Un campo opcional source_data en el objeto JSON del código fuente puede definir elementos que se usarán
que luego el navegador usará 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 aplicar un filtrado selectivo a fin de configurar trigger_data en función de source_data
Si las claves en los filtros JSON coinciden con las claves en source_data, el activador es
ignorados por completo si la intersección está vacía.
Más información en la explicación técnica
Filtros de atribución opcionales
Unirse al debate público
Cambios en la protección de la privacidad
Ruido y transparencia (informes a nivel del evento, además de informes agregables)
¿Qué cambiará y por qué?
En la nueva propuesta, se mejoró uno de los mecanismos de privacidad para los informes:
sujeto a una respuesta aleatoria.
Esto significa que algunas conversiones reales se informarán correctamente. y que un determinado porcentaje 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 simple razonar que con 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 privacidad que podría, con la configuración de ruido adecuada, garantizar que ninguna parte pueda confiar en que la API sepa con certeza que un usuario individual generó (o no) una conversión para un anuncio determinado.
Este nuevo mecanismo reemplaza al anterior mediante el cual el 5% de las veces activa los datos (datos de conversiones) se reemplazó por un valor aleatorio.
Además, el valor de probabilidad de respuesta aleatorizado se agregó al cuerpo del informe.
(campo randomized_trigger_rate). Este campo especifica la probabilidad (de 0 a 1) de que un origen
sujeto 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 AdTech).
- Esto resulta útil para un futuro en el que la API sea compatible en toda navegadores: los distintos navegadores pueden decidir aplicar distintos niveles de ruido según su objetivos de privacidad, y las partes que manejarán el informe deberán tener visibilidad de 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 al azar si atribuirá las conversiones de forma honesta y enviará informes para esto. clic o vista en el anuncio, o bien si generará un resultado falso en su lugar.
El resultado falso puede ser el siguiente:
- No hay ningún informe, independientemente de si el usuario genera una conversión.
- Uno o varios informes falsos, sin importar si el usuario genera una conversión
En los informes falsos, los datos del activador (datos de conversiones) son aleatorios: un valor aleatorio de 3 bits para los clics (cualquiera de un 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 genera una conversión. Se envían en hasta el final de una ventana de informe aleatoria.
Existen tres ventanas de informes para los clics (2, 7 o 30 días después del clic). Cada falso El informe se asigna de forma aleatoria a una de las ventanas de informe.
Por separado, como ya indicó la propuesta anterior, el orden de los informes dentro de una ventana es aleatorio.
Más información en la explicación técnica
Ejemplos de conversiones falsas contaminadas
Unirse al debate público
Limitaciones de los informes (informes a nivel del evento, además de informes agregables)
Límites de origen de los informes
¿Qué cambiará y por qué?
La nueva propuesta limita explícitamente la cantidad de partes que pueden medir eventos entre dos sitios.
- La cantidad máxima de orígenes de informes únicos (por lo general, AdTech) que se pueden registrar las fuentes por {publisher, advertiser} se limitan a 100 cada 30 días. Esta aumentará para cada clic o vista de anuncio (evento fuente), incluso aquellos que no atribuida.
- La cantidad máxima de orígenes de informes únicos (por lo general, AdTech) que pueden enviar informes por Se propone un límite de {publisher, advertiser} a 10 per 30 days. Este contador será se incrementan 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 perpetrador para realizar mediciones. pero lo suficientemente bajos como para mitigar algunos casos de abuso de las APIs.
Informes de inactividad y 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, 100 informes por {source site, destination, reporting origin} (por lo general, {publisher, advertiser, adtech}) se puede programar para más de 30 días.
Si se supera este límite, el navegador dejará de programar informes que coincidan con este {source site, destino, origen de los informes} (por lo general, {publisher, advertiser, adtech}) hasta los últimos 30 días el recuento de informes es inferior a 100 para ese {source site, destination, reporting origin}.
Más información en la explicación técnica
Informes de inactividad y límites de frecuencia
Limitación de destino (solo informes a nivel del evento)
¿Qué cambiará y por qué?
Se modifica la limitación de destino para incluir el origen de los informes (por lo general, una AdTech) en el alcance: 100 únicos destinos pendientes (por lo general, sitios de anunciantes o sitios en los que se espera que las conversiones se destinen sitio) se permiten por {publisher, adtech}.
Esta es una protección de la privacidad para limitar la reconstrucción del historial de navegación.
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 Informes de atribución.
- Lee Qué debes saber sobre la API.
La imagen del encabezado es de Diana Polekhina en Unsplash.