Informes de atribución: medición web y de aplicación cruzada

Enviar comentarios

Actualizaciones recientes

Como se describe en la propuesta de diseño de la API de Attribution Reporting, esta API permite atribuir las siguientes rutas de acceso de los activadores en un solo dispositivo Android:

  • App-to-app: El usuario ve un anuncio en una app y, luego, genera una conversión en esa app o en otra instalada.
  • App-to-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-to-app: El usuario ve un anuncio en un navegador de app o dispositivo móvil y, luego, genera una conversión en una app.
  • Web-to-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.

Aquí, "Web" hace referencia al contenido web que se muestra en una app. Este contenido se puede mostrar en el contexto de una app para navegador para dispositivos móviles o como sitios web incorporados en apps que no son de navegador.

Las rutas de activación anteriores se traducen en los siguientes requisitos:

  • Para tecnologías publicitarias: Actualizaciones en los informes y las llamadas a la API para habilitar las rutas de la app a la Web
  • Para apps y navegadores: La capacidad de pasar el registro de las fuentes de atribución web y los activadores web a Android

En este documento, se explica el modo en que se extiende la API de Attribution Reporting para admitir las rutas de activación de la app a Web, de Web a la app y de Web a la Web. También se describen los cambios que deben hacer las plataformas de tecnología publicitaria y las apps para cumplir con los requisitos de compatibilidad de estas rutas de activación.

Obtén acceso a las APIs de Attribution Reporting

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

Una vez que finalice el proceso de inscripción, la API descartará el registro si se recibe una llamada de registro.

Durante la inscripción, las plataformas de tecnología publicitaria deben asegurarse de inscribirse con todas las URLs de servidor que podrían usar en la app y en la Web para registrar fuentes y activadores de atribución. Se admiten varias URLs de registro de servidor, pero solo se admite un origen de informes. Este origen de informe se deriva del dominio de una de las URLs de registro del servidor.

Cambios para las plataformas de tecnología publicitaria

Cambios en el registro y la atribución

Actualmente, cuando registras una fuente de atribución, las plataformas de tecnología publicitaria especifican un campo de destino que es el nombre del paquete de la app en el que se produce el evento activador. Para habilitar la medición de app a web, planeamos admitir un campo de destino de la app (nombre del paquete de la app) y un campo de destino web (eTLD+1).

Cuando se registran fuentes o activadores de atribución web, la API no admite redireccionamientos porque cada app que aloja contenido web podría tener su propio modelo de permisos. Cada app es responsable de seguir los redireccionamientos (si son compatibles) y de llamar a las APIs de Web Context para cada salto de redireccionamiento.

Además, esta integración permite a las plataformas de tecnología publicitaria usar la lógica de atribución específica de la app en fuentes de atribución web. Por ejemplo, ahora puedes especificar ventanas de atribución posteriores a la instalación en una fuente de atribución web.

Recibe informes web y de apps

La API de Attribution Reporting de Android puede enviar informes de conversiones web y de apps. Si las plataformas de tecnología publicitaria no desean alinear datos de activación ni pares clave-valor de agregación en plataformas web y de apps, pueden diferenciar entre una conversión web y una de aplicación:

  • En el caso de los informes a nivel del evento, admitimos un campo de destino que especifica si la activación sucedió en la Web (el destino es un eTLD+1) o en la app (el destino es un nombre del paquete de la aplicación).
  • En el caso de los informes agregables, el destino se envía en texto simple.

Implicaciones de la medición de web a web

Las apps eligen cuándo pasar el registro a la API de Attribution Reporting. Existen varias consideraciones aquí:

  • ¿La API de Attribution Reporting está disponible en ese dispositivo? Expondremos un nuevo indicador a las apps que muestra si la API de Attribution Reporting está disponible en ese dispositivo. Consulta la sección de cambios de la aplicación para obtener más detalles sobre cómo las apps pueden pasar el registro a la API de Attribution Reporting.
  • ¿Qué parte de las fuentes de atribución y los activadores se deben pasar a la API? Esta será una decisión que tomará cada app, o la plataforma de tecnología publicitaria, si la app lo permite. Si la app tiene su propia solución de medición, te recomendamos que la uses. En última instancia, pasar todos los registros de origen y activadores a la API de Attribution Reporting de Android (cuando esté disponible) habilita la atribución más precisa en la app y la Web.

