API de Protected Audience (anteriormente FLEDGE)

Como parte de Privacy Sandbox, Chrome propuso la API de Protected Audience, una API integrada 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 del seguimiento en sitios cruzados.

Chrome está ejecutando una prueba de origen para la API de Protected Audience. Los compradores autorizados pueden participar en las pruebas de la API de Protected Audience en el inventario de publicadores de Ad Manager. Los postores pueden lograr lo siguiente probando la API de Protected Audience:

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

Los compradores autorizados que deseen realizar pruebas deben consultar la sección de incorporación para obtener más detalles.

Beta: El comportamiento que se describe aquí puede cambiar en el futuro a medida que evaluemos los resultados de las pruebas y recopilemos comentarios de los publicadores y los compradores autorizados.

Nota: Las pruebas de la API de Protected Audience solo están disponibles para los compradores autorizados. Por el momento, no se admiten las ofertas de intercambios y redes que participan en Open Bidding.

Nota: Cuando la API de Protected Audience (antes conocida como FLEDGE) esté disponible para el público en general en Chrome, Ad Manager comenzará a aumentar gradualmente la cantidad de tráfico incluido en sus pruebas. Supervisaremos el impacto en los ingresos de los publicadores a medida que aumentemos lentamente el porcentaje de tráfico, y no avanzaremos más en el proceso si observamos un impacto negativo. Esperamos que, para finales de 2023, se habilite hasta un 10% del tráfico de Chrome para las pruebas de la API de Protected Audience.

Resumen del flujo de publicación

A continuación, se incluye un resumen del flujo de publicación de anuncios de Protected Audience para los socios de Authorized Buyers:

1. Un ofertante trabaja con sus anunciantes para mantener grupos de interés para cada uno de ellos. A menudo, los anunciantes agregan una etiqueta del ofertante a 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 etiqueta del ofertante.
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. El navegador del usuario solicita la etiqueta de anuncio para publicadores de Google.
5. La etiqueta de anuncio para publicadores 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 sobre los cambios en las solicitudes de oferta para obtener más información.
7. El ofertante devuelve una respuesta de oferta que incluye el mensaje InterestGroupBidding, que se necesita para participar en la subasta de grupos de interés. En OpenRTB, esto se especifica con el campo BidResponse.ext.igbid, y en el protocolo de RTB de Google obsoleto, con el campo BidResponse.interest_group_bidding. Si el ofertante no especifica esta información, Google no incluye el origen del ofertante en interestGroupBuyers en la configuración de la subasta. InterestGroupBidding también puede contener indicadores opcionales específicos del comprador que se pasarán a la función de ofertas del ofertante durante la subasta en el navegador. En OpenRTB, se especifica con el campo BidResponse.ext.igbid.igbuyer.buyerdata, y en el protocolo de RTB de Google obsoleto, se especifica con el campo BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals. Consulta la sección sobre cambios en la respuesta de la oferta para obtener más información.
8. Google ejecuta la subasta del servidor y devuelve una respuesta a la oferta al navegador. La subasta del servidor considera las ofertas tradicionales del servidor. La respuesta de la oferta puede contener información sobre una oferta ganadora contextual (si la hay).
9. La respuesta a la oferta contiene una configuración de la subasta para la subasta en el navegador. Esto puede incluir indicadores contextuales de cada comprador participante (que se enviaron anteriormente a través de buyerdata de OpenRTB o per_buyer_signals del protocolo de RTB de Google obsoleto), información del ganador contextual y la configuración de la elegibilidad de la oferta.
10. La etiqueta del publicador de Google invoca la API de Protected Audience runAdAuction()para iniciar la subasta de grupos de interés integrada en el dispositivo. Google solo incluye a los compradores que se incluyeron como InterestGroupBuyer en InterestGroupBidding durante la configuración de la subasta.
11. Google pasa los indicadores opcionales específicos del comprador de cada ofertante apto a la configuración de la subasta de Protected Audience.
12. Si los grupos de interés de un ofertante determinado especificaron trustedBiddingSignalsUrl, el navegador realiza una solicitud al trustedBiddingSignalsUrl de cada grupo para recuperar los indicadores en tiempo real de cada grupo. Consulta los detalles en la especificación de la API de Protected Audience.
13. El navegador invoca el generateBid() del ofertante para cada grupo de interés que habilitó la participación y es apto para participar en la subasta en el navegador. En este paso, se calcula la oferta y se selecciona una creatividad. generateBid() tiene acceso a los indicadores opcionales del comprador que proporciona el ofertante y a los indicadores de ofertas de confianza para el grupo de interés determinado.
14. El navegador invoca el scoreAd() del vendedor (en este caso, Google) para asignar una clasificación a cada oferta en la subasta de anuncios del grupo de interés. Las ofertas se clasifican y filtran según las protecciones del publicador, las políticas de anuncios y otras restricciones.
15. El navegador ejecuta una subasta con las ofertas de los grupos de interés aptos. 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 reportResult() del vendedor y reportWin() del ofertante para notificar a cada parte sobre el ganador de la subasta en el navegador.
17. Si gana un anuncio de grupo de interés, la etiqueta de publicador de Google renderiza el anuncio en un 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 en las subastas en el navegador de Protected Audience. Puedes enviar creatividades para su revisión a través de la API de Ofertas en tiempo real o mediante el análisis automático de creatividades. Las creatividades de las subastas de anuncios basadas en grupos de interés de Protected Audience en el navegador deben incluir renderUrls para su revisión.

