API de Protected Audience (anteriormente FLEDGE)

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 mostrar anuncios segmentados por grupos de interés sin depender de cookies de terceros y, al mismo tiempo, proteger a los usuarios contra el seguimiento de conversiones.

Chrome está ejecutando un origen prueba para la API de Protected Audience. Los compradores de Authorized Buyers son aptos para participar en las pruebas de la API de Protected Audience en el inventario del publicador de Ad Manager. Los ofertantes pueden lograr lo siguiente si prueban la API de Protected Audience:

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

Los compradores de Authorized Buyers interesados en realizar pruebas deben consultar el artículo de Onboarding sección para obtener más información.

Resumen del flujo de entrega

Este es un resumen del flujo de publicación de anuncios de Protected Audience para Authorized Buyers socios:

Diagrama de flujo.

  1. Un ofertante trabaja con sus anunciantes para mantener grupos de interés para cada uno anunciante. A menudo, los anunciantes agregaban la etiqueta de un ofertante al la página del anunciante para agregar un navegador a los grupos de interés.
  2. Un usuario final visita la página de un anunciante. Es posible que la página contenga la información etiqueta.
  3. La etiqueta del ofertante invoca la API de Protected Audience joinAdInterestGroup(). Esta llamada solicita al navegador que agregue al usuario a un grupo de interés.
  4. El usuario final visita la página web de un publicador. Las solicitudes del navegador del usuario La etiqueta de anuncio del publicador de Google
  5. La etiqueta de anuncio del publicador de Google realiza una solicitud de anuncio contextual a un servidor de Google.
  6. Google envía solicitudes de ofertas contextuales a los ofertantes participantes. Consulta la Sección de cambios en la solicitud de oferta para obtener más información.
  7. El ofertante muestra una BidResponse con el campo interest_group_bidding. Si el ofertante no especifica interest_group_bidding, Google no lo hace Incluye el origen del ofertante en interestGroupBuyers en la subasta. configuración. La respuesta a la oferta también puede contener interest_group_bidding.per_buyer_signals. Se pasarán per_buyer_signals a la función de licitación del ofertante durante subasta en el navegador. Consulta el artículo Cambios en la respuesta de ofertas para obtener más información.
  8. Google ejecuta la subasta del servidor y devuelve una respuesta de oferta al navegador. La subasta del servidor considera las ofertas tradicionales del servidor. La respuesta a la oferta puede contener información sobre una oferta contextual ganadora (si cualquiera).
  9. La respuesta a la oferta contiene una configuración de subasta para la configuración subasta. Esto puede incluir indicadores contextuales de cada comprador participante (que se enviaron a través de interest_group_bidding.per_buyer_signals) información contextual del ganador y la configuración para la elegibilidad de la oferta.
  10. La etiqueta del publicador de Google invoca la API de Protected Audience runAdAuction(). para iniciar la subasta de un grupo de interés integrado en el dispositivo. Google solo incluye compradores que anteriormente devolvieron interest_group_bidding como interestGroupBuyers en la configuración de la subasta.
  11. Google pasa el per_buyer_signals de cada ofertante apto al Protected Configuración de la subasta de públicos.
  12. Si los grupos de intereses de un ofertante específico especificaron el trustedBiddingSignalsUrl, el navegador realiza una solicitud a la carpeta de cada grupo trustedBiddingSignalsUrl para recuperar indicadores en tiempo real de cada grupo. Consulta detalles en la API de Protected Audience spec.
  13. El navegador invoca el generateBid() del ofertante para cada grupo de interés. que la hayan habilitado y sean aptas para participar en la subasta en el navegador. Esta calcula la oferta y selecciona una creatividad. generateBid() tiene acceso a los per_buyer_signals que proporcionó el ofertante y la licitación de confianza indicadores para el grupo de interés determinado.
  14. El navegador invoca el elemento scoreAd() del vendedor (en este caso, el de Google) para hacer lo siguiente: asignar una clasificación a cada oferta en la subasta de anuncios del grupo de interés. Las ofertas están clasificadas. y se filtran según las protecciones de publicadores, las políticas de anuncios y otras restricciones.
  15. El navegador ejecuta una subasta con las ofertas aptas del grupo de interés. El la oferta contextual mejor clasificada participa en la subasta en el navegador.
  16. Después de la subasta, si hay un ganador del grupo de interés, el navegador invoca la reportResult() del vendedor y el reportWin() del ofertante para notificar a cada sobre el ganador de la subasta en el navegador.
  17. Si gana un anuncio basado en un grupo de interés, la etiqueta del publicador de Google renderiza el anuncio en una iframe.

Detalles del flujo de entrega

Antes de la publicación de anuncios

Revisión de creatividades

