Se usó la API de Cloud Translation para traducir esta página.

Indicadores de apps protegidas para admitir anuncios de instalación de apps relevantes

Esta propuesta está sujeta al proceso de inscripción de Privacy Sandbox y certificaciones. Para obtener más información sobre las certificaciones, consulta al vínculo de certificación proporcionado. Las actualizaciones futuras de esta propuesta describir los requisitos para obtener acceso a este sistema.

Los anuncios de instalación de aplicación para dispositivos móviles, también conocidos como anuncios de adquisición de usuarios, son un tipo de publicidad para dispositivos móviles que se diseñaron para motivar a los usuarios a descargar una app en este tipo de dispositivos. Por lo general, estos anuncios se muestran a los usuarios en función de sus intereses y datos demográficos y, con frecuencia, aparecen en otras apps para dispositivos móviles, como juegos, redes sociales y apps de noticias. Cuando un usuario hace clic en un anuncio de instalación de aplicación, se lo dirige directamente a la tienda de aplicaciones para que descargue la app.

Por ejemplo, es probable que un anunciante que intenta promover la instalación de una nueva app de entrega de comida a domicilio para dispositivos móviles en Estados Unidos oriente sus anuncios a usuarios que se encuentren en este país y que, anteriormente, hayan interactuado con otras apps de entrega de comida.

Por lo general, se implementa cuando se incluyen indicadores contextuales, propios y de terceros entre las tecnologías publicitarias para crear perfiles de usuario en función de los IDs de publicidad. Los modelos de aprendizaje automático de la tecnología publicitaria usan esta información como entradas para elegir los anuncios que sean relevantes para el usuario y tengan la mayor probabilidad de generar una conversión.

Se proponen las siguientes APIs para admitir anuncios de instalación de aplicación eficaces que mejoran la privacidad del usuario con la eliminación de la dependencia en los identificadores de usuario entre varias partes:

API de Protected App Signals: Se centra en el almacenamiento y la creación de atributos diseñados para tecnologías publicitarias, que representan los posibles intereses de un usuario. Las tecnologías publicitarias almacenan indicadores de eventos autodefinidos por app, como instalaciones, primeros accesos, acciones del usuario (nivelación en el juego, logros), las actividades de compra o el tiempo en la app. Los indicadores se escriben y almacenan para protegerse contra la filtración de datos y solo están disponibles para lógica de tecnología publicitaria que almacenó el indicador determinado durante una subasta protegida que se ejecuta en un entorno seguro.
API de Ad Selection: Proporciona una API para configurar y ejecutar una Subasta protegida que se ejecuta en un entorno de ejecución confiable (TEE) en la que las tecnologías publicitarias recuperan candidatos de anuncios, ejecutan inferencias, calculan ofertas puntuación para elegir una "ganadora" anuncio con indicadores de apps protegidos y información contextual en tiempo real proporcionada por el publicador.

Diagrama que muestra el flujo de instalación de la app con indicadores protegidos — Diagrama de flujo que muestra los indicadores de apps protegidos y el flujo de trabajo de selección de anuncios en Privacy Sandbox en Android.

Esta es una descripción general de alto nivel sobre cómo funcionan los indicadores de apps protegidos para admitir anuncios de instalación de aplicación relevantes. En las siguientes secciones de este documento, se proporcionan más detalles sobre cada uno de estos pasos.

Selección de indicadores: A medida que los usuarios usan aplicaciones para dispositivos móviles, las tecnologías publicitarias seleccionan indicadores. almacenando eventos de aplicaciones definidos por la tecnología publicitaria para publicar anuncios relevantes con el API de Protected App Signals. Estos eventos se almacenan en la protección similares a los públicos personalizados, y se encriptan antes de envían fuera del dispositivo, de modo que solo los servicios de ofertas y subastas dentro de entornos de ejecución confiables con las políticas de seguridad y el control de privacidad puede desencriptarlos para ofertar y calificar anuncios.
Codificación de indicadores: Los indicadores se preparan según una frecuencia programada por la lógica de la tecnología publicitaria personalizada. Una tarea en segundo plano de Android ejecuta esta lógica para realizar la codificación integrada en el dispositivo para generar una carga útil de los indicadores de apps protegidos que se pueden usar en tiempo real para la selección de anuncios durante una Subasta. La carga útil se almacena de forma segura en el dispositivo hasta que se envía para una subasta.
Selección de anuncios: Para seleccionar anuncios relevantes para el usuario, los SDKs del vendedor envía una carga útil encriptada de los indicadores de apps protegidos y configura un Subasta protegida. En la subasta, la lógica personalizada del comprador prepara el entorno los indicadores de apps junto con los datos contextuales que proporciona el publicador (datos que se suelen compartir en una solicitud de anuncio de Open-RTB) a ingenieros funciones diseñadas para la selección de anuncios (recuperación de anuncios, inferencia y oferta generación). Al igual que con Protected Audience, los compradores envían anuncios al vendedor por la puntuación final en una subasta protegida.
- Recuperación de anuncios: Los compradores usan indicadores de apps protegidos y datos contextuales proporcionados por el publicador para ingenieros de atributos relevantes para los intereses del usuario. Estas funciones permiten hacer coincidir los anuncios que cumplen con los criterios de segmentación. Se filtran los anuncios que no se encuentran dentro del presupuesto. Luego, los anuncios Top-K se seleccionan para ofertar.
- Ofertas: La lógica de las ofertas personalizadas de los compradores prepara los indicadores de apps protegidos y los datos contextuales que proporciona el publicador para diseñar atributos que se usen como entrada para los modelos de aprendizaje automático del comprador para la inferencia y las ofertas en anuncios candidatos dentro de los límites confiables que preservan la privacidad. Luego, el comprador devolverá el anuncio elegido al vendedor.
- Puntuación del vendedor: Vendedores lógica de puntuación personalizada asigna puntuaciones a los anuncios enviado por los Compradores participantes y elige el anuncio ganador para enviarlo volver a la app para su renderización.
Informes: Los participantes de la subasta reciben los informes correspondientes de anuncios ganadores y perdedores. Estamos explorando mecanismos que preserven la privacidad para incluir datos para el entrenamiento de modelos en el informe de anuncios ganadores.