Requisitos para renderUrls:

• El renderUrl enviado a través de la API debe coincidir con el renderUrl que se usa en la subasta de anuncios del grupo de interés.
• Cada renderUrl solo puede representar a un solo anunciante o campaña publicitaria. Un renderUrl determinado no se puede usar para renderizar anuncios en nombre de varios anunciantes. Cada renderUrl debe asignarse a una sola creatividad.
• Google debe poder acceder al renderUrl y recuperarlo con sus sistemas de revisión de creatividades sin conexión hasta 7 días después de que se haya realizado la última oferta por el anuncio.

API de Real‑time Bidding

Los postores pueden usar la API de Real-time Bidding para subir creatividades para las ofertas de grupos de interés.

Análisis automático de creatividades

Los ofertantes pueden configurar el análisis automático de creatividades que no se suben a través de la API de Ofertas en tiempo real.

Si configuras el análisis automático de creatividades, Google las encontrará en la subasta del navegador y las analizará automáticamente para que sean aptas para subastas futuras.

Sigue estos pasos para activar la búsqueda automática de creatividades:

• Agrega todos los orígenes renderUrl de los creativos de grupos de interés a la cuenta de Comprador Autorizado.

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

  Authorized-Buyers-Creative-ID	string Es el ID de creatividad específico del comprador. La longitud máxima del ID de creatividad es de 128 bytes.
  Authorized-Buyers-Click-Through-URLs	string Es el conjunto de URLs de destino declaradas para la creatividad, codificadas según la 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 por 15 días. Si envías creatividades con la API de Licitación en tiempo real, deberás volver a enviarlas después de 15 días. Si confías en el análisis automático de creatividades, el proceso de análisis las volverá a analizar automáticamente.

ID de informes del comprador

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

A continuación, se muestra un ejemplo de cómo agregar buyerAndSellerReportingId a la configuración del grupo de interés:

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

El buyer_reporting_id aparecerá como una nueva dimensión en la herramienta de informes del comprador autorizado, como la dimensión ID de informes del comprador.

Subasta del servidor

Cambios en las solicitudes de oferta

A continuación, se indican las versiones iniciales de los protocolos admitidos para usar en el experimento:

• Vínculo anticipado de OpenRTB
• Protocolo de RTB de Google (obsoleto) vínculo anticipado

Indica la compatibilidad con la subasta de grupos de interés

Las solicitudes de ofertas tienen nuevos campos para indicar la compatibilidad con las subastas de grupos de interés:

• OpenRTB:
  • BidRequest.imp.ext.ae
  • BidRequest.imp.ext.igbid