Google debe revisar y aprobar las creatividades antes de que se puedan publicar desde Subastas en el navegador de Protected Audience. Puede enviar creatividades para su revisión mediante la API de Real-time Bidding o mediante análisis automático de creatividades. Creatividades para Las subastas de anuncios de los grupos de interés en el navegador de Protected Audience deben incluir renderUrls para su revisión.

Requisitos de renderUrls:

  • El renderUrl enviado a través de la API debe coincidir con el renderUrl usado en la subasta de anuncios de un grupo de interés.
  • Cada renderUrl solo puede representar a un único anunciante o publicidad campaña. No se puede usar un renderUrl determinado para renderizar anuncios en nombre de varios anunciantes. Cada renderUrl debe asignarse a una sola creatividad.
  • Google debe poder acceder a renderUrl y recuperarlo de revisión de creatividades hasta 7 días después de la última oferta con la que se realizó la oferta del anuncio.
API de Real‑time Bidding

Los ofertantes pueden usar la pestaña Ofertas en tiempo real API para subir creatividades ofertas basadas en el grupo de interés.

Análisis automático de creatividades

Los ofertantes pueden configurar el análisis automático de creatividades para las creatividades que no subir a través de la API de Real-time Bidding.

Si configuras el análisis automático de creatividades, Google encontrará creatividades en la una subasta en el navegador y las analiza automáticamente para que cumplan con los requisitos en subastas futuras.

A continuación, te indicamos cómo activar el análisis automático de creatividades:

  • Agregar todos los orígenes de renderUrl de la creatividad del grupo de interés al Cuenta de Authorized Buyers

  • Agrega los siguientes encabezados HTTP personalizados a la respuesta HTTP de la creatividad:

    Authorized-Buyers-Creative-ID

    string

    Es el ID de la creatividad específico del comprador. La longitud máxima del ID del mensaje publicitario es 128 bytes.
    Authorized-Buyers-Click-Through-URLs

    string

    El conjunto de URL de destino declaradas para la creatividad codificada según a RFC2396.

Ejemplo:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
Vencimiento de la creatividad

Las creatividades se aprueban durante 15 días. Si envía creatividades con el panel de ofertas de la API, tendrás que volver a enviar la creatividad después de 15 días. Si confías en análisis automático de creatividades, el proceso de análisis vuelve a analizarlas automáticamente.

ID de informe de comprador

Puedes desglosar las métricas de los informes (como las impresiones) mediante dimensiones. proporcionados por el comprador (por ejemplo, el ID de campaña o el ID del anunciante). Para agregar un dimensión para la inversión del grupo de interés, especifica un buyerAndSellerReportingId para el anuncio cuando agregues el dispositivo del usuario al grupo de interés. Consulta las detalles en Protected Audience documentación.

El siguiente es un ejemplo de cómo agregar buyerAndSellerReportingId en la configuración del grupo de interés:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

buyer_reporting_id aparecerá como una nueva dimensión en la pestaña Herramienta de informes del comprador, como dimensión ID de informe del comprador

Subasta del servidor

Cambios en la solicitud de oferta

Las siguientes son las primeras versiones de los protocolos compatibles para su uso en el experimento:

Cómo indicar la asistencia para subastas del grupo de interés

Las solicitudes de oferta tienen un campo nuevo: auction_environment.

  • Protocolo de RTB de Google: BidRequest.adslot.auction_environment
  • OpenRTB: BidRequest.imp.ext.auction_environment

Puedes usar este campo para diferenciar las oportunidades de impresión que admitir la subasta de grupos de interés en el navegador de Protected Audience y aquellas que solo admiten la subasta de intercambio tradicional del servidor. El La enumeración auction_environment puede tener los siguientes valores:

  • SERVER_SIDE_AUCTION (JSON de OpenRTB: 0): Subastas tradicionales del servidor
  • ON_DEVICE_INTEREST_GROUP_AUCTION (JSON de OpenRTB: 1): Solicitudes con Compatibilidad con Protected Audience, en la que se ejecuta una subasta contextual en el los servidores de Exchange, y las ofertas del grupo de interés, y las ejecuciones de la subasta final en el navegador.
Indica el tamaño del espacio publicitario de Protected Audience

La solicitud de oferta incluye los siguientes campos para brindarte el Tamaño del espacio publicitario del público:

  • Protocolo de RTB de Google:
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height
  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height

Estos campos indican el tamaño del espacio publicitario para la subasta de Protected Audience. en píxeles.

Este tamaño puede ser diferente de los tamaños de la solicitud contextual. (Adslot.widthy Adslot.height, o en OpenRTB: BidRequest.imp.banner.format).

La solicitud contextual puede tener varios tamaños. El ganador de la subasta integrada en el dispositivo se espera que el anuncio rellene un solo tamaño de espacio fijo.

Indica la renderización de anuncios de Protected Audience

Los anuncios de Protected Audience pueden o no renderizarse según la configuración de integración (consulta No renderización, experimento). El render_interest_group_ads de la solicitud de oferta indica si el anuncio ganador de Protected Audience se renderizarán los datos.

  • Protocolo de RTB de Google: BidRequest.adslot.interest_group_auction.render_interest_group_ads
  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
