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

Admite la segmentación por público personalizada con la API de Protected Audience

Actualizaciones recientes

Se agregó información para programar actualizaciones de públicos personalizados.
Se agregó la integración de Attribution Reporting con Protected Audiences.
Se publicó un cronograma de las funciones de Protected Audience.
Se cambió el nombre de FLEDGE a API de Protected Audience.
Se agregó la propuesta para la delegación de público personalizado.
Se quitó el requisito de k-anonimato para la URL de actualización diaria.

Protected Audience se encuentra en versión beta y se puede probar en dispositivos públicos.

Con Protected Audience, puedes hacer lo siguiente:

Administrar públicos personalizados en función de las acciones de usuarios anteriores
Iniciar subastas integradas en el dispositivo con asistencia de la mediación en cascada o de un solo vendedor.
Prueba los informes de impresiones después de la selección de anuncios.

Para comenzar, lee la guía para desarrolladores de Protected Audience. Agradecemos tus comentarios mientras seguimos desarrollando Protected Audience.

Línea de tiempo

Lanzaremos nuevas funciones en los próximos meses. Las fechas exactas de lanzamiento varían según la función. La tabla se actualizará con vínculos a la documentación cuando esté disponible.

Función	Disponible en la Versión preliminar para desarrolladores	Disponible en versión beta
Informes a nivel del evento	Trimestre 1 de 2023	Tercer trimestre de 2023
Mediación en cascada	Primer trimestre de 2023	Cuarto trimestre de 2023
Filtrado de anuncios de instalación de aplicaciones	Trimestre 2 de 2023	Tercer trimestre de 2023
Filtrado de limitación de frecuencia	Segundo trimestre de 2023	Tercer trimestre de 2023
Cómo pasar anuncios contextuales al flujo de trabajo de selección de anuncios para filtrar	Trimestre 2 de 2023	Tercer trimestre de 2023
Informes de interacción	Segundo trimestre de 2023	Tercer trimestre de 2023
Únete a la delegación de público personalizada	Tercer trimestre de 2023	Cuarto trimestre de 2023
Facturación sin CPM	Tercer trimestre de 2023	Cuarto trimestre de 2023
Integración de servicios de ofertas y subastas	Tercer trimestre de 2023	Cuarto trimestre de 2023
Informes de depuración	Tercer trimestre de 2023	Cuarto trimestre de 2023
Integración de Attribution Reporting	N/A	Cuarto trimestre de 2023
Mediación de Open Bidding	Cuarto trimestre de 2023	Cuarto trimestre de 2023
Administración de monedas	Primer trimestre de 2024	Segundo trimestre de 2024
Integración con K-anon	N/A	Segundo trimestre de 2024
Integración de informes agregados	Tercer trimestre de 2024	Cuarto trimestre de 2024

Descripción general

En la publicidad para dispositivos móviles, los anunciantes suelen necesitar publicar anuncios a los usuarios con potencial interés en función de sus interacciones anteriores con la app en cuestión. Por ejemplo, es posible que el desarrollador de SportingGoodsApp quiera mostrar anuncios a los usuarios que tengan artículos en su carrito que les recuerden que completen su compra. La industria suele describir esta idea general con términos como "remarketing" y "segmentación por público personalizada".

Hoy en día, estos casos de uso se suelen implementar compartiendo información contextual sobre cómo se muestra el anuncio (como el nombre de la app) e información privada, como listas de público, con plataformas de tecnología publicitaria. Con esta información, los anunciantes pueden seleccionar anuncios relevantes en sus servidores.

La API de Protected Audience en Android (que anteriormente se conocía como FLEDGE) abarca las siguientes APIs para plataformas de tecnología publicitaria y anunciantes para admitir casos de uso que se basen en interacciones comunes de maneras que limitan el uso compartido tanto de identificadores entre apps como de la información de las interacciones de la app de los usuarios con terceros:

API de Custom Audience: Se centra en la abstracción de "público personalizado", que representa un público designado por el anunciante con intenciones comunes. La información del público se almacena en el dispositivo y se puede asociar con anuncios candidatos relevantes para el público y con metadatos arbitrarios, como indicadores de ofertas. La información se puede usar para informar ofertas de anunciantes, filtros de anuncios y renderización.
API de Ad Selection: Proporciona un framework organiza las plataformas de tecnología publicitaria flujos de trabajo que usan señales integradas en el dispositivo para determinar un resultado "ganador" anuncio teniendo en cuenta los anuncios candidatos almacenados localmente realizar procesamiento adicional en anuncios candidatos que una plataforma de tecnología publicitaria regresa al dispositivo.

Diagrama de flujo que muestra el flujo de trabajo de administración de públicos y selección de anuncios personalizados en Privacy Sandbox en Android.

En general, la integración funciona de la siguiente manera:

SportingGoodsApp desea recordarles a los usuarios que compren los artículos promocionales que dejaron en su carrito si no completaron la compra en 2 días. SportingGoodsApp usa la API de Custom Audience para agregar al usuario a la lista de público "productos en el carrito". La plataforma administra y almacena esta lista de público en el dispositivo, lo que limita el uso compartido con terceros. SportingGoodsApp se asocia con una plataforma de tecnología publicitaria para mostrar sus anuncios a los usuarios de su lista de público. La plataforma de tecnología publicitaria administra metadatos para listas de público y proporciona anuncios candidatos, que se ponen a disposición del flujo de trabajo de selección de anuncios para su consideración. La plataforma se puede configurar para recuperar, de forma periódica, anuncios actualizados basados en el público en segundo plano. Esto ayuda a mantener la lista de anuncios candidatos basados en el público actualizada y no correlacionada con las solicitudes enviadas a servidores de anuncios de terceros durante la oportunidad del anuncio (es decir, la solicitud de anuncio contextual).
Cuando el usuario juega al FrisbeeGame en el mismo dispositivo, es posible que vea un anuncio que le recuerde que complete la compra de los artículos que agregó al carrito de compras de SportingGoodsApp. FrisbeeGame (con un SDK de anuncios integrado) logra esto invocando la API de Ad Selection para que seleccione un anuncio ganador para el usuario en función de cualquier lista de público de la que forme parte (en este ejemplo, sería el público personalizado "productos en el carrito" creado por SportingGoodsApp). El flujo de trabajo de selección de anuncios se puede configurar para considerar los anuncios recuperados de los servidores de las plataformas de tecnología publicitaria, además de los anuncios en el dispositivo asociados con públicos personalizados y otros indicadores del dispositivo. El flujo de trabajo también se puede personalizar mediante la plataforma de tecnología publicitaria y el SDK de anuncios con ofertas personalizadas y lógica de puntuación para lograr los objetivos publicitarios apropiados. Este enfoque permite que los datos de interés del usuario o de interacciones con la app informen la selección de anuncios y, al mismo tiempo, limita el uso compartido de estos datos con terceros.
El SDK de la plataforma de tecnología publicitaria o la app de publicación de anuncios renderiza el anuncio seleccionado.
La plataforma facilita la generación de informes de impresiones y resultados de la selección de anuncios. Esta función de informes se complementa con la API de Attribution Reporting. Las plataformas de tecnología publicitaria pueden personalizarse en función de sus necesidades de creación de informes.

Obtén acceso a las APIs de Protected Audience en Android

Las plataformas de tecnología publicitaria deben inscribirse para acceder a la API de Audience Protected. Consulta Inscríbete para obtener una cuenta de Privacy Sandbox para obtener más información.

Administración de públicos personalizados

Público personalizado

Un público personalizado representa un grupo de usuarios determinado por el anunciante con intenciones o intereses comunes. Una app o un SDK puede usar un público personalizado para indicar un público en particular, como alguien que "dejó artículos en su carrito de compras" o "completó los niveles para principiantes" de un juego. La plataforma mantiene y almacena la información del público de forma local en el dispositivo y no expone en qué públicos personalizados se encuentra el usuario. Los públicos personalizados son distintos de los grupos de interés de Protected Audience de Chrome y no se pueden compartir entre la Web y las apps. Esto ayuda a limitar el uso compartido de la información de los usuarios.

Una app de anunciante o el SDK integrado pueden unirse a un público personalizado o abandonarlo en función de, por ejemplo, la participación de los usuarios en una app.

Metadatos de públicos personalizados

Cada público personalizado contiene los siguientes metadatos:

Propietario: Nombre del paquete de la app del propietario. Esto se establece de forma implícita en el nombre del paquete de la app que realiza la llamada.
Comprador: Red de publicidad del comprador que administra los anuncios para este público personalizado. El comprador también representa a la parte que puede acceder al público personalizado y obtener información relevante del anuncio. El comprador se especifica siguiendo el formato eTLD+1.
Nombre: Un nombre o identificador arbitrario para el público personalizado, como un usuario que tiene "usuarios que abandonan el carrito de compras". Este atributo se puede usar, por ejemplo, como criterio de segmentación en campañas publicitarias del anunciante o como cadena de consulta en la URL para obtener el código de oferta.
Hora de activación y vencimiento: Estos campos definen el período en el que este público personalizado permanecerá en vigencia. La plataforma usa esta información para retirar las membresías de un público personalizado. La hora de vencimiento no puede exceder un período de duración máximo para limitar la vida de un público personalizado.
URL de actualización diaria: Es la URL que la plataforma usa para recuperar anuncios candidatos y otros metadatos definidos en los campos "Indicadores de ofertas del usuario" e "Indicadores de ofertas confiables" de forma recurrente. Para obtener más detalles, consulta la sección sobre cómo recuperar anuncios candidatos para públicos personalizados.
Indicadores de oferta del usuario: Son indicadores específicos de la plataforma de tecnología publicitaria para cualquier oferta de anuncios de remarketing. Algunos ejemplos de indicadores son la ubicación aproximada del usuario y la configuración regional preferida.
Datos de ofertas confiables: Las plataformas de tecnología publicitaria se basan en datos en tiempo real para fundamentar la recuperación y la puntuación de anuncios. Por ejemplo, es posible que un anuncio se quede sin presupuesto y se deje de publicar de inmediato. Una tecnología publicitaria puede definir un extremo de URL desde el que se puedan recuperar estos datos en tiempo real y el conjunto de claves para las cuales se debe realizar la búsqueda en tiempo real. El servidor que controla esta solicitud será un servidor de confianza que administrará la plataforma de tecnología publicitaria.
URL de oferta lógica: Es la URL que la plataforma utiliza para recuperar código de ofertas de la plataforma orientada a la demanda. La plataforma realiza este paso cuando se inicia una subasta de anuncios.
Anuncios: Es una lista de anuncios de candidatos para el público personalizado. Esto incluye los metadatos del anuncio específicos de las plataformas de tecnología publicitaria y una URL para renderizar el anuncio. Cuando se inicie una subasta para el público personalizado, se considerará esta lista de metadatos de anuncios. Esta lista de anuncios se actualizará con el extremo de URL de actualización diaria cuando sea posible. Debido a restricciones de recursos en dispositivos móviles, existe un límite sobre la cantidad de anuncios que se pueden almacenar en un público personalizado.

Delegación del público personalizado

La configuración y definición de públicos personalizados tradicionales, por lo general, se basan en integraciones y tecnologías del servidor impulsadas por tecnologías publicitarias en asociación con clientes y socios de agencias y anunciantes. La API de Audience Protected habilita la configuración y definición de públicos personalizados y protege la privacidad del usuario. Para unirse a un público personalizado, 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). Con la API de Protected Audience, se busca admitir estos SDK proporcionando soluciones flexibles para la administración de públicos personalizados habilitando, en los llamadores integrados en los dispositivos, la invocación de la creación de públicos personalizados en nombre de los compradores. Este proceso se denomina delegación de público personalizado. Para configurar la delegación de públicos personalizados, sigue estos pasos:

Únete a un público personalizado

Puedes unirte a un público personalizado de dos maneras:

joinCustomAudience()

Una app o SDK puede solicitar unirse a un público personalizado si llama a joinCustomAudience() después de crear una instancia del objeto CustomAudience con los parámetros esperados. A continuación, se incluye un ejemplo ilustrativo de un fragmento de código:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

Una app o un SDK puede solicitar unirse a un público personalizado en nombre de una tecnología publicitaria que no tenga presencia en el dispositivo llamando a fetchAndJoinCustomAudience() con los parámetros esperados, como en el siguiente ejemplo:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

El extremo de URL, que es propiedad del comprador, responde con un objeto JSON CustomAudience en el cuerpo de la respuesta. Los campos de comprador y propietario del público personalizado se ignoran (y la API los autocompleta). La API también exige que la URL de actualización diaria coincida con el eTLD+1 del comprador.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

La API de fetchAndJoinCustomAudience() determina la identidad del comprador a partir del eTLD+1 de fetchUri. La identidad del comprador de CustomAudience se usa para realizar las mismas verificaciones de inscripción y de autorización de apps que realiza joinCustomAudience(), y la respuesta de recuperación no puede modificarla. El propietario de CustomAudience es el nombre del paquete de la aplicación que realiza la llamada. No hay otra validación de fetchUri aparte de la verificación de eTLD+1 y, en particular, no hay una verificación de k-anon. La API de fetchAndJoinCustomAudience() emite una solicitud GET HTTP a fetchUri y espera un objeto JSON que represente el público personalizado. Se aplican a las respuestas las mismas restricciones obligatorias y opcionales, así como los valores predeterminados para los campos de objeto de público personalizado. Obtén información sobre los requisitos y las limitaciones actuales en nuestra Guía para desarrolladores.

Cualquier respuesta de error de HTTP del comprador hace que fetchAndJoinCustomAudience falle. En particular, una respuesta de estado HTTP de 429 (Demasiadas solicitudes) bloquea las solicitudes de la aplicación actual durante un período que se deberá definir. La llamada a la API también falla si la respuesta del comprador presenta errores de formato. Las fallas se informan al llamador de la API responsable de reintentarlo debido a fallas temporales (por ejemplo, si el servidor no responde) o de controlar fallas persistentes (como fallas de validación de datos o cualquier otro error no transitorio en la comunicación con el servidor).

El objeto CustomAudienceFetchRequest permite que el llamador de la API defina cierta información para el público personalizado usando las propiedades opcionales que se muestran en el ejemplo anterior. Si se especifican en la solicitud, la respuesta que el comprador recibió no puede reemplazar estos valores; la API de Protected Audience ignora los campos en la respuesta. Si no están configurados en la solicitud, deben configurarse en la respuesta, ya que estos campos son obligatorios para crear un público personalizado. En la solicitud GET a fetchUri, se incluye una representación JSON del contenido de CustomAudience como lo define parcialmente el llamador de la API en un encabezado especial X-CUSTOM-AUDIENCE-DATA. El tamaño de la forma serializada de los datos especificados para el público personalizado se limita a 8 KB. Si se supera el tamaño, la llamada a la API de fetchAndJoinCustomAudience no se realiza.

La falta de una verificación de k-anon te permite usar fetchUri para verificar el comprador y habilitar el uso compartido de información entre el comprador y el SDK. Para facilitar la verificación de público personalizado, el comprador puede proporcionar un token de verificación. El SDK integrado en el dispositivo debe incluir este token en fetchUri de modo que el extremo alojado por el comprador pueda recuperar el contenido del público personalizado y usar el token de verificación para comprobar que la operación fetchAndJoinCustomAudience() corresponde al comprador y se originó desde un socio confiable en el dispositivo. Para compartir información, el comprador puede acordar con el llamador integrado en el dispositivo que parte de la información que se usará para crear el público personalizado se agregará como parámetros de consulta a fetchUri. Esto permite que el comprador audite las llamadas y detecte si una tecnología publicitaria maliciosa usó un token de validación para crear varios públicos personalizados diferentes.

Nota sobre la definición y el almacenamiento del token de verificación

El token de verificación es opcional, y la API de Protected Audience no lo usa para ningún fin.
- El comprador puede usar el token de verificación para comprobar que la creación de los públicos se realice en su nombre.
- La propuesta de la API de Protected Audience no especifica un formato para el token de verificación ni una manera en la que el comprador transferirá el token de verificación al llamador. Por ejemplo, el token de verificación podría cargarse previamente en el SDK o backend del propietario, o el SDK del propietario podría recuperarlo en tiempo real desde el servidor del comprador.

Abandona un público personalizado

El propietario de un público personalizado puede elegir abandonar un público si llama a leaveCustomAudience(), como se muestra en el siguiente fragmento de código de ejemplo:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

Para ayudar a conservar el uso del almacenamiento y otros recursos del dispositivo, los públicos personalizados caducan y se quitan de la tienda en el dispositivo después de un período predeterminado. Se definirá el valor predeterminado. El propietario puede anular este valor predeterminado.

Control de usuarios

La propuesta pretende dar a los usuarios visibilidad de la lista de apps instaladas que crearon al menos un público personalizado.
Los usuarios pueden quitar apps de esta lista. La eliminación borra todos los públicos personalizados asociados con las apps y evita que estas se unan a otros nuevos.
Los usuarios pueden restablecer por completo la API de Protected Audience. Cuando esto sucede, se borran todos los públicos personalizados existentes del dispositivo.
Los usuarios pueden inhabilitar por completo Privacy Sandbox en Android, que incluye la API de Protected Audience. Si el usuario inhabilitó Privacy Sandbox, la API de Protected Audience fallará de forma silenciosa.

El diseño de esta función es un trabajo en curso, y los detalles se incluirán en una actualización posterior.

Actualizaciones programadas

Las soluciones descritas anteriormente requieren que el SDK de la app o de tecnología publicitaria invoque el APIs mientras la app se ejecuta en primer plano y proporcionan las propiedades completas de la un público personalizado, ya sea directamente o por delegación. Sin embargo, no siempre posible para que los anunciantes y proveedores de tecnología publicitaria definan a qué públicos en tiempo real mientras usan la app.