Cronograma

	Versión preliminar para desarrolladores			Beta
Función	4º trimestre de 2023	1º trimestre de 2023	2º trimestre de 2023	3º trimestre de 2023
APIs de Signal Curation	APIs de almacenamiento en el dispositivo	Lógica de cuota de almacenamiento en el dispositivo Actualizaciones diarias de la lógica personalizada en el dispositivo	N/A	Disponible para dispositivos T+ de 1%
Servidor de recuperación de anuncios en un TEE	MVP	Disponible en GCP Compatibilidad con Top-K Produccionización de UDF	Disponible en AWS Depuración, métricas y supervisión con consentimiento
Servicio de inferencia en un TEE Compatibilidad con la ejecución de modelos de AA y su uso para ofertar en un TEE	En desarrollo	Disponible en GCP Capacidad de implementar y crear prototipos de modelos estáticos de AA con TensorFlow y PyTorch	Disponible en AWS Implementación de modelos produccionizados para los modelos de TensorFlow y PyTorch Telemetría, depuración y supervisión con consentimiento
Compatibilidad con ofertas y subastas en un TEE	Disponible en GCP	Integración de recuperación de anuncios de PAS-B&A y TEE (con encriptación TEE<>TEE y gRPC) Compatibilidad con recuperación de anuncios a través de rutas contextuales (incluye B&A<>compatibilidad con K/V en TEE)	Disponible en AWS Informes de depuración Depuración, métricas y supervisión con consentimiento

Selecciona indicadores de apps protegidos

Un indicador es una representación de varias interacciones del usuario en una app que la tecnología publicitaria determina que serán útiles para publicar anuncios relevantes. Una app o el El SDK integrado puede almacenar o borrar indicadores de apps protegidos definidos por las tecnologías publicitarias. según la actividad del usuario, como accesos de apps, logros, actividad de compra tiempo en la app. Los indicadores de apps protegidos se almacenan de forma segura en el dispositivo y se encriptado antes de que se envíen del dispositivo para que solo las funciones de servicios que se ejecutan en entornos de ejecución confiables con la seguridad y el control de privacidad pueden desencriptarlos para ofertar y calificar anuncios. Similar al API de Custom Audience, los indicadores almacenados en un dispositivo no se pueden leer ni inspeccionar por apps o SDK no hay una API para leer valores de indicadores, y las APIs se diseñados para evitar que se filtre la presencia de señales. La lógica personalizada de la tecnología publicitaria tiene acceso protegido a sus indicadores seleccionados para diseñar atributos que funcionen como base para la selección de anuncios en una subasta protegida.

API de Protected App Signals

La API de Protected App Signals admite la administración de indicadores con un mecanismo de delegación similar al que se usa para los públicos personalizados. La API de Protected App Signals habilita el almacenamiento de los indicadores en forma de un valor escalar único o como una serie temporal. Los indicadores de las series temporales se pueden usar para almacenar elementos, como la duración de la sesión del usuario. Los indicadores de las series temporales ofrecen una utilidad para aplicar, de manera forzosa, una longitud determinada con una regla de expulsión según el orden de llegada. El tipo de datos de un indicador escalar, o cada uno de los elementos de un indicador de serie temporal, es un array de bytes. Cada valor se enriquece con el nombre del paquete de la aplicación que almacenó el indicador y con la marca de tiempo de creación de la llamada a la API del indicador de almacenamiento. Puedes encontrar información adicional en el JavaScript de codificación de indicador. En este ejemplo, se muestra la estructura de los indicadores que son propiedad de una tecnología publicitaria determinada:

En este ejemplo, se muestra un indicador escalar y un indicador de serie temporal asociado con adtech1.com:

Un indicador escalar con la clave del valor base64 "A1c" y el valor "c12Z". com.google.android.game_app activó el almacén de indicadores el 1 de junio de 2023
Una lista de indicadores con la clave "dDE" que crearon dos aplicaciones diferentes

A las tecnologías publicitarias se les asigna una cierta cantidad de espacio para almacenar indicadores en el dispositivo. Los indicadores tendrán un TTL máximo, que se determinará.

Los indicadores de apps protegidos se quitan del almacenamiento si se desinstala la aplicación que se genera, si se impide el uso de la API de Protected App Signals o si el usuario borra los datos de la app.

La API de Protected App Signals se compone de las siguientes partes:

una API de Java y de JavaScript para agregar, actualizar o quitar indicadores
una API de JavaScript para procesar los indicadores persistentes y prepararlos para continuar con la ingeniería de atributos en tiempo real durante una subasta protegida en un entorno de ejecución confiable (TEE).

Agrega, actualiza o quita indicadores

Las tecnologías publicitarias pueden agregar, actualizar o quitar indicadores con la API de fetchSignalUpdates(). Esta API admite una delegación similar a la del público personalizado de Protected Audience.

Para agregar un indicador, las tecnologías publicitarias del comprador que no tienen presencia de SDK en apps deben colaborar con aquellas que tienen presencia en el dispositivo, como los socios de medición para dispositivos móviles (MMP) y las plataformas de proveedores (SSP). El objetivo de la API de Protected App Signals es admitir estas tecnologías publicitarias proporcionando soluciones flexibles para la administración de indicadores de apps protegidos. Para ello, se habilitan los llamadores integrados en los dispositivos para que invoquen la creación de indicadores de app protegidos en nombre de los compradores. Este proceso se denomina "delegación" y aprovecha la API de fetchSignalUpdates(). fetchSignalUpdates() toma un URI y recupera una lista de actualizaciones de los indicadores. A modo de ejemplo, fetchSignalUpdates() emite una solicitud GET al URI determinado para recuperar el lista de actualizaciones que se aplicarán al almacenamiento de indicadores locales. El extremo de URL, propiedad de el comprador responde con una lista de comandos JSON.

Los comandos JSON compatibles son los siguientes:

