Ya está disponible Privacy Sandbox en la Vista previa para desarrolladores. Descubre cómo comenzar y continúa enviando comentarios.

Informes de atribución

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Enviar comentarios

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 informes de atribución 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 las secciones posteriores de este documento describen con más detalle:

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 AdTech completa un proceso de inscripción para usar la API de Attribution Reporting.
  2. La AdTech registra las fuentes de atribución (clics en los anuncios o vistas) con la API de Attribution Reporting.
  3. La AdTech 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 mediante informes de nivel del evento y agregables a plataformas de AdTech.

Inscribe una AdTech

Para acceder a la API de Attribution Reporting y garantizar que los mecanismos de privacidad funcionen según lo previsto, todas las plataformas de tecnología de anuncios (incluida la de Google) deben completar un proceso de inscripción simple. Los detalles de este proceso aún están en desarrollo, por lo que tus comentarios son más que bienvenidos.

El proceso de inscripción garantiza que las plataformas de tecnología de anuncios no se dupliquen innecesariamente para obtener más información sobre la actividad del usuario en el sitio y la app. Por ejemplo, la API de informes de atribución limita la cantidad de información y el seguimiento que una plataforma de tecnología de anuncios puede tener sobre una fuente de atribución y un activador determinados. Encontrarás más detalles sobre estos límites en la sección Cómo ver los datos de medición en los Informes de atribución más adelante.

Las empresas pueden registrarse varias veces si hay una necesidad empresarial legítima (como operar varias líneas de productos independientes) y no combinan datos de sus múltiples inscripciones para evitar restricciones de privacidad.

Durante el proceso de inscripción, las plataformas de tecnología publicitaria proporcionan la siguiente información:

  • Información de la empresa y de contacto
  • URLs usadas para registrar fuentes y activadores de atribución
  • URLs de notificación de conversión usadas para recibir informes a nivel del evento y agregables
  • Casos de uso de la API de Informes de atribución

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

La API de atribución de informes hace referencia a los clics y las vistas de anuncios como fuentes de atribución. Para registrar un clic en el anuncio o una vista del 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 AdTech 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 de evento de la fuente: Es una DOMString que codifica un número entero sin firma de 64 bits. Este valor representa los datos a nivel de evento asociados con esta fuente de atribución (clic o vista del anuncio).
  • Destino: Origen en cuyo eTLD+1 o nombre de paquete de la app se produce en el evento del activador.
  • Vencimiento (opcional): Vencimiento, en segundos, en que la fuente debe borrarse del dispositivo. El valor predeterminado es de 30 días, con un valor mínimo de 2 días y uno máximo de 30 días. Se redondea al día más cercano.
  • Prioridad de la fuente (opcional): Es un número entero de 64 bits firmado que se usa para seleccionar con qué fuente de atribución se debe asociar un activador determinado, en caso de que se puedan asociar varias.

    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 AdTech 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.

    Un valor más alto indica una prioridad más alta.

  • Ventanas de atribución de instalación y posteriores a la instalación (opcional): Se usan a fin de determinar la atribución para los eventos posteriores a la instalación, que se describen más adelante en este documento.

  • 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 AdTech 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 AdTech llama a la API a fin de iniciar el registro de la fuente de atribución y especifica un URI para la API que se llamará:

    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 AdTech 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-Redirects: https://adtechpartner1.example?their_ad_click_id=567,
    https://adtechpartner2.example?their_ad_click_id=890
    
  4. La API envía una solicitud a cada URL especificada en Attribution-Reporting-Redirects. En este ejemplo, se especifican dos URL de socios de AdTech, 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 AdTech 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"
    }
    

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 un activador (conversión)

Las plataformas de AdTech 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 AdTech debe incluir un encabezado HTTP llamado Attribution-Reporting-Register-Event-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).
  • Prioridad del activador (opcional): Es un número entero de 64 bits firmado que representa la prioridad de este activador en comparación con otros activadores para la misma fuente de atribución. Para obtener más detalles sobre cómo la prioridad afecta los informes, consulta la sección Ejemplo de priorización.
  • Clave de anulación de duplicación (opcional): Es un número entero de 64 bits firmado que se usa a fin de identificar los casos en los que la misma plataforma de AdTech registra el mismo activador varias veces para la misma fuente de atribución.
  • 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): Una lista de cantidades de valor que contribuyen a cada clave.
  • Filtro de informe de atribución (opcional): Se usa 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 AdTech puede incluir datos adicionales en el encabezado Redireccionamientos de informe de atribución. Los datos contienen URLs de redireccionamiento, que permiten que varias AdTech registren una solicitud.

