Servicios de ofertas y subastas

En la propuesta inicial de Protected Audience, las ofertas y la subasta para la demanda de anuncios de remarketing se ejecutan de forma local en el dispositivo. Esto puede tener requisitos de procesamiento que no son prácticos para ejecutarse en dispositivos con capacidades de procesamiento limitadas o que sean demasiado lentos para seleccionar y renderizar anuncios debido a la latencia de la red.

La propuesta de servicios de ofertas y subastas (B&A) describe una forma de permitir que el procesamiento de Protected Audience se realice en servidores en la nube en un entorno de ejecución confiable (TEE), en lugar de ejecutarlo de manera local en el dispositivo de un usuario. El objetivo de la propuesta de B&A es admitir un flujo unificado para considerar la demanda de anuncios contextuales y de remarketing. Transferir el procesamiento a los servidores puede ayudar a optimizar la subasta de Protected Audience, ya que libera los ciclos computacionales y el ancho de banda de red de un dispositivo.

Google proporcionará los componentes de B&A, que estarán disponibles como código abierto. Las tecnologías publicitarias interesadas pueden alojar sus propias instancias en las plataformas de los proveedores de servicios en la nube pública compatibles. Puedes obtener más información sobre la propuesta de B&A en GitHub. Ten en cuenta que las fechas que se indican en ese documento reflejan la implementación para Chrome. En el futuro, publicaremos más detalles sobre la integración con Android. Este documento es una introducción a B&A y a las nuevas APIs que proporcionará Android para interactuar con esos servicios. En futuras actualizaciones, publicaremos más información técnica sobre el uso de estas nuevas APIs.

Dónde se usan los servicios de B&A

B&A proporciona una opción adicional para ejecutar una subasta dentro de servidores de confianza de tecnología publicitaria que ejecutan un objeto binario de código abierto que proporciona Google. Los datos del usuario igual permanecen en el dispositivo, y Google proporcionará las APIs para transferirlos de forma segura al TEE. A continuación, puedes obtener más información sobre nuestra estrategia de encriptación.

Esto significa que algunas partes del proceso de la subasta ocurren en el dispositivo y otras, en la nube. Desde la perspectiva de la DSP, los públicos personalizados (incluidos los anuncios candidatos para las campañas de remarketing) aún se administran en el dispositivo con las mismas APIs de administración de públicos personalizadas que cuando la subasta se ejecuta en el dispositivo. Desde la perspectiva de la SSP, las solicitudes aún se activan en el dispositivo, y, en este documento, se describen las APIs nuevas que se usarán. En el caso de todas las partes, informar el resultado de una subasta todavía se inicia desde el dispositivo, después de que se completan las B&A.

La principal diferencia es dónde se ejecuta la lógica de generación de la URL de informes, puntuación y ofertas. En lugar de que la lógica de informes, ofertas y subastas se ejecute en el dispositivo, la lógica de generateBid(), scoreAd(), reportResult() y reportWin() se ejecuta en el TEE. La lógica de ofertas de un comprador y la lógica de puntuación de un vendedor se ejecutan dentro de su propio entorno de B&A, en el medio del flujo de subasta de Protected Audience:

Ilustración que muestra el flujo de subasta de Protected Audience y dónde se ubican las ofertas y las subastas
El flujo de subasta de Protected Audience

Encriptación de datos

Con B&A, la información de Protected Audience, como los públicos personalizados y los importes de las ofertas, fluye desde el dispositivo, a través de los servidores de tecnología publicitaria del vendedor, a los servidores de tecnología publicitaria del comprador, y de regreso al dispositivo. Debido a esto, la plataforma encripta los datos que van a los servicios de Protected Audience, y solo los servicios certificados pueden desencriptarlos. Obtén más información sobre las estrategias de encriptación en GitHub.

Flujo de arquitectura y subasta

Esta propuesta incluye la necesidad de varios componentes nuevos que se detallan en GitHub, incluido el flujo de datos del dispositivo a B&A.

Ilustración que muestra el flujo unificado de subastas contextuales y de Protected Audience, que se describe a continuación.
Contenido unificado Flujo de subasta de Protected Audience, con servicios de ofertas y subastas.