put: Inserta o anula un valor escalar para la clave determinada.
put_if_not_present: Inserta un valor escalar para la clave determinada si aún no se almacenó un valor. Esta opción puede ser útil, por ejemplo, para establecer un ID del experimento para el usuario determinado y evita anularlo si ya estaba establecido por otra aplicación.
append: Agrega un elemento a la serie temporal asociada con la clave determinada. El parámetro maxSignals especifica la cantidad máxima de indicadores en el tiempo . Si se supera el tamaño, se quitan los elementos anteriores. Si la clave contiene un valor escalar, se transforma automáticamente en una serie temporal.
remove: Quita el contenido asociado con la clave determinada.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

Todas las claves y valores se expresan en Base64.

Los comandos que se mencionaron anteriormente tienen el objetivo de proporcionar semánticas de inserción, reemplazo y eliminación para los indicadores escalares, además de semánticas de inserción, anexo y reemplazo de series completas para los indicadores de series temporales. Las semánticas de eliminación y reemplazo en elementos específicos de un indicador de serie temporal se deben administrar durante el proceso de codificación y compactación; por ejemplo, durante la codificación, ignorar los valores en una serie temporal que se sustituyen o corrigen por valores más recientes y eliminarlos durante el proceso de compactación.

Los indicadores almacenados se asocian automáticamente con la aplicación que realiza la de recuperación y la persona que responde a la solicitud (el “sitio” u “origen” de un tecnología publicitaria inscrita), más la hora de creación de la solicitud. Todos los indicadores están sujetos a su almacenamiento en nombre de una tecnología publicitaria inscrita en Privacy Sandbox, por lo que el "sitio" o "origen" del URI debe coincidir con los datos de una tecnología publicitaria inscrita. Si la tecnología publicitaria que realiza la solicitud no está inscrita, esta se rechaza.

Cuota de almacenamiento y expulsión

Cada tecnología publicitaria tiene una cantidad limitada de espacio en el dispositivo del usuario para almacenar indicadores. Esta cuota es definida por tecnología publicitaria, por lo que los indicadores seleccionados de diferentes apps comparten la cuota. Si se supera la cuota, el sistema libera espacio con la eliminación de los valores anteriores de los indicadores, según el orden de llegada. Para evitar que la expulsión se ejecute con demasiada frecuencia, el sistema implementa una lógica de lotes para permitir una cantidad limitada de sobregiro de cuota y liberar espacio adicional una vez que se activa la lógica de expulsión.

Codificación integrada en el dispositivo para la transmisión de datos

Para preparar los indicadores para la selección de anuncios, la lógica personalizada por comprador tiene acceso protegido a los indicadores y eventos almacenados por app. Un trabajo en segundo plano del sistema Android se ejecuta cada hora para ejecutar la lógica de codificación personalizada por comprador que se descarga en el dispositivo. La lógica de codificación personalizada por comprador codifica los indicadores por app y, luego, los comprime en una carga útil que cumple con la cuota por comprador. Luego, la carga útil se encripta dentro de los límites del almacenamiento del dispositivo protegido y se transmite a los servicios de ofertas y subastas.

Las tecnologías publicitarias definen el nivel de procesamiento de los indicadores que controla su propia lógica personalizada. Por ejemplo, puedes instrumentar tu solución para que se descarten los indicadores anteriores y se agreguen indicadores similares o de refuerzo de diferentes aplicaciones en indicadores nuevos que usen menos espacio.

Si un comprador no registró un codificador de indicadores, estos no están preparados y ninguno de los indicadores seleccionados e integrados en el dispositivo se envía a los servicios de ofertas y subastas.

En una actualización futura, se brindarán más detalles sobre las cuotas de almacenamiento, carga útil y solicitud. Además, brindaremos más información sobre cómo proporcionar funciones personalizadas.

Flujo de trabajo de la selección de anuncios

Con esta propuesta, el código personalizado de la tecnología publicitaria solo puede acceder a los indicadores de app protegidos dentro de una subasta protegida (API de Ad Selection) que se ejecute en un TEE. Para satisfacer aún más las necesidades del caso de uso de instalación de aplicación, los anuncios candidatos se recuperan durante la subasta protegida en tiempo real. Esto se diferencia del caso de uso del remarketing en el que los anuncios candidatos se conocen antes de la subasta.

En esta propuesta, se usa un flujo de trabajo de selección de anuncios similar al de la propuesta de Protected Audience, con actualizaciones para admitir el caso de uso de instalación de aplicación. Para cumplir con los requisitos de procesamiento relacionados con la ingeniería de atributos y la selección de anuncios en tiempo real, las subastas para los anuncios de instalación de aplicación deben ejecutarse en servicios de ofertas y subastas que se ejecuten en TEE. El acceso a los indicadores de apps protegidos durante una subasta protegida no es compatible con las subastas integradas en el dispositivo.

Ilustración del flujo de trabajo de la selección de anuncios. — Flujo de trabajo de la selección de anuncios en Privacy Sandbox en Android.

El flujo de trabajo de la selección de anuncios es el siguiente:

El SDK del vendedor envía la carga útil encriptada e integrada en el dispositivo de los indicadores de apps protegidos.
El servidor del vendedor crea una configuración de subasta y la envía al servicio de ofertas y subastas de confianza, junto con la carga útil encriptada, para iniciar un flujo de trabajo de selección de anuncios.
El servicio de ofertas y subastas del vendedor pasa la carga útil a los servidores de frontend de los compradores participantes de confianza.
El servicio de ofertas del comprador ejecuta la lógica de selección de anuncios orientados a la compra.
1. Ejecución de la lógica de recuperación de anuncios orientados a la compra
2. Ejecución de la lógica de ofertas orientadas a la compra
Se ejecuta la lógica de puntuación orientada a la venta.
Se renderiza el anuncio, y se inician los informes.

Inicia un flujo de trabajo de selección de anuncios

Cuando una aplicación está lista para mostrar un anuncio, se usa el SDK de tecnología publicitaria (por lo general, las SSP). inicia el flujo de trabajo de selección de anuncios enviando cualquier dato contextual relevante desde el publicador y las cargas útiles encriptadas por comprador que se incluirán en la solicitud se enviará a la subasta protegida con la llamada getAdSelectionData. Este es la misma API que se utiliza para el flujo de trabajo de remarketing y que se describe en el artículo Propuesta de integración de subastas para Android