• Protocolo de RTB de Google (obsoleto):
  • BidRequest.adslot.supported_auction_environment
  • BidRequest.adslot.interest_group_bidding_allowed

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

• SERVER_SIDE_AUCTION (JSON de OpenRTB: 0): La subasta que determina el anuncio ganador se ejecuta en los servidores del intercambio.
• ON_DEVICE_INTEREST_GROUP_AUCTION (JSON de OpenRTB: 1): Son solicitudes con compatibilidad con Protected Audience, en las que se ejecuta una subasta contextual en los servidores del intercambio y la oferta del grupo de interés y la subasta final se ejecutan en el navegador.
• SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): La subasta contextual se ejecuta en los servidores del exchange, y la lógica de ofertas para las ofertas de grupos de interés y la lógica de puntuación para determinar el anuncio ganador final se ejecutan en los servidores de ofertas y subastas.

Indica el tamaño del espacio publicitario de Protected Audience

La solicitud de oferta incluye los siguientes campos para proporcionarte el tamaño de la ranura de anuncio de Audiencia Protegida:

• OpenRTB:
  • BidRequest.imp.ext.interest_group_auction.width
  • BidRequest.imp.ext.interest_group_auction.height
• Protocolo de RTB de Google (obsoleto):
  • BidRequest.adslot.interest_group_auction.width
  • BidRequest.adslot.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 diferir de los de la solicitud contextual, como los que se ven en los campos BidRequest.imp.banner.format.w y BidRequest.imp.banner.format.h de OpenRTB o en los campos BidRequest.adslot.width y BidRequest.adslot.height del protocolo de RTB de Google que dejó de estar disponible.

Es posible que la solicitud contextual tenga varios tamaños. Se espera que el anuncio ganador de la subasta en el dispositivo ocupe solo un tamaño de ranura fijo.

Indica la capacidad de renderización de los anuncios de Protected Audience

Es posible que los anuncios de Protected Audience se rendericen o no según la etapa de integración actual (consulta el experimento de no renderización). El campo render_interest_group_ads en la solicitud de oferta indica si se renderizará el anuncio ganador de Protected Audience.

• OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
• Protocolo de RTB de Google (obsoleto): BidRequest.adslot.interest_group_auction.render_interest_group_ads

Minimiza la dependencia de los identificadores de usuario

Las solicitudes de ofertas contextuales que se encuentran dentro del alcance de las pruebas de la API de Protected Audience pueden seguir incluyendo identificadores tradicionales basados en cookies cuando estén disponibles en el navegador, como los campos BidRequest.user.id y BidRequest.user.buyerid, o BidRequest.google_user_id y BidRequest.hosted_match_data en el protocolo de RTB de Google que dejó de estar disponible. La presencia de tales identificadores en las solicitudes de ofertas está sujeta a las políticas de privacidad existentes. Te recomendamos que no dependas de los identificadores basados en cookies para la segmentación y las ofertas durante las pruebas, de modo que te prepares mejor para realizar compras eficientes cuando las cookies de terceros ya no estén disponibles.

Es posible que Google también ejecute experimentos a pequeña escala en los que se ocultan los identificadores basados en cookies de las solicitudes de ofertas que se encuentran dentro del alcance de las pruebas de la API de Protected Audience. Esto se hace para evaluar el impacto potencial de la baja de las cookies de terceros.

Pruebas de baja de cookies de terceros facilitadas por Chrome

Para prepararse para la baja de las cookies de terceros (3PCD) en 2024, Chrome ahora ofrece pruebas facilitadas por Chrome.

Los sitios y los proveedores pueden usar las pruebas facilitadas por Chrome para probar sus sistemas en virtud de la 3PCD. En la prueba, los navegadores Chrome se asignan a un grupo experimental de 3PCD, ya sea del modo A o del modo B. A cada navegador se le asigna una etiqueta coherente que corresponde a un grupo experimental específico de 3PCD al que puedes 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 solicitud de oferta de RTB. Debido a las pequeñas porciones de tráfico de una etiqueta individual, Google no siempre incluye la etiqueta en contextos con limitaciones de privacidad.

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

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

