Admite la segmentación por público personalizada mediante FLEDGE

Enviar comentarios

En la publicidad para dispositivos móviles, los anunciantes suelen tener la intención de 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 de anuncios. Con esta información, los anunciantes pueden seleccionar anuncios relevantes en sus servidores.

FLEDGE en Android abarca las siguientes APIs para plataformas de tecnología de anuncios y anunciantes a fin de admitir casos de uso comunes basados en interacciones de maneras que se limita el uso compartido de identificadores en apps y de información de interacción de apps de un usuario con terceros:

  1. API de público personalizado: 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.
  2. API de selección de anuncios: Proporciona un framework que organiza los flujos de trabajo de las plataformas de tecnología de anuncios que aprovechan los indicadores del dispositivo para determinar un anuncio "ganador" considerando los anuncios candidatos almacenados de forma local y realizar un procesamiento adicional en los anuncios candidatos que plataforma de tecnología de anuncios muestra en el dispositivo.
Figura 1: Diagrama de flujo que muestra el flujo de trabajo de administración de públicos y elecciones de anuncios personalizados en Privacy Sandbox en Android

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

  1. SportingGoodsApp desea recordarles a los usuarios que compren los artículos que dejaron en su carrito con promoción si no completaron la compra en 2 días. SportingGoodsApp usa la API de público personalizado 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 de anuncios a fin de mostrar sus anuncios a los usuarios de su lista de público. La plataforma de tecnología de anuncios administra metadatos para listas de público y proporciona anuncios de candidatos, que estarán disponibles para el flujo de trabajo de selección de anuncios a fin de ser considerados. La plataforma se puede configurar para recuperar, de forma periódica, anuncios basados en el público actualizados en segundo plano. Esto ayuda a mantener la lista de anuncios candidatos basados en el público actualizados y no correlacionados con las solicitudes enviadas a servidores de anuncios de terceros durante la oportunidad del anuncio (es decir, la solicitud de anuncio contextual).

  2. 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. Esto se puede lograr mediante FrisbeeGame (con un SDK de anuncios integrado) invocando la API de selección de anuncios a fin de seleccionar 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 de anuncios, 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 de anuncios 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.

  3. El SDK de la plataforma de tecnología de anuncios o la aplicación de publicación de anuncios procesa el anuncio seleccionado.

  4. La plataforma facilitará 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 informes de atribución. Las plataformas de tecnología de anuncios pueden personalizarse en función de sus necesidades de creación de informes.

Administración de públicos personalizada

Público personalizado

Un público personalizado representa un grupo de usuarios con intenciones o intereses comunes. Una app o 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 manera local en el dispositivo. 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:

  • Lector: Red de publicidad del comprador que administra los anuncios para este público personalizado.
  • Nombre: Es un nombre o identificador arbitrario para el público personalizado, como un usuario que "dejó artículos en su 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 creació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 el campo "Indicadores de oferta de usuario". 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 de anuncios para cualquier filtro y oferta de anuncios de remarketing. Algunos ejemplos de indicadores son la ubicación aproximada del usuario y la configuración regional preferida.
  • Indicadores de ofertas confiables: Las plataformas de tecnología de anuncios 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 de anuncios 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 de anuncios.
  • 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 de anuncios 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.

Únete a un público personalizado

Para solicitar unirte a un público personalizado en una app, llama a joinCustomAudience(), como se muestra en el siguiente fragmento de código ilustrativo:

CustomAudience audience = new CustomAudience(
    "com.sporting-goods.app",      // Owner. Defaults to the calling app's
                                   // package name.
    "com.example-dsp",             // Reader.
    "running-shoes",               // A logical name for the custom audience.
    currentTime,                   // Creation time.
    expirationTime,                // Expiration time.
    Uri.parse("https://..."),      // Daily update URL.
    biddingData,                   // Trusted Bidding Data key/value pairs.
    candidateAdsList,              // List of candidate ads related to
                                   // this custom audience.
    biddingLogicUrl
);

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

La app que llama a ajoinCustomAudience() es la propietaria de ese público personalizado. Cuando se llama a este método, la app debe especificar la siguiente información:

Lector: Representa a las partes que pueden acceder al público personalizado y recuperar información relevante del anuncio.

Nombre: Es el nombre para este público personalizado.

URL de actualización diaria: Es la URL de la lista de anuncios de los candidatos.

Anuncios candidatos: Cuando un propietario de público personalizado se une a un público personalizado, puede recuperar anuncios candidatos de una plataforma de compra. La plataforma también se puede configurar para recuperar anuncios periódicamente.

Abandona un público personalizado

El propietario de un público personalizado puede elegir abandonar la llamada llamando a LeaveCustomAudience(), como se muestra en el siguiente fragmento de código de ejemplo:

// Define a custom audience populated with key fields.
CustomAudience audience = new CustomAudience(
    "com.sporting-goods.app",     // Owner. Defaults to
                                  // the calling app's package name.
    "com.example-dsp",            // Reader.
    "running-shoes"               // A logical name for the custom audience.
    ...
);

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

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 tienen al menos un público personalizado asociado.
  • Los usuarios pueden quitar apps de esta lista. La eliminación borrará todos los públicos personalizados asociados con las aplicaciones y evitará que estas se unan a otros nuevos.

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

Permisos y control de plataformas de tecnología de anuncios

El objetivo de la propuesta es proporcionar control a las app 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 de anuncios 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.

Recupera anuncios candidatos para públicos personalizados

