API de Protected Audience (anteriormente FLEDGE)

Como parte de Privacy Sandbox, Chrome propuso la API de Protected Audience, una API en el navegador que permite a los anunciantes y las empresas de tecnología publicitaria mostrar anuncios segmentados por grupo de intereses sin depender de cookies de terceros y, al mismo tiempo, proteger a los usuarios del seguimiento entre sitios.

Chrome está ejecutando una prueba de origen 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 probando la API de Protected Audience:

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

Los compradores de Authorized Buyers que deseen realizar pruebas deben consultar la sección Integración para obtener más información.

Beta: Es posible que el comportamiento descrito aquí cambie en el futuro a medida que evaluemos los resultados de las pruebas y recopilemos comentarios de los publicadores y Authorized Buyers.

Nota: Las pruebas de la API de Protected Audience solo están disponibles para Authorized Buyers. Aún no se admiten los ofertantes de intercambio y red que participan en Open Bidding.

Nota: Cuando la API de Protected Audience (antes conocida como FLEDGE) esté disponible para el público general en Chrome, Ad Manager comenzará a aumentar gradualmente la cantidad de tráfico incluido en sus pruebas. Supervisaremos el impacto en los ingresos del publicador a medida que aumentamos lentamente el porcentaje de tráfico, y no avanzaremos más en el proceso si hay un impacto negativo notable. 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 muestra un resumen del flujo de publicación de anuncios de Protected Audience para socios de Authorized Buyers:

1. Un ofertante trabaja con sus anunciantes a fin de mantener grupos de interés para cada uno. A menudo, los anunciantes agregan la etiqueta de un ofertante a su página para agregar un navegador a los grupos de intereses.
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 el joinAdInterestGroup() de la API de Protected Audience. 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 editor. El navegador del usuario solicita 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 Cambios en la solicitud de oferta para obtener más información.
7. El ofertante muestra un BidResponse con el campo interest_group_bidding. Si el ofertante no especifica interest_group_bidding, Google no incluirá el origen del ofertante en interestGroupBuyers en la configuración de la subasta. La respuesta a la oferta también puede contener interest_group_bidding.per_buyer_signals. Se pasará per_buyer_signals a la función de ofertas del ofertante durante la subasta en el navegador. Consulta la sección Cambios en la respuesta a la oferta para obtener más información.
8. Google ejecuta la subasta del servidor y muestra 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 la hay).
9. La respuesta a la oferta contiene una configuración de subasta para la subasta en el navegador. 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 de la elegibilidad de ofertas.
10. La etiqueta del publicador de Google invoca el runAdAuction() de la API de Protected Audience para iniciar la subasta del grupo de interés integrada en el dispositivo. Google solo incluye a los compradores que antes mostraron interest_group_bidding como interestGroupBuyers en la configuración de la subasta.
11. Google pasa el per_buyer_signals de cada ofertante apto a la configuración de subasta de Protected Audience.
12. Si los grupos de intereses de un ofertante especificaron el trustedBiddingSignalsUrl, el navegador realiza una solicitud al trustedBiddingSignalsUrl de cada grupo para recuperar indicadores en tiempo real de cada grupo. Consulta los detalles en las especificaciones de la API de Protected Audience.
13. El navegador invoca el generateBid() del ofertante para cada grupo de interés que aceptó participar en la subasta en el navegador y es apto para participar en ella. En este paso, se calcula la oferta y se selecciona una creatividad. generateBid() tiene acceso al per_buyer_signals que proporciona el ofertante y a los indicadores de ofertas confiables para el grupo de interés determinado.
14. El navegador invoca el scoreAd() del vendedor (en este caso, el de Google) para asignar una clasificación a cada oferta en la subasta de anuncios basados en un grupo de interés. Las ofertas se clasifican y filtran según las protecciones de los publicadores, las políticas de anuncios y otras restricciones.
15. El navegador ejecuta una subasta con las ofertas aptas del grupo de interés. 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 el reportResult() del vendedor y el reportWin() del ofertante para notificar a cada parte 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 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 desde las subastas integradas 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 el análisis automático de creatividades. Las creatividades de las subastas de anuncios del grupo de interés de Protected Audience dentro del 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 utiliza en la subasta de anuncios basados en un grupo de interés.
• Cada renderUrl 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.
• Los sistemas de revisión de creatividades sin conexión de Google deben poder acceder a la renderUrl y recuperarla hasta 7 días después de la última oferta del anuncio.

API de Real‑time Bidding

Los ofertantes pueden usar la API de Ofertas en tiempo real a fin de subir creatividades para ofertas por 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 se suben a través de la API de Real-time Bidding.

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