Minimiza el uso de identificadores de usuario

Las solicitudes de ofertas contextuales dentro del alcance de las pruebas de la API de Protected Audience pueden seguirán llevando identificadores tradicionales basados en cookies cuando estén disponibles navegador, como google_user_id (BidRequest.user.id en OpenRTB) y hosted_match_data (BidRequest.user.buyerid en OpenRTB). La presencia de dichos identificadores en las solicitudes de oferta seguirán estando sujetos a cualquier políticas de privacidad de Google. Te recomendamos que no uses identificadores basados en cookies para la segmentación y las ofertas durante las pruebas, a fin de preparar mejor comprar cuando ya no estén disponibles las cookies de terceros.

Google podría ejecutar experimentos a pequeña escala en los que los identificadores basados en cookies oculta de las solicitudes de oferta dentro del alcance de las pruebas de la API de Protected Audience. Esta es evaluar el posible impacto de la baja de las cookies de terceros.

Para prepararte para el baja de las cookies de terceros (3PCD) en el 2024, Chrome ahora ofrece Pruebas facilitadas por Chrome.

Los sitios y proveedores pueden usar las pruebas facilitadas por Chrome para probar sus sistemas según 3PCD En la prueba, los navegadores Chrome se asignan a un grupo experimental de terceros modo A o modo B. A cada navegador se le asigna una etiqueta coherente correspondiente a un grupo experimental de terceros específico al que puedas acceder a través de la API de Chrome en el navegador.

Google pasa la etiqueta sin modificar de la API de Chrome en la oferta de RTB. para cada solicitud. Debido a los pequeños fragmentos de tráfico de una etiqueta individual, no siempre incluye la etiqueta en contextos de privacidad limitada.

Estos son los campos en los que puedes ver la etiqueta:

  • Protocolo de RTB de Google: BidRequest.device.cookie_deprecation_label
  • OpenRTB: BidRequest.device.ext.cdep

Cambios en la respuesta a la oferta

Indicar la participación del grupo de interés en la subasta

Usted es responsable de indicar explícitamente su intención de participar en los subasta en el navegador mostrando el objeto InterestGroupBidding en el respuesta a la oferta contextual:

  • Protocolo de RTB de Google: BidResponse.interest_group_bidding
  • OpenRTB: BidResponse.ext.igbid

Debes proporcionar una respuesta a la oferta contextual. La respuesta no es necesaria para incluir una oferta contextual. El objeto InterestGroupBidding debe contener el elemento origin del propietario del grupo de interés, que debe coincidir con uno de los orígenes configurado por el ofertante para su cuenta. Se agrega origin a la subasta. el parámetro de configuración interestGroupBuyers cuando se llama a Google Publisher Tag runAdAuction()

Propaga indicadores contextuales del comprador (perBuyerSignals)

Puedes incluir los indicadores de un comprador en la respuesta a la oferta contextual, que Google se propaga como un objeto JSON a la función de ofertas en el dispositivo a través de la perBuyerSignals. Este puede incluirse en la respuesta a la oferta con el siguientes campos según el protocolo:

  • RTB de Google: BidResponse.interest_group_bidding.per_buyer_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
Propaga indicadores de renderización contextual del comprador

Las creatividades de grupos de interés pueden usar indicadores contextuales limitados durante la renderización de enviar esos indicadores a través de la respuesta a la oferta contextual y recibirlos en la solicitud de URL de renderización con la expansión de macros. Por ejemplo, la renderización se podrían usar para personalizar el aspecto de una creatividad para mejorar en el contexto de un espacio publicitario o una página del publicador determinados.

Puedes incluir los indicadores de renderización de un comprador serializados como una cadena segura para URLs en la respuesta a la oferta contextual, que Google reemplazará para ganar el interés construye la URL de renderización del grupo Macro ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

Los indicadores de renderización se pueden especificar en la respuesta a la oferta con los siguientes elementos: en función del protocolo:

  • RTB de Google: BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig

Se pueden incluir hasta 3 conjuntos de indicadores de renderización con diferentes sufijos de macros en la respuesta a la oferta para distinguir diferentes indicadores. Por ejemplo, un sufijo Podría usarse para hacer coincidir un conjunto específico de indicadores aplicables solo a las creatividades con la macro correspondiente en su URL de renderización, lo que reduce la transferencia de datos de tamaño del ensamble.

Se rechazará al comprador del grupo de interés que no pueda participar en el Programa de Subasta de público si los indicadores no son seguros para las URLs, los sufijos de macros no son únicos o se proporcionan más de 3 conjuntos de indicadores.

Especificar el precio máximo de la oferta en el navegador