Las plataformas de compra pueden tener anuncios candidatos basados en la interacción del usuario almacenados en el dispositivo, de modo que se pueden evaluar cuando se ejecuta una subasta para el público personalizado. Los anuncios candidatos y los metadatos relacionados con un público personalizado se pueden recuperar de dos maneras complementarias.

  1. Recuperación diaria del sistema: Cuando una app se une a un público personalizado, puede especificar una URL de actualización diaria, que la plataforma consultará a diario. Las plataformas de tecnología de anuncios pueden usar esta función para mantener actualizada la lista de anuncios y quitar aquellos que ya no estén activos o no tengan presupuesto restante. La plataforma se asegurará de que un extremo de URL pase un umbral de privacidad de anonimato k antes de procesar la solicitud de recuperación del anuncio.
  2. Recuperación basada en propietarios de públicos personalizados: Cuando un propietario agrega un usuario a un público personalizado, puede recuperar anuncios de candidatos de una plataforma orientada a la compra. Los anuncios y los metadatos mostrados se pueden almacenar en el campo "anuncios" del público personalizado. Las plataformas de tecnología de anuncios podrían querer usar esta función si quieren empezar a publicar anuncios para este usuario de inmediato.

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

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 de anuncios.

En la actualidad, las plataformas de tecnología de anuncios 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 selección de anuncios. 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 de anuncios 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 de anuncios 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 de anuncios 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 a fin de 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 de anuncios quieran crear submodelos de ofertas (la implementación puede basarse en un patrón llamado modelo de dos torres) que pueda funcionar en características de anuncios e indicadores de contexto por separado, y que combine 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.

Figura 2: Diagrama de flujo que muestra el inicio del flujo de trabajo de la 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 de anuncios en función de la siguiente secuencia:

  1. Ejecución de la lógica de ofertas de compra
  2. Filtrado y procesamiento de anuncios de compra
  3. Ejecución de la lógica de decisión de 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 publicitaria de tecnología puede iniciar el flujo de trabajo de selección de anuncios llamando al método runAdAuction().

La API espera los siguientes parámetros

Vendedor: Es el identificador de la plataforma publicitaria de venta.

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.

Indicadores de subasta: Incluye información sobre la subasta (tamaño del anuncio, formato del anuncio, etcétera).

Indicadores de vendedor: Son los indcadores 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 de anuncios que inicia el flujo de trabajo de selección de anuncios:

AuctionConfig myAuctionConfig = new AuctionConfig {
    "com.example.app",         // Package name for the calling app.
    Uri.parse("https://..."),  // Decision logic URL.
    customAudienceBuyerList,   // List of package names
                               // for custom audience buyers.
    auctionSignals,            // Auction signals
    sellerSignals,             // Seller signals
    perBuyerSignals,           // Per buyer signals
    ...
};

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

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 por 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. Podría ser un anuncio de público personalizado o el que se muestra en una respuesta contextual.

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 de anuncios se basan en datos en tiempo real para informar la recuperación y 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 de anuncios 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 de anuncios que envía esta solicitud será un servidor de confianza administrado por la plataforma de tecnología de anuncios.

Indicadores contextuales: Pueden incluir una marca de tiempo aproximada o información de ubicación aproximada.

Indicadores de usuario: Pueden incluir información como, por ejemplo, la que está disponible sobre el paquete instalado.

Lógica de filtro de compra

Las plataformas de compra podrán filtrar anuncios según indicadores adicionales disponibles en el dispositivo disponibles durante la fase de selección de anuncios. Por ejemplo, las plataformas de tecnología de anuncios 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 ejecutará después de la lógica de ofertas.

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:

filterAd(ad, per_buyer_signals, trusted_bidding_signals, contextual_signals,
        user_signals) {
    // ...
    return is_filtered;
}

Esta función de JavaScript espera parámetros de entrada similares a los de la función de lógica de ofertas.

Lógica de decisió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 runAdAuction() 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 las funciones generateBid() y filterAd().

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 runAdAuction().

Indicadores de puntuación de confianza: Las plataformas de tecnología de anuncios 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 de anuncios.

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 de anuncios 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 de anuncios debe escribirse en JavaScript. Esto permite que las plataformas de tecnología de anuncios, 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 de un usuario ni su historial de participación en la app mediante información sobre el anuncio ganador (similar a la propuesta de marcos protegidos de Chrome).

Informes de impresiones

Una vez que se renderiza el anuncio, la impresión ganadora se puede informar a las plataformas de compra y venta participantes. La plataforma invocará la lógica del informe en este orden:

  1. Informes de venta
  2. Informes de compra

Esto brinda a las plataformas de compra y venta un medio para enviar información importante disponible en el dispositivo (como datos de ofertas, nombres de públicos personalizados, etc.) a los servidores a fin de habilitar capacidades como el presupuesto en tiempo real, las actualizaciones de modelos de ofertas y flujos de trabajo de ofertas precisos. Esta compatibilidad con los informes de impresiones es complementaria a la API de informes de atribución.

Informes de venta

La plataforma invocará 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 runAdAuction():

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    return reporting_url, signals_for_buyer;
}

Salida:

  • URL de informes: La plataforma invocará esta URL que mostró la función.

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: A fin de admitir el uso compartido de datos entre las partes proveedoras y demandantes, la plataforma pasará este valor que se muestra como parámetro al código de informe de demanda.

Informes de compra

La plataforma invocará la función reportResult() 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.

reportResult(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    return reporting_url;
}

Entrada:

  • auction_signals y per_buyer_signals se recuperarán 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 contendrá la información sobre el público personalizado. Es posible que se agregue más información en el futuro.

Salida:

  • URL de informes: La plataforma invocará esta URL que mostró la función.

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

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 en 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 revelarí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 uniendo la URL de la clave con las claves presentes en los metadatos de indicadores de ofertas de confianza del público personalizado que se está procesando. 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 en el servidor de confianza de compra, la búsqueda del servidor de confianza de venta también se realiza mediante 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.