En el siguiente ejemplo, se muestra cómo pueden funcionar las apps de navegador con la API Attribution Reporting para proporcionar una medición precisa cuando el usuario hace clic en un anuncio tanto en una app de navegador como en una que no lo es:

Ejemplos de conversiones y clics de los usuarios en un período de 3 días
Ejemplo de registro de fuente y activador en un navegador y una app
  • El primer día, el usuario hace clic en un anuncio en la app del navegador.
    • La app para navegadores puede elegir usar su propia solución de medición o pasar el registro del clic en el anuncio web a la API de Attribution Reporting.
  • El segundo día, el usuario hace clic en un anuncio de una app sin navegador.
    • El clic se registra como una fuente de atribución en la API. La app del navegador no tiene visibilidad de este clic porque el evento ocurrió dentro de una app diferente.
  • El día 3, el usuario genera una conversión en la app de navegador.
    • Si la app de navegador registra el clic y la conversión con su propia solución de medición y pasa esa información a la API de Attribution Reporting, es poco probable que una plataforma de tecnología publicitaria pueda anular la duplicación de informes de conversión en todas las soluciones de medición. Además, una plataforma de tecnología publicitaria podría consumir los límites de frecuencia de las apps de navegador y los de la API de Attribution Reporting. Por lo tanto, recomendamos que las apps pasen todos los eventos y las conversiones de los anuncios para que se registren en la API, cuando esta esté disponible.

Registra la fuente de atribución y de activador desde WebView

En los casos en que la app use WebView para mostrar contenido web en lugar de un anuncio nativo de Android, la app podrá solicitar unirse a la lista de entidades permitidas de registerWebSource() y proporcionar el origen de nivel superior del sitio que se asociará con la fuente de atribución, en lugar del nombre del paquete de la app

Al igual que los navegadores, WebView admite registerWebTrigger() para los registros de activadores, que asocia el activador con el origen de nivel superior. No hay compatibilidad con WebView para registrar un activador de la app. Comunícate con nosotros si tienes un caso de uso relacionado. Para obtener la lista completa de combinaciones compatibles con WebView, consulta Fuente de atribución y registro de activadores desde WebView.

A diferencia de los navegadores, WebView solo admite el registro con el SO dentro del encabezado Attribution-Reporting-Eligible si la API de Attribution Reporting de Android está disponible. Si la API de Attribution Reporting de Android no está disponible, WebView no establece un encabezado Attribution-Reporting-Eligible ni se realizan registros.

Para registrar una fuente o un activador de atribución con el SO, sigue estos pasos:

  • Las tecnologías publicitarias deben responder a registros de origen con el encabezado Attribution-Reporting-Register-OS-Source, que inicia una llamada a la API secundaria desde WebView a registerSource() o registerWebSource().
  • La tecnología publicitaria también puede responder a registros del activador con el encabezado Attribution-Reporting-Register-OS-Trigger, que inicia una llamada a la API secundaria desde WebView a registerWebTrigger() o registerTrigger().

Ten en cuenta que si la respuesta no incluye los encabezados anteriores, o si también incluye los encabezados Attribution-Reporting-Register-Source/Attribution-Reporting-Register-Trigger, aunque la Web no sea compatible, fallará todo el registro.

Para obtener detalles sobre si WebView usará registerSource()/registerWebSource() y registerTrigger() / registerWebTrigger() (y cómo cambiar este comportamiento), consulta Fuente de atribución y registro de activadores desde WebView.

Informes de depuración de transición

La API de Attribution Reporting admite una funcionalidad opcional llamada informes de depuración de transición, que permite que las plataformas de tecnología publicitaria obtengan más información sobre los informes de atribución siempre que haya un ID de publicidad disponible. Existen dos tipos de informes de depuración: informes de atribución correcta e informes detallados. Estos informes son compatibles con la atribución entre apps y la Web, y ambos tipos de informes contienen la misma información. La única diferencia es con los permisos que se bloquean cuando se envían informes de depuración.