Cambios en las respuestas a ofertas

Indica la participación en la subasta de grupos de interés

Eres responsable de indicar explícitamente tu intención de participar en la subasta en el navegador devolviendo el objeto InterestGroupBidding en la respuesta de oferta contextual:

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

Debes proporcionar una respuesta de oferta contextual. No es necesario que la respuesta incluya una oferta contextual. El objeto InterestGroupBidding debe contener el objeto origin para cada objeto InterestGroupBuyer, que debe coincidir con uno de los orígenes configurados por el ofertante para su cuenta. El objeto origin se agrega al objeto interestGroupBuyers de la configuración de la subasta cuando la etiqueta Google Publisher Tag llama a runAdAuction().

Propaga indicadores contextuales del comprador

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

• OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
• RTB de Google (obsoleto): BidResponse.interest_group_bidding.per_buyer_signals

Propaga los indicadores de renderización contextual del comprador

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

Advertencia: Esta función depende de la compatibilidad del navegador con deprecatedRenderURLReplacements.

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

Los indicadores de renderización se pueden especificar en la respuesta de oferta con los siguientes campos, según el protocolo:

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

En la respuesta de la oferta, se pueden incluir hasta 3 conjuntos de indicadores de renderización con diferentes sufijos de macro para distinguir los diferentes indicadores. Por ejemplo, se podría usar un sufijo 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 reduciría el tamaño de la transferencia de datos.

Se rechazará la participación del comprador del grupo de interés en la subasta de Protected Audience si los indicadores no son seguros para URLs, los sufijos de macro no son únicos o se proporcionan más de 3 conjuntos de indicadores.

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

En la propuesta de Protected Audience, se espera que el cálculo de la oferta y la subasta final se ejecuten de forma local en el dispositivo. Esto puede crear posibles vectores de abuso que pueden afectar la integridad de los resultados finales de la subasta, como el precio de la oferta ganadora.

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

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

• OpenRTB: BidResponse.igbid.igbuyer.maxbid(expresado en unidades de moneda del CPM)
• Protocolo de RTB de Google (obsoleto): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (expresado en microCPM)

Atribuye las impresiones a varias cuentas

Un ofertante debe seleccionar un ID de facturación para atribuir las impresiones de su oferta de grupo de interés con los siguientes campos:

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

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

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

Si no se proporciona el ID de facturación para atribuir las impresiones de ofertas de grupos de interés, 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 un ID de facturación para la inversión contextual y el otro para la inversión en grupos de interés. Comunícate con tu administrador de cuentas si deseas configurar dos IDs de facturación para una cuenta secundaria.

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

Los IDs de facturación de todas las cuentas secundarias con presupuesto disponible apto para ofertar por la impresión aparecen en la solicitud de oferta para la selección de la atribución de la inversión. Comunícate con tu administrador de cuentas para modificar el presupuesto de un ID de facturación de grupo de interés.

Durante la subasta en el navegador

Genera ofertas en el navegador

Usa generateBid() para generar ofertas en el navegador.

Google proporciona los siguientes parámetros:

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

Se devuelven los siguientes parámetros:

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

Por ejemplo:

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

Consulta la sección On-Device Bidding de la especificación de Protected Audience para obtener una explicación de la función generateBid().

Moneda de la oferta

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

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

En OpenRTB, usa el nuevo campo cur en el objeto InterestGroupBuyer de la 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 el mensaje InterestGroupBuyer de la respuesta a la oferta.

Por ejemplo:

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

Las funciones generateBid de los ofertantes deben devolver ofertas en la misma moneda que se indica en la respuesta de oferta contextual. Completa la nueva propiedad bidCurrency en el valor de devolución de generateBid:

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

Si la moneda de la respuesta de la oferta contextual es diferente de la moneda que muestra generateBid, o si alguna de ellas muestra una moneda no válida, la oferta se filtrará antes de la subasta.

Verificaciones de calidad de los anuncios