Sigue estos pasos para activar el análisis automático de creatividades:

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

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

  Authorized-Buyers-Creative-ID	string Es un ID de la creatividad específico del comprador. La longitud máxima del ID de la creatividad es de 128 bytes.
  Authorized-Buyers-Click-Through-URLs	string Es el conjunto de URL de destino declaradas para la creatividad codificada según 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ías creatividades con la API de Real-time Bidding, deberás volver a enviarlas después de 15 días. Si utilizas el escaneo automático de creatividades, el proceso vuelve a analizarlas automáticamente.

ID de informe 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). Si deseas agregar una dimensión para la inversión del grupo de interés, especifica un buyerAndSellerReportingId para tu anuncio cuando agregues el dispositivo del usuario al grupo de interés. Consulta detalles adicionales 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);

buyer_reporting_id aparecerá como una dimensión nueva en la herramienta de informes de Authorized Buyers, como dimensión de ID de informe de comprador.

Subasta del servidor

Cambios en la solicitud de oferta

Las siguientes son versiones anticipadas de protocolos compatibles para usar en el experimento:

• Vínculo anticipado del protocolo RTB de Google
• Vínculo anticipado de OpenRTB

Cómo indicar la compatibilidad con subastas de grupos 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 entre las oportunidades de impresión que admiten la subasta del grupo de interés de Protected Audience en el navegador y las que solo admiten la subasta tradicional de intercambio del servidor. 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 de Protected Audience, en las que una subasta contextual se ejecuta en los servidores del intercambio y las ofertas del grupo de interés y la subasta final se ejecuta en el navegador

Cómo indicar el tamaño del espacio publicitario de Protected Audience

La solicitud de oferta incluye los siguientes campos para proporcionarte el tamaño del espacio publicitario de Protected Audience:

• 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 en píxeles del espacio publicitario para la subasta de Protected Audience.

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

La solicitud contextual puede tener varios tamaños. Se espera que el anuncio ganador de la subasta integrado en el dispositivo ocupe un solo tamaño de espacio fijo.

Cómo indicar la renderización de anuncios de Protected Audience

Los anuncios de Protected Audience pueden renderizarse o no según la etapa de integración actual (consulta el experimento sin renderización). El campo render_interest_group_ads de la solicitud de oferta indica si se renderizará el anuncio de Protected Audience ganador.

• 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 la dependencia de los identificadores de usuarios.

Las solicitudes de ofertas contextuales que están dentro del alcance de las pruebas de la API de Protected Audience pueden seguir llevando identificadores tradicionales basados en cookies cuando están disponibles en el navegador, como los campos 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á sujeta a las políticas de privacidad existentes. Te recomendamos que no dependas de identificadores basados en cookies para fines de segmentación y oferta durante las pruebas, a fin de prepararte mejor para una compra eficiente cuando las cookies de terceros ya no estén disponibles.

Google también puede ejecutar experimentos a pequeña escala en los que los identificadores basados en cookies se oculten de las solicitudes de oferta que estén dentro del alcance de las pruebas de la API de Protected Audience. El objetivo de esto es evaluar el impacto potencial de la baja de las cookies de terceros.

Pruebas de baja de las cookies de terceros facilitadas por Chrome

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

Los sitios y proveedores pueden usar las pruebas facilitadas por Chrome para probar sus sistemas con 3PCD. En la prueba, los navegadores Chrome se asignan a un grupo experimental de 3PCD, ya sea Modo A o 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 de privacidad limitada.

Estos son los campos donde 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 en la subasta del grupo de interés

Eres responsable de indicar de manera explícita tu intención de participar en la subasta en el navegador. Para ello, debes mostrar el objeto InterestGroupBidding en la respuesta de la oferta contextual:

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

Debes proporcionar una respuesta a la oferta contextual. No es necesario que la respuesta incluya una oferta contextual. El objeto InterestGroupBidding debe contener el origin del propietario del grupo de interés, que debe coincidir con uno de los orígenes que configuró el ofertante para su cuenta. Cuando Google Publisher Tag llama a runAdAuction(), se agrega el origin al interestGroupBuyers de la configuración de la subasta.

Propaga indicadores contextuales del comprador (perBuyerSignals)

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

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

Especificar el precio máximo de 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 puedan afectar la integridad de los resultados finales de la subasta, 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, 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 muestre la función de ofertas. Si la oferta ganadora informada desde la subasta en el navegador supera este importe, la oferta ganadora no se cuenta como un 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 los 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 según el CPM)

Atribuir impresiones a varias cuentas