En la sección Protected Audience propuesta, el cálculo de la oferta y se espera que la subasta final se ejecute a nivel local en el dispositivo. Esto puede generar posibles vectores de abuso que pueden afectar la integridad de la subasta final resultados, como el precio de la oferta ganadora.

Como mitigación admitida durante las pruebas de la API de Protected Audience que realiza Google para sus socios de RTB, puede especificar un valor de oferta máximo esperado en cada respuesta a la oferta contextual. La oferta máxima esperada es el precio de oferta máximo que se espera que se muestre tu función de ofertas. Si la oferta ganadora informada desde Si la subasta en el navegador supera este importe, no se cuenta la oferta ganadora como evento facturable. Este enfoque está sujeto a cambios.

En la respuesta de la oferta, puedes especificar el valor de la oferta máximo esperado en la siguientes campos:

  • Protocolo de RTB de Google: BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (expresado en microCPM)
  • OpenRTB: BidResponse.igbid.igbuyer.maxbid(expresado en unidades de moneda del CPM)
Atribuye las impresiones a varias cuentas

Un ofertante debe seleccionar un ID de facturación para atribuir su interés impresiones de la oferta grupal mediante los siguientes campos:

  • Protocolo de RTB de Google: BidResponse.interest_group_bidding.interest_group_buyers.billing_id
  • OpenRTB: BidResponse.igbid.igbuyer.billing_id

El ID de facturación seleccionado debe ser un ID de facturación apto de la solicitud de oferta:

  • Protocolo de RTB de Google: BidRequest.adslot.matching_ad_data.billing_id
  • OpenRTB: BidRequest.imp.ext.billing_id

Si el ID de facturación al que se atribuirán las impresiones de ofertas de grupos de interés no es , el ofertante no participará en la subasta de Protected Audience.

Las cuentas secundarias pueden tener hasta dos IDs de facturación. El comprador podría usar uno Es el ID de facturación para la inversión contextual y el otro para la inversión del grupo de interés. Comunícate con tu administrador de cuentas si deseas configurar dos IDs de facturación. para una cuenta infantil.

Es posible establecer un presupuesto diario para cada ID de facturación. Comunícate con tu administrador de cuentas establezca el presupuesto diario de los IDs de facturación de las cuentas secundarias.

IDs de facturación de todas las cuentas secundarias con presupuesto disponible aptas para ofertar en el impresión aparece en la solicitud de oferta para seleccionar la atribución de inversión. Comunicación para modificar el presupuesto de un ID de facturación de un grupo de interés.

Durante la subasta en el navegador

Generar ofertas en el navegador

Utilice generateBid() para generar ofertas en el navegador.

Google proporciona los siguientes parámetros:

  • auctionSignals: Vacío
  • perBuyerSignals: Es un objeto de JavaScript de los mismos indicadores que proporciona el ofertante en la respuesta contextual

Se muestran los siguientes parámetros:

  • ad: Google ignora este campo.
  • bid: Es una oferta numérica que ingresa en la subasta. Debe estar en unidades de CPM. (no en micros).
  • render: Es la URL renderizada para mostrar la creatividad si la oferta gana el subasta. Google debe revisar y aprobar esta URL; de lo contrario, se filtrará de la subasta.
  • allowComponentAuction: Debe ser true. Actualmente, Google admite pruebas de subastas de varios vendedores.

Por ejemplo:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

Consulta la especificación de Protected Audience en el dispositivo Ofertas para obtener una explicación sobre la función generateBid().

Moneda de la oferta

Las ofertas de subasta en el navegador se realizan en unidades de CPM de la moneda de oferta elegida.

La moneda de la oferta debe indicarse tanto en la respuesta de la oferta contextual como en el valor que se muestra de generateBid y debe ser un código alfa ISO 4217 válido, como como "USD", "EUR" o "JPY".

En OpenRTB, usa el nuevo campo cur en el objeto InterestGroupBuyer en Extensión de respuesta a la oferta de Google.

Por ejemplo:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

En el protocolo de RTB de Google, usa el nuevo campo currency en la InterestGroupBuyer mensaje en la respuesta a la oferta.

Por ejemplo:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

Ofertantes Las funciones generateBid deben mostrar ofertas en la misma moneda que que se indica en la respuesta a la oferta contextual. Completa la nueva propiedad bidCurrency en Valor que se muestra de generateBid:

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

Si la moneda de la respuesta de oferta contextual es diferente de la moneda que devuelve generateBid, o si cualquiera de ellos devuelve una moneda no válida, el oferta se filtrará antes de la subasta.

Controles de calidad del anuncio

La aplicación de la política de creatividades y de los controles del publicador puede ser más restrictiva para lo siguiente: ofertas de grupos de interés en el navegador durante la prueba de RTB de la API de Protected Audience socios.

Asistencia de la Ley de Servicios Digitales