Varias AdTech pueden registrar el mismo evento de activación mediante redireccionamientos en el campo Attribution-Reporting-Redirects o varias llamadas al método registerTrigger(). Te recomendamos usar el campo clave de anulación de duplicación para evitar incluir activadores duplicados en los informes en caso de que la misma AdTech 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 AdTech llama a la API para iniciar el registro del activador, con un URI con el que se inscribieron:

    triggerAttribution(
        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 AdTech responde con encabezados que contienen lo siguiente:

    Attribution-Reporting-Register-Event-Trigger: {
        "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-Redirects: https://adtechpartner.example?app_install=567
    
  4. La API envía una solicitud a cada URL especificada en Attribution-Reporting-Redirects. 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 AdTech responde con encabezados que contienen lo siguiente:

    Attribution-Reporting-Register-Event-Trigger: {
        "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 desee asegurarse 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 AdTech registren una fuente de atribución, como se describe más adelante en este documento, esta atribución ocurre de forma independiente para cada AdTech. En cada AdTech, 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 AdTech 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.

Las plataformas de AdTech 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 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, rango aceptado de 2 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 AdTech 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.

    Estamos buscando formas de admitir casos de uso en los que los usuarios desinstalen y vuelvan a instalar la app.

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 AdTech pueden usar la atribución posterior a la instalación. Supongamos que la misma red de AdTech 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 Primer activador registrado por la AdTech. En este ejemplo, se representa un primer acceso, pero puede ser 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 Segundo activador registrado por la AdTech. En este ejemplo, se 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 especifica install_attribution_window, no se aplicará la atribución posterior a la instalación.
  • Las instalaciones verificadas no se registran mediante plataformas de AdTech y no se envían en los informes. No se descuentan de los límites de frecuencia de una AdTech. 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 AdTech pueden registrar cualquier tipo de activador. En otras palabras, no es necesario que el primer activador sea un primer acceso.
  • Si se registran más activadores después de que vence post_install_exclusivity_window, el clic 1 es apto para la atribución, si suponemos que 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, de todos modos, se atribuirán los activadores de "primer acceso" y los posteriores a la instalación. 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 AdTech podría recibir 2 ventanas de informes diferentes.

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.
  • De la Web a la 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 la Zona de pruebas de privacidad 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 AdTech y las apps a fin de 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 este documento.

Existen límites sobre la cantidad de activadores que se pueden atribuir a una sola fuente de atribución. Para obtener más detalles, lee la sección sobre cómo ver los datos de medición de informes de atribución que se encuentra más adelante en este documento. En los casos en los que haya 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 AdTech 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 determinada ventana de informe.

Permite que varias AdTech registren fuentes de atribución o activadores

Es común que más de una tecnología de anuncios reciba informes de atribución, por lo general, para anular la duplicación en varias redes. Por lo tanto, la API permite que varias AdTech registren la misma fuente de atribución o activador. Una AdTech 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 AdTech 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 AdTech que llama al método registerSource() puede proporcionar un campo Attribution-Reporting-Redirects adicional en su respuesta, que representa el conjunto de URL de redireccionamiento de la AdTech de socios.
  2. Luego, la API llama a las URLs de redireccionamiento para que la AdTech de socios pueda registrar la fuente de atribución.

Se pueden enumerar varias URLs de AdTech de socios en el campo Attribution-Reporting-Redirects, y estas últimas no pueden especificar su propio campo Attribution-Reporting-Redirects.

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

Activadores

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

Cuando un anunciante usa varias AdTech 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 AdTech. Por ejemplo, una AdTech 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 AdTech. Si no se proporciona una clave de anulación de duplicación, los activadores duplicados se pueden informar a cada AdTech como únicos.

Administra activadores duplicados

Una tecnología de anuncios 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 AdTech. Por ejemplo, la app del anunciante usa dos socios de medición: MMP n.º 1 y MMP n.º 2. Ambas MMP redireccionan a la AdTech n.º 3. Cuando se activa un activador, ambos MMP lo registran con la API de Attribution Reporting. Luego, la AdTech n.º 2 recibe dos redireccionamientos independientes, uno de MMP n.º 1 y otro de MMP n.º 2, para el mismo activador.

En estos casos, existen varias formas de suprimir los informes a nivel de evento en los activadores duplicados para que sea menos probable que excedan los límites de frecuencia aplicados a los informes a nivel de 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 AdTech 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 AdTech o SDK. Esas AdTech o SDK luego pasan la clave de anulación de duplicación a los redireccionamientos mediante un parámetro en las URLs especificadas en Attribution-Reporting-Redirects.

Las AdTech puede 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 AdTech pueden especificar el deduplication_key cuando registran activadores duplicados.

Si una AdTech 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 AdTech coinciden en los tipos de activadores por anunciante

En situaciones en las que las AdTech 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 AdTech que miden conversiones para un anunciante determinado deben trabajar en conjunto a fin de definir diferentes tipos de activadores para cada anunciante.

Las AdTech que inician la llamada de registro del activador (por ejemplo, los SDK) incluyen un parámetro en las URLs especificadas en Attribution-Reporting-Redirects, 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 AdTech pueden enviar un subconjunto de estos activadores duplicados a los informes a nivel del evento. Las AdTech 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 (Adtech A y Adtech B) y un socio de medición (MMP).

Para comenzar, Adtech A, Adtech B y MMP deben completar cada inscripción para usar la API de informes de atribució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 Adtech A, Adtech B y MMP:

Día 1: el usuario hace clic en un anuncio publicado por Adtech A

Adtech 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 Adtech A.

Adtech A también incluye el URI de MMP en el encabezado Attribution-Reporting-Redirects. 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 Adtech B

Adtech 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 Adtech B.

Al igual que Adtech A, Adtech B también incluyó el URI de MMP en el encabezado Attribution-Reporting-Redirects. 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 Adtech A

La API responde de la misma manera que lo hizo el Día 1, salvo que se registró una vista para Adtech 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 URI de Adtech A y Adtech B en el encabezado Attribution-Reporting-Redirects. La API envía solicitudes a los servidores de Adtech A y Adtech B, y la conversión se registra según los metadatos de las respuestas del servidor.

En la Figura 1, se ilustra el proceso que se describe en la lista anterior:

Figura 1. Ejemplo de cómo la API de informes de atribución responde a una serie de acciones del usuario.

La atribución funciona de la siguiente manera:

  • Adtech 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.
  • Adtech 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.

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

La API de informes de atribución habilita los siguientes tipos de informes, que se describen en detalle más adelante en este documento:

  • Los informes de nivel de evento asocian una fuente de atribución en particular (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 de 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 AdTech durante uno de los períodos para enviar informes, que se describen en más detalle más adelante en este documento.

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

Límites en la cantidad de AdTech por fuente de atribución

Hay límites en la cantidad de plataformas de AdTech que se pueden asociar con una única fuente de atribución, con una propuesta actual de lo siguiente:

  • 100 AdTech con fuentes de atribución por {source app, destination app, 30 days}
  • 10 AdTech con activadores atribuidos por {source app, destination app, 30 days}

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 de inactividad y de frecuencia

A fin de limitar la cantidad de filtraciones de identidad de un usuario entre un par (fuente, destino), 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 AdTech a 100 activadores atribuidos por {source app, destination app, 30 days}.

Cantidad de destinos únicos

La API limita la cantidad de destinos que una AdTech puede intentar medir. Cuanto más bajo sea el límite, más difícil será para una plataforma de AdTech usar la API a fin de 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 AdTech a 100 destinos distintos por 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 completos de metadatos.

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 $ p $ de que la fuente de atribución se registre con normalidad y con la probabilidad $ 1-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. Actualmente, estamos trabajando en los parámetros de ruido exactos, por lo que están sujetos a cambios en función de los comentarios que recibamos.

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-2 activadores para fuentes de atribución de anuncios de vistas
  • 3 activadores para las fuentes de atribución de anuncios de clics

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

Períodos específicos para enviar informes

Los informes de 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 inferior a 2 días ni superior a 30 días.

Los informes de las fuentes de atribución de clics en el anuncio no se pueden configurar y se envían antes de que la fuente venza, en un momento específico relacionado con la fecha en 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 de 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 inferior a 2 días ni superior a 30 días.

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 de nivel de 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 la Figura 2:

  1. El dispositivo envía informes encriptados a AdTech. En un entorno de producción, las AdTech no pueden usar estos informes directamente.
  2. La AdTech envía un lote de informes que se pueden agregar al servicio de agregación para la 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 AdTech en un informe de resumen
Figura 2: 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:

  • Fuente: Es el nombre del paquete de la app o la URL web de eTLD+1 donde se publicó el anuncio.
  • 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 este documento:

  • El servicio de agregación es el único que se espera que implementen las AdTech.
  • Los servicios de administración de claves y presupuesto de privacidad están a cargo de partes de confianza denominadas verificadores. Estos verificadores certifican que el código que ejecuta el servicio de agregación es que proporciona Google a nivel público y que todos los usuarios del servicio de agregación tienen aplicados los mismos servicios de clave y presupuesto.
Servicio de agregación

Las plataformas de AdTech 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 AdTech con las claves de desencriptación correctas para sus datos de activador.

Servicio de presupuesto de privacidad

Este servicio realiza un seguimiento de la frecuencia con la que el servicio de agregación de una plataforma de AdTech accede a un activador específico (que puede contener varias claves de agregación) y limita el acceso a la cantidad adecuada de desencriptaciones. Se permite una desencriptación por activador.

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 plataforma de AdTech puede registrar una lista de claves de agregación, con el nombre de histogram_contributions, si responde con un encabezado HTTP nuevo, Attribution-Reporting-Register-Aggregate-Source, con los siguientes campos para cada clave de agregación en la lista:

  • ID del evento de fuente: Es una string para el nombre de la clave. Se usa como clave de unión para combinar con claves del lado del activador a fin de formar la clave final.
  • Pieza de clave: Es un valor de string 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 strings hexadecimales en el archivo JSON deben limitarse a 32 dígitos como máximo.

En el siguiente ejemplo, una AdTech 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 adtech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Aggregatable-Source:
[{
// Generates a "0x159" key piece named (low order bits of the key) for the key
// named "campaignCounts".
  "id": "campaignCounts",
// User saw an ad from campaign 345 (out of 511).
  "key_piece": "0x159",
},
{
// Generates a "0x5" key piece (low order bits of the key) for the key named "geoValue"
  "id": "geoValue",
// Source-side geo region = 5 (US), out of a possible ~100 regions.
  "key_piece": "0x5",
}]

Registra el activador agregable

El registro del activador incluye dos encabezados adicionales.

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

  • Pieza de clave: Es un valor de string de bits para la clave.
  • Claves de fuente: Es una lista de strings 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 encabezado se usa para registrar una lista de valores que deben contribuir a cada clave. La AdTech debería responder con el encabezado HTTP Attribution-Reporting-Register-Aggregatable-Values.

El segundo encabezado 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}] $. La plataforma de AdTech debe responder con el encabezado HTTP Attribution-Reporting-Register-Aggregatable-Values.

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-Event-Trigger object appears
// when an adtech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-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.
Attribution-Reporting-Register-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 los siguientes contribuciones de histogramas:

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

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}) \]