Para las atribuciones de Web a Web que se producen dentro de una sola app (por ejemplo, dentro de la misma app del navegador), los informes detallados y de atribución correcta solo están disponibles cuando las cookies de terceros están disponibles, y no dependen de la disponibilidad del ID de publicidad.

En el caso de las atribuciones de app a Web, de Web a app y de Web a Web, los informes detallados y de atribución correcta están disponibles si el ID del anuncio está disponible en la app, y la plataforma de tecnología publicitaria puede pasar el mismo ID del anuncio (correcto) a la Web. A continuación, se muestra un ejemplo de app a Web en el que la fuente ocurre en una app de publicador, pero el activador se produce en el sitio de un anunciante dentro de una app de navegador.

Si deseas habilitar un informe de depuración de atribución correcta de app a Web, se deben cumplir las siguientes tres condiciones:

  • El usuario no debe inhabilitar la personalización mediante el ID de publicidad.
  • La app del publicador debe tener los permisos de ID del anuncio declarados.
  • La plataforma de tecnología publicitaria debe pasar el valor del ID del anuncio en el registro del activador (desde un contexto web).

Sigue estos pasos para habilitar los informes detallados de depuración de app a Web:

  • Los informes detallados de origen solo dependen de los permisos del publicador. Para que se envíen los informes detallados de fuente, el usuario no debe inhabilitar la personalización del ID del anuncio, y la app del publicador debe tener declarados los permisos correspondientes.
  • Los informes detallados de activadores dependen solo de los permisos del activador (en este ejemplo, la Web). Las cookies de terceros deben estar disponibles en el navegador para que se envíen los informes detallados.
  • En los informes detallados de activadores que pueden incluir un source_debug_key de forma opcional, se incluye source_debug_key si el ID de publicidad está disponible para la app del publicador.

Ten en cuenta que, en todos los casos, la plataforma de tecnología publicitaria aún debe habilitar la recepción de informes de depuración detallados a través del campo del diccionario debug_reporting en los encabezados de registro de la fuente y del activador.

Cambios para apps

Permitiremos la atribución en todas las plataformas web y de apps. Para ello, permitiremos que las apps pasen el registro de las fuentes de atribución web y los activadores web a la API de Attribution Reporting en Android mediante un nuevo conjunto de llamadas a la API de contexto web.

Después de completar los pasos de registro en las siguientes secciones, las fuentes y los activadores de atribución web y de la app se almacenan en el dispositivo, y la API de Attribution Reporting puede realizar una atribución prioritaria de fuente y del último punto de acceso en toda la app y las plataformas web.

Consulta Privacy Sandbox para la propuesta de la Web y consulta un ejemplo de cómo los navegadores pueden integrarse con la API de Attribution Reporting de Android para habilitar la medición entre apps y la Web. En la propuesta, el navegador agregará los siguientes encabezados de solicitud:

  • Attribution-Reporting-Eligible transmite si la compatibilidad a nivel del SO para la atribución está disponible. En este caso, el encabezado indica si la API de Attribution Reporting de Android está disponible.
  • Si está disponible, las plataformas de tecnología publicitaria pueden responder de manera opcional con Attribution-Reporting-Register-OS-Source, que inicia una llamada a la API secundaria desde la app del navegador hacia registerWebSource().
  • La tecnología publicitaria también puede responder a registros del activador con el encabezado Attribution-Reporting-Register-OS-Trigger, que inicia una llamada a la API secundaria desde la app del navegador hacia registerWebTrigger().

Registro de la fuente de atribución

Cuando se registra una fuente de atribución, las apps pueden llamar a registerWebSource(), que espera los siguientes parámetros:

  • URIs de fuente de atribución: La plataforma emite una solicitud a cada URI de esta lista para recuperar los metadatos asociados con la fuente de atribución.

    Cada URI debe acompañar a una marca booleana de depuración para indicar si las claves de depuración que proporcionan las plataformas de tecnología deben incluirse en el informe.
  • Evento de entrada: Es un objeto InputEvent (para un evento de clic) o null (para un evento de vista).
  • Origen de fuente: Es el origen en el que comenzó la fuente (sitio web del publicador).
  • Destino del SO: Es el nombre del paquete de una app donde ocurre el evento activador.
  • Destino web: Es un eTLD+1 en el que se produce el evento activador.
  • Destino verificado: Es el intent de URI de destino web o de SO que se usa para la navegación cuando el usuario hace clic.