Debido al artículo 26 de la Ley de Servicios Digitales, los publicadores pueden exigir que los compradores en las divulgaciones de transparencia en los anuncios. Cuando aparezca la página "Solicitar a los compradores que solo muestren anuncios información de transparencia en mi sitio o aplicación en el EEE" un control de acceso mediante una publicador, los compradores de grupos de interés pueden determinar de qué oportunidades necesarios para presentar la transparencia del comprador. Para ello, se deben tener en cuenta los siguientes campos en solicitudes de oferta recibidas: BidRequest.dsa.dsa_support y BidRequest.dsa.publisher_rendering_support para el protocolo Google Authorized Buyers y BidRequest.regs.dsa.required y BidRequest.dsa.pubrender para el protocolo OpenRTB.

Cuando un ofertante que desea participar en subastas de la API de Protected Audience recibe el indicador en la solicitud de oferta de que debe mostrarse la transparencia de la DSA anuncios publicados con la API de Protected Audience, deben evaluar puedan mostrar adecuadamente la información requerida y especificar BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render para el protocolo de Google Authorized Buyers o BidResponse.ext.igbid.igbuyer.dsaadrenderpara el protocolo OpenRTB. De lo contrario, no se incluirá el comprador en la subasta de la API de Protected Audience.

Para obtener más información sobre la Transparencia de Anuncios de la Ley de Servicios Digitales, consulte el Artículo del Centro de ayuda: Apoyo a la Ley de Servicios Digitales.

Filtrado de ofertas

Google exige la aplicación de de usuario y de anuncio políticas durante la subasta integrada en el dispositivo.

Después de la subasta en el navegador

Informar el resultado de la subasta al comprador: reportWin()

Google no propaga los siguientes argumentos:

  • auctionSignals
  • sellerSignals

Usa reportWin() para informar el resultado de la subasta al comprador.

Consulta los informes de los compradores sobre el procesamiento y los anuncios. Eventos de la explicación de la API de Protected Audience para obtener más información.

Macros

El renderUrl que hace referencia a la creatividad de la API de Protected Audience puede incluir uno o más marcadores de posición, llamados macros. Después de la subasta de un grupo de interés concluye, pero antes de la renderización, las macros se reemplazan por los de salida. Los renderUrl que se usan en la subasta integrada en el dispositivo pueden incluir lo siguiente: macros:

${GDPR} Se expande a 0 si no se aplica el GDPR o a 1 si sí lo es. Ver la documentación.
${GDPR_CONSENT_XXXX} Se expande a la Transparencia y Cadena de consentimiento (TC) asociada con la solicitud. Si los filtros de transparencia y La cadena de consentimiento (TC) está en blanco o no es válida; esta macro no se expande.

Usa esta macro para pasar la cadena de TC a un proveedor registrado en la GVL de IAB en una URL. Reemplaza XXXX por el ID de la GVL de IAB que se registró en la GVL de IAB con el proveedor de servicios en la nube. Si la cadena de TC está en blanco o no es válida, esta macro no se expande.

Las creatividades con la macro ${GDPR_CONSENT_XXXX} podrían cambiar se bloqueará si el proveedor registrado en la GVL de IAB asociado con su ID insertado no tiene el consentimiento del usuario.

La macro ${GDPR_CONSENT_XXXX} debería ocurrir una sola vez en renderUrl
${ADDL_CONSENT} Se expande a la sección Recursos Cadena de consentimiento (AC) asociada con la solicitud.
${AD_WIDTH}, ${AD_HEIGHT) Estas macros insertan el ancho y la altura del espacio publicitario.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

Macro que contiene indicadores del comprador en el tiempo de renderización especificadas en la respuesta a la oferta.

Reemplaza el marcador de posición buyer.origin.example por el origen del comprador del grupo de interés, que debe corresponder a interest_group_buyers.origin en la respuesta a la oferta. Puedes incluyen un _OPTIONAL_SUFFIX para proporcionar hasta tres renderizando valores de indicadores.

Recuento de impresiones

Durante las pruebas de la API de Protected Audience con socios de RTB, Google contará impresiones cuando el navegador llama a su función reportResult() y y, luego, recuperará la URL de informes de Google en una llamada a sendReportTo().

Dado que el evento que usa Google para contar impresiones en Protected Audience las subastas integradas en el navegador pueden ser diferentes del evento que se usa para contar. impresiones por sus socios compradores de RTB, el recuento de impresiones podría variar.

Uno de los objetivos de Google para probar la API de Protected Audience es identificar y reducir estas discrepancias.

Atribución de impresiones facturables

Toda la inversión de un ofertante de las subastas en el navegador de Protected Audience es que se atribuyen a una sola cuenta de ofertantes en función de la asignación del interés orígenes de propietarios de grupos configurados para el ofertante Atribuir la inversión a diferentes No se admiten las cuentas de licencias secundarias de un ofertante.

Límite de presupuesto diario