Prioridad de registro, atribución y ejemplos de informes

En este ejemplo, se muestra un conjunto de interacciones del usuario y cómo la AdTech 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 AdTech 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 AdTech 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 AdTech 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 AdTech 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 AdTech en cuanto se procesan, unas horas después de que se registran los activadores.

    Como AdTech, 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 AdTech 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.

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. Planeamos permitir que varias AdTech registren fuentes de atribución y activadores para habilitar la medición de terceros. Con nuestra propuesta actual, solo la plataforma de AdTech que origina las llamadas a la API puede especificar una lista de plataformas de AdTech de terceros. Para simplificar el diseño de nuestra API, podríamos permitir que las AdTech adopten redireccionamientos de encadenamiento especificando solo la próxima AdTech.
  2. A fin de evitar duplicar los informes a nivel del evento y de agregación para el mismo activador, en el caso de que una plataforma de AdTech registre el mismo activador varias veces, te recomendamos que uses una clave de anulación de duplicación. Esto podría suceder si una plataforma de AdTech inicia una llamada a la API para registrar el activador y también se incluye en la ruta de redireccionamiento de otra AdTech que registra ese mismo activador. Las apps tendrían que pasar esta clave de anulación de duplicación a todas las AdTech que estén usando, o esas AdTech tendrían que alinearse con la nomenclatura del tipo de conversión. Nos preguntamos si es factible.
  3. Para el registro de la fuente de atribución, estamos evaluando si el diseño propuesto para terceros y redireccionamientos es posible, incluso para redes de atribución automática. En particular, nos preguntamos si necesitas transparencia para ver a todos en la ruta de redireccionamiento.
  4. Al registrar una fuente de atribución, las AdTech pueden especificar solo un destino de app. Nos preguntamos si funciona para tus casos de uso.
  5. Cuando registras una fuente de atribución, puedes establecer un vencimiento, que es el equivalente de una ventana de visualización. El vencimiento mínimo aceptado es de 2 días a partir de la fecha en que se produjo la fuente de atribución. Nos preguntamos si hay casos de uso en los que se interrumpe este flujo de trabajo.
  6. Nos preguntamos si hay casos de uso en los que te gustaría 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 AdTech.