Para facilitar esto, es posible que la tecnología publicitaria llame al API de scheduleCustomAudienceUpdate(). Esta API permite que el llamador especifique una demora en el momento en que se debe realizar la llamada a la API, lo que proporciona tiempo adicional para que la tecnología publicitaria que responde procese los eventos a nivel de la app y determine a qué Públicos protegidos debe unirse el usuario o de qué debe quitarse.

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

El elemento ScheduleCustomAudienceUpdateRequest contiene la información necesaria para y registrar un trabajo retrasado para ejecutarse en la plataforma. Después del retraso especificado, un trabajo en segundo plano se ejecutará periódicamente y enviará las solicitudes. El ScheduleCustomAudienceUpdateRequest puede contener la siguiente información:

UpdateUri: Es el extremo de URI al que se le enviaría una llamada GET para recuperar la actualización. La identidad del comprador se infiere de forma intrínseca del eTLD+1 y no es necesario proporcionarla de forma explícita, y la respuesta de actualización no puede modificarla. La solicitud GET espera un objeto JSON que contenga una lista de objetos customAudience como resultado.
DelayTime: Es el tiempo que indica la demora desde el momento en que se realiza la llamada a la API de scheduleCustomAudienceUpdate() para programar la actualización.

PartialCustomAudience: La API también permite que el SDK integrado en el dispositivo envíe una lista de públicos personalizados parcialmente creados. Esto permite que los SDKs integrados en la app publiquen la doble función, de total a control parcial sobre la administración de públicos personalizados en función de su asociación con las DSP.
- De esta manera, también se mantendrá la compatibilidad de la API con fetchAndJoinCustomAudience(). que permite compartir información similar.
ShouldReplacePendingUpdates: Es un valor booleano que determina si se deben cancelar las actualizaciones programadas pendientes y reemplazarlas por la actualización detallada en el ScheduleCustomAudienceUpdateRequest actual. Si se establece en false y hay actualizaciones solicitadas anteriormente que aún están pendientes para el mismo comprador en el misma app, una llamada a scheduleCustomAudienceUpdate con esta ScheduleCustomAudienceUpdateRequest fallará. La configuración predeterminada es false.

Permisos y control de la app

El objetivo de la propuesta es proporcionar control a las apps sobre sus públicos personalizados:

Una app puede administrar sus asociaciones con públicos personalizados.
Una app puede otorgar permisos a plataformas de tecnología publicitaria de terceros para que administren los públicos personalizados en su nombre.

El diseño de esta función es un trabajo en curso, y los detalles se incluirán en una actualización posterior.

Control de plataformas de tecnología publicitaria

En esta propuesta, se describen las maneras en que las tecnologías publicitarias pueden controlar sus públicos personalizados:

Las tecnologías publicitarias se inscriben en Privacy Sandbox y proporcionan un dominio eTLD+1 que hace coincidir todas las URLs para un público personalizado.
Las tecnologías publicitarias pueden asociarse con apps o SDK para proporcionar tokens de verificación que se usen para comprobar la creación de un público personalizado. Cuando este proceso se delega a un socio, la creación de públicos personalizados se puede configurar de modo que se requiera la confirmación de la tecnología publicitaria.
Una tecnología publicitaria puede elegir desactivar las llamadas a joinCustomAudience en su nombre y solo permitir que la API de fetchAndJoinCustomAudience habilite todos los públicos personalizados de llamadas. El control se puede actualizar durante la inscripción a Privacy Sandbox. Ten en cuenta que el control permite todas las tecnologías publicitarias o ninguna. Debido a las limitaciones de la plataforma, los permisos de delegación no pueden realizarse por tecnología publicitaria.

Respuesta de metadatos y anuncios candidatos

Los metadatos y anuncios candidatos que se muestran en una plataforma orientada de compra deben incluir los siguientes campos:

Metadatos: Son 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.
URL de renderización: Extremo para renderizar la creatividad del anuncio.
Filtro: Es la información opcional necesaria para que la API de Protected Audience filtre los anuncios según los datos en el dispositivo. Para obtener más información, consulta la sección sobre lógica de filtro de compra.

Flujo de trabajo de la selección de anuncios

El objetivo de esta propuesta es mejorar la privacidad mediante la introducción de la API de selección de anuncios, que organiza la ejecución de las subastas para plataformas de tecnología publicitaria.

En la actualidad, las plataformas de tecnología publicitaria suelen realizar ofertas y seleccionar anuncios solo en sus servidores. Con esta propuesta, se podrá acceder a públicos personalizados y otros indicadores sensibles del usuario, como la información de paquetes instalados disponible, solo a través de la API de Ad Selection. Además, en los casos de uso de remarketing, los anuncios de candidatos se recuperarán fuera de banda (es decir, en el contexto en el que se mostrarán). Las plataformas de tecnología publicitaria deberán prepararse para que se implementen y ejecuten en el dispositivo algunas partes de su lógica de subasta y selección de anuncios actuales. Las plataformas de tecnología publicitaria pueden considerar los siguientes cambios en su flujo de trabajo de selección de anuncios:

Sin la información de paquetes instalados disponible en el servidor, es posible que las plataformas de tecnología publicitaria quieran enviar varios anuncios contextuales al dispositivo y, luego, invocar el flujo de trabajo de selección de anuncios para habilitar el filtrado basado en la instalación de la app para maximizar las posibilidades y mostrar un anuncio relevante.
Debido a que los anuncios de remarketing se recuperan fuera de la banda, es posible que los modelos de ofertas actuales deban actualizarse. Puede que las plataformas de tecnología publicitaria quieran crear submodelos de ofertas (la implementación puede basarse en un patrón llamado modelo de dos torres) que puedan funcionar en características de anuncios e indicadores de contexto por separado, y que combinen los resultados de los submodelos en el dispositivo para predecir ofertas. Esto puede beneficiarse de las subastas y las subastas del servidor para cualquier oportunidad de anuncio determinada.

