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

Informes de atribución

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 informes de atribución 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 de 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 informes de atribución funciona de la siguiente manera, que se describe en detalle en las secciones posteriores de este documento:

  1. La plataforma de tecnología de anuncios completa un proceso de inscripción para usar la API de informes de atribución.
  2. La plataforma de tecnología de anuncios registra las fuentes de atribución (es decir, las vistas o los clics en el anuncio) con la API de Informes de atribución.
  3. La plataforma de tecnología de anuncios registra los activadores (conversiones de usuarios en la app o el sitio web del anunciante) con la API de informes de atribución.
  4. La API de informes de atribución 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 de evento y agregables a plataformas de tecnología de anuncios.

Inscribe una plataforma de tecnología de anuncios

Para acceder a la API de Informes de atribución 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 de anuncios proporcionan la siguiente información:

  • Información de la empresa y de contacto
  • URL 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 registerAttributionSource(). 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 de anuncios 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 plataforma de tecnología de anuncios puede definir su propia estrategia 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.

La respuesta de metadatos de la fuente de atribución puede incluir datos adicionales en los siguientes encabezados separados:

En el siguiente fragmento, se muestra el diseño actual para los datos de origen de atribución:

Attribution-Reporting-Register-Source: {
  "source_event_id": "[64 bit unsigned integer]",
  "destination": "[eTLD+1 or app package name]",
  "expiry": "[64 bit signed integer]",
  "source_priority": "[64 bit signed integer]"
}
Attribution-Reporting-Register-Aggregate-Source: <aggregation-key-data>
Attribution-Reporting-Redirects: <Ad tech partner URLs>

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

  1. El SDK de tecnología de anuncios 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á:

    registerAttributionSource(
        Uri.parse("https://adtech.example/attribution_source?my_ad_click_id=123"),
        myClickEvent);
    
  2. La API envía una solicitud a https://adtech.example/attribution_source?my_ad_click_id=123 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 esta plataforma de tecnología de anuncios responde con encabezados que contienen lo siguiente:

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "234",
        "expiry": "60000",
        "source_priority": "5"
    }
    Attribution-Reporting-Redirects: https://adtechpartner1.example?their_ad_click_id=567,
    https://adtechpartner2.example?their_ad_click_id=890
    Attribution-Reporting-Source-Info: navigation
    
  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 tecnología de anuncios, 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 esta plataforma de tecnología de anuncios responde con encabezados que contienen lo siguiente:

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

    Ten en cuenta que las respuestas de las plataformas de tecnología de anuncios 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 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 triggerAttribution().

El método triggerAttribution() 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-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.
  • Clave de anulación de duplicación (opcional): Es un número entero de 64 bits firmado que se usa para identificar los casos en los que la misma plataforma de tecnología de anuncios registra el mismo activador varias veces para la misma fuente de atribución.

La respuesta del servidor de tecnología de anuncios puede incluir datos adicionales en los siguientes encabezados:

Varias plataformas de tecnología de anuncios pueden registrar el mismo evento de activación mediante redireccionamientos en el campo Attribution-Reporting-Redirects o varias llamadas al método triggerAttribution(). 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 plataforma de tecnología de anuncios proporcione varias respuestas para el mismo evento de activación.

En el siguiente fragmento, se muestra el diseño actual para datos de activadores:

Attribution-Reporting-Register-Event-Trigger: {
    // trigger_data returned in reports is truncated to the last 1 or 3 bits,
    // based on conversion type
    "trigger_data": "[unsigned 64-bit integer]",
    "trigger_priority": "[signed 64-bit integer]",
    "deduplication_key": "[signed 64-bit integer]"
}
Attribution-Reporting-Aggregate-Trigger-Data: <aggregation-key-data>
Attribution-Reporting-Aggregate-Values: <aggregation-value-data>
Attribution-Reporting-Redirects: <Ad tech partner URLs>

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

  1. El SDK de tecnología de anuncios 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?app_install=123"));
    
  2. La API envía una solicitud a https://adtech.example/attribution_trigger?app_install=123.

  3. El servidor HTTPS de esta plataforma de tecnología de anuncios 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
        "trigger_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 esta plataforma de tecnología de anuncios responde con encabezados que contienen lo siguiente:

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "5566",
        "trigger_priority": "3",
        "deduplication_key": "3344"
    }
    

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

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

