Integración y optimización de los servicios de ofertas y subastas

La propuesta de diseño de los servicios de ofertas y subastas para Android detalla el flujo de ejecución y datos de la ejecución de subastas en Android con el servidor de ofertas y subastas de confianza. Para garantizar que solo las APIs que preservan la privacidad y los servidores de confianza controlen los datos en tránsito, los datos se encriptan entre el cliente y el servidor con la encriptación bidireccional de claves públicas híbridas.

Para ejecutar la subasta como se detalló antes, la tecnología publicitaria del vendedor en el dispositivo debe realiza los siguientes pasos:

1. Recopilar y encriptar datos para una subasta del servidor
2. Enviar una solicitud a un servicio de vendedor no confiable
3. Recibir una respuesta de un servicio de vendedor no confiable
4. Desencriptar la respuesta de la subasta de Protected Audience y obtener el resultado

Protected Audience presenta dos APIs nuevas para admitir la ejecución de subastas del servidor:

1. La API de getAdSelectionData recopila datos para la subasta del servidor y genera una carga útil encriptada que contiene datos de la subasta. El servidor de ofertas y subastas usa esta carga útil para ejecutar una subasta, generar el resultado y, luego, mostrarlo.
2. Los clientes de tecnología publicitaria en el dispositivo pueden llamar a la API de persistAdSelectionResult para desencriptar el resultado que genera la subasta del servidor y obtener la URL de renderización de anuncios ganadora.

La tecnología publicitaria del vendedor en el dispositivo debe integrar y crear lo siguiente para ejecutar una subasta:

1. Recopilar y encriptar datos para el vendedor de la subasta del servidor: La tecnología publicitaria debe llamar a la API de getAdSelectionData para obtener la carga útil encriptada.
2. Enviar una solicitud a un servicio de vendedor no confiable: Una solicitud HTTP POST o PUT que contiene la carga útil encriptada que genera la API de getAdSelectionData para su servicio de vendedor no confiable y los datos que requiere este servicio para generar resultados contextuales.
3. Recibir una respuesta de un servicio de vendedor no confiable: La respuesta del servicio de vendedor no confiable contendrá el resultado encriptado de la subasta de Protected Audience y el resultado de la subasta contextual.
4. Desencriptar la respuesta de la subasta de Protected Audience y obtener el resultado: Para desencriptar el resultado de la subasta de Protected Audience, la tecnología publicitaria del vendedor debe llamar la API de persistAdSelectionResult. El resultado que genera persistAdSelectionResult ayudarán a las plataformas de tecnología publicitaria a determinar si los anuncio o de Protected Audience ganaron la subasta y el URI del ganador anuncio de Protected Audience, si corresponde.

Funciones admitidas para la subasta del servidor

Nuestro objetivo es admitir todas las funciones disponibles para la subasta en el dispositivo. El cronograma para admitir estas funciones en la subasta del servidor es el siguiente:

Ejecuta subastas del servidor con las APIs de Protected Audience

En el segmento de la Versión preliminar para desarrolladores, AdSelectionManager expone dos APIs nuevas: getAdSelectionData y persistAdSelectionResult. Estas APIs permiten a los SDKs de tecnología publicitaria integrarse en los servidores de ofertas y subastas.

Recopila y encripta datos para una subasta del servidor

La API de getAdSelectionData genera la entrada requerida para los componentes de ofertas y subastas, como BuyerInput y ProtectedAudienceInput, y encripta los datos antes de que el resultado esté disponible para el llamador. Para evitar la filtración de datos en las apps, estos contienen información de todos los compradores presentes en el dispositivo. Obtén más información sobre esta decisión en la sección de consideraciones de la privacidad y las estrategias de optimización en la sección de consideraciones de tamaño.