Este enfoque permite que los datos de las interacciones del usuario con la app informen la selección de anuncios y, al mismo tiempo, limita el uso compartido de estos datos con terceros.

Diagrama de flujo en el que se muestra el inicio del flujo de trabajo de selección de anuncios.

Este flujo de trabajo de selección de anuncios organiza la ejecución en el dispositivo del código JavaScript proporcionado por la tecnología publicitaria en función de la siguiente secuencia:

Ejecución de la lógica de ofertas orientada a la compra
Filtrado y procesamiento de anuncios de compra
Ejecución de la lógica de decisión orientada a la venta

En el caso de las selecciones de anuncios que involucran públicos personalizados, la plataforma recuperará código JavaScript de compra basado en el extremo de la URL pública definido por los metadatos de "URL de lógica de ofertas" del público personalizado. El extremo de URL para el código de decisión de venta también se pasará como entrada para iniciar el flujo de trabajo de selección de anuncios.

El diseño de las selecciones de anuncios que no incluyen públicos personalizados está en proceso de diseño activo.

Inicia un flujo de trabajo de selección de anuncios

Cuando una app necesita mostrar un anuncio, el SDK de la plataforma de tecnología publicitaria puede iniciar el flujo de trabajo de selección de anuncios si llama al método selectAds() después de crear una instancia del objeto AdSelectionConfig con los parámetros esperados:

Vendedor: Es el identificador de la plataforma de anuncios orientada a la venta con el formato eTLD+1.
URL de lógica de decisión: Cuando se inicia una subasta de anuncios, la plataforma usará esta URL para obtener el código JavaScript de la plataforma de venta a fin de obtener un anuncio ganador.
Compradores de públicos personalizados: Es la lista de plataformas de compra con demanda basada en públicos personalizados para esta subasta con el formato eTLD+1.
Indicadores de selección de anuncios: Incluye información sobre la subasta (tamaño del anuncio, formato del anuncio, etcétera).
Indicadores de vendedor: Se trata de los indicadores específicos de la plataforma de proveedores.
URL de indicadores de puntuación de confianza: Es el indicador de confianza del extremo de URL de venta a partir del cual se puede obtener información en tiempo real específica de la creatividad.
Indicadores por comprador: Las partes de demanda involucradas pueden usar este parámetro para proporcionar entradas en la subasta. Por ejemplo, este parámetro puede incluir información contextual completa que resulte útil para determinar las ofertas.

En el siguiente fragmento de código ilustrativo, se muestra un SDK de plataforma de tecnología publicitaria que inicia el flujo de trabajo de selección de anuncios. Para ello, primero define el AdSelectionConfig y, luego, invoca a selectAds a fin de obtener el anuncio ganador:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

Lógica de las ofertas de compra

Por lo general, la lógica de ofertas la proporcionan las plataformas de compra. El propósito del código es determinar las ofertas para los anuncios candidatos. Podría aplicarse una lógica empresarial adicional para determinar el resultado.

La plataforma usará los metadatos de "URL de lógica de ofertas" de público personalizado para obtener el código JavaScript que debería incluir la siguiente firma de función:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

La API de generateBid() muestra el importe calculado de la oferta. La plataforma invocará esta función para todos los anuncios (contextuales o de remarketing) de manera secuencial. Si hay varios proveedores de lógica de ofertas, el sistema no garantiza la secuencia de ejecución entre ellos.

La función espera los siguientes parámetros:

Anuncio: Es el anuncio que se considera en el código de la oferta de compra. Este será un anuncio de un público personalizado apto.
Indicadores de subasta: Son indicadores específicos de la plataforma de venta.
Indicadores por comprador: Las partes de demanda involucradas pueden usar este parámetro para proporcionar entradas en la subasta. Por ejemplo, este parámetro puede incluir información contextual completa que resulte útil para determinar las ofertas.
Indicadores de ofertas confiables: Las plataformas de tecnología publicitaria se basan en datos en tiempo real para fundamentar la recuperación y la puntuación de anuncios. Por ejemplo, es posible que una campaña publicitaria se quede sin presupuesto y se deje de publicar de inmediato. Una tecnología publicitaria puede definir un extremo de URL desde el que se puedan recuperar estos datos en tiempo real y el conjunto de claves para las cuales se debe realizar la búsqueda en tiempo real. El servidor administrado de la plataforma de tecnología publicitaria que envía esta solicitud será un servidor de confianza administrado por la plataforma de tecnología publicitaria.
Indicadores contextuales: Pueden incluir una marca de tiempo general o información de ubicación aproximada, o el costo por clic en el anuncio.
Indicadores de usuario: Pueden incluir información como, por ejemplo, la que está disponible sobre el paquete instalado.

Costo de los anuncios

Además de la oferta, las plataformas de compra tienen la opción de mostrar el costo por clic como parte de generateBid(). Por ejemplo:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

Si este anuncio es el ganador, adCost se redondea estocásticamente a 8 bits por motivos de privacidad. Luego, el valor redondeado de adCost se pasa al parámetro contextual_signals en reportWin durante el informe de impresiones.

Lógica de filtro de compra

Las plataformas de compra podrán filtrar anuncios según indicadores adicionales integrados en el dispositivo y disponibles durante la fase de selección de anuncios. Por ejemplo, las plataformas de tecnología publicitaria pueden implementar capacidades de limitación de frecuencia aquí. Si hay varios proveedores de filtros, el sistema no garantiza la secuencia de ejecución entre ellos.

La lógica de filtro de compra se puede implementar como parte de la lógica de ofertas mostrando un valor de oferta de 0 para un anuncio determinado.

Además, las plataformas de compra podrán indicar que un anuncio determinado debe filtrarse en función de los indicadores adicionales integrados en el dispositivo, disponibles para Protected Audience y que no saldrán del dispositivo. A medida que consolidamos los diseños de una lógica de filtrado adicional, las plataformas de compra seguirán esta misma estructura para indicar que debe ocurrir el filtrado.