Un ofertante debe seleccionar un ID de facturación para atribuir las impresiones de la oferta del grupo de interés 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 no se proporciona el ID de facturación para atribuir las impresiones de ofertas del grupo 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 el gasto del grupo de interés. Comunícate con tu administrador de cuentas si deseas configurar dos ID de facturación para una cuenta secundaria.

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

Los ID de facturación de todas las cuentas secundarias con presupuesto disponible aptos para ofertar por la impresión aparecen en la solicitud de oferta para la selección de atribución de 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

Generar ofertas en el navegador

Usa generateBid() para generar ofertas en el navegador.

Google proporciona los siguientes parámetros:

• auctionSignals: Vacía
• perBuyerSignals: Es un objeto de JavaScript con 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 la subasta. Google debe revisar y aprobar esta URL; de lo contrario, se filtrará de la subasta.
• allowComponentAuction: Debe ser true. Actualmente, Google admite las pruebas de subastas de varios vendedores.

Por ejemplo:

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

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

Moneda de la oferta

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

La moneda de la oferta debe indicarse en la respuesta de la oferta contextual y en el valor de retorno 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 en 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 mostrar ofertas en la misma moneda que se indica en la respuesta de oferta contextual. Completa la propiedad bidCurrency nueva en el 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 que muestra generateBid, o si cualquiera de ellas muestra una moneda no válida, se filtrará la oferta antes de la subasta.

Verificaciones de calidad del anuncio

La aplicación de políticas de creatividades y controles de publicador puede ser más restrictiva para las ofertas del grupo de interés en el navegador durante las pruebas de la API de Protected Audience para socios de RTB.

Apoyo a la Ley de Servicios Digitales

Debido al artículo 26 de la Ley de Servicios Digitales, los publicadores pueden requerir que los compradores rendericen divulgaciones de transparencia en los anuncios. Cuando un publicador habilita el control "Solicitar a los compradores que solo muestren anuncios con información de transparencia de DSA en mi sitio o app en el EEE", los compradores de grupos de interés pueden determinar las oportunidades para las que se necesitarán para renderizar la transparencia del comprador. Para ello, deben anotar los siguientes campos en las solicitudes de oferta recibidas: BidRequest.dsa.dsa_support y BidRequest.dsa.publisher_rendering_support para el protocolo de Google Authorized Buyers y BidRequest.regs.dsa.required y BidRequest.dsa.pubrender para el protocolo OpenRTB.

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 se debe mostrar la transparencia de DSA para los anuncios publicados a través de la API de Protected Audience, debe evaluar si puede mostrar de forma adecuada la información requerida y especificarlo configurando BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render para el protocolo de Google Authorized Buyers o BidResponse.ext.igbid.igbuyer.dsaadrender para el protocolo OpenRTB. De lo contrario, no se incluirá al comprador en la subasta de la API de Protected Audience.

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

Filtrado de ofertas

Google aplica los controles del publicador y las políticas de anuncios 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 la sección Informes de compradores 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 concluye la subasta del grupo de interés, pero antes de la renderización, las macros se reemplazan por los valores correspondientes. El renderUrl que se usa en la subasta integrada en el dispositivo puede incluir las siguientes macros:

${GDPR}	Se expande a 0 si no se aplica el GDPR o a 1 si se aplica el GDPR. 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, la macro no se expandirá. 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 del proveedor registrado en la GVL de la IAB. Si la cadena de TC está en blanco o no es válida, la macro no se expandirá. Las creatividades con la macro ${GDPR_CONSENT_XXXX} podrían bloquearse si el proveedor registrado en la GVL de IAB asociado con el ID de la GVL de IAB que insertaste no tiene el consentimiento del usuario. La macro ${GDPR_CONSENT_XXXX} debe ocurrir solo 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.

Recuento de impresiones

Durante las pruebas de la API de Protected Audience con socios de RTB, Google registrará 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().

Debido a que el evento que usa Google para contar impresiones en las subastas de Protected Audience en el navegador puede ser diferente del que usan sus socios compradores de RTB, los recuentos de impresiones pueden diferir.

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

Atribución de impresiones facturables