Durante la prueba de la API de Protected Audience, cada cuenta tiene un Límite de presupuesto diario de inversión de Protected Audience. El límite del presupuesto diario limita el riesgo en el entorno de subasta en el navegador. Cuando se alcanza el límite del presupuesto diario, la cuenta ya no recibe solicitudes de ofertas aptas para Protected Audience.

La cuenta puede seguir participando en subastas contextuales del servidor después de alcanza el límite de Protected Audience. Por ejemplo, una cuenta de ofertante que alcanza el límite de Protected Audience podría recibir una solicitud de oferta con auction_environment = SERVER_SIDE_AUCTION (OpenRTB: 0), incluso si la solicitud de oferta es apta para una subasta de Protected Audience.

Comentarios en tiempo real y oferta mínima para ganar

Los ofertantes que aceptaron recibir comentarios en tiempo real recibirán comentarios sobre los compradores del grupo de interés a quienes se solicitó que se los incluya en un subasta de Protected Audience integrada en el dispositivo. Cada comprador del grupo de interés al que que especifique que en una respuesta a la oferta recibirán un objeto feedback, independientemente de cómo muchas ofertas que el comprador del grupo de interés coloca en la subasta de Protected Audience. El La siguiente información estará disponible en los comentarios del comprador del grupo de interés. objeto:

  • El tipo de feedback del objeto feedback será INTEREST_GROUP_BUYER_FEEDBACK
  • Indica el origen del comprador del grupo de interés.
  • La oferta mínima para ganar el comprador del grupo de interés con el fin de ganar el la subasta general.
  • La oferta mínima para ganar el comprador del grupo de interés con el fin de superar el la oferta con la clasificación más alta del componente del servidor de la subasta general.
  • Es el código de estado del comprador del grupo de interés. Los códigos de estado posibles son definidos en interest-group-buyer-status-codes.txt.

Consulta la documentación de protocolo para RTB de Authorized Buyers y Extensiones de OpenRTB para los nombres de campos específicos.

Notificación de comentarios sobre la oferta

Chrome ofrece una depuración temporal API de la API de Protected Audience, que permite que Ad Manager envíe notificaciones de depuración servidor a servidor que contengan comentarios sobre una instancia Oferta de público. Esta notificación incluirá algunos motivos por los cuales podrían haberse realizado en la subasta en el navegador de Protected Audience, además de otras información sobre una oferta que se describe a continuación.

Los ofertantes pueden comunicarse con su administrador de cuentas para configurar una URL estática que se que se usan para entregar notificaciones de comentarios sobre la oferta de depuración de Protected Audience. Esta La URL estática se recuperará de los servidores de Google y se reemplazarán las macros seleccionadas después de que se complete la subasta de Protected Audience. Las siguientes macros compatibles:

  • %%GOOGLE_QUERY_ID%%: Esta macro se reemplaza por el ID de consulta de Google. (BidRequest.google_query_id en el protocolo de Authorized Buyers y BidRequest.ext.google_query_id en el protocolo OpenRTB) que se envió en el Solicitud de oferta contextual habilitada para Protected Audience.
  • %%INTEREST_GROUP_OWNER%%: Es el origen del propietario del grupo de interés.
  • %%BID_CPM%%: Es el precio de la oferta en CPM que especificó el comprador en la función generateBid().
  • %%RENDER_URL%%: Es la URL de renderización de la creatividad.
  • %%STATUS%%: Es un código de estado si se rechazó la oferta en scoreAd(). Los valores son el estado de creatividad. infraestructura.

A continuación, se incluye un ejemplo de URL estática que un ofertante puede proporcionar a su administrador de cuentas:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

La notificación de comentarios sobre la oferta es una función temporal que depende de la API temporal de ForDebuggingOnly.

TURTLEDOVE a nivel del producto

Anuncios compuestos por varios elementos o a nivel del producto, TURTLEDOVE (PLTD) es compatible con los socios de RTB de Google durante la API de Protected Audience y pruebas. Durante la integración, informa a tu administrador de cuentas si planeas realizar pruebas. PLTD, ya que se requieren recursos y configuración adicionales.

Integración

Puedes probar la API de Protected Audience de la siguiente manera:

Pasos

  1. Completa el formulario de solicitud. para unirte al experimento de la API de Protected Audience.
  2. Después de enviar el formulario de solicitud, comunícate con tu administrador de cuentas o informa lo siguiente: un ticket mediante la Ayuda de Authorized Buyers Center.
  3. Una vez configurada la cuenta, tanto Google como el socio podrán verificar la mediante los pasos que se indican en Etapas de prueba.

Revisión de creatividades