Lógica de puntuación de venta

Por lo general, la plataforma de venta proporciona la lógica de puntuación. El propósito del código es determinar cuál es el anuncio ganador en función de los resultados de la lógica de ofertas. Podría aplicarse una lógica empresarial adicional para determinar el resultado. Si hay varios proveedores de lógica de decisión, el sistema no garantiza la secuencia de ejecución entre ellos. La plataforma usará el parámetro de entrada "URL de lógica de decisión" de la API de selectAds() para recuperar el código de JavaScript que debería incluir la siguiente firma de función:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

La función espera los siguientes parámetros:

Anuncio: Es el anuncio que se evalúa, resultado de la función generateBid().
Oferta: Muestra el importe de la oferta de la función generateBid().
Configuración de subasta: Es el parámetro de entrada del método selectAds().
Indicadores de puntuación de confianza: Las plataformas de tecnología publicitaria se basan en datos en tiempo real para informar filtros y puntuaciones de anuncios. Por ejemplo, un publicador de apps puede bloquear una campaña publicitaria para que no muestre anuncios en la app. Estos datos se obtienen de un parámetro de URL de indicadores de puntuación de confianza en la configuración de la subasta. El servidor que envía esta solicitud debe ser de confianza y estar administrado por tecnología publicitaria.
Indicador contextual: Puede incluir una marca de tiempo general o información sobre la ubicación aproximada.
Indicador del usuario: Puede incluir información como la tienda de apps que inició la instalación de la app.
Indicador de público personalizado: Si el anuncio puntuado proviene de un público personalizado en el dispositivo, contendrá información como el lector y el nombre del público personalizado.

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

En la propuesta, el sistema recuperará el código de subasta proporcionado por la plataforma de tecnología publicitaria de los extremos de URL configurables y lo ejecutará en el dispositivo. Debido a las restricciones de recursos en dispositivos móviles, el código de subasta debe cumplir con los siguientes lineamientos:

El código debería terminar de ejecutarse en un período predefinido. Este límite se aplicará de manera uniforme a todas las redes de publicidad de compradores. Los detalles de este límite se compartirán en una actualización posterior.
El código debe ser independiente y no debe tener dependencias externas.

Dado que el código de subasta, como la lógica de ofertas, puede necesitar acceso a datos privados del usuario, como fuentes de instalación de apps, el entorno de ejecución no proporcionará acceso a la red ni al almacenamiento.

Lenguaje de programación

El código de subasta proporcionado por la plataforma de tecnología publicitaria debe escribirse en JavaScript. Esto permite que las plataformas de tecnología publicitaria, por ejemplo, compartan código de ofertas entre las plataformas que admitan Privacy Sandbox.

Renderización de anuncios ganadores

El anuncio con la puntuación más alta se considera el ganador de la subasta. En esta propuesta inicial, el anuncio ganador se pasa al SDK para su renderización.

El plan es desarrollar la solución para garantizar que ni la app ni el SDK puedan determinar información sobre la pertenencia de un usuario a un público personalizado ni su historial de participación en la app a través de información sobre el anuncio ganador (similar a la propuesta de marcos vallados de Chrome).

Informes de impresiones y eventos

Una vez que se renderiza el anuncio, la impresión ganadora se puede informar a las plataformas participantes orientadas a la compra y a la venta. Esto permite que los compradores y vendedores incluyan información de la subasta, como la oferta o el nombre del público personalizado, en el informe de impresiones ganadoras. Además, la plataforma orientada a la venta y la plataforma ganadora orientada a la compra pueden recibir informes a nivel del evento adicionales sobre el anuncio ganador. Esto permite incluir información sobre la subasta (oferta, nombre del público personalizado, etc.) con clics, vistas y otros eventos del anuncio. La plataforma invoca la lógica de informes en este orden:

Informes orientados a la venta
Informes orientados a la compra

Esto brinda a las plataformas orientadas a la compra y a la venta una manera de enviar información importante disponible en el dispositivo a los servidores para habilitar capacidades como el presupuesto en tiempo real, las actualizaciones de modelos de ofertas y los flujos de trabajo de facturación precisos. Esta compatibilidad con los informes de impresiones es complementaria a la API de Attribution Reporting.

Se requieren dos pasos para admitir los informes de interacción: el JavaScript orientado a la venta y a la compra debe registrar para qué evento debe recibir informes de eventos, y el orientado a la venta es responsable de generar ese tipo de informes.

Protected Audience proporciona un mecanismo para suscribirse a eventos futuros relacionados con una subasta ganadora registrando píxeles contadores. En la función reportResult() de JavaScript de un vendedor, las plataformas orientadas a la venta pueden registrar píxeles contadores usando la función registerAdBeacon() de la plataforma. Del mismo modo, las plataformas orientadas a la compra pueden llamar al método registerAdBeacon() desde su función reportWin() de JavaScript.

registerAdBeacon(beacons)

Entrada:

event_key: Es una cadena que indica el tipo de interacción para el que se debe registrar. Se usa como clave para buscar el extremo en el que hace ping la plataforma y, al mismo tiempo, informar los resultados de la subasta.
reporting_url: Es la URL que pertenece a la plataforma de tecnología publicitaria para controlar el evento.

Las claves de evento son identificadores de cadenas que pertenecen al SDK orientado a la venta responsable de informar los resultados de la subasta. Para que se realice una devolución de llamada, las plataformas de tecnología publicitaria registran píxeles contadores con claves que coinciden con las que usan las plataformas orientadas a la venta cuando se informan los eventos. No es necesario que sean k-anónimas, aunque existen límites para la cantidad y longitud de las claves que se pueden registrar para un público personalizado determinado. Si se llama a reportEvent(), las plataformas orientadas a la venta que ejecutaron la subasta siempre serán aptas para recibir estos informes de eventos. Solo la plataforma ganadora orientada a la compra es apta para recibir estos informes.

Informes orientados a la venta