La aplicación de la política de creatividad y los controles del publicador podría ser más restrictiva para las ofertas de grupos de interés en el navegador durante las pruebas de la API de Protected Audience para los socios de RTB.

Asistencia para la Ley de Servicios Digitales

Según el Artículo 26 de la Ley de Servicios Digitales, es posible que los publicadores exijan a los compradores que rendericen las divulgaciones de transparencia en el anuncio. Cuando un publicador habilita el control "Ask buyers to only show ads with DSA transparency information on my site or app in EEA", los compradores de grupos de interés pueden determinar en qué oportunidades se les exigirá que rendericen la transparencia del comprador observando los valores de BidRequest.regs.dsa.required y BidRequest.dsa.pubrender en la solicitud de oferta (BidRequest.dsa.dsa_support y BidRequest.dsa.publisher_rendering_support, respectivamente, en el protocolo de RTB de Google obsoleto).

Cuando un ofertante que desea participar en las subastas de la API de Protected Audience recibe el indicador en la solicitud de oferta de que debe mostrarse la transparencia según la DSA para los anuncios publicados a través de la API de Protected Audience, debe evaluar si puede mostrar correctamente la información requerida y especificarlo configurando BidResponse.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render en el protocolo de RTB de Google obsoleto). De lo contrario, el comprador no se incluirá en la subasta de la API de Protected Audience.

Para obtener más información sobre la transparencia de los anuncios en virtud de la Ley de Servicios Digitales, consulta el artículo del Centro de ayuda: Compatibilidad con la Ley de Servicios Digitales.

Filtrado de ofertas

Google aplica los controles del publicador y las políticas de anuncios durante la subasta en el dispositivo.

Después de la subasta en el navegador

Informa 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 la sección Informes del comprador sobre eventos de renderización y anuncios de la explicación de la API de Protected Audience para obtener más información.

Macros

Nota: Las macros están diseñadas para usarse en las pruebas de la API de Protected Audience y es posible que no se admitan en el futuro.

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 que finaliza la subasta del grupo de interés, pero antes de la renderización, las macros se reemplazan por los valores correspondientes. renderUrl que se usa en la subasta en el dispositivo puede incluir las siguientes macros:

${GDPR}	Se expande a 0 si no se aplica el RGPD o a 1 si se aplica. Ver la documentación.
${GDPR_CONSENT_XXXX}	Se expande a la cadena de transparencia y consentimiento (TC) asociada con la solicitud. Si la cadena de transparencia y 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 IAB GVL del proveedor registrado en IAB GVL. Si la cadena de TC está en blanco o no es válida, esta macro no se expande. Es posible que se bloqueen las creatividades que contengan la macro ${GDPR_CONSENT_XXXX} si el proveedor registrado en la GVL de IAB asociado con el ID de GVL de IAB que insertaste no cuenta con el consentimiento del usuario. La macro ${GDPR_CONSENT_XXXX} solo debe aparecer una vez dentro de renderUrl.
${ADDL_CONSENT}	Se expande a la cadena de consentimiento adicional (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]}	Es una macro que contiene indicadores del comprador en el momento de la renderización especificados en la respuesta de 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 incluir un _OPTIONAL_SUFFIX para proporcionar hasta tres valores de indicadores de renderización diferentes.

Recuento de impresiones

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

Dado que el evento que usa Google para contar las impresiones en las subastas en el navegador de Protected Audience puede ser diferente del evento que usan sus socios compradores de RTB para contar las impresiones, es posible que los recuentos de impresiones difieran.

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

Atribución de las impresiones facturables

Todo el gasto de un ofertante en las subastas en el navegador de Protected Audience se atribuye a una sola cuenta del ofertante según la asignación de los orígenes del propietario del grupo de interés configurados para el ofertante. No se admite la atribución de la inversión a diferentes cuentas secundarias de un ofertante.

Límite de presupuesto diario