La API de informes de atribución utiliza un algoritmo de atribución priorizado por la fuente para hacer coincidir un activador (conversión) con una fuente de atribución. En el caso de que varias plataformas de tecnología de anuncios registren una fuente de atribución, como se describe más adelante en este documento, esta atribución se realiza de forma independiente para cada plataforma de tecnología de anuncios. Para cada plataforma de tecnología de anuncios, 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.

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 plataformas de tecnología de anuncios 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).
  • Cuando registres una fuente de atribución, especifica una ventana 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).
  • La API de informes de atribución 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 plataformas de tecnología de anuncios y no se incluye en los límites de frecuencia respectivos de las plataformas.
  • 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.

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 informes de atribución web, que puede llamar a las APIs de Android para habilitar la atribución en apps y sitios web.

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 plataforma de tecnología de anuncios 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 plataformas de tecnología de anuncios registren fuentes de atribución o activadores

Es común que más de una plataforma de tecnología de anuncios reciba informes de atribución. Por lo tanto, la API permite que varias plataformas de tecnología de anuncios registren la misma fuente o activador de atribución. Una plataforma de tecnología de anuncios debe registrar fuentes de atribución y activadores para recibir notificaciones de conversión desde la API.

Fuentes de atribución

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

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

Se pueden mostrar varias URLs de plataformas de tecnología de anuncios de socios en el campo Attribution-Reporting-Redirects, y las plataformas de tecnología de anuncios de socios no pueden especificar su propio campo Attribution-Reporting-Redirects.

La API también permite diferentes plataformas de tecnología de anuncios en cada llamada a registerAttributionSource().

Activadores

Para el registro del activador, los terceros son compatibles de manera similar: las plataformas de tecnología de anuncios pueden usar el campo Attribution-Reporting-Redirects adicional o cada una puede llamar al método triggerAttribution().

Cuando un anunciante usa varias plataformas de tecnología de anuncios a fin de registrar el mismo evento de activación, 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. Si no se proporciona una clave de anulación de duplicación, los activadores duplicados se pueden informar a cada plataforma de tecnología de anuncios como únicos.

Ejemplo de atribución

En el ejemplo que se describe en esta sección, el anunciante usa dos plataformas de tecnología de anuncios 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 informes de atribución 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 registerAttributionSource() 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 registerAttributionSource() 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 triggerAttribution() 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 de 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 cada plataforma de tecnología de anuncios durante uno de los 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.

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

Límites en la cantidad de plataformas de tecnología de anuncios por fuente de atribución

Existen límites en la cantidad de plataformas de tecnología de anuncios que se pueden asociar con una sola fuente de atribución. Estos límites se aplican después de que se tienen en cuenta las prioridades relacionadas con 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 informes de atribución prepara y envía informes agregables se muestra en la Figura 1:

  1. El dispositivo envía a los informes de agregación encriptados a la plataforma de tecnología de anuncios.
  2. La plataforma de tecnología de anuncios envía un lote de informes que se pueden agregar al servicio de agregación para la agregación.
  3. El servicio de agregación lee un lote de informes agregables, los desencripta y los agrega.
  4. Los agregados finales se envían de vuelta a la plataforma de tecnología de anuncios.
Figura 1: Proceso que la API de informes de atribución 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 plataformas de tecnología de anuncios.
  • 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 tecnología de anuncios 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 de anuncios 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 tecnología de anuncios 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 tecnología de anuncios puede registrar una lista de claves de agregación 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.
  • Desplazamiento de clave: Es un valor entero del índice de desplazamiento para combinar esta pieza de clave con la pieza del activador.

La clave final es una combinación de esta pieza y las del activador, mediante el uso del campo desplazamiento de clave para concatenar las strings de bits. Las claves finales están restringidas a un máximo de 128 bits; las claves más largas se truncan.

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

  • Recuentos totales de conversiones a nivel de campaña
  • Valores agregados de compra a nivel geográfico