Para acceder a la API, se debe habilitar el acceso a la API de Protected Audience y el permiso ACCESS_ADSERVICES_CUSTOM_AUDIENCE debe definirse en el manifiesto del llamador.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. El llamador debe establecer el campo seller en la solicitud, ya que se usa para ejecutar verificaciones de inscripción antes de revisar la solicitud.
2. El campo coordinatorOriginUri es opcional.
   1. Si se establece, debe ser igual al esquema, el nombre de host y el puerto del parámetro de configuración del proyecto que se configuró implementar el servidor de B&A del vendedor
   2. El coordinador debe pertenecer a la lista de coordinadores aprobados:

      Proveedor	URI	Origen del URI	Predeterminado
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	Sí
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	No

   3. Si no se proporciona un origen de coordinador, se usa el predeterminado.
   4. Aunque es poco probable que la URL de coordinador cambie, se recomienda implementar un mecanismo para administrar esta URL de forma dinámica. Esto garantiza que cualquier cambio futuro en la URL pueda adaptarse sin necesidad de realizar una nueva versión del SDK.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

Después de validar la solicitud, los datos del comprador en el dispositivo se componen de BuyerInput y ProtectedAudienceInput. Luego, el objeto de carga útil final se encripta con la encriptación de claves públicas híbridas.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome se genera como resultado de la API de getAdSelectionData. Contiene lo siguiente:

1. adSelectionId: Es un número entero opaco para identificar esta invocación de getAdSelectionData. El cliente de tecnología publicitaria debe conservar este valor de adSelectionId porque actúa como el puntero de la llamada a getAdSelectionData. La API de persistAdSelectionResult requiere este identificador para desencriptar el resultado de la subasta desde el servidor de ofertas y subastas, y también es necesario para las APIs de reportImpression y reportEvent.
2. adSelectionData: Estos son los datos de la subasta encriptados que requerirían el servidor de ofertas y subastas para ejecutar subastas. Este método contiene lo siguiente:
   1. Los datos del público personalizado filtrados basados en la limitación de frecuencia, los filtros de instalación de apps y los requisitos de subasta del servidor para los públicos personalizados.
   2. En una versión futura, contendrá datos de instalación de apps.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Manejo de errores, excepciones y fallas

Si la generación de datos de selección de anuncios no se puede completar correctamente debido a motivos como argumentos no válidos, tiempos de espera o un consumo excesivo de recursos, la devolución de llamada OutcomeReceiver.onError() proporciona una AdServicesException con los siguientes comportamientos:

1. Si se inicia getAdSelectionData con argumentos no válidos, la AdServicesException indica una IllegalArgumentException como la causa.
2. Todos los demás errores recibirán AdServicesException con IllegalStateException como la causa.

Envía una solicitud a un servicio de vendedor no confiable

Con AdSelectionData, el SDK integrado en el dispositivo puede enviar una solicitud al servicio de anuncios del vendedor. Para ello, debe incluir los datos en una solicitud POST o PUT:

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

El SDK integrado en el dispositivo es responsable de codificar estos datos. Se recomienda usar una solución eficiente en el espacio, como enviar la solicitud al servicio de anuncios del vendedor como datos de varias partes o de formulario.

Recibe una respuesta de un servicio de vendedor no confiable

Como se detalla en la explicación del servidor de ofertas y subastas, cuando el servicio de vendedor no confiable recibe la solicitud, realiza llamadas a compradores socios para los anuncios contextuales.

El servicio de vendedor no confiable reenvía el adSelectionData y la AuctionConfig encriptados al servicio de SellerFrontEnd del servidor de ofertas y subastas que se ejecuta en un TEE.

Cuando se completa la subasta de Protected Audience, el servicio de SellerFrontEnd encripta el resultado de la subasta y lo muestra una como respuesta al servicio de vendedor no confiable.

El servicio de vendedor no confiable envía una respuesta al dispositivo que contiene el resultado encriptado de la subasta de Protected Audience o el resultado de la subasta de anuncio contextual.

Cuando recibe la respuesta, el código de la tecnología publicitaria del vendedor en el dispositivo puede elegir solo usar el anuncio contextual en la respuesta o, si considera que hay un valor incremental en obtener el resultado de Protected Audience, puede optar por desencriptar el resultado de Protected Audience llamando a la API de PersistAdSelectionResult.

