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

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Esta propuesta está sujeta al proceso de inscripción y a 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 definidos por el usuario, como las instalaciones de la app, los primeros accesos, las acciones del usuario (niveles en el juego, logros), las actividades de compra o el tiempo en la app. Los indicadores se escriben y almacenan en el dispositivo para proteger contra la filtración de datos y solo están disponibles para la lógica de la 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 anuncios candidatos, 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 que proporciona 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 plataformas de tecnología publicitaria seleccionan indicadores almacenando eventos de apps que define 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 desde el dispositivo, de modo que solo los servicios de ofertas y subastas que se ejecutan en entornos de ejecución confiables con el control de seguridad y privacidad adecuado puedan desencriptarlos para realizar ofertas 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. Un trabajo 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 pueda usar, posteriormente, 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 a una subasta.
• Selección de anuncios: Para seleccionar anuncios relevantes para el usuario, los SDKs del vendedor envían una carga útil encriptada de los indicadores de apps protegidos y configuran una subasta protegida. En la subasta, la lógica personalizada del comprador prepara los indicadores de apps protegidos junto con los datos contextuales que proporciona el publicador (datos que se suelen compartir en una solicitud de anuncio de Open-RTB) para diseñar atributos destinados 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 que proporciona el publicador para diseñar atributos relevantes para los intereses del usuario. Estos atributos se usan para hacer coincidir los anuncios que cumplen con los criterios de segmentación. Se filtran los anuncios que no se encuentran dentro del presupuesto. Luego, se seleccionan los anuncios Top-K 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 la puntuación personalizada de los vendedores califica los anuncios que envían los compradores participantes y elige un anuncio ganador que se devolverá 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

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 los indicadores de apps protegidos que definen las tecnologías publicitarias según la actividad del usuario, como aperturas de apps, logros, actividad de compra o tiempo en la app. Los indicadores de apps protegidos se almacenan de forma segura en el dispositivo y se encriptan antes de enviarse, de modo que solo los servicios de ofertas y subastas que se ejecutan en entornos de ejecución confiables con el control de seguridad y privacidad adecuados puedan desencriptarlos para realizar ofertas y calificar anuncios. 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 existe una API para leer los valores de los indicadores, y las APIs están diseñadas para evitar que se filtre la presencia de los 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 y prepararlos para la ingeniería de atributos adicional 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 los indicadores. A modo de ejemplo, fetchSignalUpdates() emite una solicitud GET al URI determinado para recuperar la lista de actualizaciones que se aplicarán al almacenamiento de indicadores locales. El extremo de URL, 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 el 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 incluye 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 quien responde la solicitud (el "sitio" o "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 para que se incluyan en la solicitud que se enviará a la subasta protegida con la llamada a getAdSelectionData. Esta es la misma API que se usa para el flujo de trabajo de remarketing y se describe en la propuesta de 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 con lo siguiente:

  • auction_config.auction_signals (para la 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 del comprador)

• 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 candidatos Top-K del servicio de recuperación de anuncios. El servicio de ofertas envía esta solicitud al extremo configurado del servidor de recuperación.
3. El servicio de recuperación de anuncios ejecuta la UDF getCandidateAds(), que filtra hasta el conjunto de anuncios candidatos Top-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 objeto 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.
• El objeto auction_signals de los indicadores contextuales (para la información sobre la subasta) y buyer_signals (para los campos de los indicadores del comprador)

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.
• Cálculo de las incorporaciones privadas para su recuperación: Si se necesitan predicciones de recuperación, se realiza la llamada al servicio de inferencia con los atributos anteriores y se obtiene 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:

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 incorporaciones de ofertas: Si el código de ofertas necesita incorporaciones del servicio de par clave-valor para realizar predicciones del tiempo de ofertas, 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
• Cualquier tecnología publicitaria de incorporación no privada se materializó a partir 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 inferencias 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:

• 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 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. Estos atributos se pueden usar durante la inferencia para predecir información, como el porcentaje de clics y 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(), 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. 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 aplicación 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 se utiliza para el remarketing.

Informes

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

Un caso de uso común para generar informes sobre el lado del comprador es obtener los 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 de la plataforma a los servidores de tecnología publicitaria. Estas cargas útiles de salida pueden incluir ciertos datos del usuario.

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

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

Técnicamente, funciona de la siguiente manera:

1. Las tecnologías publicitarias definen un esquema para los datos que desean transmitir.
2. En generateBid(), compilan la carga útil de salida deseada.
3. La plataforma valida la carga útil de salida en función del esquema y aplica los 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 anuncios ganadores en formato de cable, se recibe en los servidores de tecnología publicitaria, se decodifica y se usa para el entrenamiento de modelos.

Cómo definir el esquema de las cargas útiles de salida

Para que la plataforma aplique los requisitos de privacidad en evolución, las cargas útiles de salida deben estar estructuradas de una manera que la plataforma pueda entender. Las tecnologías publicitarias definirán la estructura de sus cargas útiles de salida proporcionando un archivo JSON de esquema. La plataforma procesará ese esquema, y los servicios de ofertas y subastas lo mantendrán en secreto con los mismos mecanismos que otros recursos de tecnología publicitaria, como las UDF y los modelos.

Te proporcionaremos un archivo CDDL que defina la estructura de ese JSON. El archivo CDDL incluirá un conjunto de tipos de atributos admitidos (por ejemplo, atributos booleanos, enteros, buckets, etcétera). Se creará una versión del archivo CDDL y del esquema proporcionado.

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

Cómo compilar 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 se crean las funciones, las tecnologías publicitarias crean su carga útil en formato JSON. Esta carga útil de salida se incluirá en el informe de ganancias del comprador para su transmisión a los 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 sus ventajas y desventajas, y tomaremos la decisión final en función de 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 asegura que los valores de las funciones sean válidos para sus tipos, que se cumplan las restricciones de tamaño y que las partes interesadas maliciosas no intenten anular 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á de forma silenciosa de las entradas que se envían al informe de ganancias. Esto se debe a que no queremos proporcionar información de depuración a ninguna persona malintencionada que intente evitar la validación.

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

validate(payload, schema)

Esta API de JavaScript es completamente para que los llamadores determinen si una carga útil en particular superará la validación de la plataforma. La validación real se debe realizar en la plataforma para protegerte contra las UDF generateBid() maliciosas.

Genera ruido en la carga útil de salida

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

El método de contaminación es el siguiente:

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

Transmisión, recepción y decodificación de la carga útil de salida para el entrenamiento de modelos

La carga útil de salida validada y con ruido se incluirá en los argumentos de reportWin() y se transmitirá a los servidores de tecnología publicitaria del comprador fuera de los límites de privacidad para el entrenamiento del modelo. La carga útil de salida estará en formato de cable.

Los 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 equilibra la utilidad y la minimización de datos. Trabajaremos con la industria para determinar el tamaño adecuado mediante la experimentación. Mientras ejecutamos esos experimentos, exportaremos datos temporalmente sin limitaciones de tamaño de bits. Esos datos de salida adicionales sin limitación 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: Una carga útil de salida temporal ilimitada en tamaño 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 en varios tamaños de carga útil de salida (por ejemplo, 5, 10, … bits).
4. En función de los resultados del experimento, determinamos el tamaño de la carga útil de salida con las compensaciones correctas de utilidad y privacidad.
5. Establecemos 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 solo dejamos egressPayload con su nuevo tamaño.

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

A continuación, explicaremos un posible protocolo de experimento para finalizar el tamaño de egressPayload. Nuestro objetivo es trabajar con la industria para encontrar un tamaño que equilibre la utilidad y la 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 eje Y es el porcentaje de ingresos que genera un modelo de ese tamaño en comparación con un modelo de referencia sin límite de tamaño.

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

1. Determina la arquitectura de los modelos que usarán con los indicadores de apps protegidos. Por ejemplo, deberá determinar si usará o no la factorización de modelos.
2. Define una métrica para medir la calidad del modelo. Las métricas sugeridas son la pérdida de AUC y la pérdida de registro.
3. Define el conjunto de atributos que usará durante el entrenamiento del modelo.
4. Con esa arquitectura de modelo, métrica de calidad y conjunto de atributos de entrenamiento, ejecuta estudios de ablación para determinar la utilidad que se aporta por bit para cada modelo que se desea usar en PAS. El protocolo sugerido para el estudio de ablación es el siguiente:
   1. Entrena el modelo con todas las funciones y mide la utilidad. Este es el modelo de referencia para la comparación.
   2. Para cada atributo que se usa para producir el modelo de referencia, entrena el modelo con todos los atributos excepto ese atributo.
   3. Mide la utilidad resultante. Divide el delta por el tamaño de la función en bits. Esta es la utilidad esperada por bit para esa función.
5. Determina los tamaños de carga útil de entrenamiento que son de interés para la experimentación. Te recomendamos [5, 10, 15, …, size_of_all_training_features_for_baseline] bits. Cada uno de ellos representa un tamaño posible para egressPayload que el experimento evaluará.
6. Para cada tamaño posible, selecciona un conjunto de atributos inferior o igual a ese tamaño que maximice la utilidad por bit con los resultados del estudio de abstracción.
7. Entrena un modelo para cada tamaño posible y evalúa su utilidad como un porcentaje de la utilidad del modelo de referencia entrenado en todas las características.
8. Grafica los resultados en un gráfico en el que el eje x sea el tamaño de la carga útil de entrenamiento en bits y el eje y sea el porcentaje de ingresos que genera ese modelo en comparación con el modelo de referencia.

A continuación, las tecnologías publicitarias pueden repetir los pasos del 5 al 8 en los experimentos de tráfico en vivo con los datos de atributos que se envían a través de temporaryUnlimitedEgressPayload. Las tecnologías publicitarias pueden optar por compartir los resultados de sus experimentos de tráfico sin conexión y publicado con Privacy Sandbox para fundamentar 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 en el valor resultante, excede el alcance de este documento y se incluirá 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. Tanto egressPayload como temporaryUnlimitedEgressPayload tendrán ruido.
2. Para la minimización y protección de datos, temporaryUnlimitedEgressPayload estará disponible solo durante la ejecución de los experimentos de tamaño, en los que determinaremos 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 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 en el 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 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 usen para comprobar 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.