La plataforma invoca la función reportResult() de JavaScript en el código proporcionado por el proveedor descargado desde la URL de lógica de decisión del vendedor para la API de selectAds():

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

Resultado: Un objeto JSON que contiene lo siguiente:

Estado: 0 para indicar la ejecución correcta; cualquier otro valor si falla.
URL de informes: La plataforma invoca esta URL que mostró la función.
Indicadores para el comprador: Es un objeto JSON que se pasará a la función reportWin del comprador.

Los proveedores pueden codificar indicadores relevantes en la URL de informes para ayudarlos a obtener más estadísticas sobre la subasta y el anuncio ganador. Por ejemplo, puede incluir los siguientes indicadores:

URL de renderización de anuncios
Importe de la oferta ganadora
Nombre de la app
Identificadores de consulta
Indicadores para el comprador: Para admitir el uso compartido de datos entre las partes proveedoras y demandantes, la plataforma pasa este valor que se muestra como parámetro de entrada al código de informe de demanda.

Informes orientados a la compra

La plataforma invoca la función reportWin() de JavaScript en el código proporcionado por la demanda descargado desde los metadatos de la URL de lógica de ofertas del público personalizado asociado con la subasta.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

Entrada:

auction_signals y per_buyer_signals se recuperan de AuctionConfig. Cualquier dato que la plataforma de compra deba pasar a la URL de informes puede provenir de este dato.
signals_for_buyer es la salida del reportResult de venta. Esto brinda a la plataforma de venta la oportunidad de compartir datos con la plataforma de compra con fines de generación de informes.
contextual_signals contiene información como el nombre de la app, y custom_audience_signals contiene la información sobre el público personalizado. Es posible que se agregue más información en el futuro.

Resultado:

Estado: 0 para indicar la ejecución correcta; cualquier otro valor si falla.
URL de informes: La plataforma invoca esta URL que mostró la función.

Informes de eventos

Solo se pueden generar informes de eventos después de que se completan los informes de impresiones de la subasta. El SDK orientado a la venta es responsable de informar cualquier evento. La plataforma expone una API que toma un elemento ReportEventRequest que especifica la subasta ejecutada recientemente, la clave de evento que se informa, los datos asociados con esa clave, si el informe se debe enviar al comprador o al vendedor (o a ambos) y un evento de entrada opcional para los eventos de anuncios. El cliente define la clave de evento y la recopilación de datos para informar.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

Entrada:

ad_selection_id debe ser un AdSelectionId de una subasta ejecutada recientemente que se recuperó de AdSelectionOutcome.
event_key es una cadena definida orientada a la venta que describe el evento de interacción.
event_data es una cadena que representa los datos asociados con event_key.
reporting_destinations es un conjunto de máscaras binarias con marcas que la plataforma proporciona. Puede ser FLAG_REPORTING_DESTINATION_SELLER, FLAG_REPORTING_DESTINATION_BUYER o ambos.
input_event (opcional) se usa para la integración con la API de Attribution Reporting. Es un objeto InputEvent (para un evento de clic) o un valor nulo (para un evento de vista). Consulta Integración de la API de Attribution Reporting para obtener más detalles sobre este parámetro.

Después de que el SDK orientado a la venta invoca a reportEvent y, según la marca reporting_destinations, la plataforma intenta hacer coincidir el objeto event_key con las claves registradas por los compradores y vendedores en sus funciones de JavaScript reportWin y reportResult. Si hay una coincidencia, la plataforma realiza una POST de los event_data en la reporting_url asociada. El tipo de contenido de la solicitud es texto sin formato, y el cuerpo contiene los event_data. Esta solicitud se realiza como mejor esfuerzo y falla de forma silenciosa en caso de que se produzca un error de red o una respuesta de error del servidor, o bien que no se encuentren claves coincidentes.

Integración de la API de Attribution Reporting

Para admitir compradores que participan en una subasta de Protected Audience, proporcionamos funcionalidad entre APIs en las APIs de Protected Audience y Attribution Reporting (ARA). Esta funcionalidad permite que las tecnologías publicitarias evalúen el rendimiento de su atribución en varias tácticas de remarketing para que puedan comprender qué tipos de públicos proporcionan el ROI más alto.

A través de esta integración entre APIs, las AdTech pueden hacer lo siguiente:

Crear un mapa de par clave-valor de los URIs que se usarán para 1) los informes de interacción con los anuncios y 2) el registro de fuentes
Incluir los datos de la subasta de Protected Audience en su asignación de claves del lado del código fuente para los informes de resumen agregados (a través de la API de Attribution Reporting) (consulta la propuesta de diseño de ARA para obtener más información)

Cuando un usuario ve un anuncio o hace clic en él, sucede lo siguiente:

La URL que se usa para informar esas interacciones de eventos con Protected Audience les brindará los datos necesarios al comprador, que se usarán para registrar una vista o un clic como una fuente apta con la API de Attribution Reporting.
La tecnología publicitaria puede elegir pasar el objeto CustomAudience (o cualquier otra información contextual relevante sobre el anuncio, como la posición del anuncio o la duración de la vista) con esa URL para que estos metadatos se propaguen a los informes de resumen cuando la tecnología publicitaria revisa el rendimiento total de la campaña.

Habilita el registro de fuentes

reportEvent() aceptará un nuevo parámetro opcional InputEvent. Los compradores ganadores que registran píxeles contadores de anuncios pueden elegir qué informes de reportEvent se inscriben con las APIs de Attribution Reporting como una fuente registrada. El encabezado de la solicitud de Attribution-Reporting-Eligible se agregará a todas las solicitudes de informes de eventos que se envíen desde reportEvent(). Cualquier respuesta con encabezados correctos de la ARA se analizará de la misma manera que cualquier otra respuesta normal del registro de fuentes de la ARA. Consulta la explicación de la API de Attribution Reporting para obtener información sobre cómo registrar una URL de origen.