Para ofertar con anuncios a nivel del producto (anuncios compuestos por varios elementos) En las subastas de la API de Protected Audience, cumple con estos requisitos:

  • Incluye el parámetro de consulta &pltd=True en renderUrl para el componente del contenedor del anuncio (también llamado renderUrl de nivel superior) para distinga el nivel superior renderUrls durante la revisión de creatividades.
  • Renderice una creatividad representativa cuando el contenedor del anuncio de componente esté recuperado para una revisión de creatividades por parte de Google. Para entender cuándo un la renderización de anuncios representativa, puedes consultar el El sistema de revisión de creatividades de Google estableció validation=True parámetro de búsqueda.

Lista de tareas de integración

  • Configura un extremo de solicitud de oferta que propagará la API de Protected Audience campos relacionados en la respuesta a la oferta contextual, por ejemplo, interest_group_bidding
  • Implementar el etiquetado en las páginas del anunciante para unir el navegador del usuario el grupo de interés.
  • Implementa generateBid() y reportWin().
  • Selecciona los orígenes de propietarios del grupo de interés y agrégalos a Authorized Buyers de servicio predeterminada.
    • Los orígenes de los propietarios del grupo de interés deben coincidir con los orígenes en los que Se alojan las funciones generateBid().
    • Comunícate con el administrador de cuentas o envía un ticket a través del Centro de ayuda Centro de ayuda al comprador para completar este paso.
  • Configura la segmentación previa para el inventario relevante para la API de Protected Audience y pruebas.
  • Enviar las creatividades para su revisión y aprobación a través de la pestaña Creatividades API
  • (Opcional) Configura los extremos de los indicadores de ofertas de confianza.
  • (Opcional) Configura una página del anunciante de prueba que permita a los ingenieros de Google agregar su navegador a los grupos de interés que pertenezcan al grupo de interés del comprador origen. Esto nos permite activar manualmente las subastas de Protected Audience.
  • (Opcional) Habilita los comentarios en tu cuenta en tiempo real para recibir comentarios sobre compradores basados en un grupo de interés cuya inclusión se solicite en un público protegido subasta.
  • (Opcional) Comunícate con tu administrador de cuentas para configurar una URL estática para recibir una notificación de servidor a servidor que proporciona la oferta de Protected Audience comentarios sobre el estado de una oferta de un público protegido en el dispositivo subasta para ayudar a depurar problemas inesperados. Ver comentarios sobre la oferta notificación para obtener más información.

Etapas de prueba

Etapa 1: Prueba manual

A continuación, te mostramos cómo activar manualmente una subasta de Protected Audience para asegurarte de que el anuncio pueda y registra la impresión:

  1. Usa Chrome 101 o una versión posterior.
  2. Habilita la API de Privacy Sandbox y el Marco vallado con chrome://flags/#privacy-sandbox-ads-apis y chrome://flags/#enable-fenced-frames Obtén más información en el artículo Prueba la privacidad zona de pruebas.
  3. Enviar una creatividad para su aprobación mediante la herramienta Ofertas en tiempo real API
  4. Usa la página del anunciante proporcionado por el ofertante para agregar un navegador al propietario del ofertante grupo de interés.

  5. Usa la siguiente página del publicador de prueba proporcionada por Google para activar una política Subasta de público:

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

    El grupo de interés en el navegador debe realizar una oferta lo suficientemente alta para ganar la subasta, ya que podría competir con las ofertas del servidor convencionales. Google también proporciona un página dedicada del publicador de prueba para cada socio, en la que solo el socio indicado pueden participar en la subasta. Puede ser más fácil ganar de manera confiable subastas integradas en el navegador, en una página específica del socio.

  6. Verifica lo siguiente:

    1. Se renderiza el anuncio ganador esperado.
    2. El resultado de la subasta se envía del servidor, es decir, un ofertante ganador. recibe un ping de reportWin().
    3. La consola de la página del publicador de prueba registra un mensaje de depuración para cada oferta con la siguiente información:
      • renderUrl: Es la URL de renderización de la oferta.
      • interestGroupOwner: Es el propietario del grupo de interés de la oferta.
      • accepted: Este campo es true si se acepta la oferta y false si scoreAd() rechazó la oferta.
      • externalBidStatus: un código de estado si la oferta se rechazó en un plazo de scoreAd() Los valores son el estado de creatividad. infraestructura.

Etapa 2: (opcional) Experimento sin renderización

Después de que Google y el socio verifiquen manualmente que el socio puede participan en la subasta de Protected Audience, Google permite al socio lo siguiente: la siguiente etapa de prueba.

Google asigna una pequeña cantidad de tráfico en vivo para ejecutar Protected Audience subastas. Luego, ni Google ni el socio deberán activar manualmente un subasta de Protected Audience. El resultado de la subasta de Protected Audience no se se renderizan. Esto nos permite probar la integración a gran escala.

Comunícate con tu administrador de cuentas o envía un ticket a través de Authorized Buyer. Centro de ayuda cuando esté todo listo. Google habilitará la cuenta para esta etapa.

Etapa 3: Experimento de renderización

