Descripción general de los Informes de atribución para dispositivos móviles

Nota: Este documento refleja las propuestas de diseño actuales de Privacy Sandbox en Android y está sujeto a cambios. Te animamos a enviarnos tus comentarios para ayudarnos en esta iniciativa.

Actualizaciones recientes

• Se actualizó la lista de próximos cambios y problemas conocidos.
• Se introdujo la configuración flexible y lite a nivel del evento, como un puente a la configuración flexible completa a nivel del evento.
• A partir de septiembre de 2023, registerWebSource, registerWebTrigger, registerAppSource y registerAppTrigger deben usar cadenas para los campos que esperan un valor numérico (como priority, source_event_id, debug_key, trigger_data, deduplication_key, etcétera).
• En el cuarto trimestre de 2023, se agregará la compatibilidad de Google Cloud con la API de Attribution Reporting de Android para generar informes de resumen usando el servicio de agregación en Google Cloud. Los plazos más específicos se reflejan aquí. Consulta la guía de implementación para descubrir cómo configurar el servicio de agregación con Google Cloud.
• Nuevos límites de tarifa que preservan la privacidad para la cantidad de destinos únicos.
• La funcionalidad actualizada para los filtros de activadores de la ventana de visualización estará disponible en el primer trimestre de 2024. Consulta la nota para obtener más información.

Descripción general

Actualmente, es común que las soluciones de atribución y medición para dispositivos móviles usen identificadores de distintas partes, como el ID de publicidad. La API de Attribution Reporting está diseñada para brindar una mayor privacidad del usuario, ya que quita la dependencia de los identificadores de usuario entre varias partes y admite casos de uso clave para la medición de atribución y conversión en apps y la Web.

Esta API tiene los siguientes mecanismos estructurales que ofrecen un framework para mejorar la privacidad, que se describen en las secciones posteriores de este documento con más detalle:

• Limita la cantidad de bits disponibles para informes a nivel del evento.
• Habilita los datos de conversiones de mayor fidelidad solo en informes agregables.
• Introduce límites de frecuencia de activadores disponibles (conversiones) y la cantidad de plataformas de tecnología publicitaria que se pueden asociar con una sola fuente de atribución.
• Incorpora varias técnicas que agregan ruido.

Los mecanismos anteriores limitan la capacidad de vincular la identidad del usuario en dos apps o dominios diferentes.

La API de Attribution Reporting admite los siguientes casos de uso:

• Informes de conversiones: Ayudan a los anunciantes a medir el rendimiento de sus campañas, ya que muestran los recuentos de conversiones (activadores) y los valores de conversiones (activadores) en varias dimensiones, como por campaña, grupo de anuncios y creatividad del anuncio.
• Optimización: Proporciona informes a nivel del evento que admiten la optimización de la inversión publicitaria, ya que brinda datos de atribución por impresión que se pueden usar para entrenar modelos de AA.
• Detección de actividad no válida: Brinda informes que se pueden usar en el análisis de detección de fraude publicitario y tráfico no válido.

En un nivel superior, la API de Attribution Reporting funciona de la siguiente manera, que se describe en detalle en las secciones posteriores de este documento:

1. La tecnología publicitaria completa un proceso de inscripción para usar la API de Attribution Reporting.
2. La tecnología publicitaria registra las fuentes de atribución (clics en los anuncios o vistas) con la API de Attribution Reporting.
3. La tecnología publicitaria registra activadores (conversiones de usuarios en la app o el sitio web del anunciante) con la API de Attribution Reporting.
4. La API de Attribution Reporting une los activadores con las fuentes de atribución (atribución de conversión), y se envían desde el dispositivo uno o más activadores a través de informes a nivel del evento y agregables a las plataformas de tecnología publicitaria.

Nota: Si quieres obtener más información para implementar este diseño en un caso de uso de atribución de app a app, consulta la sección sobre la atribución entre varias redes en la Guía para desarrolladores de la API de Attribution Reporting. Si quieres obtener información para implementar un caso de uso de app a Web o de Web a app, consulta la propuesta de diseño de medición web y entre apps.

Obtén acceso a las APIs de Attribution Reporting

Las plataformas de tecnología publicitaria deben inscribirse para acceder a las APIs de Attribution Reporting. Consulta Inscríbete para obtener una cuenta de Privacy Sandbox y obtén más información.

Registra una fuente de atribución (clic o vista)

La API de Attribution Reporting hace referencia a los clics y las vistas de anuncios como fuentes de atribución. Para registrar un clic en el anuncio o una reproducción de un anuncio, llama a registerSource(). Esta API espera los siguientes parámetros:

• URI de la fuente de atribución: La plataforma emite una solicitud a este URI para recuperar los metadatos asociados con la fuente de atribución.
• Evento de entrada: Es un objeto InputEvent (para un evento de clic) o null (para un evento de vista).

Cuando la API envía una solicitud al URI de fuente de atribución, la plataforma de tecnología publicitaria debe responder con los metadatos de la fuente de atribución en un encabezado HTTP nuevo Attribution-Reporting-Register-Source con los siguientes campos:

• ID del evento de origen: Este valor representa los datos a nivel del evento asociados con esta fuente de atribución (clic o vista del anuncio). Debe ser un número entero de 64 bits sin firma con formato de cadena.
• Destino: Es un origen en cuyo eTLD+1 o nombre de paquete de la app se produce en el evento del activador.
• Vencimiento (opcional): Es el vencimiento, en segundos, al cabo del cual la fuente debe borrarse del dispositivo. El valor predeterminado es de 30 días, con un valor mínimo de 1 día y uno máximo de 30 días. Se redondea al día más cercano. Puede tener el formato de un número entero o una cadena de 64 bits sin firma.
• Ventana de informe de eventos (opcional): Es la duración en segundos después de registrar una fuente durante la cual se pueden crear informes de eventos para dicha fuente. Si ya finalizó la ventana del informe del evento, pero aún no pasó el vencimiento, es posible que se detecte una coincidencia entre un activador y una fuente, pero no se enviará un informe de evento para ese activador. La ventana no puede ser mayor que el vencimiento. Puede tener el formato de un número entero o una cadena de 64 bits sin firma.
• Ventana de informe agregable (opcional): Es la duración en segundos después de que se registra una fuente durante la cual se pueden crear informes agregables para esa fuente. La ventana no puede ser mayor que el vencimiento. Puede tener el formato de un número entero o una cadena de 64 bits sin firma.
• Prioridad de la fuente (opcional): Se usa para seleccionar con qué fuente de atribución se debe asociar un activador determinado, en caso de que se puedan asociar varias. Debe ser un número entero de 64 bits firmado con formato de cadena.
  
  Cuando se recibe un activador, la API encuentra la fuente de atribución coincidente con el valor de prioridad de fuente más alto y genera un informe. Cada plataforma de tecnología publicitaria puede definir su propia estrategia de priorización. Para obtener más detalles sobre cómo la prioridad afecta la atribución, consulta la sección Ejemplo de priorización.
  
  Los valores más altos indican prioridades más altas.
• Ventanas de atribución de instalación y posteriores a la instalación (opcional): Se usan con el objetivo de determinar la atribución para los eventos posteriores a la instalación, que se describen más adelante en esta página.
• Datos de filtrado (opcional): Se usan para filtrar de manera selectiva algunos activadores e ignorarlos de forma efectiva. Para obtener más información, consulta la sección Filtros del activador de esta página.
• Claves de agregación (opcional): Especifica la segmentación que se usará en los informes agregables.

De forma opcional, la respuesta de metadatos de la fuente de atribución puede incluir datos adicionales en el encabezado Redireccionamientos de informe de atribución. Los datos contienen URLs de redireccionamiento, que permiten que varias tecnologías publicitarias registren una solicitud.

La guía para desarrolladores incluye ejemplos que muestran cómo aceptar el registro del código fuente.

En los siguientes pasos, se muestra un flujo de trabajo de ejemplo:

1. El SDK de tecnología publicitaria llama a la API para iniciar el registro de la fuente de atribución y especifica un URI para llame la API:

   registerSource(
       Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
       myClickEvent);
   

2. La API envía una solicitud a https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA mediante uno de los siguientes encabezados:

   <!-- For click events -->
   Attribution-Reporting-Source-Info: navigation
   
   <!-- For view events -->
   Attribution-Reporting-Source-Info: event
   

3. El servidor HTTPS de tecnología publicitaria responde con encabezados que contienen lo siguiente:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "234",
       "expiry": "60000",
       "priority": "5"
   }
   Attribution-Reporting-Redirect:
   https://adtechpartner1.example?their_ad_click_id=567
   Attribution-Reporting-Redirect:
   https://adtechpartner2.example?their_ad_click_id=890
   

4. La API envía una solicitud a cada URL especificada en Attribution-Reporting-Redirect. En este ejemplo, se especifican dos URLs de socios de tecnología publicitaria, por lo que la API envía una solicitud a https://adtechpartner1.example?their_ad_click_id=567 y otra a https://adtechpartner2.example?their_ad_click_id=890.

5. El servidor HTTPS de tecnología publicitaria responde con encabezados que contienen lo siguiente:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "789",
       "expiry": "120000",
       "priority": "2"
   }
   

   Nota: Las respuestas de las plataformas de tecnología publicitaria pueden especificar metadatos diferentes en el encabezado Attribution-Reporting-Register-Source.