Todo el gasto de un ofertante de las subastas en el navegador de Protected Audience se atribuye a una sola cuenta de ofertante en función de la asignación de los orígenes de propietario del grupo de interés configurados para el ofertante. No se admite la atribución de la inversión a diferentes cuentas de licencias 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, que limita el riesgo en el entorno de subastas en el navegador. Una vez que se alcanza el límite de 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 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: 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 del grupo de interés que se solicitaron para incluirse en una subasta de Protected Audience integrada en el dispositivo. Cada comprador de grupo de interés que especifique un ofertante en una respuesta a la oferta recibirá un objeto de comentarios, sin importar cuántas ofertas haga el comprador del grupo de interés 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 feedback del objeto feedback será INTEREST_GROUP_BUYER_FEEDBACK.
• Es el origen del comprador del grupo de interés.
• Es la oferta mínima que debe ganar el comprador del grupo de interés para ganar la subasta general.
• Es la oferta mínima que debe ganar el comprador del grupo de interés para superar la oferta de 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 de RTB de Authorized Buyers y Extensiones de OpenRTB para los nombres de 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 que Ad Manager envíe notificaciones de depuración de servidor a servidor en tiempo real que contienen comentarios sobre una oferta de Protected Audience. En esta notificación, se incluirán los motivos por los que las ofertas podrían haberse filtrado 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 entregar notificaciones de comentarios sobre la oferta de depuración de Protected Audience. Esta URL estática se recuperará de los servidores de Google con las macros seleccionadas que se reemplazarán 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 (BidRequest.google_query_id en el protocolo de Authorized Buyers y BidRequest.ext.google_query_id en el protocolo OpenRTB) que se envió en la 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 un plazo de scoreAd(). Los valores son códigos de estado de las creatividades.

A continuación, se incluye una URL estática de ejemplo 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 de Chrome.

Haz clic en Eventos.

Los ofertantes pueden informar a Google eventos de clic en anuncios de Protected Audience mediante la API de Fenced Frame Reporting. Los ofertantes deben usar el tipo de evento click para notificar a Google sobre los clics. Por ejemplo:

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

TURTLEDOVE a nivel del producto

Los socios de RTB de Google admiten anuncios compuestos por varias piezas o TURTLEDOVE (PLTD) a nivel del producto durante las pruebas de la API de Protected Audience. Si planeas probar PLTD, infórmale a tu administrador de cuentas durante la integración, 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 envía un ticket a través del Centro de ayuda de Authorized Buyers.
3. Una vez configurada la cuenta, tanto Google como el socio pueden verificar la integración mediante los pasos de las 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 del componente (también llamado renderUrl de nivel superior) para distinguir el renderUrls de nivel superior durante la revisión de la creatividad.
• Renderizar una creatividad representativa cuando se recupera el contenedor del anuncio componente para una revisión de la creatividad por parte de Google Para comprender cuándo se debe mostrar una renderización de anuncios 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 propagará los campos relacionados de la API de Protected Audience en la respuesta de la 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 del propietario del grupo de interés y agrégalos a la cuenta de Authorized Buyers.
  • 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 de Authorized Buyers para completar este paso.
• Configurar la segmentación previa del inventario relevante 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 Creatives.
• (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 su navegador a los grupos de interés que pertenecen al origen del comprador de tu grupo 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 solicitaron que se incluyan en una subasta de Protected Audience.
• (Opcional) Comunícate con tu administrador de cuentas para configurar una URL estática y así recibir una notificación de servidor a servidor que proporcione comentarios sobre la oferta de Protected Audience sobre el estado de una oferta de una subasta de Protected Audience integrada en el dispositivo para 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

Aquí te mostramos cómo activar manualmente una subasta de Protected Audience, asegurarte de que se pueda renderizar el anuncio y registrar la impresión:

1. Usa Chrome 101 o una versión posterior.
2. Habilita la API de Privacy Sandbox y el Marco cercado con chrome://flags/#privacy-sandbox-ads-apis y chrome://flags/#enable-fenced-frames. Obtén más información en Cómo probar Privacy Sandbox.
3. Enviar una creatividad para su aprobación mediante la API de Ofertas en tiempo real
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 del publicador de prueba que proporciona 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 realizar una oferta lo suficientemente alta como 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 dedicada para cada socio, en la que solo el socio determinado puede participar en la subasta. Puede ser más fácil ganar subastas en el navegador de manera confiable en una página específica de un socio.

6. Verifica lo siguiente:

   1. Se renderiza el anuncio ganador esperado.
   2. El resultado de la subasta se envía del servidor, lo que significa que 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 tendrá el valor true si se aceptó la oferta y false si la rechazó el scoreAd().
      • externalBidStatus: Es un código de estado si se rechazó la oferta en un plazo de scoreAd(). Los valores son códigos de estado de las creatividades.

Etapa 2: Experimento sin renderización (opcional)

Después de que Google y el socio verifiquen de forma manual que el socio puede participar en la subasta de Protected Audience, Google lo habilitará para la siguiente etapa de prueba.

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.

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

Etapa 3: Experimento de renderización

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

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