Guía de pruebas y integración de Protected Audience (antes conocida como FLEDGE) para SSP

Como parte de Privacy Sandbox, Chrome propuso Protected Audience API, una API en el navegador que permite a los anunciantes y a las empresas de tecnología publicitaria seleccionar y segmentar grupos de interés (listas de público) sin depender de cookies de terceros y, al mismo tiempo, proteger a los usuarios del seguimiento entre sitios. Desarrollador guía

Las SSP pueden probar la API de Protected Audience con Display & Video 360 y Google Ads para hacer lo siguiente:

• Itera los flujos de la API de Protected Audience y obtén información sobre su eficacia.
• Proponer y generar comentarios sobre posibles mejoras de la API en público foros, por ejemplo, GitHub.
• Prepárate para admitir la publicidad personalizada a través de Protected Audience API sin depender de cookies de terceros.

En la siguiente guía, se describen los detalles de la integración entre una SSP y Display & Video 360 y Google Ads Las SSP interesadas en coordinar una prueba deberían con sus campañas de Display y Representante de la sociedad de Video 360

Inscripción

Las SSP deben registrarse por su cuenta para usar la API de Protected Audience.

Resumen del flujo de entrega

En el siguiente diagrama, se muestra el flujo genérico que describe los principales puntos de interacción entre Chrome, SSP, Display y Video 360 y Google Ads

Opciones de integración

Opción 1: Directo o Vendedor único

Pasos:

1. La etiqueta de anuncio de la SSP envía una solicitud de anuncio al servidor de la SSP indicando que el navegador es compatible con la API de Protected Audience.
2. El servidor SSP envía una solicitud de oferta de OpenRTB contextual a la DSP para indicar que se navegador compatible con la API de Protected Audience
3. La DSP responde con una respuesta de oferta de OpenRTB que contiene señales para el subasta integrada en el dispositivo.
4. El servidor de la SSP envía la respuesta del anuncio con la configuración de la subasta a la etiqueta de anuncio de la SSP.
5. La etiqueta de anuncio de la SSP inicia la subasta integrada en el dispositivo mediante una llamada runAdAuction(): pasando señales de la respuesta de oferta de OpenRTB de la DSP a través de perBuyerSignals
6. Chrome llama al servidor de ofertas DSP de confianza del par clave-valor. para recuperar indicadores de las ofertas en tiempo real.
7. Chrome llama a generateBid() Función de JavaScript de la DSP para cada grupo de interés participante.
8. Chrome llama al servidor de puntuación de SSP de confianza de clave-valor. para recuperar indicadores de puntuación en tiempo real.
9. Chrome llama a scoreAd() Función de JavaScript de SSP para cada grupo de interés participante.
10. Chrome llama a reportWin() Función de JavaScript de la DSP para informar al ganador a la DSP.
11. Chrome llama a reportResult() Función de JavaScript de la SSP para informar el ganador a la SSP.

Cambios mínimos en la SSP

• La etiqueta de anuncio de la SSP se debe actualizar para

  • detectar si el navegador es compatible con la API de Protected Audience
  • Enviar esa información como parte de la solicitud de anuncio al servidor de la SSP. [1]
  • Inicia una subasta integrada en el dispositivo llamando a runAdAuction() y pasando indicadores de la respuesta de oferta de OpenRTB de la DSP [5] (consulta el campo purchasedata en solicitud de oferta y estructura de respuesta a continuación).

• el servidor de SSP necesita

  • propagar información sobre la compatibilidad de la API de Protected Audience a la DSP a través del campo de la solicitud de oferta de OpenRTB [2] (consulte la sección sobre ofertas la estructura de solicitud y respuesta a continuación).
  • propagar los indicadores del comprador de la DSP en la respuesta de oferta de OpenRTB al anuncio de la SSP etiqueta (consulta la sección sobre solicitud de oferta / estructura de respuesta a la oferta más abajo) [4]

• [Optional] La SSP necesita implementar un servidor de SSP de confianza para recuperar el contenido en tiempo real. indicadores de puntuación para respaldar los controles de calidad de los anuncios y la aplicación de la configuración del publicador. [8]

• La SSP necesita implementar JavaScript con "scoreAd(...)" y "reportResult(...)". funciones [9], [11]

Opción 2: Varios vendedores

Pasos:

1. El adaptador de SSP envía una solicitud de anuncio al servidor de la SSP indicando que el navegador es compatible con la API de Protected Audience.
2. El servidor SSP envía una solicitud de oferta de OpenRTB contextual a la DSP para indicar que se navegador compatible con la API de Protected Audience,
3. El servidor DSP responde con una respuesta a la oferta de openRTB que contiene señales subasta integrada en el dispositivo.
4. El servidor de la SSP envía la respuesta del anuncio con la configuración de la subasta a la etiqueta de anuncio de la SSP.
5. El adaptador de SSP Prebid proporciona la configuración de subasta de componentes al servidor de anuncios del publicador etiqueta.
6. La etiqueta del servidor de anuncios del publicador envía una solicitud de anuncio al servidor de ese servidor.
7. La etiqueta del servidor de anuncios del publicador inicia una subasta integrada en el dispositivo mediante una llamada runAdAuction(...) en la API de Cloud.
8. Chrome llama al servidor de ofertas DSP de confianza del par clave-valor. para recuperar indicadores de las ofertas en tiempo real.
9. Chrome llama a generateBid() Función de JavaScript de la DSP para cada grupo de interés participante.
10. Chrome llama al servidor de puntuación de SSP de confianza de clave-valor. para recuperar indicadores de puntuación en tiempo real.
11. Chrome llama a scoreAd() Función de JavaScript de SSP para cada grupo de interés participante.
12. Chrome llama a reportWin() Función de JavaScript de la DSP para informar al ganador a la DSP.
13. Chrome llama a reportResult() Función de JavaScript de la SSP para informar el ganador a la SSP.

Cambios mínimos en la SSP

• El adaptador de SSP debe actualizarse para

  • detectar si el navegador admite Protected Audience
  • Enviar esa información como parte de la solicitud de anuncio al servidor de la SSP. [1]
  • Proporcionar la configuración de subasta del componente a la etiqueta de anuncio del servidor de anuncios del publicador [5]
  • Si Google Ad Manager es el servidor de anuncios del publicador, la SSP puede realizar alguna de estas acciones: * Usar Prebid Protected Audience módulo * Llamar a la etiqueta de anuncio setConfig() de Google Ad Manager API con varios vendedores

• el servidor de SSP necesita

  • propagar información sobre la compatibilidad de Protected Audience a la DSP a través de en el campo de la solicitud de oferta de OpenRTB [2] (consulte la sección sobre ofertas la estructura de solicitud y respuesta a continuación).
  • propagar los indicadores del comprador de la DSP en la respuesta de oferta de OpenRTB al anuncio de la SSP etiqueta (consulta la sección sobre solicitud de oferta / estructura de respuesta a la oferta más abajo) [4]

• [Optional] La SSP necesita implementar un servidor de SSP de confianza para recuperar el contenido en tiempo real. indicadores de puntuación para respaldar los controles de calidad de los anuncios y la aplicación de la configuración del publicador. [10]

• La SSP necesita exponer JavaScript con scoreAd() y reportResult() funciones [11], [14].

Servicios de ofertas y subastas

Estamos evaluando detenidamente las ofertas y Servicios de subastas (B&A) proposal

Cuando se muestran Video 360 está listo para probar la API de Protected Audience con B&A, nos comunicaremos contigo para darte más detalles.

Protocolo OpenRTB

Solicitud de oferta

Para diferenciar entre las oportunidades de impresión que admiten la protección API de Audience para la subasta integrada en el dispositivo de aquellas que solo admiten Subasta de intercambio del servidor, un nuevo campo de enumeración llamado ae para "subasta" entorno" debe agregarse como una extensión del objeto Imp en el archivo una solicitud de oferta para especificar qué entorno de subasta es compatible con la espacio de impresión. La enumeración ae puede tener los siguientes valores:

• 0: Subastas estándar del servidor
• 1: Son solicitudes compatibles con la API de Protected Audience, en las que se muestra la subasta se ejecuta en los servidores del intercambio, y las ofertas del grupo de interés, y La subasta final se ejecuta en el navegador.