Cuando la API realiza una solicitud al URI de la fuente de atribución, la plataforma de tecnología publicitaria debe responder con los metadatos de la fuente de atribución en un encabezado HTTP, Attribution-Reporting-Register-Source. Este encabezado usa los mismos campos que el registro de fuente de atribución de app a app, con algunos cambios:

  • La API valida los destinos que especifica la plataforma de tecnología publicitaria con los destinos especificados por la app. Si los destinos son diferentes, la API descarta el registro de fuente de atribución.

    Se espera que las apps validen destinos web antes de llamar a la API del contexto web. En el caso de los clics, las apps deben comprobar que el destino especificado coincida con el destino con el que navega el usuario.
  • La API ignora los URI de redireccionamiento proporcionados en Attribution-Reporting-Redirects. Las apps deben seguir los redireccionamientos por su cuenta y llamar a registerWebSource() para cada redireccionamiento de modo que puedan aplicar sus propias políticas de permisos según sea necesario.

Las apps deben unirse a una lista de entidades permitidas para llamar a registerWebSource(). Completa este formulario para unirte a la lista de entidades permitidas. El objetivo de la lista de entidades permitidas es mitigar las consideraciones de privacidad en torno al restablecimiento de la confianza para el contexto de la Web.

Registro de activador (conversión)

Durante el registro del activador, las apps pueden llamar a registerWebTrigger(), que espera los siguientes parámetros:

  • URI de activador: La plataforma emite una solicitud a cada URI de esta lista para recuperar los metadatos asociados con el activador.
  • Origen de destino: origen en el que ocurrió el activador (sitio web del anunciante)

Fuente de atribución y registro de activadores desde WebView

De forma predeterminada, WebView usará registerSource() y registerWebTrigger(). De esta manera, se asocian las fuentes con la app y los activadores con el origen de nivel superior de WebView cuando se activa.

Si una app requiere un comportamiento diferente (como los que alojan contenido web en una WebView), deben usar el método setAttributionRegistrationBehavior en la clase androidx.webkit.WebViewSettingsCompat. Este método especificará si WebView debe llamar a registerWebSource() o registerSource(), y registerWebTrigger() o registerTrigger().

Las opciones disponibles para setAttributionRegistrationBehavior son las siguientes:

Valor Descripción Ejemplo de caso de uso
APP_SOURCE_AND_WEB_TRIGGER (predeterminada) Permite que las apps registren fuentes de apps (fuentes asociadas con el nombre del paquete de la app) y activadores web (activadores asociados con eTLD+1) desde WebView. Apps que usan WebView para publicar anuncios en lugar de habilitar la navegación web
WEB_SOURCE_AND_WEB_TRIGGER Permite que las apps registren fuentes web y activadores web desde WebView.
Nota: Las apps que usen esta opción deberán solicitarse para unirse a la lista de entidades permitidas y usar registerWebSource().		 Aplicaciones para navegadores basadas en WebView, en las que las impresiones de anuncios y las conversiones podrían ocurrir en sitios web en WebView.
APP_SOURCE_AND_APP_TRIGGER Permite que las apps registren fuentes y activadores de apps desde WebView. Aplicaciones basadas en WebView en las que las impresiones de anuncios y las conversiones siempre deben asociarse con la app, en lugar del eTLD+1 de WebView
INHABILITADO Inhabilita el registro de fuente y activador desde WebView.
Ten en cuenta que es posible que la llamada de red inicial a los URI del activador o de la fuente de atribución aún ocurra, pero se descartará cualquier respuesta y no se almacenará nada en el dispositivo.

Consideraciones de privacidad y seguridad

Impacto en los mecanismos que protegen la privacidad en los informes

