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

Esta propuesta está sujeta al proceso de inscripción y las certificaciones de Privacy Sandbox. Para obtener más información sobre las certificaciones, consulta el vínculo de certificación proporcionado. En las próximas actualizaciones de esta propuesta, se describirán 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:

1. 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 por app autodefinidos, como instalaciones de apps, primeros accesos, acciones del usuario (nivelación en el juego, logros), actividades de compra o tiempo en la app. Los indicadores se escriben y almacenan en el dispositivo para protegerse contra la filtración de datos y solo están disponibles para la lógica de tecnología publicitaria que almacenó el indicador determinado durante una subasta protegida que se ejecuta en un entorno seguro.
2. 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 el que las tecnologías publicitarias recuperan candidatos de anuncios, ejecutan inferencias, calculan ofertas y realizan puntuaciones para elegir un anuncio "ganador" con los indicadores de apps protegidos y la información contextual en tiempo real proporcionada por el publicador.

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 apps para dispositivos móviles, las tecnologías publicitarias seleccionan indicadores almacenando eventos de apps definidos por la tecnología publicitaria para publicar anuncios relevantes con la API de Protected App Signals. Estos eventos se almacenan en un almacenamiento protegido en el dispositivo, similar a los públicos personalizados, y se encriptan antes de enviarse fuera del dispositivo, de modo que solo los servicios de ofertas y subastas que se ejecutan en entornos de ejecución confiables con la seguridad y el control de privacidad adecuados puedan desencriptarlos para la licitación y la puntuación de anuncios.
• Codificación de indicadores: Los indicadores se preparan según una frecuencia programada por la lógica de la tecnología publicitaria personalizada. Un trabajo en segundo plano de Android ejecuta esta lógica para realizar la codificación integrada en el dispositivo a fin de generar una carga útil de indicadores de apps protegidas que luego se puedan usar en tiempo real para la selección de anuncios durante una subasta protegida. La carga útil se almacena de forma segura en el dispositivo hasta que se envía para una subasta.
• Selección de anuncios: A fin de seleccionar anuncios relevantes para el usuario, los SDK del vendedor envían una carga útil encriptada de indicadores de apps protegidos y configuran una subasta protegida. En la subasta, la lógica personalizada del comprador prepara los indicadores de apps protegidas junto con los datos contextuales proporcionados por el publicador (datos que suelen compartirse en una solicitud de anuncio Open-RTB) para diseñar funciones destinadas a la selección de anuncios (recuperación de anuncios, inferencia y generación de ofertas). Al igual que con Protected Audience, los compradores envían anuncios al vendedor para obtener 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 desarrollar funciones relevantes para los intereses del usuario. Estas funciones se utilizan para hacer coincidir anuncios que cumplen con los criterios de segmentación. Se filtran los anuncios que no se encuentran dentro del presupuesto. Luego, se seleccionan los k anuncios superiores para las ofertas.
  • 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: La lógica de puntuación personalizada del vendedor asigna una puntuación a los anuncios que envían los compradores participantes y elige un anuncio ganador que se enviará de vuelta 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 SDK integrado pueden almacenar o borrar indicadores de apps protegidos definidos por las tecnologías publicitarias según la actividad del usuario, como aperturas de la app, logros, actividad de compra o tiempo en la app. Los indicadores de apps protegidas se almacenan de forma segura en el dispositivo y se encriptan antes de enviarse fuera del dispositivo para que solo los servicios de ofertas y subastas que se ejecuten en entornos de ejecución confiables con la seguridad y el control de privacidad adecuados puedan desencriptarlos para las ofertas y los anuncios de puntuación. Al igual que la API de Custom Audience, las apps o los SDKs no pueden leer ni inspeccionar los indicadores almacenados en un dispositivo; no hay una API para leer los valores de los indicadores, y las APIs están diseñadas para evitar que se filtren la presencia de indicadores. 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 a fin de prepararlos para otras tareas de ingeniería de atributos en tiempo real durante una subasta protegida que se ejecuta 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 indicadores. A modo de ejemplo, fetchSignalUpdates() emite una solicitud GET al URI específico para recuperar la lista de actualizaciones que se aplicarán al almacenamiento de indicadores locales. El extremo de URL, que es propiedad del 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 podría ser útil, por ejemplo, para establecer un ID de experimento para un usuario determinado y evitar anularlo si ya lo configuró una aplicación diferente.
• 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 la serie temporal. 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 solicitud de recuperación y con la persona que responde la solicitud (el "sitio" o el "origen" de una tecnología publicitaria inscrita), además de 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.

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