Durante las pruebas de la API de Protected Audience, cada cuenta tiene un límite de presupuesto diario de inversión de Protected Audience a nivel de la cuenta. El límite de presupuesto diario reduce el riesgo en el entorno de subasta en el navegador. Una vez que 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 las subastas contextuales del servidor después de alcanzar 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 JSON: 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 habilitaron la opción para recibir comentarios en tiempo real recibirán comentarios sobre los compradores de grupos de interés que se solicitó incluir en una subasta de Protected Audience integrada en el dispositivo. Cada comprador de grupo de interés que un ofertante especifique en una respuesta de oferta recibirá un objeto de comentarios, independientemente de la cantidad de ofertas que el comprador de grupo de interés coloque en la subasta de Protected Audience. La siguiente información estará disponible en el objeto de comentarios del comprador del grupo de interés:

• El tipo de comentarios del objeto de comentarios será INTEREST_GROUP_BUYER_FEEDBACK.
• Es el origen del comprador del grupo de interés.
• Es la oferta mínima para ganar que debe realizar el comprador del grupo de interés para ganar la subasta general.
• Es la oferta mínima para ganar del comprador del grupo de interés para superar 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 se definen en interest-group-buyer-status-codes.txt.

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

Notificación de comentarios sobre la oferta

Chrome proporciona una API de depuración temporal para la API de Protected Audience que permite a Ad Manager enviar notificaciones de depuración de servidor a servidor en tiempo real que contienen comentarios sobre una oferta de Protected Audience. Esta notificación incluirá los motivos por los que se pueden haber filtrado las ofertas en la subasta en el navegador de Protected Audience, además de otra 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 usará para enviar notificaciones de comentarios de ofertas de depuración de Protected Audience. Esta URL estática se recuperará de los servidores de Google con las macros seleccionadas reemplazadas después de que se complete la subasta de Protected Audience. Se admiten las siguientes macros:

• %%GOOGLE_QUERY_ID%%: Esta macro se reemplaza por el ID de consulta de Google que se envió en la solicitud de oferta contextual habilitada para Protected Audience. En el protocolo de OpenRTB, se especifica con BidRequest.ext.google_query_id, mientras que el protocolo de RTB de Google que dejó de estar disponible usa BidRequest.google_query_id.
• %%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 dentro de scoreAd(). Los valores son códigos de estado de la creatividad.

A continuación, se muestra un ejemplo de una URL estática que un ofertante podría 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 ForDebuggingOnly de Chrome.

TURTLEDOVE a nivel del producto

Anuncios compuestos por varias partes o TURTLEDOVE a nivel del producto (PLTD) se admiten para los socios de RTB de Google durante las pruebas de la API de Protected Audience. Durante la integración, infórmale a tu administrador de cuentas si planeas probar la PLTD, ya que se requieren recursos y configuración adicionales.

Integración

A continuación, te explicamos cómo puedes probar la API de Protected Audience:

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 presenta un ticket a través del Centro de ayuda de Authorized Buyers.
3. Una vez que se configure la cuenta, tanto Google como el socio podrán verificar la integración siguiendo los pasos que se indican en Etapas de prueba.

Revisión de creatividades

Para ofertar con anuncios a nivel del producto (anuncios compuestos por varias partes) en las subastas de la API de Protected Audience, sigue estos requisitos:

• Incluye el parámetro de consulta &pltd=True en el renderUrl del contenedor del anuncio de componente (también llamado renderUrl de nivel superior) para distinguir el renderUrls de nivel superior durante la revisión de la creatividad.
• Renderiza una creatividad representativa cuando se recupera el contenedor del anuncio de componente para una revisión de la creatividad por parte de Google. Para comprender cuándo se debe devolver una renderización de anuncio representativa, puedes consultar el parámetro de búsqueda validation=True establecido por el sistema de revisión de creatividades de Google.

Lista de tareas de integración