API de PersistAdSelectionResult

Para desencriptar el resultado de Protected Audience, la tecnología publicitaria del vendedor puede llamar a persistAdSelectionResult de la segunda API de Protected Audience. La API desencripta el resultado y muestra un AdSelectionOutcome, el mismo objeto que se muestra hoy a partir de una subasta en el dispositivo.

Para acceder a la API, el llamador debe habilitar el acceso a la API de Protected Audience y definir el permiso ACCESS_ADSERVICES_CUSTOM_AUDIENCE en su manifiesto.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

El llamador debe establecer lo siguiente en la solicitud:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: Es el identificador opaco que genera la llamada a getAdSelectionData, cuyo resultado el llamador desea desencriptar.
2. seller: Es el identificador de tecnología publicitaria del vendedor debe establecerse en la solicitud para ejecutar verificaciones de inscripción antes de revisar la solicitud.
3. adSelectionResult: Es el resultado de la subasta encriptado que genera el servidor de ofertas y subastas que el emisor desea desencriptar.

Respuesta de AdSelectionOutcome

Si hay un ganador de Protected Audience, AdSelectionOutcome muestra el URI de renderización del anuncio ganador. Una vez que se desencripta adSelectionResult, los datos de informes persisten de forma interna. La devolución de llamada OutcomeReceiver.onResult() muestra un AdSelectionOutcome que contiene lo siguiente:

• URI: Si hay un anuncio de Protected Audience ganador, se muestra una URL de renderización del anuncio ganador. Si no hay un ganador de Protected Audience, se muestra "Uri.EMPTY".
• adSelectionId: Es el adSelectionId asociado a la ejecución de la subasta de este servidor.

Manejo de errores, excepciones y fallas

Si la generación de datos de selección de anuncios no se puede completar correctamente debido a motivos como argumentos no válidos, tiempos de espera o un consumo excesivo de recursos, la devolución de llamada OutcomeReceiver.onError() proporciona una AdServicesException con los siguientes comportamientos:

1. Si se inicia getAdSelectionData con argumentos no válidos, AdServicesException indica un IllegalArgumentException como la causa.
2. Todos los demás errores recibirán AdServicesException con IllegalStateException como la causa.

Consideraciones de privacidad

adSelectionData está encriptado para garantizar que solo la PPAPI y los servidores de confianza puedan acceder a los datos en tránsito.

A pesar de la encriptación, puede ocurrir una filtración de datos debido al tamaño de adSelectionData. El tamaño de adSelectionData puede variar por los siguientes motivos:

1. Hay cambios en los datos de CustomAudience presentes en el dispositivo.
2. Hay cambios en la lógica de filtrado de CustomAudience.
3. Hay cambios en la entrada de la llamada a getAdSelectionData.

Los cambios en el tamaño de adSelectionData se pueden usar para generar un identificador entre apps, como se menciona en la discusión sobre filtración de 1 bit. Aquí también se aplican muchas mitigaciones aplicables a las filtraciones de 1 bit.

Para administrar estas filtraciones, planeamos generar el mismo adSelectionData para todas las llamadas a la API de getAdSelectionData. En las versiones iniciales, todos los CustomAudiences en el dispositivo se usan para crear adSelectionData y la carga útil encriptada tendrá padding para enmascarar las variaciones de tamaño. También restringiremos la influencia de los parámetros de entrada GetAdSelectionData en los adSelectionData generados.

Sin embargo, generar el mismo adSelectionData para todas las tecnologías publicitarias que usan todos los Los datos de subasta integrados en el dispositivo crean una gran carga útil que ahora se debe transferir en cada llamada al servidor de tecnología publicitaria. El uso de todos los públicos personalizados en el dispositivo para generar una carga útil de subasta también genera que el ecosistema quede vulnerable ante el abuso de entidades maliciosas. Abordamos estas inquietudes en las secciones Optimizaciones de tamaño y Mitigación de abusos que aparecen más abajo.