Attribution-Reporting-Register-Aggregate-Source:
[{
  // Generates a "101011001" key prefix named "campaignCounts".
  "source_event_id": "campaignCounts",
  "key_piece": "101011001", // User saw ad from campaign 345 (out of 511).
  "key_offset": 0 // The first part of the key
                  // when combined with trigger-side keys.
},
{
  // Generates a "101" key prefix named "geoValue".
  "source_event_id": "geoValue",
  // Source-side geo region = 5 (US) but pad with 0s since the shop operates in
  // ~100 separate countries.
  "key_piece": "0000101",
  "key_offset": 0 // The first part of the key
                  // when combined with trigger-side keys.
}]

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 plataforma de tecnología de anuncios debe responder con el encabezado HTTP Attribution-Reporting-Aggregate-Trigger-Data y debe incluir los siguientes campos para cada clave agregada en la lista:

  • Pieza de clave: Es un valor de string de bits para la clave.
  • Desplazamiento de clave: Es un valor entero que se usa como índice de desplazamiento cuando se combina la pieza clave de la fuente de atribución con la pieza clave del activador.
  • 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.

En el siguiente fragmento, se continúa con el ejemplo de registro de datos de fuente agregados en informes agregables:

Attribution-Reporting-Aggregate-Trigger-Data:
[
  // Each dictionary independently adds pieces to multiple source keys.
  {
    "key_piece": "10",// Conversion type purchase = 2
    // Combine key piece at offset index 9 with attribution source key piece.
    "key_offset": 9,
    // Apply this suffix to:
    "source_keys": ["campaignCounts"]
  },
  {
    "key_piece": "10101",// Purchase category shirts = 21
    // Combine key piece at offset index 9 with attribution source key piece.
    "key_offset": 7,
    // Apply this suffix to:
    "source_keys": ["geoValue" ]
  }
]

El segundo encabezado se usa para registrar una lista de valores que deben contribuir a cada clave. La plataforma de tecnología de anuncios debe responder con el encabezado HTTP Attribution-Reporting-Aggregate-Values.

Cada activador puede realizar varias contribuciones a los informes agregables. El importe total de las contribuciones a cualquier fuente de atribución 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 de atribución determinada. 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 privacidad 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:

Attribution-Reporting-Aggregate-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 recuentos agregados:

[
  // campaignCounts:
  {
    // The attribution source key piece "101011001" (offset 0)
    // is concatenated with  "10" (offset 9) trigger key piece to form
    // the final key "10101100110" = 1382.
    "key": "1382",
    "value": 32768
  },
  // geoValue:
  {
    // The attribution source key piece "0000101" (offset 0)
    // is concatenated with  "10101" (offset 7) trigger key piece to form
    // the final key "000010110101" = 181.
    "key": "181",
    "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}) \]

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 plataformas de tecnología de anuncios registren fuentes de atribución y activadores para habilitar la medición de terceros. Con nuestra propuesta actual, solo la plataforma de tecnología de anuncios que origina las llamadas a la API puede especificar una lista de plataformas de tecnología de anuncios de terceros. Para simplificar el diseño de nuestra API, podríamos permitir que las plataformas de tecnología de anuncios usen redireccionamientos de encadenamiento especificando solo la siguiente plataforma de tecnología de anuncios.
  2. Para habilitar la medición de app a la Web, en la que el activador puede ocurrir en la app o en la Web, las plataformas de tecnología de anuncios deben proporcionar el mismo campo destino en la fuente de atribución y activar el registro. Estamos evaluando si es razonable usar el eTLD+1 web, incluso si el activador ocurrió en la app.
  3. Para evitar informes de activadores duplicados, en el caso de que una plataforma de tecnología de anuncios registre el mismo activador varias veces, te recomendamos que uses una clave de anulación de duplicación. Estamos evaluando si las apps pueden pasar esta clave de anulación de duplicación a todas las plataformas de tecnología de anuncios, incluidas las plataformas de terceros.
  4. 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.
  5. Estamos evaluando el caso en el que existen varias fuentes de atribución, algunas basadas en la Web y otras basadas en apps, que conducen al activador, y si existe alguna atribución especial que deba ocurrir.
  6. Cuando se registra una fuente de atribución, las plataformas de tecnología de anuncios solo pueden especificar un destino de app. Nos preguntamos si funciona para tus casos de uso.
  7. 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 tecnología de anuncios.