Se registran tres fuentes de atribución de navegación (clic) en función de las solicitudes que se muestran en los pasos anteriores.

Registra una fuente de atribución desde WebView

WebView admite el caso de uso en el que una app renderiza un anuncio dentro de un WebView. Esto se controla a través de WebView que llama directamente a registerSource() como una solicitud en segundo plano. Esta llamada asocia la fuente de atribución a la app en lugar del origen de nivel superior. También se admite el registro de fuentes de contenido web incorporado en el contexto de un navegador. Los llamadores de la API y las apps deben ajustar la configuración para hacerlo. Consulta Registra la fuente de atribución y de activador desde WebView si quieres obtener instrucciones para los llamadores de la API y Fuente de atribución y registro de activadores desde WebView si quieres obtener instrucciones para las apps.

Dado que las tecnologías publicitarias usan código común en la Web y en WebView, este último sigue los redireccionamientos HTTP 302 y pasa los registros válidos a la plataforma. No planeamos admitir el encabezado Attribution-Reporting-Redirect en esta situación, pero puedes comunicarte con nosotros si tienes un caso de uso afectado.

Registra un activador (conversión)

Las plataformas de tecnología de anuncios pueden registrar activadores (conversiones, como instalaciones o eventos posteriores a la instalación) mediante el método registerTrigger().

El método registerTrigger() espera el parámetro URI del activador. La API envía una solicitud a este URI para recuperar metadatos asociados con el activador.

La API sigue los redireccionamientos. La respuesta del servidor de tecnología de anuncios debe incluir un encabezado HTTP llamado Attribution-Reporting-Register-Trigger, que representa la información de uno o más activadores registrados. El contenido del encabezado debe estar codificado en JSON y, además, incluir los siguientes campos:

• Datos del activador: Datos que identifican el evento activador (3 bits para clics, 1 bit para vistas). Debe ser un número entero de 64 bits firmado con formato de cadena.
• Prioridad del activador (opcional): Representa la prioridad de este activador en comparación con otros activadores para la misma fuente de atribución. Debe ser un número entero de 64 bits firmado con formato de cadena. Para obtener más detalles sobre cómo la prioridad afecta los informes, consulta la sección de priorización.
• Clave de anulación de duplicación (opcional): Se usa para identificar los casos en los que la misma plataforma de tecnología publicitaria registra el mismo activador varias veces para la misma fuente de atribución. Debe ser un número entero de 64 bits firmado con formato de cadena.
• Claves de agregación (opcional): Es una lista de diccionarios que especifica las claves de agregación y qué informes con agregación deben tener su valor agregado.
• Valores de agregación (opcional): Es una lista de cantidades de valor que contribuyen a cada clave.
• Filtros (opcional): Se usan para filtrar de manera selectiva los activadores o los datos de estos. Para obtener más información, consulta la sección Filtros del activador de esta página.

De forma opcional, la respuesta del servidor de tecnología publicitaria puede incluir datos adicionales en el encabezado Redireccionamientos de informe de atribución. Los datos contienen URLs de redireccionamiento, que permiten que varias tecnologías publicitarias registren una solicitud.

Varias tecnologías publicitarias pueden registrar el mismo evento de activación mediante redireccionamientos en el campo Attribution-Reporting-Redirect o varias llamadas al método registerTrigger(). Te recomendamos que uses el campo clave de anulación de duplicación para evitar incluir activadores duplicados en los informes en caso de que la misma tecnología publicitaria proporcione varias respuestas para el mismo evento de activación. Obtén más información sobre cómo y cuándo usar una clave de anulación de duplicación.

La guía para desarrolladores incluye ejemplos que muestran cómo aceptar el registro de activadores.

En los siguientes pasos, se muestra un flujo de trabajo de ejemplo:

1. El SDK de tecnología publicitaria llama a la API para iniciar el registro del activador a través de un URI ya inscrito. Consulta Inscríbete para obtener una cuenta de Privacy Sandbox para obtener más información.

   registerTrigger(
       Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
   

2. La API envía una solicitud a https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA.

3. El servidor HTTPS de tecnología publicitaria responde con encabezados que contienen lo siguiente:

   Attribution-Reporting-Register-Trigger: {
       "event_trigger_data": [{
       "trigger_data": "1122",
       // This returns 010 for click-through conversions (CTCs) and 0 for
       // view-through conversions (VTCs) in reports
       "priority": "3",
       "deduplication_key": "3344"
       }],
   }
   Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567
   

   Nota: Solo la tecnología publicitaria que inicia la llamada a la API puede especificar socios en Attribution-Reporting-Redirect.

4. La API envía una solicitud a cada URL especificada en Attribution-Reporting-Redirect. En este ejemplo, solo se especifica una URL, por lo que la API envía una solicitud a https://adtechpartner.example?app_install=567.

5. El servidor HTTPS de tecnología publicitaria responde con encabezados que contienen lo siguiente:

   Attribution-Reporting-Register-Trigger: {
   "event_trigger_data":[{
     "trigger_data": "5566",
     "priority": "3",
     "deduplication_key": "3344"
   }]
   }
   

   Se registran dos activadores según las solicitudes de los pasos anteriores.

Capacidades de atribución

En las siguientes secciones, se explica cómo la API de Attribution Reporting hace coincidir los activadores de conversión con las fuentes de atribución.

Aplicación del algoritmo de atribución priorizada por la fuente

La API de Attribution Reporting utiliza un algoritmo de atribución priorizado por la fuente para hacer coincidir un activador (conversión) con una fuente de atribución.

Los parámetros de prioridad proporcionan formas de personalizar la atribución de activadores a las fuentes:

• Puedes atribuir activadores a ciertos eventos de anuncios por sobre otros. Por ejemplo, puedes optar por poner más énfasis en los clics que en las vistas o centrarte en los eventos desde ciertas campañas.
• Puedes configurar la fuente y el activador de atribución de modo que, si alcanzas los límites de frecuencia, es más probable que recibas los informes que sean más importantes para ti. Por ejemplo, es posible que desees asegurarte de que las conversiones aptas para ofertas o las conversiones de alto valor tengan más probabilidades de aparecer en estos informes.

En el caso de que varias tecnologías publicitarias registren una fuente de atribución, como se describe más adelante en esta página, esta atribución se realiza de forma independiente para cada tecnología publicitaria. Para cada una, la fuente de atribución con la prioridad más alta se atribuye con el evento activador. Si hay varias fuentes de atribución con la misma prioridad, la API elige la última registrada. Cualquier otra fuente de atribución que no se elija se descartará y ya no será apta para una atribución de activador futura.

Filtros del activador

El registro de la fuente y del activador incluye funciones opcionales adicionales para hacer lo siguiente:

• Filtrar, de manera selectiva, algunos activadores e ignorarlos de forma efectiva
• Elegir los datos de los activadores para los informes a nivel del evento basados en los datos de la fuente
• Decidir excluir un activador de los informes a nivel del evento

Para filtrar de manera selectiva los activadores, la tecnología publicitaria puede especificar datos de filtros, que constan de claves y valores, durante el registro de la fuente y el activador. Si se especifica la misma clave para la fuente y el activador, se ignora el activador en el caso de que la intersección esté vacía. Por ejemplo, una fuente puede especificar "product": ["1234"], en el que product es la clave de filtro y 1234 es el valor. Si el filtro de activadores se configura como "product": ["1111"], se ignora el activador. Si no hay una clave del filtro de activadores que coincida con product, se ignorarán los filtros.

Otra situación en la que las plataformas de tecnología publicitaria podrían querer filtrar de manera selectiva los activadores es para forzar un período de vencimiento más corto. Durante el registro del activador, una plataforma de tecnología publicitaria puede especificar (en segundos) una ventana de visualización desde el momento en que ocurrió la conversión. Por ejemplo, una ventana de visualización de 7 días se definiría de la siguiente manera: "_lookback_window": 604800 // 7d

Para decidir si un filtro coincide, la API primero verificará la ventana de visualización. Si está disponible, la duración desde que se registró la fuente debe ser menor o igual que la duración de la ventana de visualización.

Nota: La lógica y la funcionalidad del filtro de visualización que se describen se aplicarán en el primer trimestre de 2024. Puedes encontrar más detalles específicos sobre los tiempos de lanzamiento. La lógica anterior requería que se especificaran las ventanas de visualización por hora, tanto en el lado de la fuente como del activador. Esta lógica de atributos actualizada es incompatible con versiones anteriores, lo que significa que las fuentes que usan la clave "_lookback_window" anterior no se registrarán correctamente.

Las plataformas de tecnología publicitaria también pueden elegir datos del activador, según los datos de eventos de la fuente. Por ejemplo, la API genera source_type automáticamente como navigation o event. Durante el registro del activador, trigger_data se puede establecer como un valor para "source_type": ["navigation"] y como un valor diferente para "source_type": ["event"].

Los activadores se excluyen de los informes a nivel del evento si se cumple alguna de las siguientes condiciones:

• No se especificó trigger_data.
• La fuente y el activador especifican la misma clave del filtro, pero los valores no coinciden. Ten en cuenta que, en este caso, el activador se ignora para los informes agregables y a nivel del evento.

Atribución posterior a la instalación

En algunos casos, es necesario atribuir los activadores posteriores a la instalación a la misma fuente de atribución que generó la instalación, incluso si hay otras fuentes de atribución aptas que se activaron recientemente.

La API puede admitir este caso de uso, ya que permite que las tecnologías publicitarias establezcan un período de atribución posterior a la instalación:

• Cuando registres una fuente de atribución, especifica una ventana de atribución de instalación durante la cual se esperan las instalaciones (por lo general, de 2 a 7 días, con un rango aceptado de 1 a 30 días). Especifica esta ventana de tiempo en segundos.
• Cuando registres una fuente de atribución, especifica una ventana de exclusividad de atribución posterior a la instalación, en la que los eventos de activación posteriores a la instalación deberían estar asociados con la fuente de atribución que generó la instalación (por lo general, de 7 a 30 días, rango aceptado de 0 a 30 días). Especifica esta ventana de tiempo en segundos.
• La API de Attribution Reporting valida cuándo ocurre una instalación de app y la atribuye internamente a la fuente de atribución priorizada por fuente. Sin embargo, la instalación no se envía a tecnologías publicitarias y no se tiene en cuenta en los límites de frecuencia respectivos de las plataformas.
• La validación de la instalación de apps está disponible para cualquier app descargada.
• Cualquier activador futuro que ocurra dentro de la ventana de atribución posterior a la instalación se atribuirá a la misma fuente de atribución que la instalación validada, siempre que esa fuente de atribución sea apta.

En el futuro, es posible que exploremos la posibilidad de extender el diseño para admitir modelos de atribución más avanzados.

En la siguiente tabla, se muestra un ejemplo de cómo las tecnologías publicitarias pueden usar la atribución posterior a la instalación. Supongamos que la misma red de tecnología publicitaria registra todas las fuentes y los activadores de atribución, y que todas las prioridades son las mismas.

Evento	Día en que ocurre el evento	Notas
Clic 1	1	install_attribution_window está configurado en 172800 (2 días) post_install_exclusivity_window está configurado en 864000 (10 días)
Instalación verificada	2	La API atribuye de forma interna las instalaciones verificadas, pero esas instalaciones no se consideran activadores. Por lo tanto, en este evento, no se envían informes.
Activador 1 (primer acceso)	2	El primer activador que registra la tecnología publicitaria. En este ejemplo, representa un primer acceso, pero puede ser de cualquier tipo de activador. Se atribuye a clic 1 (coincide con la atribución de instalación verificada).
Clic 2	4	Usa los mismos valores para install_attribution_window y post_install_exclusivity_window que el clic 1.
Activador 2 (posterior a la instalación)	5	El segundo activador que registra la tecnología publicitaria. En este ejemplo, representa una conversión posterior a la instalación, como una compra. Se atribuye a clic 1 (coincide con la atribución de instalación verificada). Se descarta el clic 2 y no es apto para una atribución futura.

En la siguiente lista, se proporcionan algunas notas adicionales sobre la atribución posterior a la instalación:

• Si la instalación verificada no se realiza dentro de la cantidad de días que se especifica en install_attribution_window, no se aplicará la atribución posterior a la instalación.
• Las instalaciones verificadas no se registran mediante plataformas de tecnología publicitaria y no se envían en los informes. No se descuentan de los límites de frecuencia de una tecnología publicitaria. Las instalaciones verificadas solo se usan para identificar la fuente de atribución que se acredita con la instalación.
• En el ejemplo de la tabla anterior, el activador 1 y el activador 2 representan un primer acceso y una conversión posterior a la instalación, respectivamente. Sin embargo, las plataformas de tecnología publicitaria pueden registrar cualquier tipo de activador. En otras palabras, no es necesario que el primer activador sea un activador abierto por primera vez.
• Si se registran más activadores después del vencimiento de post_install_exclusivity_window, el clic 1 es apto para la atribución, si suponemos que no venció ni alcanzó sus límites de frecuencia.
  • Si se registra una fuente de atribución con mayor prioridad, es posible que el clic 1 se pierda o se descarte.
• Si se desinstala y se vuelve a instalar la app del anunciante, reinstalarla se cuenta como una nueva instalación verificada.
• Si, en su lugar, el clic 1 fue un evento de vista se atribuyen los activadores de "primer acceso" y los posteriores a la instalación de todos modos. La API restringe la atribución a un activador por vista, excepto en el caso de la atribución posterior a la instalación, en la que se permiten hasta dos activadores por vista. En el caso de una atribución posterior a la instalación, la tecnología publicitaria podría recibir 2 ventanas de informes diferentes (a los 2 días o en el vencimiento de la fuente).

Se admiten todas las combinaciones de rutas de activación basadas en la app y en la Web

La API de informes de atribución habilita la atribución de las siguientes rutas de activación en un solo dispositivo Android:

• App a app: El usuario ve un anuncio en una app y, luego, genera una conversión en esa app o en otra instalada.
• App a la Web: El usuario ve un anuncio en una app y, luego, genera una conversión en un navegador de dispositivo móvil o app.
• Web a app: El usuario ve un anuncio en un navegador de app o dispositivo móvil y, luego, genera una conversión en una app.
• Web a Web: El usuario ve un anuncio en un navegador de dispositivo móvil o app y, luego, realiza una conversión en el mismo navegador o en otro, en el mismo dispositivo.

Permitimos que los navegadores web admitan nuevas funciones expuestas en la Web, como aquellas que son similares a Privacy Sandbox para la API de Attribution Reporting web, que puede llamar a las APIs de Android para habilitar la atribución en apps y sitios web.

Obtén información sobre los cambios que deben hacer las plataformas de tecnología publicitaria y las apps para admitir rutas de acceso para la medición web y de apps.

Prioriza varios activadores para una sola fuente de atribución

Una única fuente de atribución puede generar varios activadores. Por ejemplo, un flujo de compra podría incluir un activador de "instalación de la app", uno o más activadores de "agregar al carrito" y uno de "compra". Cada activador se atribuye a una o más fuentes de atribución según el algoritmo de atribución priorizado por la fuente, que se describe más adelante en esta página.

Existen límites sobre la cantidad de activadores que se pueden atribuir a una sola fuente de atribución. Si quieres obtener más detalles, lee la sección para ver los datos de medición de informes de atribución que se encuentra más adelante en esta página. En los casos en los que hay varios activadores que superen estos límites, es útil ingresar una lógica de priorización para recuperar los activadores más valiosos. Por ejemplo, los desarrolladores de una tecnología publicitaria podrían querer priorizar la obtención de activadores de "compra" por sobre los activadores de "agregar al carrito".

Para admitir esta lógica, se puede configurar un campo de prioridad independiente en el activador y elegir los activadores de mayor prioridad antes de que se apliquen los límites, dentro de una ventana de creación de informes determinada.

Nota: Los activadores de prioridad más baja que ya se hayan informado siempre consumirán el presupuesto.

Permite que varias tecnologías publicitarias registren fuentes de atribución o activadores

Es común que más de una tecnología publicitaria reciba informes de atribución, por lo general, para anular la duplicación en varias redes. Por lo tanto, la API permite que varias tecnologías publicitarias registren la misma fuente de atribución o activador. Una tecnología publicitaria debe registrar fuentes de atribución y activadores para recibir notificaciones de la API, y la atribución se realiza entre las fuentes de atribución y los activadores que la tecnología publicitaria registró en la API.

Los anunciantes que deseen usar un tercero para anular la duplicación entre varias redes pueden continuar haciéndolo, con una técnica similar a la siguiente:

• Configurar un servidor interno para registrar y recibir informes de la API
• Continuar usando un socio de medición para dispositivos móviles existente.

Fuentes de atribución

Los redireccionamientos de fuente de atribución son compatibles con el método registerSource():

1. La tecnología publicitaria que llama al método registerSource() puede proporcionar un campo Attribution-Reporting-Redirect adicional en su respuesta, que representa el conjunto de URLs de redireccionamiento de la tecnología publicitaria de socios.
2. Luego, la API llama a las URLs de redireccionamiento para que la tecnología publicitaria de socios pueda registrar la fuente de atribución.

Se pueden enumerar varias URLs de tecnología publicitaria de socios en el campo Attribution-Reporting-Redirect, y estas últimas no pueden especificar su propio campo Attribution-Reporting-Redirect.

La API también permite diferentes plataformas de tecnología publicitaria para cada llamada a registerSource().

Activadores

Para el registro del activador, los terceros son compatibles de manera similar: las tecnologías publicitarias pueden usar el campo adicional Attribution-Reporting-Redirect o cada uno puede llamar al método registerTrigger().

Cuando un anunciante usa varias tecnologías publicitarias para registrar el mismo evento activador, se debe usar una clave de anulación de duplicación. La clave de anulación de duplicación sirve para desambiguar estos informes repetidos del mismo evento que registra la misma plataforma de tecnología publicitaria. Por ejemplo, una tecnología publicitaria podría hacer que su SDK llame a la API directamente para registrar un activador y tener su URL en el campo de redireccionamiento de otra llamada de tecnología publicitaria. Si no se proporciona una clave de anulación de duplicación, los activadores duplicados se pueden informar a cada tecnología publicitaria como únicos.

Administra activadores duplicados

Una tecnología publicitaria puede registrar el mismo activador varias veces con la API. Las situaciones incluyen lo siguiente:

• El usuario realiza la misma acción (activador) varias veces. Por ejemplo, el usuario explora el mismo producto varias veces en la misma ventana de informes.
• La app del anunciante usa varios SDK para la medición de conversiones, que se redireccionan a la misma tecnología publicitaria. Por ejemplo, la app del anunciante usa dos socios de medición, MMP nº 1 y MMP nº 2. Ambas MMP redireccionan a la tecnología publicitaria nº 3. Cuando se produce una activación, ambos MMP lo registran con la API de Attribution Reporting. Luego, la tecnología publicitaria nº 3 recibe dos redireccionamientos independientes, uno de MMP nº 1 y otro de MMP nº 2, para el mismo activador.

En esos casos, existen varias formas de suprimir los informes a nivel del evento en los activadores duplicados para que sea menos probable que excedan los límites de frecuencia aplicados a los informes a nivel del evento. La forma recomendada es usar una clave de anulación de duplicación.

Método recomendado: clave de anulación de duplicación

El método recomendado es que la app del anunciante pase una clave de anulación de duplicación única a cualquier tecnología publicitaria o SDK que esté usando para la medición de conversiones. Cuando se produce una conversión, la app pasa una clave de anulación de duplicación a las tecnologías publicitarias o SDK. Esas tecnologías publicitarias o SDKs luego pasan la clave de anulación de duplicación a los redireccionamientos mediante un parámetro en las URLs especificadas en Attribution-Reporting-Redirect.

Las tecnologías publicitarias pueden optar por registrar solo el primer activador con una clave de anulación de duplicación determinada o pueden registrar varios activadores o todos los activadores. Las tecnologías publicitarias pueden especificar la deduplication_key cuando registran activadores duplicados.

Si una tecnología publicitaria registra varios activadores con la misma clave de anulación de duplicación y la misma fuente atribuida, solo se envía el primer activador registrado en los informes de nivel de evento. Los activadores duplicados aún se envían en los informes agregables encriptados.

Método alternativo: Las tecnologías publicitarias coinciden en los tipos de activadores por anunciante

En situaciones en las que las tecnologías publicitarias no desean usar la clave de anulación de duplicación o en los que la app del anunciante no puede pasar una clave de anulación de duplicación, existe una opción alternativa. Todas las tecnologías publicitarias que miden conversiones para un anunciante determinado deben trabajar en conjunto para definir diferentes tipos de activadores para cada anunciante.

Las tecnologías publicitarias que inician la llamada de registro del activador (por ejemplo, los SDKs) incluyen un parámetro en las URLs especificadas en Attribution-Reporting-Redirect, como duplicate_trigger_id. Ese parámetro duplicate_trigger_id puede incluir información como el nombre del SDK y el tipo de activador de ese anunciante. Las tecnologías publicitarias pueden enviar un subconjunto de estos activadores duplicados a los informes a nivel del evento. Las tecnologías publicitarias también pueden incluir este duplicate_trigger_id en sus claves de agregación.

Ejemplo de atribución entre varias redes

En el ejemplo que se describe en esta sección, el anunciante usa dos plataformas de tecnología publicitaria de publicación (tecnología publicitaria A y tecnología publicitaria B) y un socio de medición (MMP).

Para comenzar, tecnología publicitaria A, tecnología publicitaria B y MMP deben completar cada inscripción para usar la API de Attribution Reporting. Consulta Inscríbete para obtener una cuenta de Privacy Sandbox para obtener más información.

En la siguiente lista, se proporciona una serie hipotética de acciones del usuario que ocurren cada día, y cómo la API de Attribution Reporting controla esas acciones con respecto a tecnología publicitaria A, tecnología publicitaria B y MMP:

Día 1: El usuario hace clic en un anuncio publicado por tecnología publicitaria A

La tecnología publicitaria A llama a registerSource() con su URI. La API envía una solicitud al URI, y el clic se registra con los metadatos de la respuesta del servidor de tecnología publicitaria A.

La tecnología publicitaria A también incluye el URI de MMP en el encabezado Attribution-Reporting-Redirect. La API envía una solicitud al URI de MMP, y el clic se registra con los metadatos de la respuesta del servidor de MMP.

Día 2: El usuario hace clic en un anuncio publicado por la tecnología publicitaria B

La tecnología publicitaria B llama a registerSource() con su URI. La API envía una solicitud al URI, y el clic se registra con los metadatos de la respuesta del servidor de tecnología publicitaria B.

Al igual que la tecnología publicitaria A, la tecnología publicitaria B también incluyó el URI de MMP en el encabezado Attribution-Reporting-Redirect. La API envía una solicitud al URI de MMP, y el clic se registra con los metadatos de la respuesta del servidor de MMP.

Día 3: El usuario ve un anuncio publicado por la tecnología publicitaria A

La API responde de la misma manera que lo hizo el Día 1, salvo que se registró una vista para la tecnología publicitaria A y MMP.

Día 4: El usuario instala la app, que utiliza MMP para la medición de conversiones

MMP llama a registerTrigger() con su URI. La API envía una solicitud a la URL y la conversión se registra con los metadatos de la respuesta del servidor de MMP.

MMP también incluye los URIs de tecnología publicitaria A y tecnología publicitaria B en el encabezado Attribution-Reporting-Redirect. La API envía solicitudes a los servidores de tecnología publicitaria A y tecnología publicitaria B, y la conversión se registra según los metadatos de las respuestas del servidor.

En el siguiente diagrama, se ilustra el proceso descrito en la lista anterior:

Ejemplo de cómo la API de Attribution Reporting responde a una serie de acciones del usuario.

La atribución funciona de la siguiente manera:

• La tecnología publicitaria A establece la prioridad de los clics más alta que la de vistas y, por lo tanto, obtiene la instalación atribuida al clic el Día 1.
• La tecnología publicitaria B obtiene la instalación atribuida el Día 2.
• MMP establece la prioridad de los clics más alta que la de vistas y obtiene la instalación atribuida al clic el Día 2. El clic del Día 2 es el evento de anuncio más reciente con mayor prioridad.

Atribución entre varias redes sin redireccionamientos

Si bien recomendamos utilizar redireccionamientos para permitir que varias tecnologías publicitarias registren fuentes de atribución y activadores, reconocemos que puede haber situaciones en las que no sea posible usar redireccionamientos. En esta sección, se detalla cómo admitir la atribución entre redes sin redireccionamientos.

Flujo de alto nivel

1. En el registro de la fuente, la red de tecnología publicitaria de entrega comparte sus claves de agregación de fuente.
2. Durante el registro del activador, el anunciante o socio de medición elige qué partes del código fuente debe usar y especifica su configuración de atribución.
3. La atribución se basa en la configuración de atribución, las claves compartidas y cualquier fuente registrada por ese anunciante o socio de medición (p. ej., de otra red de tecnología publicitaria de publicación que tenga redireccionamientos habilitados).
4. Si el activador se atribuye a una fuente de una tecnología publicitaria de publicación que no sea de redireccionamientos, el anunciante o socio de medición puede recibir un informe agregable que combina la fuente y los elementos clave del activador definidos en el paso 2.

Registro de fuente

En el registro de la fuente, la red de tecnología publicitaria de publicación puede optar por compartir sus claves de agregación de fuente o un subconjunto de sus claves de agregación de fuente en lugar de redireccionar. No es necesario que la tecnología publicitaria de publicación use estas claves de fuente en sus propios informes agregables y puede declararlas en nombre del anunciante o del socio de medición si es necesario.

Las claves de agregación compartidas están disponibles para cualquier tecnología publicitaria que registre un activador para el mismo anunciante. Sin embargo, depende de la tecnología publicitaria de publicación y la tecnología publicitaria de medición del activador colaborar en qué tipos de claves de agregación se necesitan, sus nombres y cómo decodificar las claves en dimensiones legibles.

Registro de activador

En el registro del activador, la tecnología publicitaria de medición elige qué piezas del lado del código fuente se aplican a cada pieza de clave del activador, incluidas las que se comparten mediante la tecnología publicitaria de publicación.

Además, la tecnología publicitaria de medición también debe especificar su lógica de atribución en cascada con una nueva llamada a la API de configuración de atribución. En esta configuración, la tecnología publicitaria puede especificar la prioridad de fuente, el vencimiento y los filtros de las fuentes que no tenían visibilidad (p. ej., las fuentes que no utilizaron un redireccionamiento).

Atribución

La API de Attribution Reporting realiza una atribución de último toque con prioridad de fuente para la tecnología publicitaria de medición en función de su configuración de atribución, claves compartidas y cualquier fuente que haya registrado. Por ejemplo:

• El usuario hizo clic en los anuncios publicados por las tecnologías publicitarias A, B, C y D. Luego, el usuario instaló la app del anunciante, que usa un socio de tecnología publicitaria de medición (MMP).
• La tecnología publicitaria A redirecciona sus fuentes al MMP.
• Las tecnologías publicitarias B y C no redireccionan, pero comparten sus claves de agregación.
• La tecnología publicitaria D no redirecciona ni comparte claves de agregación.

El MMP registra una fuente de la tecnología publicitaria A y define una configuración de atribución que incluye tecnología publicitaria B y tecnología publicitaria D.

La atribución del MMP ahora incluye lo siguiente:

• La tecnología publicitaria A, ya que el MMP registró una fuente a partir del redireccionamiento de esa tecnología publicitaria
• La tecnología publicitaria B, ya que esta compartió claves y el MMP la incluyó en su configuración de atribución

La atribución del MMP no incluye lo siguiente:

• La tecnología publicitaria C, ya que el MMP no la incluyó en su configuración de atribución
• La tecnología publicitaria D, ya que no se redireccionaron ni compartieron claves de agregación.

Nota: Si quieres obtener más información para implementar este diseño, consulta la Guía para desarrolladores de la API de Attribution Reporting.

Depuración

Para admitir la depuración de la atribución entre redes sin redireccionamientos, hay un campo adicional, shared_debug_key, disponible para que las plataformas de tecnología publicitaria establezcan en el registro de la fuente. Si se configura en el registro de la fuente original, también se configurará en la fuente derivada correspondiente como debug_key durante el registro del activador para la atribución entre redes sin redireccionamientos. Esta clave de depuración se adjunta como source_debug_key en los informes de eventos y agregados.

Esta función de depuración solo será compatible con la atribución entre redes sin redireccionamientos en las siguientes situaciones:

• Medición de app a app en las que se permite el ID del anuncio
• Medición de app a la Web en la que se permite el ID del anuncio y que coincide tanto en la fuente de la app como en el activador web
• Medición de Web a Web (en la misma app de navegador) cuando ar_debug` está presente en la fuente y en el activador

Descubrimiento de claves para la atribución entre redes sin redireccionamientos

El objetivo del descubrimiento de claves es optimizar la forma en que las tecnologías publicitarias (por lo general, los MMPs) implementan su configuración de atribución para fines de atribución entre redes cuando una o varias tecnologías publicitarias usan claves de agregación compartidas (como se describió en Atribución entre redes sin redireccionamientos).

Cuando un MMP consulta el servicio de agregación para generar informes de resumen para las campañas que incluyen fuentes derivadas, el servicio de agregación requiere que el MMP especifique la lista de claves posibles como entrada para el trabajo de agregación. En algunos casos, la lista de posibles claves de agregación puede ser muy grande o desconocida. Es difícil hacer un seguimiento de listas grandes de claves posibles, y es probable que su procesamiento sea complejo y costoso. Considera los siguientes ejemplos:

• Cuando la lista de todas las claves posibles es grande:
  • Una red de publicidad ejecuta una iniciativa compleja de adquisición de usuarios que incluye 20 campañas, cada una con 10 grupos de anuncios, y cada uno de estos grupos con 5 creatividades que se actualizan cada semana según el rendimiento.
• Cuando se desconoce la lista de todas las claves posibles:
  • Una red de publicidad publica anuncios en muchas apps para dispositivos móviles en los que no se conoce la lista completa de los IDs de apps del publicador cuando se inicia la campaña.
  • Un anunciante trabaja en varias redes de publicidad que no redireccionan al MMP al momento del registro de la fuente, y cada red de publicidad tiene una estructura y unos valores de clave diferentes, que pueden no compartirse de antemano con el MMP.

Con la introducción del descubrimiento de claves sucede lo siguiente:

• El servicio de agregación ya no requiere una enumeración completa de las posibles claves de agregación.
• En lugar de tener que especificar la lista completa de claves posibles, un MMP puede crear un conjunto de claves vacío (o parcialmente vacío) y establecer un umbral para que solo las claves (no declaradas previamente) con valores que superen el umbral se incluyan en el resultado.
• El MMP recibe un informe de resumen que incluye valores con ruido para las claves que tienen valores de contribución superiores al umbral establecido. El informe también puede incluir claves que no tienen contribuciones de usuarios reales asociadas y que solo tienen ruido.
• El MMP usa el campo x_network_bit_mapping en el registro del activador para determinar qué tecnología publicitaria corresponde a qué clave.
• Luego, el MMP puede comunicarse con la tecnología publicitaria adecuada para comprender los valores de la clave de origen.

En resumen, el descubrimiento de claves permite a los MMP obtener claves de agregación sin conocerlas de antemano y evitar el procesamiento de un gran volumen de claves de origen a expensas de ruido adicional.

Nota: Esta función se encuentra en la etapa de propuesta y aún no está disponible para pruebas. Te animamos a que nos envíes tus comentarios.

Redireccionamientos de encadenamiento

Si proporcionas varios encabezados Attribution-Reporting-Redirect en una respuesta del servidor HTTPS de registro de fuente o activador, una tecnología publicitaria puede usar la API de Attribution Reporting para realizar varios registros de fuente y activador con una sola llamada a la API de registro.

En la respuesta del servidor, la tecnología publicitaria también puede incluir un solo encabezado Location (redireccionamiento 302) con una URL, que, a su vez, conduce a otro registro, hasta un límite establecido.

Ambos tipos de encabezados son opcionales y no se puede proporcionar ninguno si no se necesitan redireccionamientos. Se puede proporcionar uno o ambos tipos de encabezados. Las solicitudes de registro de fuente y activador (incluidos los redireccionamientos) se vuelven a intentar en caso de falla de la red. La cantidad de reintentos por solicitud se limita a una cantidad fija para evitar un impacto significativo en el dispositivo.

No se aceptan redireccionamientos para registerWebSource y registerWebTrigger que usan los navegadores. Puedes encontrar más detalles en la Guía de implementación entre sitios y apps.

Consulta los datos de medición en los informes de atribución

La API de Attribution Reporting habilita los siguientes tipos de informes, que se describen en detalle más adelante en esta página:

• Los informes a nivel del evento asocian una fuente de atribución en particular (de clic o vista) con bits limitados de datos de activador de alta fidelidad.
• Los informes agregables no están necesariamente vinculados con una fuente de atribución específica. Estos informes proporcionan datos de activación más detallados y de mayor fidelidad que los datos de nivel de evento, pero estos datos solo están disponibles de forma agregada.

Estos dos tipos de informes se complementan y se pueden usar en simultáneo.

Informes de nivel del evento

Después de que se atribuye un activador a una fuente de atribución, se genera un informe de nivel del evento, que se almacena en el dispositivo hasta que se pueda enviar a la URL de notificación de conversión de cada plataforma de tecnología publicitaria durante uno de los períodos para enviar informes, que se describen en más detalle más adelante en esta página.

Los informes de nivel del evento son útiles cuando se necesita muy poca información sobre el activador. Los datos de activadores de nivel del evento están limitados a 3 bits para los clics, lo que significa que a un activador se le puede asignar una de ocho categorías, y a 1 bit para las vistas. Además, los informes de nivel de evento no admiten la codificación de datos de activador de alta fidelidad, como un precio específico o el tiempo del activador. Debido a que la atribución se realiza en el dispositivo, los informes de nivel de evento no admiten las estadísticas entre diferentes dispositivos.

El informe de nivel de evento contiene los siguientes datos:

• Destino: Es el nombre del paquete de la app del anunciante o el eTLD+1 donde ocurrió el activador.
• ID de la fuente de atribución: Es el mismo ID de la fuente de atribución que se usó para registrar una fuente de atribución.
• Tipo de activador: Corresponde a 1 o 3 bits de datos de activador de baja fidelidad, según el tipo de fuente de atribución.

Mecanismos de preservación de la privacidad aplicados a todos los informes

Estos límites se aplican después de que se tienen en cuenta las prioridades sobre las fuentes de atribución y los activadores.

Límites en la cantidad de plataformas de tecnología publicitaria

Existen límites sobre la cantidad de tecnologías publicitarias que pueden registrar o recibir informes de la API, con una propuesta actual de lo siguiente:

• 100 tecnologías publicitarias con fuentes de atribución por {source app, destination app, 30 days, device}.
• 10 plataformas de tecnología publicitaria con activadores atribuidos por {source app, destination app, 30 days, device}
• 20 plataformas de tecnología publicitaria pueden registrar una sola fuente de atribución o activador (con Attribution-Reporting-Redirect)

Límites en la cantidad de destinos únicos

Estos límites dificultan que un conjunto de tecnologías publicitarias colaboren a través de consultas a una gran cantidad de apps para comprender el comportamiento de uso de una app por parte de un usuario determinado.

• En todas las fuentes registradas y en todas las tecnologías publicitarias, la API no admite más de 200 destinos únicos por app fuente por minuto.
• En todas las fuentes registradas, para una sola tecnología publicitaria, la API admite no más de 50 destinos únicos por app fuente por minuto. Este límite evita que una plataforma de tecnología publicitaria agote todo el presupuesto del límite de frecuencia mencionado anteriormente.

Las fuentes vencidas no se consideran en los límites de frecuencia.

Un solo origen de informes por app de origen por día

Una plataforma de tecnología publicitaria determinada solo puede usar un origen de informes para registrar fuentes en una app de publicador para un dispositivo determinado el mismo día. Este límite de frecuencia evita que las plataformas de tecnología publicitaria usen varios orígenes de informes para acceder a un presupuesto de privacidad adicional.

Considera la siguiente situación, en la que una sola plataforma de tecnología publicitaria desea usar varios orígenes de informes para registrar fuentes de una app de publicador en un solo dispositivo.

1. El origen de informes 1 de la plataforma de tecnología publicitaria A registra una fuente en la app B.
2. Después de 12 horas, el origen de informes 2 de la plataforma de tecnología publicitaria A intenta registrar una fuente en la app B.

La API rechazaría la segunda fuente correspondiente al origen de informes 2 de la tecnología publicitaria A. El origen de informes 2 de la plataforma de tecnología publicitaria A no podría registrar correctamente una fuente en el mismo dispositivo en la app B hasta el día siguiente.

Límites de inactividad y de frecuencia

Para limitar la cantidad de filtraciones de identidad de un usuario entre un par {source, destination}, la API limita la cantidad total de información que se envía en un período determinado para un usuario.

La propuesta actual es limitar cada plataforma de tecnología publicitaria a 100 activadores atribuidos por {source app, destination app, 30 days, device}.

Cantidad de destinos únicos

La API limita la cantidad de destinos que una plataforma de tecnología publicitaria puede intentar medir. Cuanto más bajo sea el límite, más difícil será para una plataforma de tecnología publicitaria usar la API para intentar medir la actividad de navegación del usuario que no está asociada con los anuncios que se muestran.

La propuesta actual es limitar cada plataforma de tecnología publicitaria a 100 destinos distintos con fuentes no vencidas por app fuente.

Mecanismos de preservación de la privacidad aplicados a informes de nivel del evento

Fidelidad limitada de los datos de activación

La API proporciona 1 bit para los activadores de vista completa y 3 bits para los activadores de clic. Las fuentes de atribución continúan admitiendo los 64 bits de metadatos completos.

Debes evaluar si reducir la información expresada en activadores para que funcionen con la cantidad limitada de bits disponibles en los informes a nivel de evento y cómo hacerlo.

Framework para el ruido de privacidad diferencial

Un objetivo de esta API es permitir que la medición de nivel de evento satisfaga los requisitos de privacidad diferenciales locales mediante el uso de respuestas aleatorias de k a fin de generar un resultado ruidoso para cada evento de fuente.

El ruido se aplica en función de si se informa honestamente un evento de fuente de atribución. Se registra una fuente de atribución en el dispositivo con la probabilidad $ 1-p $ de que la fuente de atribución se registre con normalidad y con la probabilidad $ p $ que el dispositivo elige al azar entre todos los posibles estados del resultado de la API (lo que incluye no informar nada o enviar varios informes falsos).

La respuesta aleatorizada de k es un algoritmo que es épsilon diferencial privado si se cumple la siguiente ecuación:

\[ p = \frac{k}{k + e^ε - 1} \]

Para valores bajos de ε, el resultado verdadero está protegido por el mecanismo de respuesta aleatorio de k. Estamos trabajando en los parámetros de ruido exactos, por lo que están sujetos a cambios en función de los comentarios con una propuesta actual de lo siguiente:

• p=0.24% para las fuentes de navegación
• p=0.00025% para las fuentes de eventos

Límites de los activadores disponibles (conversiones)

Existen límites sobre la cantidad de activadores por fuente de atribución, con una propuesta actual de los siguientes elementos:

• 1 o 2 activadores para las fuentes de atribución de vistas de anuncios (2 activadores solo están disponibles en el caso de la atribución posterior a la instalación)
• 3 activadores para las fuentes de atribución de anuncios de clics

Nota: Esto describe el comportamiento predeterminado de la API para la cantidad de atribuciones por fuente a través de los informes a nivel del evento. Con la introducción de los informes flexibles a nivel del evento en octubre de 2023, las plataformas de tecnología publicitaria ahora pueden configurar esta dimensión de sus informes en función de lo que resulte mejor para su caso de uso.

Períodos específicos para enviar informes (comportamiento predeterminado)

Los informes a nivel del evento para las fuentes de atribución de vistas de anuncios se envían 1 hora después de que vence la fuente. Esta fecha de vencimiento se puede configurar, pero no puede ser menor a 1 día ni superior a 30 días. Si se atribuyen dos activadores a una fuente de atribución de vistas de anuncios (mediante la atribución posterior a la instalación), los informes a nivel del evento se pueden enviar en los intervalos de la ventana de informes especificados de la siguiente manera.

Los informes de las fuentes de atribución de clics en el anuncio a nivel del evento no se pueden configurar y se envían antes de que la fuente venza o cuando esta lo hace, en un momento específico relacionado con la fecha en la que se registró la fuente. El tiempo entre la generación de la fuente de atribución y su vencimiento se divide en varias ventanas de informe. Cada ventana de informe tiene una fecha límite (a partir de la hora de la fuente de atribución). Al final de cada ventana de informe, el dispositivo recopila todos los activadores que ocurrieron desde la ventana del informe anterior y envía un informe programado. La API admite las siguientes ventanas de informe:

• 2 días: El dispositivo recopila todos los activadores que se produjeron hasta 2 días después de que se registró la fuente de atribución. El informe se envía 2 días y 1 hora después de que se registra la fuente de atribución.
• 7 días: El dispositivo recopila todos los activadores que ocurrieron hace más de 2 días, pero no más de 7 días después de que se registró la fuente de atribución. El informe se envía 7 días y 1 hora después de que se registra la fuente de atribución.
• Una duración personalizada: La define el atributo "vencimiento" de una fuente de atribución. El informe se envía 1 hora después de la hora de vencimiento especificada. Este valor no puede ser menor a 1 día ni superior a 30 días.

Nota: Esto describe el comportamiento predeterminado de la API para las ventanas de informes a nivel del evento. Con la introducción de los informes flexibles a nivel del evento en octubre de 2023, las plataformas de tecnología publicitaria ahora pueden configurar esta dimensión de sus informes en función de lo que resulte mejor para su caso de uso.

Configuración flexible a nivel del evento

Se recomienda que las plataformas de tecnología publicitaria usen la configuración predeterminada para los informes a nivel del evento cuando comiencen las pruebas de utilidad, pero puede no ser lo ideal en todos los casos de uso. La API de Attribution Reporting admitirá configuraciones opcionales y más flexibles para que las tecnologías publicitarias tengan un mayor control sobre la estructura de sus informes a nivel del evento y puedan maximizar la utilidad de los datos.

Esta flexibilidad adicional se introducirá en la API de Attribution Reporting en dos fases:

• Fase 1: Configuración flexible y lite a nivel del evento
  • Esta versión proporciona un subconjunto de las funciones completas y se puede usar independientemente de la Fase 2.
• Fase 2: Versión completa de la configuración flexible a nivel del evento

La Fase 1 (flexible y lite a nivel del evento) podría usarse para lo siguiente:

• Variar la frecuencia de los informes si se especifica la cantidad de ventanas de informes
• Variar la cantidad de atribuciones por registro de fuente
• Reducir la cantidad total de ruido disminuyendo los parámetros anteriores
• Configurar las ventanas de informes en lugar de usar los valores predeterminados

La Fase 2 (flexible y completa a nivel del evento) podría usarse para realizar todas las funciones de la Fase 1, además de lo siguiente:

• Variar la cardinalidad de datos del activador en un informe
• Reducir la cantidad total de ruido disminuyendo la cardinalidad de datos del activador

Reducir una dimensión de la configuración predeterminada permite que la plataforma de tecnología publicitaria aumente otra. Como alternativa, la cantidad total de ruido en un informe a nivel del evento se puede reducir si se disminuyen los parámetros mencionados anteriormente.

Además de establecer niveles de ruido de forma dinámica en función de la configuración elegida por una tecnología publicitaria, tendremos algunos límites de parámetros para evitar grandes costos de procesamiento y configuraciones con demasiados estados de salida (en los que el ruido aumentará de forma considerable). Este es un ejemplo de un conjunto de restricciones. Te recomendamos que envíes comentarios sobre [la propuesta de diseño][50]:

• Un máximo de 20 informes en todo el mundo y por datos del activador
• Un máximo de 5 ventanas de informes posibles por datos del activador
• Un máximo de 32 cardinalidades de datos del activador (no aplicable a la Fase 1, flexible y lite a nivel del evento)

A medida que las tecnologías publicitarias comiencen a usar esta función, ten en cuenta que el uso de valores extremos puede generar una gran cantidad de ruido o errores de registro si no se cumplen los niveles de privacidad.

Nota: La fase 1 (parcialmente flexible a nivel del evento) se lanzó en versión beta en octubre de 2023. El lanzamiento en versión beta de la Fase 2 (parcialmente flexible a nivel del evento) se programó para más adelante durante el primer trimestre de 2024.

Informes agregables

Antes de usar informes agregables, debes configurar tu cuenta de la nube y comenzar a recibir informes agregables.

Los informes agregables proporcionan datos de activador de mayor fidelidad del dispositivo más rápido, más allá de lo que se ofrece para los informes a nivel del evento. Estos datos de mayor fidelidad solo se pueden aprender en la clase agregada y no están asociados con un activador ni usuario en particular. Las claves de agregación son de hasta 128 bits, lo que permite que los informes agregables admitan casos de uso de informes como los siguientes:

• Informes para valores de activadores, como ingresos
• Administración de más tipos de activadores

Además, los informes agregables usan la misma lógica de atribución priorizada por la fuente que los informes a nivel del evento, pero admiten más conversiones atribuidas a un clic o una vista.

El diseño general de cómo la API de Attribution Reporting prepara y envía informes agregables se muestra en el diagrama:

1. El dispositivo envía informes encriptados a la tecnología publicitaria. En un entorno de producción, las tecnologías publicitarias no pueden usar estos informes directamente.
2. La tecnología publicitaria envía un lote de informes que se pueden agregar al servicio de agregación.
3. El servicio lee un lote de informes agregables, los desencripta y los agrega.
4. Los agregados finales se envían de vuelta a la tecnología publicitaria en un informe de resumen.

Proceso que la API de Attribution Reporting usa para preparar y enviar informes agregables.

Los informes agregables contienen los siguientes datos relacionados con las fuentes de atribución:

• Destino: Es el nombre del paquete de la app o la URL web de eTLD+1 donde ocurrió el activador.
• Fecha: Es la fecha en la que ocurrió el evento que representa la fuente de atribución.
• Carga útil: Son los valores de activador, recopilados como pares clave-valor encriptados, que se usan en el servicio de agregación de confianza para computar las agregaciones.

Servicios de agregación

Los siguientes servicios proporcionan funciones de agregación y ayudan a proteger contra el acceso inapropiado a los datos de agregación.

Estos servicios son administrados por diferentes partes, que se describen con más detalle más adelante en esta página:

• El servicio de agregación es el único que se espera que implementen las plataformas de tecnología publicitaria.
• Los servicios de administración de claves y contabilidad de informes agregables están administrados por partes de confianza llamadas coordinadores. Estos coordinadores certifican que el código que ejecuta el servicio de agregación es el código disponible de forma pública que proporciona Google y que todos los usuarios del servicio de agregación tienen aplicados los mismos servicios de contabilidad de informes agregables y clave.

Servicio de agregación

Las plataformas de tecnología publicitaria deben implementar por adelantado un servicio de agregación basado en objetos binarios proporcionados por Google.

Este servicio de agregación opera en un entorno de ejecución confiable (TEE) alojado en la nube. Un TEE ofrece los siguientes beneficios de seguridad:

• Garantiza que el código que opera en el TEE sea el objeto binario específico que ofrece Google. A menos que se cumpla esta condición, el servicio de agregación no podrá acceder a las claves de desencriptación que necesita para funcionar.
• Ofrece seguridad en todo el proceso en ejecución, ya que lo aísla de la supervisión y la manipulación externas.

Estos beneficios de seguridad permiten que un servicio de agregación realice de forma más segura operaciones sensibles, como el acceso a datos encriptados.

Para obtener más información sobre el diseño, el flujo de trabajo y las consideraciones de seguridad del servicio de agregación, consulta el documento del servicio de agregación en GitHub.

Servicio de administración de claves

Este servicio verifica que un servicio de agregación ejecute una versión aprobada del objeto binario y, luego, proporcione el servicio de agregación en la plataforma de tecnología publicitaria con las claves de desencriptación correctas para sus datos de activador.

Contabilidad de informes agregables

Este servicio realiza un seguimiento de la frecuencia con la que el servicio de agregación de una plataforma de tecnología publicitaria accede a un activador específico (que puede contener varias claves de agregación) y limita el acceso a la cantidad adecuada de desencriptaciones. Consulta la propuesta de diseño del servicio de agregación de la API de Attribution Reporting para obtener más detalles.

API de informes agregables

La API de creación de contribuciones en informes agregables usa la misma API de base que el registro de fuentes de atribución para informes de nivel de evento. En las siguientes secciones, se describen las extensiones de la API.

Registra los datos de fuente agregables

Cuando la API envía una solicitud al URI de fuente de atribución, la tecnología publicitaria puede registrar una lista de claves de agregación, llamada histogram_contributions, mediante la respuesta con un campo nuevo llamado aggregation_keys en el encabezado HTTP Attribution-Reporting-Register-Source, con la clave como key_name y el valor como key_piece:

• Nombre de la clave (clave): Es una cadena para el nombre de la clave. Se usa como clave de unión para combinar con claves del lado del activador para formar la clave final.
• Pieza de clave (valor): Es un valor de cadena de bits para la clave.

La clave final del bucket de histograma se define por completo en el momento del activador mediante una operación binaria OR en estas partes y en las del activador.

Las claves finales están restringidas a un máximo de 128 bits; las claves más largas se truncan. Es decir, las cadenas hexadecimales en el archivo JSON deben limitarse a 32 dígitos como máximo.

Obtén más información sobre el modo en que se estructuran las claves de agregación y su configuración.

En el siguiente ejemplo, una plataforma de tecnología publicitaria usa la API para recopilar lo siguiente:

• Recuentos totales de conversiones a nivel de campaña
• Valores agregados de compra a nivel geográfico

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

Registra el activador agregable

El registro del activador incluye dos campos adicionales.

El primer campo se usa para registrar una lista de claves agregadas en el lado del activador. La tecnología publicitaria debería responder con el campo aggregatable_trigger_data en el encabezado HTTP Attribution-Reporting-Register-Trigger, con los siguientes campos para cada clave agregada en la lista:

• Pieza de clave: Es un valor de cadena de bits para la clave.
• Claves de fuente: Es una lista de cadenas con los nombres de las claves complementarias de la fuente de atribución con la que se debe combinar la clave de activación para formar las claves finales.

El segundo campo se usa para registrar una lista de valores que deben contribuir a cada clave. La tecnología publicitaria debería responder con el campo aggregatable_values en el encabezado HTTP Attribution-Reporting-Register-Trigger. El segundo campo se usa para registrar una lista de valores que deben contribuir a cada clave, que pueden ser números enteros en el rango de $ [1, 2^{16}] $.

Cada activador puede realizar varias contribuciones a los informes agregables. El importe total de las contribuciones a cualquier evento de fuente está sujeto a un parámetro $ L1 $, que es la suma máxima de contribuciones (valores) en todas las claves de agregación para una fuente determinada. $ L1 $ hace referencia a la sensibilidad de L1 o a la norma de las contribuciones de histogramas por evento de fuente. Si superas estos límites, las futuras contribuciones disminuirán de forma silenciosa. La propuesta inicial es establecer $ L1 $ a $ 2^{16} $ (65536).

El ruido en el servicio de agregación se escala en proporción a este parámetro. Debido a esto, se recomienda escalar de forma adecuada los valores informados para una clave agregada determinada, según la parte del presupuesto de $ L1 $ que se le asigne. Este enfoque ayuda a garantizar que los informes agregados conserven la mayor fidelidad posible cuando se aplique ruido. Este mecanismo es muy flexible y puede admitir muchas estrategias de agregación.

En el siguiente ejemplo, el presupuesto de privacidad se divide de forma equitativa entre campaignCounts y geoValue, ya que se divide la contribución de $ L1 $ a cada una:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

En el ejemplo anterior, se generan las siguientes contribuciones de histogramas:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

Nota: filters se sigue aplicando a los informes agregables, y aún se pueden aplicar filtros de conversión en cada diccionario de aggregatable_trigger_data, del mismo modo que los filtros del activador para los informes a nivel del evento.

Los factores de escalamiento se pueden invertir para obtener los valores correctos, el ruido de módulo que se aplica:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

Privacidad diferencial

Un objetivo de esta API es tener un framework que admita la medición agregada privada diferencial. Para ello, se puede agregar un ruido proporcional al presupuesto de $ L1 $; por ejemplo, se puede elegir el ruido con la siguiente distribución:

\[ Laplace(\frac{L1}{ε}) \]

Integración de la API de Protected Audience y la API de Attribution Reporting

La integración entre APIs en las APIs de Protected Audience y Attribution Reporting permite a las AdTech evaluar el rendimiento de su atribución en varias tácticas de remarketing para comprender qué tipos de públicos proporcionan el ROI más alto.

A través de esta integración entre APIs, las AdTech pueden hacer lo siguiente:

• Crea un mapa de par clave-valor de los URIs que se usarán para 1) los informes de interacción y 2) el registro de fuentes.
• Incluye CustomAudience en su asignación de claves del lado del código fuente para los informes de resumen agregados (a través de la API de Attribution Reporting).

Cuando un usuario ve un anuncio o hace clic en él, sucede lo siguiente:

• La URL que se usa para informar esas interacciones con Protected Audience también se usará para registrar una vista o un clic como una fuente apta con la API de Attribution Reporting.
• La tecnología publicitaria puede elegir pasar CustomAudience (o cualquier otra información contextual relevante sobre el anuncio, como la posición del anuncio o la duración de la vista) con esa URL para que estos metadatos se propaguen a los informes de resumen cuando la tecnología publicitaria revisa el rendimiento total de la campaña.

Si quieres obtener más información para habilitar esto en Protected Audience, consulta la sección relevante de la explicación de la API de Protected Audience.

Prioridad de registro, atribución y ejemplos de informes

En este ejemplo, se muestra un conjunto de interacciones del usuario y cómo la tecnología publicitaria definió la fuente de atribución y las prioridades de activador podrían afectar los informes atribuidos. En este ejemplo, suponemos lo siguiente:

• Todas las fuentes de atribución y los activadores se registran con la misma tecnología publicitaria para el mismo anunciante.
• Todas las fuentes y activadores de atribución ocurren durante la primera ventana de informe del evento (en un plazo de 2 días a partir de que se muestran, en un principio, los anuncios en una app de publicador).

Ten en cuenta el caso en el que un usuario hace lo siguiente:

1. El usuario ve un anuncio. La tecnología publicitaria registra una fuente de atribución con la API, con una prioridad de 0 (vista n.º 1).
2. El usuario ve un anuncio registrado con una prioridad de 0 (vista nº 2).
3. El usuario hace clic en un anuncio, registrado con una prioridad de 1 (clic n° 1).
4. El usuario genera una conversión (llega a la página de destino) en una app del anunciante. La plataforma de tecnología publicitaria registra un activador con la API, con una prioridad de 0 (conversión nº 1).
   • A medida que se registran activadores, la API realiza la atribución antes de generar informes.
   • Hay 3 fuentes de atribución disponibles: vista n° 1, vista n° 2 y clic n° 1. La API atribuye este activador al clic n.º 1 porque es la prioridad más alta y más reciente.
   • Las vistas n° 1 y n° 2 se descartan, y ya no son aptas para una atribución futura.
5. El usuario agrega un artículo a su carrito en la app del anunciante, registrada con una prioridad de 1 (conversión n° 2).
   • El clic n.º 1 es la única fuente apta. La API atribuye este activador al clic n.º 1.
6. El usuario agrega un artículo a su carrito en la app del anunciante, registrada con una prioridad de 1 (conversión nº 3).
   • El clic n.º 1 es la única fuente apta. La API atribuye este activador al clic n.º 1.
7. El usuario agrega un artículo a su carrito en la app del anunciante, registrada con una prioridad de 1 (conversión nº 4).
   • El clic n.º 1 es la única fuente apta. La API atribuye este activador al clic n.º 1.
8. El usuario realiza una compra en la app del anunciante, registrada con una prioridad de 2 (conversión n° 5).
   • El clic n.º 1 es la única fuente apta. La API atribuye este activador al clic n.º 1.

Los informes a nivel del evento tienen las siguientes características:

• De forma predeterminada, los primeros 3 activadores atribuidos a un clic y el primer activador atribuido a una vista se envían después de las ventanas de informes aplicables.
• Dentro de la ventana de informes, si hay activadores registrados con una prioridad más alta, estos tienen preferencia y reemplazan al activador más reciente.
• En el ejemplo anterior, la tecnología publicitaria recibe 3 informes de eventos después de una ventana de informes de 2 días para la conversión nº 2, nº 3 y nº 5.
  • Los 5 activadores se atribuyen al clic n° 1. De forma predeterminada, la API enviará informes para los primeros 3 activadores: conversión n° 1, n° 2 y n° 3.
  • Sin embargo, la prioridad de la conversión n° 4 (1) es mayor que la prioridad de la conversión n° 1 (0). El informe de eventos de la conversión n° 4 reemplaza el informe de eventos de la conversión n° 1 que se enviará.
  • Además, la prioridad de la conversión n° 5 (2) es mayor que cualquier otro activador. El informe de eventos de la conversión n° 5 reemplaza el informe de la conversión n° 4 que se enviará.

Los informes agregables tienen las siguientes características:

• Los informes agregables encriptados se envían a la tecnología publicitaria en cuanto se procesan, unas horas después de que se registran los activadores.

  Como tecnología publicitaria, creas sus lotes según la información que no está encriptada en tus informes agregables. Esta información se encuentra en el campo shared_info de tu informe agregado e incluye la marca de tiempo y el origen del informe. No puedes generar por lotes según la información encriptada en tus pares clave-valor de agregación. Algunas estrategias simples que puedes seguir son los informes por lotes diarios o semanales. Lo ideal sería que los lotes contengan al menos 100 informes cada uno.

• La tecnología publicitaria depende de cuándo y cómo generar los informes agregables por lotes y enviarlos al servicio de agregación.

• En comparación con los informes a nivel del evento, los informes agregables encriptados pueden atribuir más activadores a una fuente.

• En el ejemplo anterior, se envían 5 informes agregables, uno para cada activador registrado.

Informes de depuración de transición

La API de Attribution Reporting es una forma nueva y bastante compleja de realizar mediciones de atribución sin identificadores entre apps. Por lo tanto, admitimos un mecanismo de transición para obtener más información sobre los informes de atribución cuando el ID de publicidad está disponible (el usuario no inhabilitó la personalización mediante el ID de publicidad y el publicador o la app del anunciante declaró los permisos de ID del anuncio). Esto garantiza que la API se entienda por completo durante el lanzamiento, ayude a eliminar cualquier error y compare con más facilidad el rendimiento con alternativas basadas en el ID de publicidad. Existen dos tipos de informes de depuración: informes de atribución correcta e informes detallados.

Lee la guía sobre los informes de depuración de transición para obtener información sobre los informes de depuración con medición de app a Web y de Web a app.

Informes de depuración de atribución correcta

Los registros de fuente y activador aceptan un nuevo campo debug_key de 64 bits (con formato de cadena), que la tecnología publicitaria propaga. source_debug_key y trigger_debug_key se pasan sin alteraciones en los informes a nivel del evento y en los agregados.

Si se crea un informe con claves de depuración de fuente y de activador, se envía un informe de depuración duplicado con un retraso limitado a un extremo .well-known/attribution-reporting/debug/report-event-attribution. Los informes de depuración son idénticos a los informes normales, incluidos ambos campos de clave de depuración. La inclusión de estas claves en ambos informes permite vincular informes normales a la transmisión independiente de informes de depuración.

• Para los informes a nivel del evento:
  • Los informes de depuración duplicados se envían con un retraso limitado y, por lo tanto, los límites en activadores disponibles no los suprimen, lo que permite que las tecnologías publicitarias comprendan el impacto de esos límites para los informes a nivel del evento.
  • Los informes a nivel del evento asociados con eventos de activador falsos no tendrán trigger_debug_key. Esto permite que las plataformas de tecnología publicitaria comprendan mejor cómo se aplica el ruido en la API.
• Para informes agregables:
  • Se admitirá un nuevo campo debug_cleartext_payload que contiene la carga útil desencriptada, solo si se configuran source_debug_key y trigger_debug_key.

Informes de depuración detallados

Los informes de depuración detallados permiten a los desarrolladores supervisar determinadas fallas en la fuente de atribución o activar registros. Estos informes de depuración se envían con un retraso limitado después de la fuente de atribución o se activan registros en unextremo well-known/attribution-reporting/debug/verbose.

Cada informe detallado contiene los siguientes campos:

• Tipo: Es la razón por la que se generó el informe. Consulta la lista completa de tipos de informes detallados.
  • En general, existen informes detallados de fuentes y de activadores.
  • Los informes detallados de fuente requieren que el ID de publicidad esté disponible para la app del publicador, y los informes de activadores detallados requieren que el ID de publicidad esté disponible para la app del anunciante.
  • Los informes detallados del activador (excepto trigger-no-matching-source) pueden incluir la source_debug_key de forma opcional solo si el ID de publicidad también está disponible para la app del publicador.
• Cuerpo: Es el cuerpo del informe, según su tipo.

Las plataformas de tecnología publicitaria deben habilitar la recepción de informes de depuración detallados a través de un nuevo campo de diccionario debug_reporting en los encabezados Attribution-Reporting-Register_Source y Attribution-Reporting-Register-Trigger.

• Los informes detallados de fuente solo requieren la habilitación en el encabezado de registro de la fuente.
• Los informes de depuración de activadores requieren la habilitación solo en el encabezado de registro del activador.

Cómo usar los informes de depuración

Si se realizó una conversión (según tu sistema de medición existente) y se recibió un informe de depuración para esa conversión, significa que el activador se registró correctamente.

Para cada informe de atribución de depuración, verifica si recibes un informe de atribución regular que coincida con las dos claves de depuración.

La falta de coincidencia puede deberse a varios motivos.

Funciona según lo previsto:

• Comportamientos de la API que preserva la privacidad:
  • Un usuario alcanza el límite de frecuencia de informes, lo que provoca que no se envíen todos los informes posteriores en el período, o se quita una fuente debido al límite de destino pendiente.
  • Para los informes a nivel de evento: el informe está sujeto a una respuesta aleatoria (ruido) y se suprime, o puedes recibir un informe aleatorio.
  • Para los informes a nivel del evento: se alcanzó el límite de tres informes (para los clics) o un informe (para las vistas), y los informes posteriores no tienen una prioridad explícita establecida, o bien una prioridad que es inferior a los informes existentes.
  • Se excedió el límite de contribuciones para los informes agregables.
• Lógica empresarial definida por tecnología publicitaria:
  • Un activador se filtra a través de filtros o reglas de prioridad.
• Demoras o interacciones con la disponibilidad de la red (p. ej., el usuario apaga su dispositivo durante un período prolongado)

Causas no deseadas:

• Problemas de implementación:
  • El encabezado de fuente está mal configurado.
  • El encabezado del activador está mal configurado.
  • Otros problemas de configuración.
• Problemas con el dispositivo o la red:
  • Errores debido a condiciones de red.
  • La respuesta de registro de fuente o activador no llega al cliente.
  • Error de la API.

Consideraciones futuras y preguntas abiertas

Actualmente, estamos trabajando en la API de informes de atribución. También estamos explorando las posibles funciones futuras, como modelos de atribución que no sean de último clic y casos de uso de medición multidispositivo.

Además, nos gustaría recibir comentarios de la comunidad sobre algunos problemas:

1. ¿Hay algún caso de uso en el que quieras que la API envíe informes para la instalación verificada? Estos informes se tomarían en cuenta para los límites de frecuencia respectivos de las plataformas de tecnología publicitaria.
2. ¿Prevees alguna dificultad para pasar el InputEvent de la app a la tecnología publicitaria para el registro de fuentes?
3. ¿Tienes casos de uso de atribución especiales para las apps cargadas con anterioridad o las apps reinstaladas?