Optimizaciones de tamaño

Se espera que el SDK del cliente de tecnología publicitaria empaquete los bytes encriptados de adSelectionData en la llamada contextual HTTP PUT/POST realizada al servidor de tecnología publicitaria. Para una latencia y un costo de tiempo de ida y vuelta más bajos, es necesario reducir el tamaño de adSelectionData tanto como sea posible, sin afectar la utilidad.

Planeamos explorar y, potencialmente, incorporar las siguientes optimizaciones en las próximas versiones para reducir el tamaño de adSelectionData:

1. Carga útil generada en un conjunto fijo de tamaños de bucket con padding: Para minimizar la filtración por variaciones de tamaño y seguir posibilitando cargas útiles más bajas, sugerimos usar el agrupamiento de tamaño fijo en la carga útil generada. Mantener una cantidad pequeña de buckets, por ejemplo, 7, generará menos de 3 bits de entropía filtrada por llamada a getAdSelectionData.

   Si los datos en el dispositivo superan el tamaño máximo del bucket, se usarán las estrategias mencionadas a continuación, como los valores de prioridad, para decidir qué datos se descartarán.

2. Configuración del comprador: Estamos evaluando la viabilidad de permitir que los compradores establezcan una configuración de carga útil por comprador. Esta configuración sería útil para identificar las subastas a las que un comprador le interesa unirse. Si fuera posible, durante la inscripción, una tecnología publicitaria de comprador podría registrar un extremo desde el que Protected Audience recuperaría la configuración de la carga útil a una cadencia normal diaria. Como alternativa, las APIs que preservan la privacidad expondrían una API para permitir que las tecnologías publicitarias del comprador registren este extremo.

   Esta configuración se usaría para evaluar la contribución de un comprador a los adSelectionData generados para cada solicitud getAdSelectionData.

   La configuración de la carga útil del comprador permitiría a los compradores especificar lo siguiente:

   1. Lista de vendedores permitidos: Los CustomAudiences del comprador se agregarán a la carga útil solo si un vendedor en la lista de entidades permitidas inicia la llamada getAdSelectionData. Recuperaríamos la configuración de la carga útil a una cadencia diaria para mantener actualizada la lista de entidades permitidas.
   2. Límite de tamaño por vendedor: El comprador podría especificar un límite de tamaño por vendedor para determinar el tamaño de los datos que se enviarían en la carga útil cuando un vendedor determinado inicie una subasta. Esto sería útil si un comprador desea dedicar más recursos al procesamiento de datos de subasta de ciertos vendedores. SellerFrontendService solo reenvía datos específicos del comprador a cada BuyerFrontendService. Por lo tanto, si definiera un límite de tamaño por vendedor, un comprador podría controlar de forma explícita la cantidad de datos que transfiere y procesa BuyerFrontendService de su servidor de ofertas y subastas para las subastas que ejecuta un vendedor.

3. Configuración del vendedor: Estamos evaluando la viabilidad de una configuración de subasta por vendedor que permitiría a los vendedores definir parámetros de subasta para controlar el tamaño de la carga útil y los participantes en la subasta. Si fuera posible, durante la inscripción, la tecnología publicitaria del vendedor podría especificar el extremo desde el que Protected Audience podría recuperar la configuración de subasta por vendedor a una cadencia normal. Luego, esta configuración se usaría para determinar la composición y los límites de los adSelectionData generados para cada solicitud getAdSelectionData.

   Como sucede con la configuración del comprador, una configuración por vendedor permitiría a los vendedores especificar qué conjunto de compradores esperan ver en una subasta y definir límites de contribución por comprador al tamaño de la carga útil.

   La configuración de subasta del vendedor permitiría a los vendedores especificar lo siguiente:

   1. Lista de compradores permitidos: En las subastas que inició el vendedor determinado, solo los compradores de la lista de entidades permitidas podrían contribuir con CustomAudiences para la subasta. La configuración de la subasta debería actualizarse a diario para mantener la lista actualizada con la lista de compradores permitidos del servidor.
   2. Límite de tamaño por comprador: Los vendedores podrían especificar un límite por comprador para regular el tamaño de los datos que sube cada comprador a la carga útil que se envía a SellerFrontendService. Si el comprador superara el límite de tamaño por comprador, se usaría la prioridad de CustomAudience establecida en la configuración de la carga útil del comprador para obtener los datos en los límites esperados.
   3. Prioridad por comprador: Permite que los vendedores establezcan la prioridad por comprador. Se usaría la prioridad de comprador para identificar qué datos del comprador se deberían conservar en la carga útil si el tamaño supera el límite.
   4. Límite de tamaño máximo para la carga útil: Es posible que diferentes vendedores tengan una asignación de recursos distinta y que deseen establecer un límite de tamaño máximo para la carga útil de subasta por solicitud. El límite de tamaño máximo respetaría los buckets de tamaño fijo establecidos por la API de Protected Audience.