1. El SDK del vendedor envía la carga útil encriptada e integrada en el dispositivo de los indicadores de apps protegidos.
2. 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.
3. El servicio de ofertas y subastas del vendedor pasa la carga útil a los servidores de frontend de los compradores participantes de confianza.
4. 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
5. Se ejecuta la lógica de puntuación orientada a la venta.
6. 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, el SDK de tecnología publicitaria (por lo general, las SSP) inicia el flujo de trabajo de selección de anuncios enviando los datos contextuales relevantes del publicador y las cargas útiles encriptadas por comprador que se incluirán en la solicitud que se enviará a la subasta protegida con la llamada getAdSelectionData. Es la misma API que se usa para el flujo de trabajo del remarketing y que se describe en la propuesta Integración de ofertas y 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 que usan:

  • auction_config.auction_signals (para obtener información sobre la subasta)

  • auction_config.seller_signals (para los indicadores del vendedor)

  • auction_config.per_buyer_config["buyer"].buyer_signals (para los indicadores de los compradores)

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

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.

1. El servicio de BuyerFrontEnd recibe una solicitud de anuncio.
2. 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 k candidatos principales del servicio de recuperación de anuncios. El servicio de ofertas envía esta solicitud al extremo del servidor de recuperación configurado.
3. El servicio de recuperación de anuncios ejecuta la UDF getCandidateAds(), que filtra hasta el conjunto de anuncios candidatos principales k, que se envían al servicio de ofertas del comprador.
4. 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.
5. 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:

1. 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).
2. 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 se pasan a las UDF en el per_buyer_signals.
3. 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.
4. 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 campos auction_signals (para información sobre la subasta) y buyer_signals (para los campos de indicadores de compradores) de los indicadores contextuales.

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 incorporaciones privadas para la recuperación: si se necesitan predicciones de recuperación, realiza la llamada al servicio de inferencia mediante los atributos anteriores y obtiene una incorporación privada para las predicciones en el 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:

1. 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.
2. 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.
3. 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.
4. Recuperación de incorporación de ofertas: Si el código de ofertas necesita incorporaciones del servicio de par clave-valor para hacer predicciones en el momento de la oferta, estas se pueden recuperar 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 la entrada de indicadores específicos de la subasta
• Incorporaciones privadas que se pasan con la entrada de indicadores adicionales
• Todas las tecnologías publicitarias de incorporación no privada se materializaron de sus servidores en el 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, esto puede incluir información sobre la campaña publicitaria y criterios de segmentación, como la ubicación y el idioma. Los metadatos pueden incluir incorporaciones opcionales que se usan cuando se necesita la factorización de modelos para ejecutar la inferencia durante las ofertas.
• Indicadores adicionales: De manera opcional, el servicio de recuperación de anuncios puede incluir información adicional, como incorporaciones adicionales o indicadores de spam para usar 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:

• Featurización: Transforma indicadores en atributos para su uso 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 a fin de calcular la oferta 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 pueden usar durante la inferencia para predecir factores como la tasa de clics y los 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:

1. 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).
2. 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.
3. En generateBid():
   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. Esta es la predicción final que se puede usar 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 la instalación de aplicaciones se especifica de la misma manera que el flujo de remarketing de Protected Audience. Para obtener más detalles, consulta la configuración de ofertas y subastas. El código de oferta estará disponible en la misma ubicación de almacenamiento en la nube que la que se utiliza para el remarketing.

Informes

En esta propuesta, se usan las mismas APIs de informes que la propuesta de informes de Protected Audience (por ejemplo, reportImpression(), que activa la plataforma para enviar informes de vendedores y compradores).

Un caso de uso común para generar informes orientados a la compra es obtener los datos de entrenamiento de 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 salir de datos a nivel de evento de la plataforma a servidores de tecnología publicitaria. Estas cargas útiles de salida pueden incluir ciertos datos del usuario.

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

A corto plazo, proporcionaremos una forma temporal de salida de datos con ruido desde generateBid(). A continuación, se incluye nuestra propuesta inicial para esto, y la mejoraremos (incluidos los posibles cambios incompatibles con versiones anteriores) en respuesta a los comentarios de la industria.

Técnicamente, esto es así:

1. Las tecnologías publicitarias definen un esquema para los datos que quieren transmitir.
2. En generateBid(), compilan la carga útil de salida deseada.
3. La plataforma valida la carga útil de salida con el esquema y aplica límites de tamaño.
4. La plataforma agrega ruido a la carga útil de salida.
5. La carga útil de salida se incluye en el informe de éxito en formato de conexión, se recibe en servidores de tecnología publicitaria, se decodifica y se usa para el entrenamiento de modelos.

Define el esquema de las cargas útiles de salida

Para que la plataforma aplique los requisitos de privacidad en constante evolución, las cargas útiles de salida deben estructurarse de manera tal que la plataforma pueda comprenderlas. Las tecnologías publicitarias definirán la estructura de sus cargas útiles de salida mediante un archivo JSON de esquema. La plataforma procesará ese esquema y será confidencial por los servicios de ofertas y subastas con los mismos mecanismos que otros recursos de tecnología publicitaria, como UDF y modelos.

Proporcionaremos un archivo CDDL que define la estructura de ese JSON. El archivo CDDL incluirá un conjunto de tipos de atributos admitidos (por ejemplo, atributos booleanos, números enteros, buckets, etc.). Se controlará el control de versiones del archivo CDDL y el esquema proporcionado.