En general, el flujo de datos se describe de la siguiente forma:

  1. En el dispositivo, los vendedores usan la API de getAdSelectionData para recopilar información de Protected Audience.
  2. El SDK integrado en el dispositivo envía una solicitud a su servicio de anuncios del vendedor. Esta solicitud incluye una carga útil contextual y un elemento ProtectedAudienceInput encriptado.
  3. El servicio de anuncios del vendedor envía una solicitud al servicio de ofertas en tiempo real (RTB) del comprador que se ejecuta fuera de un TEE para obtener anuncios contextuales candidatos y, luego, asigna una puntuación y selecciona un anuncio contextual ganador.
  4. El servicio de anuncios del vendedor envía una solicitud a su servicio de SellerFrontEnd que se ejecuta en un TEE.
  5. El servicio de SellerFrontEnd envía solicitudes con datos específicos del comprador a los servicios de BuyerFrontEnd.
  6. Los compradores utilizan su propio servicio de par clave-valor y servicio de ofertas, que genera ofertas para candidatos de anuncios provenientes del dispositivo para todos los públicos personalizados que se consideraron para el remarketing.
  7. El servicio de SellerFrontEnd lee desde su servicio de par clave-valor y asigna una puntuación a los anuncios candidatos. El resultado se encripta y se muestra en el servicio de anuncios del vendedor.
  8. El servicio de anuncios del vendedor muestra el resultado ganador encriptado y, opcionalmente, un resultado contextual al SDK en el dispositivo.
  9. En el dispositivo, los vendedores recuperan el anuncio ganador con la API de processAdSelectionResult, que desencripta la respuesta del servicio de anuncios del vendedor.

Puedes encontrar una descripción detallada de cada paso y de cómo se encriptan los datos en GitHub. El código de estos componentes estará disponible a través de código abierto. El código proporcionado controlará la integración de solicitudes del servicio de SellerFrontEnd a los servicios de BuyerFrontEnd.

Implementación en la nube

Las tecnologías publicitarias implementarán servicios de B&A en una plataforma de nube pública compatible. Las tecnologías publicitarias que serán responsables de definir un objetivo de nivel de servicio de disponibilidad administrarán estas implementaciones.

Cómo ejecutar una subasta

El primer paso para ejecutar la subasta de B&A es recopilar los datos de los públicos personalizados en el dispositivo y encriptarlos para enviarlos a las subastas del servidor. Para ello, usa la API de getAdSelectionData:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

El método getAdSelectionData genera la entrada necesaria para los componentes de B&A, como BuyerInput y ProtectedAudienceInput, y encripta los datos antes de que el resultado esté disponible para el llamador. Para evitar la filtración de datos en las apps, estos contienen información de todos los compradores presentes en el dispositivo. Obtén más información sobre esta decisión en la sección Consideraciones de privacidad.

Esta API muestra un objeto AdSelectionData:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

Con este AdSelectionData, el SDK integrado en el dispositivo puede enviar una solicitud a su servicio de anuncios del vendedor si incluye los datos en una solicitud POST o PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

El SDK integrado en el dispositivo es responsable de codificar estos datos. Se recomienda usar una solución eficiente en el espacio, como enviar la solicitud al servicio de anuncios del vendedor como multipart/form-data.

Una vez que se inicia la solicitud, el servicio de anuncios del vendedor la reenvía al servicio de SellerFrontEnd que se ejecuta en un TEE. Cuando configuras un servicio de SellerFrontEnd, los vendedores proporcionan una lista de las direcciones de dominios que corresponden a los servicios de BuyerFrontEnd que operan los compradores con los que se asoció el vendedor. Las solicitudes se integrarán en los diversos servicios de BuyerFrontEnd que proporcionó el vendedor, de modo que los compradores puedan generar ofertas para los candidatos de anuncios que seleccionen. En el caso de un comprador específico, B&A solo enviará información sobre los públicos personalizados que posee el comprador para que no haya filtraciones de datos entre los compradores. Después de generar las ofertas, la lista de anuncios candidatos vuelve al servicio de SellerFrontEnd, donde se selecciona un ganador. Por último, el servicio de SellerFrontEnd muestra el anuncio ganador encriptado en el dispositivo.

Con la respuesta de la solicitud al servicio de anuncios del vendedor en el dispositivo, la plataforma ofrece una segunda API nueva para desencriptar el resultado y proporcionar un AdSelectionOutcome, el mismo objeto que se muestra desde una subasta integrada en el dispositivo hoy.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Informes