4. Cambios en los públicos personalizados

   1. Especifica la prioridad de público personalizado: Permite que los compradores especifiquen un valor de prioridad en un público personalizado. El campo priority se usaría para identificar los públicos personalizados que se deberían incluir en una subasta si el conjunto de públicos personalizados del comprador supera los límites de tamaño por vendedor o por comprador. Un valor de prioridad no especificado en un público personalizado se establecería de forma predeterminada en 0.0.

5. Cambios en los datos de la carga útil

   1. Reduce los datos que se envían en la carga útil: Como se detalla en Optimización de la carga útil de los servicios de ofertas y subastas, la carga útil más alta se genera a partir de datos de ads del público personalizado, indicadores de ofertas del usuario e indicadores de Android. Las cargas útiles más altas pueden reducirse de la siguiente manera:
      1. Hacer que el cliente envíe IDs de renderización de anuncios (en lugar de objetos de anuncios) en la carga útil
      2. Hacer que el cliente no envíe datos de anuncios en la carga útil
      3. No enviar indicadores de ofertas del usuario en la carga útil del cliente

Si bien las estrategias mencionadas anteriormente permiten que las tecnologías publicitarias definan configuraciones para administrar la composición y los límites de la carga útil de adSelectionData, también pueden convertirse en un factor para modular el tamaño de adSelectionData cambiando de los parámetros de configuración. Para evitar esto, Protected Audience recuperaría la configuración a diario desde el extremo configurado.

Optimización de latencia

Para que las subastas del servidor tengan un nivel de utilidad deseable, debemos asegurarnos de que las APIs de getAdSelectionData y de persistAdSelectionResult tengan una latencia baja por llamada. Si bien pretendemos ofrecer compatibilidad de funciones para las APIs en 2023, nuestra versión posterior se enfocará en comparativas de latencia y optimizaciones para las APIs.

Estamos explorando las siguientes estrategias para mantener la latencia dentro de los límites aceptables:

1. Pregeneración de datos de Protected Audience por vendedor: Debido a que las configuraciones de subasta del vendedor y de la carga útil del comprador serán estables durante un período considerable (a diario), la plataforma podría precalcular y almacenar los datos de Protected Audience aptos.

   Esto requeriría que la plataforma cree un mecanismo para supervisar las actualizaciones del público personalizado y modificar los datos de Protected Audience pregenerados en función de las actualizaciones. La plataforma también debería declarar los SLO en la carrera. puede demorar la tecnología publicitaria entre las actualizaciones del público personalizado Cambio en los adSelectionData generados para la subasta del servidor

   Dado que un dispositivo proporciona un modelo de cálculo de recursos limitado con prioridades de proceso variables, reconocemos que esta función de pregeneración que brindaríamos debería ser altamente confiable y tener garantías de SLO.

   Entonces, la pregeneración de los datos de Protected Audience se basaría en lo siguiente:

   1. Que el vendedor acepte la pregeneración de datos de Protected Audience
   2. Que los compradores sean aptos para participar en una subasta que inició un vendedor en particular
   3. Identificación de públicos personalizados por comprador que formarían parte de la carga útil en función de lo siguiente:
      1. Límites de tamaño por comprador, prioridad por comprador y límites de tamaño máximo definidos en la configuración del vendedor
      2. Límite de tamaño por vendedor y prioridad del público personalizado definida en la configuración del comprador