{
  "id": …
  "imp": [{
    "id": "1"
    "video": {...}
    "ext": {
      "ae": 1
    }]
}

Respuesta a la oferta

Además de las ofertas contextuales, una respuesta a la oferta también se usa para pasar que es relevante para las campañas de Display La participación de Video 360 y Google Ads en el Subastas de grupos de interés de la API de Protected Audience. La respuesta a la oferta se actualiza admiten las subastas de grupos de interés de la siguiente manera:

{
  "seatbid": [{
    "bid": [{
      … // Traditional contextual bids
    }]
  }],

  "ext": {
    // InterestGroupBidding object which holds information for running an
    // in-browser interest group auction.
    "igbid": [{
      // ID of the Imp object of the impression to which
      // these interest group bidding signals apply to.
      "impid": "1",

      // InterestGroupBuyer object which holds DSP information for the in-browser
      // auction.
      "igbuyer": [{
        // Origin of Display & Video 360 and Google Ads to participate in the
        // interest group auction. For more info regarding the origin see:
        // https://developer.mozilla.org/en-US/docs/Glossary/Origin
        "origin": "https://td.doubleclick.net",

        // Buyer-specific signals to use in auctionConfig as perBuyerSignals.
        // Used by the buyer's interest group bidding function. Can be left empty
        "buyerdata": ...,

        // Buyer experiment group id to support coordinated experiments with
        // buyers' trusted servers. This experiment id should be added to the
        // `perBuyerExperimentGroupIds` map in auctionConfig.
        "buyer_experiment_group_id": 12345
      }]
    }]
  }
}

Se admiten las siguientes situaciones.

• SITUACIÓN 1: Anuncios gráficos y Video 360 y Google Ads solo quieren participar en una subasta contextual. En esta situación, no hay ningún campo igbid.

• SITUACIÓN 2: Anuncios gráficos y Video 360 y Google Ads solo quieren participar en una subasta de un grupo de interés. En este caso, Display & Los anuncios de video en 360° y Google Ads eliminará el campo seatbid en la respuesta a la oferta y solo mostrar información de igbid. En otras palabras, la presencia del campo igbid indica el hecho de que Display & Video 360 y Google Ads quieren que sus grupos de interés para participar en la subasta integrada en el dispositivo.

• SITUACIÓN 3: Anuncios gráficos y Video 360 y Google Ads quieren participar en subastas contextuales y de grupos de interés. En este caso, Display & Video 360 y Google Ads mostrarán ambos campos seatbid en la respuesta a la oferta e igbid.

Metadatos con oferta de anuncios

La API de Protected Audience permite el passing arbitrary metadata sobre el anuncio a partir de la función generateBid().

Anuncios gráficos y Video 360 planea basarse en lo siguiente: specification para los metadatos de anuncios: API de Protected Audience y OpenRTB.

A saber, Display & Video 360 mostrará los siguientes campos como parte del anuncio. objeto:

Atributo PA	Tipo	Descripción de OpenRTB
ad.seat	String; obligatorio.	ID de la licencia del comprador (p.ej., anunciante o agencia) en cuyo nombre se realiza esta oferta.
ad.adomain	String[]	Es el dominio del anunciante para la verificación de listas de entidades bloqueadas (p.ej., “ford.com”). En el caso de las creatividades rotativas, puede usarse una variedad. Los intercambios pueden requerir que solo se permita un dominio.
ad.cid	string	ID de la campaña para ayudar con la comprobación de calidad del anuncio.
ad.crid	string	Es el ID de la creatividad para ayudar con la comprobación de calidad del anuncio.
ad.language	string	Es el idioma de la creatividad que utiliza ISO-639-1-alpha-2. El código no estándar "xx" también puede usarse si la creatividad no tiene contenido lingüístico (p.ej., un banner con solo el logotipo de la empresa). Solo debe estar presente un idioma o langb.
ad.w	integer	Es el ancho de la creatividad en píxeles independientes del dispositivo (DIPS).
ad.h	integer	Es la altura de la creatividad en píxeles independientes del dispositivo (DIPS).

Ejemplo

{
  "seat": "123"
  "adomain": ["example.com"]
  "cid": "12345"
  "crid": "12345"
  "language": "en"
  "w": 300
  "h": 250
}

Informes de eventos

La API de Protected Audience proporciona una API de informes a nivel del evento que se describe en este Publicación de GitHub: Fenced Frame Ads Reporting. Aunque su nombre dice "Fenced Frame Ads Reporting", la API está disponible en marcos vallados e iframes (consulta los detalles here)

La SSP puede registrar una URL con el navegador en su función reportResult mediante la ejecución del siguiente comando: llamando a registerAdBeacon() en la API de Cloud.

Anuncios gráficos y Video 360 llamará a reportEvent() API con el destino "component-seller" desde la creatividad para informar impresiones y clics. De este modo, se enviará una baliza al URL registrada.

Ten en cuenta que Display & Video 360 llamará a la API de reportEvent() para las impresiones y clics sin datos de publicación vacíos.

Ejemplo

registerAdBeacon({
 'impression': 'https://ssp.example/impression?ssp_event_id=abc',
});
registerAdBeacon({
 'click': 'https://ssp.example/click?ssp_event_id=abc',
});

Etiqueta de prueba de baja de cookies

Anuncios gráficos y Video 360 participará en Chrome-facilitated testing de baja de las cookies de terceros. Para realizar las pruebas, les pedimos a los socios que pasar las etiquetas de Chrome en la solicitud de oferta de OpenRTB de acuerdo con lo siguiente: specification:

Objeto: Device.ext

Atributo	Tipo	Descripción
CDEP	String	la etiqueta tal como se recibió de Chrome o de un socio upstream.

Documentos relacionados

• API de Protected Audience en Chrome Developers
• Primer experimento en GitHub