Las URLs de informes se generarán en los servicios de B&A. Los pings a esas URLs para informar impresiones e interacciones para subastas aún deberán activarse en el dispositivo. El SDK integrado en el dispositivo aún deberá invocar las APIs de reportImpression() y reportInteraction() con AdSelectionId, que se generó durante el flujo de B&A. Los píxeles contadores generados para los informes de interacción y las URLs correspondientes se contienen en la respuesta encriptada, de modo que, durante la desencriptación de la respuesta, se almacenan los eventos y las asignaciones de URL en el dispositivo.

Consideraciones de privacidad

En la propuesta de la API de subastas y ofertas del navegador en GitHub, se describe cómo se tuvieron en cuenta las consideraciones de privacidad. Esta propuesta usa la nomenclatura de Chrome, pero se aplican los mismos principios a Android.

adSelectionData está encriptado para garantizar que solo la PPAPI y los servidores de confianza puedan acceder a los datos en tránsito. Para mitigar el riesgo de filtración de datos debido a cambios de tamaño de adSelectionData, planeamos generar el mismo adSelectionData para todas las llamadas a la API de getAdSelectionData. Eso implica que todos los CustomAudience del dispositivo se usan para crear adSelectionData. También planeamos restringir la influencia de los parámetros de entrada de GetAdSelectionData en el adSelectionData generado.

La generación del mismo adSelectionData para todas las tecnologías publicitarias con todos los datos de subastas integrados en el dispositivo da como resultado una carga útil más alta que se debe transferir en cada llamada al servidor de tecnología publicitaria al mismo tiempo que, potencialmente, se abre el ecosistema a abusos de entidades maliciosas. Estos asuntos se abordan en las secciones Consideraciones de tamaño y Consideraciones de medidas contra el abuso a continuación.

Consideraciones de tamaño

Se espera que el SDK de cliente de tecnología publicitaria empaquete los bytes encriptados de adSelectionData en una llamada de solicitud de anuncios contextuales realizada al servidor del vendedor. Para obtener un rendimiento óptimo, es importante optimizar el tamaño de adSelectionData sin perjudicar la funcionalidad. Planeamos incorporar optimizaciones como se indica en la explicación de la optimización de la carga útil para reducir el tamaño de adSelectionData. Estas optimizaciones incluirán lo siguiente:

  1. Agregar ad_render_id en CustomAudience para que se envíe con adSelectionData en lugar de usar URI y metadatos de renderización de anuncios. Las tecnologías publicitarias pueden optimizar aún más esto si no envían datos de anuncios en adSelectionData. Esta opción será compatible en la CustomAudience API en versiones futuras.
  2. Garantizar que no se envíen user_bidding_signals en adSelectionData. En cambio, las tecnologías publicitarias pueden recuperar user_bidding_signals de su servidor de par clave-valor.
  3. Permitir que los compradores prioricen CustomAudience.
  4. Permitir que el comprador especifique la prioridad del vendedor.
  5. Generar adSelectionData en algunos intervalos fijos para limitar la filtración de bits y reducir el tamaño de la carga útil.

Se realizarán optimizaciones de tamaño según los problemas mencionados en las consideraciones de privacidad.

Consideraciones de medidas contra el abuso

Como se mencionó en las consideraciones de privacidad, adSelectionData se genera usando todos los datos del comprador en el dispositivo.

Esto abre el ecosistema a posibles entidades maliciosas que podrían agregar datos fraudulentos del comprador que tal vez degraden el rendimiento, aumenten las cargas útiles para aumentar los costos, etc.

Para combatir el abuso de adSelectionData, incorporaremos las siguientes medidas:

  • Permitir que CustomAudience especifique de forma explícita los vendedores aprobados y la prioridad del vendedor
  • Permitir que las SSP especifiquen de forma explícita los compradores, las prioridades de compradores y la cuota por comprador en la carga útil generada
  • Proporcionar un mecanismo para que las SSP definan una cantidad máxima de compradores por llamada o un tamaño máximo por comprador

Estas medidas están diseñadas para permitir que las tecnologías publicitarias definan con qué otras tecnologías publicitarias colaboran y establecer límites aceptables en la carga útil de adSelectionData que deberían procesar. Proponemos permitir que el vendedor especifique esta prioridad y esta lista de compradores en una llamada separada. Esta especificación se mantendrá constante durante un período determinado para no exponer datos adicionales sobre el usuario a través de llamadas repetidas.

Las mitigaciones que se mencionaron antes se siguen debatiendo y están sujetas a cambios a lo largo del tiempo. Como se indicó anteriormente, todas las mitigaciones que se incluyeron para la prevención del abuso y las restricciones de tamaño deben cumplir con las consideraciones de privacidad.