Una vez que Google y el socio verifiquen las subastas de Protected Audience a gran escala sin la renderización, Google puede permitir que el socio renderice el Programa Anuncio ganador del público. Google tiene una pequeña cantidad de tráfico en la que Las subastas de público son aptas para publicarse, y los anuncios ganadores de grupos de interés no se renderizan. Ofertantes participantes las ofertas en el navegador compiten con el de ofertas.

Comunícate con tu administrador de cuentas o envía un ticket a través de Authorized Buyer. Centro de ayuda cuando esté todo listo. Google habilitará la cuenta para esta etapa.

Funciones adicionales

Las siguientes funciones son extensiones del protocolo principal.

Paralelización

La paralelización es una optimización que disminuye la latencia de la subasta de extremo a extremo en un iniciar la solicitud de anuncios contextuales en paralelo con las solicitudes al servidores de confianza del comprador especificadas en trustedBiddingSignalsUrl.

La paralelización reduce la latencia, pero afecta el grupo de interés la elegibilidad de los compradores para experimentos coordinados. La paralelización se aplica a todos los ofertantes que participan en la subasta de grupos de interés en el dispositivo. No es necesario que los ofertantes tomen medidas para participan en subastas paralelas, pero deben familiarizarse con y cómo la paralelización puede afectar su elegibilidad en las subastas integradas en el dispositivo. Aún no se admiten los IDs de grupo de experimentos para los experimentos coordinados en las subastas paralelas.

Resumen del flujo de entrega

A continuación, se presenta un resumen del flujo de la subasta paralela: Diagrama de flujo.

Elegibilidad de compradores de grupos de interés integrados en el dispositivo

En el caso de las subastas paralelas, la llamada de navigator.runAdAuction ocurre antes. se devuelve la respuesta de anuncio contextual. Para iniciar el contacto de confianza del comprador llamadas al servidor, navigator.runAdAuction requiere que el El parámetro interestGroupBuyers debe tener se pasan como un valor, mientras que los parámetros de subasta restantes aceptan JavaScript Promesas que se puedan resolver después de la respuesta del anuncio contextual Desde Se pasa interestGroupBuyers antes de la respuesta del anuncio contextual. la respuesta de anuncio contextual (incluidas las respuestas a la oferta) No se puede usar para elegir qué compradores participan en la subasta paralelizada. para la solicitud dada. En lugar de las cachés de la etiqueta del publicador de Google En el navegador del usuario, el parámetro interestGroupBuyers del anterior navigator.runAdAuction ejecuciones en el mismo dominio.

La paralelización tiene varias consideraciones importantes:

  1. Indicadores de subasta que no son necesarios para las solicitudes del servidor de confianza del comprador como perBuyerSignals, pueden seguir especificando las respuestas de ofertas de RTB del mismo modo que en las subastas no paralelizadas. Una vez resueltas las promesas de esos indicadores, los pasos restantes del la subasta integrada en el dispositivo se completará del mismo modo que en la campaña de la subasta.

  2. Dado que la paralelización se basa en el almacenamiento en caché de la lista de compradores del grupo de interés, Google no siempre ejecuta una subasta paralela, ya que la caché de paralelización esté vacío o haya vencido. Si la caché está vacía o venció, Google ejecuta un subasta estándar no paralela de la API de Protected Audience y usa la intención del comprador para Participar en la subasta no paralela para crear la caché de compradores del grupo de interés.

  3. Si al menos un comprador de cualquier ofertante se almacena en caché para el publicador actual dominio, Google ejecutará una consulta subasta, lo que se indicará en la solicitud de oferta:

    • Protocolo de RTB de Google: BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized

  4. Cada origen del comprador del grupo de interés registrado para un ofertante determinado que fue incluidos en la subasta paralela tendrán un ParallelAuctionBuyer entrada:

    • Protocolo de RTB de Google: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer

  5. Si se ejecuta una subasta paralela, pero un origen de comprador específico no está presente en la caché, no se podrá agregar ese comprador determinado al subasta. Esto se indica mediante una solicitud con parallelized=True que no tiene un Entrada de ParallelAuctionBuyer para el origen de los compradores de un grupo de interés determinado. Sin embargo, los ofertantes que indican interés ya que incluyen datos válidos y aptos InterestGroupBuyer en su respuesta a la oferta tendrá el comprador del grupo de interés correspondiente orígenes agregados a la caché, y estos serán aptos para futuras solicitudes paralelizadas del mismo navegador y dominio. Intención de participar en subastas de grupos de interés puede indicarse en los siguientes campos:

    • Protocolo de RTB de Google: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: BidResponse.ext.igbid.igbuyer

  6. Los orígenes de compradores almacenados en la caché (que se incluyen en el flujo de compra parámetro interestGroupBuyers) para los que un ofertante no indica una intención para participar en su respuesta a la oferta, es posible que reciba una llamada al servidor de confianza del comprador pero no participará en la subasta paralela.