2. Aplicación más sencilla del filtrado negativo: Si un vendedor lo prefiere, la plataforma podría precalcular los adSelectionData con la pregeneración de datos de Protected Audience y la aplicación del filtrado negativo de la llamada crítica getAdSelectionData. Esto permitiría a los vendedores equilibrar la disminución de latencia y aceptar la inactividad en el filtrado negativo.

   La plataforma podría ofrecer esta compatibilidad proporcionando una opción predeterminada en la configuración del vendedor con un límite de inactividad y una opción de anulación en getAdSelectionData para posibilitar un cálculo más reciente si es necesario. Como alternativa, la plataforma podría proporcionar una API de inicialización adicional a la cual llamar antes del getAdSelectionData para preparar la subasta.

3. Cálculo de la carga útil para varias subastas: En algunos casos, puede ser preferible tener una API eficiente en términos de latencia a costa de una mayor inactividad de los datos. Para proporcionar esto, la plataforma podría incorporar una API de inicialización para calcular toda la carga útil y proporcionar una referencia a la carga útil calculada para el llamador.

   En el caso de las llamadas posteriores a getAdSelectionData, el llamador podría proporcionar una referencia a la carga útil precalculada que se usará para la generación de adSelectionData.

Las tres estrategias mencionadas anteriormente se encuentran en la etapa de exploración inicial y tienen como objetivo describir la dirección que podría tomar la plataforma para emplear optimizaciones de latencia. A medida que exploremos los perfiles de latencia más detallados de la API y los requisitos de la tecnología publicitaria, seguiremos proponiendo estrategias adicionales.

Identificación y mitigación de abusos

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

Sin embargo, si se usan todos los datos del comprador en el dispositivo para generar la adSelectionData, una entidad maliciosa podría hacerse pasar por un comprador y crear datos de compradores fraudulentos para disminuir el rendimiento de Android, sobredimensionar la carga útil a Aumentar el costo para que una tecnología publicitaria ejecute subastas o ofertas, etcétera

Mitigación

Algunas medidas mencionadas en la sección de consideraciones de tamaño, como la configuración de la carga útil del comprador que contiene vendedores permitidos y la configuración de subastas del vendedor que contiene compradores permitidos, ayudarían a excluir datos inesperados en la carga útil.

Otras medidas de consideración del tamaño, como permitir que las SSP especifiquen la prioridad del comprador, colocar la cuota por comprador en la carga útil generada y establecer un tamaño máximo por carga útil de subasta, también pueden ayudar a mitigar el impacto del sobredimensionamiento malicioso de la carga útil. El objetivo de estas medidas es permitir que las tecnologías publicitarias definan con qué otras tecnologías publicitarias colaboran y establecer límites aceptables en la carga útil que deberían procesar.

Como se indicó anteriormente, todas las mitigaciones que se incluyeron para la prevención del abuso y las restricciones de tamaño deben cumplir con las consideraciones de privacidad.

Identificación de entidades maliciosas

Si bien las mitigaciones mencionadas anteriormente protegen la generación de adSelectionData para las subastas del servidor, no ayudan a identificar entidades maliciosas ni a proteger la plataforma contra abusos, como la creación de una cantidad sin precedentes de públicos personalizados de un comprador.

Para garantizar la estabilidad y el buen funcionamiento de la plataforma, debemos encontrar un mecanismo para identificar entidades maliciosas, vectores de abuso y la motivación detrás de los ataques específicos. En versiones posteriores, incorporaremos explicaciones que detallan los posibles vectores de abuso y las protecciones que se emplearán para contrarrestarlos.