Por ejemplo, una carga útil de salida que consta de un único atributo booleano seguido de un atributo 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 funciones admitidos están disponibles en GitHub.

Compila cargas útiles de salida en generateBid()

Todos los indicadores de apps protegidas de un comprador determinado están disponibles para su UDF generateBid(). Una vez que esto se logra, las tecnologías publicitarias crean su carga útil en formato JSON. Esta carga útil de salida se incluirá en el informe de éxito del comprador para la transmisión a servidores de tecnología publicitaria.

Una alternativa a este diseño es que el cálculo del vector de salida se realice en reportWin() en lugar de generateBid(). Cada enfoque tiene ventajas y desventajas, y finalizaremos esta decisión según los comentarios de la industria.

Valida la carga útil de salida

La plataforma validará cualquier carga útil de salida creada por la tecnología publicitaria. La 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 actores maliciosos no intenten vencer los controles de privacidad empaquetando 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 enviadas al informe de éxito. Esto se debe a que no queremos proporcionar información de depuración a ninguna persona que actúa de mala fe que intenta anular la validación.

Proporcionaremos una API de JavaScript para que las tecnologías publicitarias aseguren que la carga útil de salida que creen en generateBid() pase la validación de la plataforma:

validate(payload, schema)

Esta API de JavaScript está pensada exclusivamente para que los llamadores determinen si una carga útil en particular pasará la validación de la plataforma. La validación real debe realizarse en la plataforma para protegerte contra las UDF generateBid() maliciosas.

Haz ruido en la carga útil de salida

La plataforma detectará las cargas útiles de salida antes de incluirlas en el informe de éxito. El umbral de ruido inicial será del 1%, y este valor puede evolucionar con el tiempo. La plataforma no proporcionará una indicación si se hizo ruido una carga útil de salida en particular.

El método de generación de ruido es el siguiente:

1. La plataforma carga la definición de esquema para la carga útil de salida.
2. Se elegirá el 1% de las cargas útiles de salida para el ruido.
3. Si no se elige una carga útil de salida, se conserva todo el valor original.
4. Si se elige una carga útil de salida, el valor de cada atributo se reemplazará por un 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 con ruido se incluirá en los argumentos de reportWin() y se transmitirá a los servidores de tecnología publicitaria del comprador que estén fuera de los límites de privacidad para el entrenamiento de modelos. La carga útil de salida estará en su formato de cable.

Los detalles sobre el formato de conexión para todos los tipos de funciones y la carga útil de salida en sí 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 equilibra la utilidad y la minimización de datos. Trabajaremos con la industria para determinar el tamaño apropiado a través de la experimentación. Mientras ejecutemos esos experimentos, saldremos de manera temporal los datos sin límite de tamaño de bits. Esos datos de salida adicionales sin límite de tamaño de bits se quitarán una vez que se completen los experimentos.

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

1. Inicialmente, 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 (lo que significa que siempre se quitará durante la validación).
   2. temporaryUnlimitedEgressPayload: Es una carga útil de salida temporal de tamaño ilimitado para experimentos de tamaño. El formato, la creación y el procesamiento de esta carga útil de salida usan los mismos mecanismos que egressPayload.
2. Cada una de estas cargas útiles de salida tendrá su propio archivo JSON de esquema: egress_payload_schema.json y temporary_egress_payload_schema.json.
3. Proporcionamos un protocolo de experimento y un conjunto de métricas para determinar la utilidad del modelo con varios tamaños de cargas útiles de salida (por ejemplo, 5, 10, etc.).
4. En función de los resultados del experimento, determinamos el tamaño de la carga útil de salida con las compensaciones correctas entre la utilidad y la privacidad.
5. Configuramos el tamaño de egressPayload de 0 bits al nuevo tamaño.
6. Después de un período de migración establecido, quitamos temporaryUnlimitedEgressPayload y dejamos solo egressPayload con su tamaño nuevo.

Estamos investigando barreras de seguridad técnicas adicionales para administrar este cambio (por ejemplo, encriptar egressPayload cuando aumentamos su tamaño de 0 bits). Esos detalles, junto con información adicional, como el protocolo del experimento, el tiempo de este, y el cronograma para quitar temporaryUnlimitedEgressPayload, se incluirán en una actualización posterior.

Medidas de protección de datos

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

1. Se hará ruido en egressPayload y temporaryUnlimitedEgressPayload.
2. Para la minimización y protección de datos, temporaryUnlimitedEgressPayload solo estará disponible mientras duren los experimentos de tamaño, en los que determinaremos el tamaño correcto de 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:
  • Se borran todos los indicadores de apps protegidos y los públicos personalizados asociados con la app.
  • 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, se borran todos los indicadores de apps protegidos y los públicos personalizados existentes 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 los indicadores de apps protegidas 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 usen para verificar la creación de indicadores de apps protegidas. 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.