• Configura un extremo de solicitud de oferta que completará los campos relacionados con la API de Protected Audience en la respuesta de oferta contextual, por ejemplo, interest_group_bidding.
• Implementa el etiquetado en las páginas del anunciante para unir el navegador del usuario al grupo de interés.
• Implementa generateBid() y reportWin().
• Selecciona los orígenes de los propietarios de grupos de interés y agrégalos a la cuenta de Authorized Buyer.
  • Los orígenes del propietario del grupo de interés deben coincidir con los orígenes en los que se alojan las funciones de generateBid().
  • Comunícate con el administrador de cuentas o presenta un ticket a través del Centro de ayuda para compradores autorizados para completar este paso.
• Configura el segmentación previa para el inventario pertinente para las pruebas de la API de Protected Audience.
• Envía creatividades para su revisión y aprobación a través de la API de Creatividades.
• (Opcional) Configura los extremos de los indicadores de ofertas confiables.
• (Opcional) Configura una página de anunciante de prueba que permita a los ingenieros de Google agregar sus navegadores a los grupos de interés que son propiedad del origen de tu comprador de grupos de interés. Esto nos permite activar manualmente las subastas de Protected Audience.
• (Opcional) Habilita los comentarios en tiempo real en tu cuenta para recibir comentarios sobre los compradores de grupos de interés que se solicitó incluir en una subasta de Protected Audience.
• Opcional: Comunícate con tu administrador de cuentas para configurar una URL estática y recibir una notificación de servidor a servidor que proporcione comentarios sobre la oferta de Protected Audience para el estado de una oferta de una subasta de Protected Audience en el dispositivo y, así, ayudar a depurar problemas inesperados. Consulta la notificación de comentarios sobre la oferta para obtener más detalles.

Etapas de prueba

Etapa 1: Prueba manual

A continuación, se explica cómo activar manualmente una subasta de Protected Audience, garantizar que se pueda renderizar el anuncio y registrar la impresión:

1. Usa Chrome 101 o versiones posteriores.
2. Habilita la API de Privacy Sandbox y el marco protegido con chrome://flags/#privacy-sandbox-ads-apis y chrome://flags/#enable-fenced-frames. Obtén más información en Test the Privacy Sandbox.
3. Envía una creatividad para su aprobación con la API de Real-time Bidding.
4. Usa la página del anunciante proporcionada por el ofertante para agregar un navegador al grupo de interés propiedad del ofertante.

5. Usa la siguiente página de publicador de prueba proporcionada por Google para activar una subasta de Protected Audience:

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

   El grupo de interés en el navegador debe ofertar lo suficiente para ganar la subasta, ya que podría competir con las ofertas convencionales del servidor. Google también proporciona una página de publicador de prueba exclusiva para cada socio, en la que solo el socio determinado puede participar en la subasta. Puede ser más fácil ganar de forma confiable las subastas 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 lado del servidor, lo que significa que el mejor postor recibe un ping de reportWin().
   3. En la consola de la página del publicador de prueba, se registra un mensaje de depuración para cada oferta con la siguiente información:
      • renderUrl: 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 aceptó la oferta y false si scoreAd() rechazó la oferta.
      • externalBidStatus: Es un código de estado si se rechazó la oferta dentro de scoreAd(). Los valores son códigos de estado de la creatividad.

Etapa 2: (Opcional) Experimento sin renderización

Después de que Google y el socio verifican manualmente que el socio puede participar en la subasta de Protected Audience, Google habilita al socio para la siguiente etapa de pruebas.

Google asigna una pequeña cantidad de tráfico en vivo para ejecutar subastas de Protected Audience. Luego, Google y el socio ya no necesitan activar manualmente una subasta de Protected Audience. No se renderiza el resultado de la subasta de Protected Audience. Esto nos permite probar la integración a gran escala.

Cuando esté todo listo, comunícate con tu administrador de cuentas o presenta un ticket a través del Centro de ayuda de Authorized Buyers. Google habilitará la cuenta para esta etapa.

Etapa 3: Experimento de procesamiento

Una vez que Google y el socio hayan verificado las subastas de Protected Audience a gran escala sin renderización, Google podrá habilitar al socio para que renderice el anuncio ganador de Protected Audience. Google tiene una pequeña cantidad de tráfico en la que las subastas de Protected Audience son aptas para ejecutarse y se renderizan los anuncios de los grupos de interés ganadores. Las ofertas en el navegador de los ofertantes participantes compiten con las ofertas tradicionales.