Para iniciar la selección de anuncios, el vendedor pasa una lista de compradores participantes y la carga útil encriptada de los indicadores de apps protegidos en el dispositivo. Con esta información, el servidor de anuncios orientados a la venta prepara un elemento SelectAdRequest para su servicio de SellerFrontEnd de confianza.

El vendedor establece lo siguiente:

La carga útil recibida de getAdSelectionData, que incluye los indicadores de apps protegidos
Los indicadores contextuales con lo siguiente:
- auction_config.auction_signals (para información sobre la subasta)
- auction_config.seller_signals (para los indicadores del vendedor
- auction_config.per_buyer_config["buyer"].buyer_signals (para el período compradores indicadores)
La lista de compradores incluida en las subastas con el campo buyer_list

Ejecución de la lógica de selección de anuncios orientados a la compra

En un nivel superior, la lógica personalizada del comprador usa datos contextuales que proporciona el publicador y los indicadores de apps protegidos para seleccionar y aplicar una oferta a los anuncios relevantes para la solicitud de anuncio. La plataforma les permite a los compradores restringir un gran conjunto de anuncios disponibles a los más relevantes (los Top-K), para los cuales se calculan las ofertas antes de que los anuncios se devuelvan al vendedor para la selección final.

Ilustración de la lógica de ejecución de selección de anuncios orientados a la compra. — Lógica de ejecución de selección de anuncios orientados a la compra en Privacy Sandbox en Android.

Antes de ofertar, los compradores comienzan con un gran conjunto de anuncios. El proceso para calcular una oferta para cada anuncio es demasiado lento, por lo que los compradores primero deben seleccionar los candidatos Top-K del conjunto grande. A continuación, los compradores deben calcular las ofertas para cada uno de esos candidatos Top-K. Luego, esos anuncios y ofertas se devuelven al vendedor para la selección final.

El servicio de BuyerFrontEnd recibe una solicitud de anuncio.
El servicio de BuyerFrontEnd envía una solicitud al servicio de ofertas del comprador. El servicio de ofertas del comprador ejecuta una UDF llamada prepareDataForAdRetrieval(), que crea una solicitud para obtener los candidatos Top-K de la recuperación de anuncios Servicio. El servicio de ofertas envía esta solicitud a la recuperación configurada extremo del servidor.
El servicio de recuperación de anuncios ejecuta la UDF getCandidateAds(), que filtra el conjunto de anuncios candidatos Top-K, que se envían al comprador servicio de licitación.
El servicio de ofertas del comprador ejecuta la UDF generateBid(), que elige el mejor candidato, calcula su oferta y la devuelve al servicio de BuyerFrontEnd.
El servicio de BuyerFrontEnd devuelve los anuncios y las ofertas al vendedor.

Hay varios detalles importantes sobre este flujo, en especial, en relación con la forma en que las partes se comunican entre sí y con la manera en que la plataforma proporciona atributos, por ejemplo, la capacidad de realizar predicciones de aprendizaje automático para recuperar los anuncios Top-K y calcular sus ofertas.

Antes de analizar sus partes con más detalle, hay algunas notas arquitectónicas importantes sobre los TEE en el diagrama anterior.

El servicio de ofertas del comprador incluye internamente un servicio de inferencia. Las tecnologías publicitarias pueden subir modelos de aprendizaje automático al servicio de ofertas del comprador. Proporcionaremos APIs de JavaScript para que las tecnologías publicitarias realicen predicciones o generen incorporaciones a partir de estos modelos desde las UDF que se ejecutan en el servicio de ofertas del comprador. A diferencia del servicio de recuperación de anuncios, el servicio de ofertas del comprador no tiene un servicio de par clave-valor para almacenar los metadatos de los anuncios.

El servicio de recuperación de anuncios incluye internamente un servicio de par clave-valor. Las tecnologías publicitarias pueden materializar pares clave-valor en este servicio desde sus propios servidores, fuera de los límites de privacidad. Proporcionaremos una API de JavaScript para que las tecnologías publicitarias lean a partir de este servicio de par clave-valor desde las UDF que se ejecutan en el servicio de recuperación de anuncios. A diferencia del servicio de ofertas del comprador, el servicio de recuperación de anuncios no incluye un servicio de inferencia.

Una pregunta central que aborda este diseño es la manera en que se realizan las predicciones del tiempo de recuperación y de la oferta. La respuesta para ambos puede incluir una solución llamada factorización de modelos.

Factorización de modelos

La factorización de modelos es una técnica que permite dividir un solo modelo en varias partes y, luego, combinarlas en una predicción. En el caso de uso de instalación de aplicación, los modelos suelen usar tres tipos de datos: del usuario, contextuales y de anuncios.

En el caso no factorizado, un solo modelo se entrena con los tres tipos de datos. En el caso factorizado, dividimos el modelo en varias partes. Solo es sensible la parte que contiene los datos del usuario. Es decir, solo el modelo con la parte del usuario debe ejecutarse dentro del límite de confianza, en el servicio de inferencia del servicio de ofertas del comprador.

De esta manera, es posible el siguiente diseño:

Divide el modelo en una parte privada (los datos del usuario) y uno o más partes no privadas (los datos contextuales y de anuncios).
De manera opcional, pasa algunas o todas las partes no privadas como argumentos a una UDF que necesite realizar predicciones. Por ejemplo, las incorporaciones contextuales son se pasan a las UDF en el per_buyer_signals.
De manera opcional, las tecnologías publicitarias pueden crear modelos para partes no privadas y, luego, materializar las incorporaciones de esos modelos en el almacén de pares clave-valor del servicio de recuperación de anuncios. Las UDF en el servicio de recuperación de anuncios pueden recuperar estas incorporaciones durante el tiempo de ejecución.
Para realizar una predicción durante una UDF, combina las incorporaciones privadas del servicio de inferencia con las incorporaciones no privadas desde los argumentos de la función de la UDF o el almacén de pares clave-valor con una operación, como un producto punto. Esta es la predicción final.

Una vez explicado esto, podemos analizar cada UDF con más detalle. Explicaremos qué hacen, cómo se integran y cómo pueden realizar las predicciones necesarias para elegir los anuncios Top-K y calcular sus ofertas.

La UDF `prepareDataForAdRetrieval()`

La función prepareDataForAdRetrieval() que se ejecuta en el servicio de ofertas del comprador se ocupa de crear la carga útil de la solicitud que se enviará al servicio de recuperación de anuncios para obtener los anuncios candidatos Top-K.

prepareDataForAdRetrieval() tiene en cuenta la siguiente información:

La carga útil por comprador recibida de getAdSelectionData Esta carga útil incluye los indicadores de apps protegidos.
Los indicadores contextuales auction_signals (para la información sobre la subasta) y buyer_signals (para compradores indicadores).

prepareDataForAdRetrieval() realiza dos acciones:

Transformación de atributos: Si se necesita la inferencia en el tiempo de recuperación, transforma los indicadores entrantes en atributos para usarlos durante las llamadas al servicio de inferencia para obtener incorporaciones privadas para su recuperación.
Calcula las incorporaciones privadas para su recuperación: si corresponde a predicciones de recuperación. se necesitan, realiza la llamada al servicio de inferencia con el comando de los atributos y recibe una incorporación privada para las predicciones del tiempo de recuperación.

prepareDataForAdRetrieval() devuelve lo siguiente:

Indicadores de apps protegidos: La carga útil de los indicadores seleccionados por la tecnología publicitaria
Indicadores específicos de la subasta: Indicadores orientados a la venta específicos de la plataforma y la información contextual, como auction_signals y per_buyer_signals (incluidas las incorporaciones contextuales) de SelectAdRequest Es similar a Protected Audiences
Indicadores adicionales: Información adicional, como incorporaciones privadas recuperadas del servicio de inferencia

Esta solicitud se envía al servicio de recuperación de anuncios, que busca coincidencias de candidatos y, luego, ejecuta la UDF getCandidateAds().

La UDF `getCandidateAds()`

La función getCandidateAds() se ejecuta en el servicio de recuperación de anuncios. Recibe la solicitud que creó prepareDataForAdRetrieval() en el servicio de ofertas del comprador. El servicio ejecuta getCandidateAds(), que recupera los candidatos Top-K para su oferta convirtiendo la solicitud en una serie de consultas establecidas, recuperaciones de datos y ejecutando lógica empresarial personalizada y otra lógica de recuperación personalizada.

getCandidateAds() tiene en cuenta la siguiente información:

Indicadores de apps protegidos: La carga útil de los indicadores seleccionados por la tecnología publicitaria
Indicadores específicos de la subasta: Indicadores orientados a la venta específicos de la plataforma y la información contextual, como auction_signals y per_buyer_signals (incluidas las incorporaciones contextuales) de SelectAdRequest Es similar a Protected Audiences
Indicadores adicionales: Información adicional, como incorporaciones privadas recuperadas del servicio de inferencia

getCandidateAds() realiza las siguientes acciones:

Recuperación de un conjunto inicial de anuncios candidatos: Se obtiene con criterios de segmentación, como el idioma, la ubicación geográfica, el tipo de anuncio, el tamaño del anuncio o el presupuesto, para filtrar los anuncios candidatos.
Obtención de las incorporaciones de recuperación: Si se necesitan incorporaciones del servicio de par clave-valor para realizar una predicción del tiempo de recuperación para la selección de Top-K, deben obtenerse del servicio de par clave-valor.
Selección de candidatos Top-K: Calcula una puntuación baja para el conjunto filtrado de anuncios candidatos en función de los metadatos de los anuncios que se recuperan del almacén de par clave-valor y la información que se envía desde el servicio de ofertas del comprador, y para elegir a los candidatos Top-K en función de esa puntuación. Por ejemplo, la puntuación puede ser la probabilidad de instalar una app, según el anuncio.
Recuperación de incorporaciones de ofertas: Si las incorporaciones del servicio de par clave-valor son que necesita el código de oferta para hacer predicciones del tiempo de oferta, pueden del servicio de par clave-valor.

Ten en cuenta que la puntuación de un anuncio puede ser el resultado de un modelo predictivo, que, por ejemplo, predice la probabilidad de que un usuario instale una app. Este tipo de generación de puntuaciones implica un tipo de factorización de modelos: como getCandidateAds() se ejecuta en el servicio de recuperación de anuncios y no tiene un servicio de inferencia, las predicciones se pueden generar combinando lo siguiente:

Incorporaciones contextuales que se pasan con los indicadores específicos de la subasta entrada.
Incorporaciones privadas que se pasan con la entrada de indicadores adicionales
Cualquier tecnología publicitaria de incorporación no privada se materializó a partir de sus servidores al servicio de par clave-valor del servicio de recuperación de anuncios

Ten en cuenta que la UDF generateBid() que se ejecuta en el servicio de ofertas del comprador también puede aplicar su propio tipo de factorización de modelos para realizar sus predicciones de ofertas. Si se necesita alguna incorporación de un servicio de par clave-valor para hacerlo, se debe recuperar ahora.

getCandidateAds() devuelve lo siguiente:

Anuncios candidatos: Los anuncios Top-K que se pasarán a generateBid(). Cada anuncio se compone de lo siguiente:
- URL de renderización: Extremo para renderizar la creatividad del anuncio
- Metadatos: Metadatos de anuncios específicos de la tecnología publicitaria orientados a la compra. Por ejemplo, esta Pueden incluir información sobre la campaña publicitaria y los criterios de segmentación. como la ubicación y el idioma. Los metadatos pueden incluir parámetros Incorporaciones que se usan cuando se necesita la factorización de modelos para ejecutarse de inferencia durante la licitación.
Indicadores adicionales: De manera opcional, el servicio de recuperación de anuncios puede incluir información adicional, como incorporaciones adicionales o indicadores de spam que se usarán en generateBid().

Estamos investigando otros métodos para proporcionar anuncios que reciban una puntuación, lo que incluye lograr que esté disponible como parte de la llamada a SelectAdRequest. Estos anuncios se pueden recuperar con una solicitud de oferta de RTB. Ten en cuenta que, en esos casos, los anuncios deben recuperarse sin indicadores de apps protegidos. Anticipamos que las tecnologías publicitarias evaluarán las compensaciones antes de elegir la mejor opción, lo que incluye el tamaño de la carga útil de respuesta, la latencia, el costo y la disponibilidad de indicadores.

La UDF `generateBid()`

Una vez que hayas recuperado el conjunto de anuncios candidatos y las incorporaciones durante la recuperación, estarás listo para continuar con la oferta, que se ejecuta en el servicio de ofertas del comprador. Este servicio ejecuta la UDF de generateBid() que proporciona el comprador para seleccionar el anuncio Top-K que se ofertará y, luego, devolverlo con su oferta.

generateBid() tiene en cuenta la siguiente información:

Anuncios candidatos: Los anuncios Top-K que devuelve el servicio de recuperación de anuncios
Indicadores específicos de la subasta: Indicadores orientados a la venta específicos de la plataforma y la información contextual, como auction_signals y per_buyer_signals (incluidas las incorporaciones contextuales) de SelectAdRequest
Indicadores adicionales: Información adicional que se utilizará durante el tiempo de oferta

La implementación de generateBid() del comprador realiza tres acciones:

Transformación de atributos: Transforma indicadores en atributos para usarlos durante la inferencia.
Inferencia: Genera predicciones con modelos de aprendizaje automático para calcular valores, como el porcentaje de clics y de conversiones previstos.
Ofertas: Combina los valores inferidos con otras entradas para calcular el para un anuncio candidato.

generateBid() devuelve lo siguiente:

El anuncio candidato
El importe calculado de la oferta

Ten en cuenta que la función generateBid() que se usa para los anuncios de instalación de aplicación y la que se usa para los anuncios de remarketing son diferentes.

En las siguientes secciones, se describen, en detalle, la transformación de atributos, la inferencia y las ofertas.

Transformación de atributos

generateBid() puede preparar los indicadores de subasta en atributos. Estas funciones se puede usar durante la inferencia para predecir factores como el porcentaje de clics y porcentajes de conversiones. También estamos explorando mecanismos que preserven la privacidad para transmitir algunos de ellos en el informe de anuncios ganadores para usarlos en el entrenamiento de modelos.

Inferencia

Mientras se calcula una oferta, es frecuente realizar inferencias en uno o más modelos de aprendizaje automático. Por ejemplo, los cálculos efectivos de eCPM suelen usar modelos para predecir los porcentajes de clics y de conversiones.

Los clientes pueden proporcionar una serie de modelos de aprendizaje automático junto con su implementación de generateBid(). También proporcionaremos una API de JavaScript en generateBid() para que los clientes puedan realizar inferencias durante el tiempo de ejecución.

La inferencia se ejecuta en el servicio de ofertas del comprador. Esto puede afectar la latencia y el costo de la inferencia, en especial, porque los aceleradores aún no están disponibles en los TEE. Algunos clientes descubrirán que sus necesidades se satisfacen con modelos individuales que se ejecutan en el servicio de ofertas del comprador. Es posible que algunos clientes, por ejemplo, aquellos con modelos muy grandes, deseen considerar opciones, como la factorización de modelos, para minimizar el costo y la latencia de la inferencia al momento de la oferta.

En una actualización futura, se proporcionará más información sobre las capacidades de inferencia, como los formatos de modelo compatibles y los tamaños máximos.

Implementa la factorización de modelos

Anteriormente, explicamos la factorización de modelos. Durante el tiempo de oferta, el enfoque específico es el siguiente:

Divide el modelo en una parte privada (los datos del usuario) y uno o más partes no privadas (los datos contextuales y de anuncios).
Pasa partes no privadas a generateBid(), que pueden provenir de per_buyer_signals o de incorporaciones que las tecnologías publicitarias calculan de forma externa, materializan en el almacén de pares clave-valor del servicio de recuperación, obtienen durante el tiempo de recuperación y devuelven como parte de los indicadores adicionales. No se incluyen las incorporaciones privadas, ya que no se pueden obtener desde fuera del límite de privacidad.
En generateBid(), haz lo siguiente:
1. Realiza inferencias con los modelos para obtener incorporaciones privadas de usuarios.
2. Combina las incorporaciones privadas de usuarios con las incorporaciones contextuales de per_buyer_signals o las incorporaciones contextuales o los anuncios no privados del servicio de recuperación con una operación, como un producto punto. Este es el que puede usarse para calcular las ofertas.

Con este enfoque, es posible realizar inferencias durante el tiempo de oferta en modelos que, de otro modo, serían demasiado grandes o lentos para ejecutarse en el servicio de ofertas del comprador.

Lógica de puntuación orientada a la venta

En esta etapa, se califican los anuncios con las ofertas que se reciben de todos los compradores participantes. El resultado de generateBid() se pasa al servicio de subastas del vendedor para ejecutar el objeto scoreAd(), y este scoreAd() tiene en cuenta solo un anuncio a la vez. En función de la puntuación, el vendedor elige un anuncio ganador para devolver al dispositivo para su renderización.

La lógica de puntuación es la misma que se usa para el flujo de remarketing de Protected Audience y puede seleccionar un ganador entre los candidatos del flujo de remarketing y de instalación de aplicación. La función se llama una vez por cada anuncio candidato enviado en la subasta protegida. Consulta la explicación sobre ofertas y subastas para obtener más detalles.

Entorno de ejecución de código de selección de anuncios

En la propuesta, el código de selección de anuncios para instalación de aplicación se especifica en el mismo que en el flujo de remarketing de Protected Audience. Para obtener más información, consulta la Configuración de ofertas y subastas. El código de oferta disponible en la misma ubicación de almacenamiento en la nube que la que se usó para el remarketing.

Informes

Esta propuesta usa las mismas APIs de informes que los informes de Protected Audience. propuesta (por ejemplo, reportImpression(), que activa la plataforma para que enviar informes de vendedores y compradores).

Un caso de uso común para generar informes de compra es obtener datos de entrenamiento para los modelos que se usan durante la selección de anuncios. Además de las APIs existentes, la plataforma proporcionará un mecanismo específico para la salida de datos a nivel del evento desde a servidores de tecnología publicitaria. Estas cargas útiles de salida pueden incluir ciertas de datos no estructurados.

A largo plazo, estamos investigando soluciones que preserven la privacidad para abordar entrenamiento de modelos con datos que se usan en subastas protegidas sin enviar a nivel del evento datos del usuario fuera de los servicios que se ejecutan en TEE. Proporcionaremos más detalles en una actualización posterior.

A corto plazo, proporcionaremos una forma temporal de salida de datos con ruido desde generateBid() A continuación, presentamos nuestra propuesta inicial para esta implementación, y la modificaremos (incluidos los posibles cambios que generen incompatibilidad con versiones anteriores) comentarios.

Técnicamente, esto funciona de la siguiente manera:

Las tecnologías publicitarias definen un esquema para los datos que quieren transmitir.
En generateBid(), compilan la carga útil de salida deseada.
La plataforma valida la carga útil de salida en función del esquema y aplica límites de tamaño.
La plataforma agrega ruido a la carga útil de salida.
La carga útil de salida se incluye en el informe de anuncios ganadores en formato de cable, que se recibió el de tecnología publicitaria, decodificados y usados para el entrenamiento de modelos.

Define el esquema de las cargas útiles de salida

Para que la plataforma aplique requisitos de privacidad en constante evolución, las cargas útiles de salida deben se estructuren de forma que la plataforma pueda comprender. Las tecnologías publicitarias definirán de sus cargas útiles de salida con un archivo JSON de esquema. Ese esquema serán procesados por la plataforma y serán confidenciales ante la Licitación y de subasta que usan los mismos mecanismos que otros recursos de tecnología publicitaria como las UDF y los modelos.

Te proporcionaremos un archivo CDDL que define la estructura de ese JSON. El El archivo CDDL incluirá un conjunto de tipos de atributos compatibles (por ejemplo, que son booleanos, números enteros, buckets, etcétera). Tanto el archivo CDDL como el se controlará la versión del esquema proporcionado.

Por ejemplo, una carga útil de salida que consta de un solo atributo booleano seguido de una característica de bucket de tamaño dos se vería de la siguiente manera:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Los detalles sobre el conjunto de tipos de características compatibles están disponibles en GitHub.

Compila cargas útiles de salida en `generateBid()`

Todos los indicadores de apps protegidos de un comprador determinado están disponibles para su UDF generateBid(). Una vez que estos elementos están destacados, las tecnologías publicitarias crean su carga útil JSON. Esta carga útil de salida se incluirá en el informe de victorias del comprador para de transmisión a servidores de tecnología publicitaria.

Una alternativa a este diseño es que el cálculo del vector de salida ocurra reportWin() en lugar de generateBid(). Cada uno tiene ventajas y desventajas y finalizaremos esta decisión en respuesta a los comentarios del sector.

Valida la carga útil de salida

La plataforma validará cualquier carga útil de salida creada por la tecnología publicitaria. Validación garantiza que los valores de los atributos sean válidos para sus tipos, que se cumplan las restricciones de tamaño y que los agentes maliciosos no intenten vencer los controles de privacidad y empaquetar información adicional en sus cargas útiles de salida.

Si una carga útil de salida no es válida, se descartará en silencio de las entradas. al informe de anuncios ganadores. Esto se debe a que no queremos ofrecer depuración información a personas que actúan de mala fe y que intentan frustrar la validación.

Proporcionaremos una API de JavaScript para que las tecnologías publicitarias garanticen la carga útil de salida Crear en generateBid() pasará la validación de la plataforma:

validate(payload, schema)

Esta API de JavaScript está totalmente destinada a los emisores a determinar si una carga útil en particular pasará la validación de la plataforma. La validación real debe realizarse en la plataforma para brindan protección contra UDF generateBid() maliciosas.

Hacer ruido en la carga útil de salida

La plataforma hará ruido las cargas útiles de salida antes de incluirlas en el informe de anuncios ganadores. El umbral de ruido inicial será del 1%, y este valor puede evolucionar con el tiempo. El de seguridad no proporcionará una indicación sobre si una carga útil de salida en particular tiene ruido.

El método de ruido es el siguiente:

La plataforma carga la definición de esquema para la carga útil de salida.
El 1% de las cargas útiles de salida se elegirá para generar ruido.
Si no se elige una carga útil de salida, se conserva todo el valor original.
Si se elige una carga útil de salida, el valor de cada atributo se reemplazará con una valor aleatorio válido para ese tipo de atributo (por ejemplo, 0 o 1 para un atributo booleano).

Transmitir, recibir y decodificar la carga útil de salida para el entrenamiento de modelos

La carga útil de salida validada y con ruido se incluirá en los argumentos para reportWin() y se transmiten a los servidores de tecnología publicitaria del comprador que están fuera de la privacidad límite para el entrenamiento de modelos. La carga útil de salida tendrá el formato de cable.

Detalles sobre el formato de cable para todos los tipos de componentes y para la carga útil de salida están disponibles en GitHub.

Determina el tamaño de la carga útil de salida

El tamaño de la carga útil de salida en bits balancea utilidad y minimización de datos. Trabajaremos con la industria para determinar el tamaño adecuado a través de para realizar experimentos. Mientras llevemos a cabo esos experimentos, de entrada y salida sin límite de tamaño de bits. Esos datos de salida adicionales sin el límite de tamaño se quitará una vez que se completen los experimentos.

El método para determinar el tamaño es el siguiente:

En un principio, admitiremos dos cargas útiles de salida en generateBid():
1. egressPayload: La carga útil de salida de tamaño limitado que describimos hasta ahora en este documento. Inicialmente, el tamaño de esta carga útil de salida será de 0 bits (es decir, siempre se quitará durante la validación).
2. temporaryUnlimitedEgressPayload: Una salida temporal de tamaño ilimitado útil para los experimentos de tamaño. El formateo, la creación y el procesamiento de esta carga útil de salida usa los mismos mecanismos que egressPayload.
Cada una de estas cargas útiles de salida tendrá su propio archivo de esquema JSON: egress_payload_schema.json y temporary_egress_payload_schema.json.
Proporcionamos un protocolo para el experimento y un conjunto de métricas para determinar el modelo con varios tamaños de carga útil de salida (por ejemplo, 5, 10, ... bits).
En función de los resultados del experimento, determinamos el tamaño de la carga útil de salida con el un equilibrio correcto entre la utilidad y la privacidad.
Configuramos el tamaño de egressPayload de 0 bits al tamaño nuevo.
Después de un período de migración establecido, quitamos temporaryUnlimitedEgressPayload, y deja solo egressPayload con su nuevo tamaño.

Estamos investigando barreras técnicas adicionales para administrar este cambio (por ejemplo, encriptar egressPayload cuando aumentamos su tamaño de 0 bits). Estos detalles, junto con los plazos del experimento y la eliminación de temporaryUnlimitedEgressPayload: Se incluirá en una actualización posterior.

A continuación, explicaremos un posible protocolo de experimento para finalizar el tamaño del egressPayload Nuestro objetivo es trabajar con la industria para encontrar un tamaño que equilibre utilidad y minimización de datos. El artefacto que producirán estos experimentos es un gráfico en el que el eje x es el tamaño de la carga útil de entrenamiento en bits, y el El eje Y es el porcentaje de ingresos generados por un modelo con ese tamaño en comparación a un modelo de referencia de tamaño ilimitado.

Supongamos que estamos entrenando un modelo pInstall y nuestras fuentes de datos de entrenamiento. son nuestros registros y el contenido de los temporaryUnlimitedegressPayload que recibir cuando ganamos subastas. El protocolo para las tecnologías publicitarias primero implica experimentos:

Determinar la arquitectura de los modelos que usarán con Protected App Indicadores. Por ejemplo, tendrán que determinar si usa la factorización de modelos.
Define una métrica para medir la calidad del modelo. Las métricas sugeridas son la pérdida AUC y pérdida logística.
Definir el conjunto de atributos que usarán durante el entrenamiento de modelos
Con la arquitectura del modelo, la métrica de calidad y el conjunto de atributos realizar estudios de ablación para determinar la utilidad aportada por bit para cada modelo que quieren usar en PAS. El protocolo sugerido para el estudio de ablación es:
1. Entrenar el modelo con todos los atributos y medir la utilidad esta es la de referencia para realizar una comparación.
2. Para cada atributo que se usa para producir el modelo de referencia, entrena el modelo con atributos, excepto ellos.
3. Mide la utilidad resultante. Divide el delta por el tamaño del atributo en bits; esta es la utilidad por bit esperada para esa función.
Determinar los tamaños de la carga útil de entrenamiento que son de interés para la experimentación Mié sugerir [5, 10, 15, ..., size_of_all_training_features_for_baseline] bits. Cada uno de estos representa un posible tamaño para egressPayload que el que el experimento evaluará.
Para cada tamaño posible, selecciona un conjunto de atributos menores o iguales a ese que maximizan la utilidad por bit, con los resultados del estudio de ablación.
Entrena un modelo para cada tamaño posible y evalúa su utilidad como el porcentaje de la utilidad del modelo de referencia entrenado con todos los atributos.
Trazar los resultados en un gráfico donde el eje X sea el tamaño del entrenamiento carga útil en bits, y el eje Y es el porcentaje de ingresos generados por en comparación con el modelo de referencia.

Luego, las tecnologías publicitarias pueden repetir los pasos 5 a 8 en los experimentos de tráfico en vivo, mediante datos enviados a través de temporaryUnlimitedEgressPayload. Las tecnologías publicitarias pueden elegir compartir los resultados de sus experimentos de tráfico en vivo y sin conexión con Privacy Sandbox para informar la decisión sobre el tamaño de egressPayload.

El cronograma de estos experimentos, así como el cronograma para establecer el tamaño de egressPayload al valor resultante, está fuera del alcance de este documento. y los abordaremos más adelante.

Medidas de protección de datos

Aplicaremos una serie de protecciones a los datos de salida, incluidas las siguientes:

egressPayload y temporaryUnlimitedEgressPayload tendrán ruido.
Para la minimización y protección de datos, temporaryUnlimitedEgressPayload estarán disponibles solo durante los experimentos de tamaño, en los que determinar el tamaño correcto para egressPayload

Permisos

Control de usuarios

La propuesta pretende dar a los usuarios visibilidad de la lista de apps instaladas que almacenaron, al menos, un indicador de apps protegido o un público personalizado.
Los usuarios pueden bloquear y quitar apps de esta lista. Bloquear y quitar implica lo siguiente:
- Borra todos los indicadores de apps protegidos y los públicos personalizados asociados con la aplicación.
- Impedir que las apps almacenen nuevos indicadores de apps protegidos y públicos personalizados.
Los usuarios pueden restablecer, por completo, las APIs de Protected App Signals y Protected Audience. Cuando esto sucede, todas las apps protegidas existentes Se borran los indicadores y los públicos personalizados del dispositivo.
Los usuarios pueden inhabilitar, por completo, Privacy Sandbox en Android, que incluye las APIs de Protected App Signals y Protected Audience. Cuando sucede, las APIs de Protected Audience y Protected App Signals devuelven un mensaje de excepción estándar: SECURITY_EXCEPTION.

Permisos y control de la app

El objetivo de la propuesta es proporcionar control a las apps sobre sus indicadores protegidos:

Una app puede administrar sus asociaciones con los indicadores de apps protegidos.
Una app puede otorgar permisos a plataformas de tecnología publicitaria de terceros para que administren Indicadores de apps protegidos en su nombre.

Control de plataformas de tecnología publicitaria

En esta propuesta, se describen las maneras en que las tecnologías publicitarias pueden controlar sus indicadores de apps protegidos:

Todas las tecnologías publicitarias deben inscribirse con Privacy Sandbox y proporcionan un dominio del "sitio" o "origen" que hace coincidir todas las URLs para indicadores de apps protegidos.
Las tecnologías publicitarias pueden asociarse con apps o SDKs para proporcionar tokens de verificación que se usan para verificar la creación de indicadores de apps protegidos. Cuando este proceso se delega a un socio, la creación de indicadores de apps protegidos se puede configurar de modo que se requiera la confirmación de la tecnología publicitaria.