Como la ARA en Android admite eventos de vista y de clic, InputEvents se usa para distinguir entre estos dos tipos. Al igual que en el registro de fuentes de la ARA, la API de reportEvent() interpretará un objeto InputEvent verificado por la plataforma como un evento de clic. Si falta InputEvent, es nulo o no es válido, el registro de la fuente se considerará un evento de vista.

Ten en cuenta que el objeto eventData posterior a la subasta puede contener información sensible, por lo que la plataforma descarta el eventData en las solicitudes de registro de fuentes redireccionadas.

Ejemplo de informes de participación y conversiones

En este ejemplo, los analizaremos desde la perspectiva del comprador a quien le interesa asociar los datos de la subasta, el anuncio renderizado y la app de conversión.

En este flujo de trabajo, el comprador coordina con el vendedor para enviar un ID único a la subasta. Durante la subasta, el comprador envía este ID único con los datos de la subasta. Durante el período de renderización y de conversión, los datos del anuncio renderizado también se envían con el mismo ID único. Más adelante, se puede usar el ID único para asociar estos informes.

Flujo de trabajo: Antes de que comience la subasta, el comprador envía un ID único al vendedor como parte de su respuesta de oferta programática de la licitación en tiempo real ("RTB"). El ID se puede establecer como una variable, por ejemplo, auctionId. El ID se pasa como perBuyerSignals en el objeto auctionConfig y estará disponible en la lógica de ofertas del comprador.

Durante la ejecución de reportWin, el comprador puede registrar un pixel contador de anuncios para que se active durante el tiempo de renderización de anuncios y para eventos de interacción específicos (registerAdBeacon()). Si deseas asociar indicadores de subasta para un evento de anuncio, establece auctionId como un parámetro de consulta de la URL del píxel contador.
Durante el tiempo de renderización de anuncios, los píxeles contadores que registraste durante la subasta se pueden activar o mejorar con datos a nivel del evento. El vendedor debe activar reportEvent() y pasar los datos a nivel del evento. La plataforma hará ping a la URL del píxel contador de anuncios registrada del comprador que se correlaciona con el objeto reportEvent() que se activó.
El comprador registrará el anuncio con la API de Attribution Reporting respondiendo las solicitudes del píxel contador de anuncios con el encabezado Attribution-Reporting-Register-Source. Si deseas asociar indicadores de subasta para un evento de conversión, establece auctionId en la URL de registro de fuentes.

Después del proceso anterior, el comprador tendrá un informe de subasta, un informe de interacción y un informe de conversiones, que se pueden correlacionar a través de un ID único, que puede usarse para que se asocien entre sí.

Un flujo de trabajo similar se aplica a un vendedor si necesita acceder a los datos de atribución, y el vendedor también puede usar un ID único para enviar con registerAdBeacon(). La llamada a reportEvent() contiene una propiedad de destino que se puede usar para enviar el informe al comprador y al vendedor.

Servidor de confianza administrado por la plataforma de tecnología publicitaria

En la actualidad, la lógica de selección de anuncios requiere información en tiempo real, como el estado del agotamiento del presupuesto, para determinar si se deben seleccionar anuncios candidatos para una subasta. Las plataformas de compra y venta podrán obtener esta información de los servidores que operan. Para minimizar la filtración de información sensible a través de estos servidores, la propuesta llama a las siguientes restricciones:

Los comportamientos de estos servidores, que se describen más adelante en esta sección, no filtrarían información del usuario.
Los servidores no crearían perfiles seudónimos basados en los datos que ven, es decir, deberán ser "de confianza".

Compra: Una vez la compra inicia la lógica de oferta correspondiente, la plataforma realiza una recuperación de HTTP de los datos de las ofertas de confianza del servidor de confianza. La URL se compone de agregar la URL y las claves presentes en la página de Metadatos de indicadores del público personalizado que se se procesan. Esta recuperación se realiza únicamente cuando se procesan anuncios de los públicos personalizados en el dispositivo. En esta etapa, la compra puede aplicar presupuestos, verificar el estado de pausa o reanudación de una campaña, establecer objetivos de rendimiento, etcétera.

A continuación, se incluye una URL de ejemplo de obtención de datos de oferta de confianza, basados en metadatos de indicadores de ofertas confiables del público personalizado:

https://www.kv-server.example/getvalues?keys=key1,key2

La respuesta del servidor debe ser un objeto JSON cuyas claves sean key1, key2, etc., y cuyos valores estén disponibles para las funciones de ofertas del comprador.

Venta: Al igual que en el flujo de compra anterior, es posible que la venta quiera obtener información sobre las creatividades consideradas en la subasta. Por ejemplo, es posible que un publicador quiera exigir que ciertas creatividades no se muestren en su app debido a problemas de seguridad de la marca. Esta información se puede recuperar y poner a disposición para la lógica de subastas de venta. Al igual que en la búsqueda del servidor de confianza orientado a la compra, venda la búsqueda en el servidor de confianza lateral también se realiza con una recuperación de HTTP. La URL se compone uniendo la URL de los indicadores de puntuación confiables con las URLs de renderización de las creatividades para las que se deben recuperar los datos.

A continuación, se incluye una URL de ejemplo para obtener información sobre las creatividades consideradas en la subasta, según las URLs de renderización de creatividades:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

La respuesta del servidor debe ser un objeto JSON cuyas claves sean URLs de procesamiento enviadas en la solicitud.

Estos servidores operarían de manera confiable para ofrecer varios beneficios de seguridad y privacidad:

El valor que muestra el servidor para cada clave es confiable, ya que se basa únicamente en esa clave.
El servidor no realiza registros a nivel de evento.
El servidor no tiene otros efectos secundarios basados en estas solicitudes.

Como mecanismo temporal, el comprador y el vendedor pueden recuperar estos indicadores de ofertas de cualquier servidor, incluidos los que ellos mismos operan. Sin embargo, en la versión de actualización, la solicitud solo se enviará a un servidor de tipo clave-valor confiable.

Los compradores y vendedores podrían usar un servidor de tipo clave-valor común y confiable para plataformas compatibles con Privacy Sandbox en Android y la Web.