Cuando esté todo listo, comunícate con tu administrador de cuentas o presenta un ticket a través del Centro de ayuda de Authorized Buyers. 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, ya que inicia la solicitud de anuncio contextual en paralelo con las solicitudes a los servidores de compradores de confianza especificados en trustedBiddingSignalsUrl.

La paralelización reduce la latencia, pero afecta la elegibilidad de los compradores de grupos de interés y la compatibilidad con los experimentos coordinados. La paralelización se aplica a todos los ofertantes que participan en la subasta de grupos de interés en el dispositivo. Los postores no necesitan realizar ninguna acción para participar en las subastas paralelas, pero deben familiarizarse con la forma en que la paralelización puede afectar su elegibilidad en las subastas en el dispositivo. Los IDs de grupos de experimentos para experimentos coordinados aún no son compatibles con las subastas paralelas.

Resumen del flujo de publicación

A continuación, se incluye un resumen del flujo de la subasta paralela:

Elegibilidad del comprador de grupos de interés en el dispositivo

En el caso de las subastas paralelas, la llamada de navigator.runAdAuction se realiza antes de que se devuelva la respuesta del anuncio contextual. Para iniciar llamadas al servidor de confianza del comprador, navigator.runAdAuction requiere que el parámetro interestGroupBuyers se pase como un valor, mientras que los parámetros restantes de la subasta aceptan promesas de JavaScript que se pueden resolver después de la respuesta del anuncio contextual. Dado que interestGroupBuyers se pasa antes de la respuesta del anuncio contextual, esta respuesta (incluidas las respuestas de ofertas) no se puede usar para elegir qué compradores participan en la subasta paralela para la solicitud determinada. En cambio, la etiqueta del editor de Google almacena en caché, en el navegador del usuario, el parámetro interestGroupBuyers de las ejecuciones anteriores de navigator.runAdAuction en el mismo dominio.

La paralelización tiene varias consideraciones importantes:

1. Los indicadores de subasta que no son necesarios para las solicitudes del servidor de confianza del comprador, como perBuyerSignals, se pueden seguir especificando en las respuestas de ofertas de RTB de la misma manera que para las subastas no paralelizadas. Una vez que se resuelvan las promesas para estos indicadores, se completarán los pasos restantes de la subasta en el dispositivo de la misma manera que para el flujo de subasta no paralelo.

2. Dado que la paralelización se basa en el almacenamiento en caché de la lista de compradores de grupos de interés, Google no siempre ejecuta una subasta paralela, ya que la caché de paralelización puede estar vacía o vencida. Si la caché está vacía o venció, Google ejecuta una 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 y compilar la caché de compradores del grupo de interés.

3. Si al menos un comprador para cualquier ofertante se almacena en caché para el dominio del publicador actual, Google ejecutará una subasta paralela, 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 de comprador de grupo de interés registrado para un ofertante determinado que se incluyó en la subasta paralela tendrá una entrada de ParallelAuctionBuyer correspondiente:

   • 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 no hay un origen de comprador específico en la caché, no se podrá agregar ese comprador a la subasta actual en el dispositivo. Esto se indica con una solicitud con parallelized=True que no tiene una entrada ParallelAuctionBuyer para un origen del comprador de un grupo de interés determinado. Sin embargo, los postores que indiquen interés incluyendo InterestGroupBuyer válidos y aptos en su respuesta de oferta tendrán los orígenes de compradores de grupos de interés correspondientes agregados a la caché, y esos orígenes serán aptos para futuras solicitudes paralelizadas del mismo navegador y dominio. La intención de participar en las subastas de grupos de interés se puede indicar 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 del comprador almacenados en caché (que se incluyen en el parámetro interestGroupBuyers de la subasta paralela) para los que un ofertante no indica su intención de participar en su respuesta a la oferta pueden recibir una llamada al servidor de confianza del comprador, pero no participarán en la subasta paralela.