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

Enviar comentarios

Actualizaciones recientes

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

Descripción general

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 publicitaria. 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 publicitaria 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 publicitaria que aprovechan los indicadores del dispositivo para determinar un anuncio "ganador" considerando los anuncios candidatos almacenados de forma local y realizando un procesamiento adicional en los anuncios candidatos que la plataforma de tecnología publicitaria muestra en el dispositivo.
Figura 1: Diagrama de flujo que muestra el flujo de trabajo de administración de públicos y selecciones 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 publicitaria a fin de 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 pondrán 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 basados en el público actualizados 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).

  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. FrisbeeGame (con un SDK de anuncios integrado) logra esto invocando la API de selección de anuncios 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.

  3. El SDK de la plataforma de tecnología publicitaria 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 publicitaria pueden personalizarse en función de sus necesidades de creación de informes.

Obtén acceso a FLEDGE para las APIs de Android

Las plataformas de tecnología publicitaria deben inscribirse para acceder a las APIs de FLEDGE para Android. Consulta Inscríbete para obtener una cuenta de Privacy Sandbox y 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 diferentes de FLEDGE en los grupos de interés 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. FLEDGE permite la definición y configuración del público personalizado de una manera que preserva la privacidad. 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 las APIs de FLEDGE, se busca admitir estos SDK proporcionando soluciones flexibles para la administración de públicos personalizados habilitando en los emisores 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);

fetchCustomAudience()

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 fetchCustomAudience() con los parámetros esperados, como en el siguiente ejemplo:

CustomAudienceFetchRequest fetchRequest = new CustomAudienceFetchRequest(
    // 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("{...}")
);

fetchCustomAudience(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": 1680603133,
 "expiration_time": 1680803133,
 "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/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": "key1",
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": "key2",
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

La API de fetchCustomAudience() 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 fetchCustomAudience() 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 CustomAudience falle. En particular, una respuesta de estado HTTP de 429 (Demasiadas solicitudes) bloqueará las solicitudes de la aplicación actual durante un período a definir. Las fallas se informan al llamador de la API que es responsable de reintentarlo en caso de fallas temporales (por ejemplo, si el servidor no responde o si se agota el tiempo de espera), o de controlar fallas persistentes (como fallas de validación de datos o cualquier otro tipo de error no temporal 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 mediante las propiedades opcionales que se muestran en el ejemplo anterior. Si se especifican, la respuesta que el comprador recibió no puede reemplazar estos valores. FLEDGE ignorará los campos en la respuesta. 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 los datos especificados para el público personalizado se limita a 8 KB.

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 fetchCustomAudience() 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 de 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 FLEDGE 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 FLEDGE 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 FLEDGE por completo. 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 FLEDGE. Cuando esto sucede, las APIs de FLEDGE muestran un mensaje de excepción estándar: SECURITY_EXCEPTION.

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

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

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 FLEDGE filtre los anuncios según los datos en el dispositivo. Para obtener más detalles, consulta la lógica de filtrado orientado a la 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 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 publicitaria en función de la siguiente secuencia:

  1. Ejecución de la lógica de ofertas orientada a la compra
  2. Filtrado y procesamiento de anuncios de compra
  3. 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: Son 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 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 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 FLEDGE y que no saldrán del dispositivo. A medida que consolidamos los diseños de la 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 mediante información sobre el anuncio ganador (similar a la propuesta de marcos vallados 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 selectAds():

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

Resultado:

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

Resultado:

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

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