Como se describe en la propuesta de diseño principal, la API aplica límites de frecuencia para preservar la privacidad en los informes. Algunos límites se particionan entre las apps fuentes y de destino. Cuando se registra un activador o una fuente de atribución web, el límite de frecuencia se particiona por el sitio fuente o de destino, en lugar de la app.

Si la app mantiene límites de frecuencia separados, es posible que un adversario consuma límites de frecuencia específicos de la app además de los límites de frecuencia de la API. Para mitigar este problema, las apps deben asegurarse de que una fuente de atribución determinada no se registre en la solución de medición de la app y en la API de Attribution Reporting de Android.

Establece confianza en el contexto de la Web

En las llamadas a la API de contexto web, la API confía en la app para detectar y especificar los orígenes de fuente y destino. Esto puede abrir posibles consideraciones de privacidad y seguridad:

  • Un adversario puede afirmar alojar un sitio web de su propiedad en un intento por evitar los límites de frecuencia relacionados con la cantidad de información que cualquier fuente puede transferir.
  • Varios adversarios pueden agrupar datos en fuentes de atribución distintas y reclamar el mismo sitio fuente. Esto podría provocar que el sitio de origen alcance los límites de frecuencia de la plataforma de tecnología publicitaria y evite que el sitio fuente real registre fuentes de atribución legítimas.

Para mitigar este problema, limitaremos qué navegadores o apps pueden llamar a registerWebSource() a navegadores o apps que certifiquen que el sitio de origen que se usa en el registro representa el sitio real que se muestra al usuario. Completa este formulario para unirte a la lista de entidades permitidas y llamar a registerWebSource().

Cualquier app podría llamar a registerWebTrigger() porque las consideraciones de privacidad y seguridad del lado del activador no son aplicables sin la colisión del código fuente.

Controles de usuario

Las apps pueden seguir admitiendo políticas de permisos o controles del usuario, siempre y cuando se puedan definir en el momento del registro. Por ejemplo, si las apps permiten algún permiso a nivel del sitio o del usuario, deben evaluarse y determinar si se debe llamar a las APIs de contexto web.

Además, admitiremos una nueva llamada a la API de las apps para borrar cualquier fuente de atribución, activador y registro pendiente que se almacene para esa app en el dispositivo. Por ejemplo, si las apps permiten que el usuario borre su historial de navegación, es posible que quieran llamar a la API para borrar fuentes de atribución, activadores y los informes pendientes almacenados de esa app en el dispositivo del usuario.

Consideraciones futuras y preguntas abiertas

Se está trabajando en la interoperabilidad de app a web para la API de Attribution Reporting. Queremos conocer la siguiente idea de los comentarios de la comunidad:

  1. En un dispositivo compatible con Privacy Sandbox en Android, ¿cómo usarás las soluciones de medición del navegador con la API de Attribution Reporting de Android? ¿Prefieres pasar todo a Android?
  2. ¿Hay alguna inquietud con respecto a la posible recepción de 2 pings para cada fuente y activador de atribución, uno desde el navegador o la app y otro desde la API de Attribution Reporting?
  3. ¿Cómo podemos facilitar la depuración de datos entre diferentes APIs?
  4. La propuesta no incluye la validación de que los destinos web y de apps estén afiliados. Es posible que en el futuro podamos validar estos destinos mediante la verificación de asociaciones con Vínculos de recursos digitales. ¿Bloquearía alguno de tus casos de uso? ¿Tiene sentido usar Vínculos de recursos digitales para hacer esta validación?
  5. Cuando registres una fuente de atribución, debes especificar un destino. En el caso de la Web a la app, es posible que desees especificar un vínculo de app. ¿Qué formatos se usan para especificar este vínculo de app?
  6. Cuando registres una fuente de atribución de app a Web, ese evento fuente debe registrarse desde la app con la API de Attribution Reporting. Por ejemplo, si el usuario hace clic en un anuncio y el clic se abre en un navegador o en la pestaña personalizada de un navegador, ese clic (evento de fuente) debe registrarse desde la app y no en el contexto del navegador. Comunícate con nosotros si tienes inquietudes sobre este tema o si hay otros casos de uso que no se incluyen en las categorías que se tratan en este problema que describe los flujos admitidos.