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

Versión beta: Es posible que el comportamiento que se describe aquí cambie 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. No se admiten los ofertantes de intercambio ni de red que participan en Open Bidding aún.

Nota: Cuando la API de Protected Audience (antes conocida como FLEDGE) pasa a ser disponibles de forma general en Chrome, Ad Manager comenzará a aumentar gradualmente la cantidad de tráfico incluida en las pruebas. Supervisaremos el impacto en el los ingresos, ya que aumentamos lentamente el porcentaje de tráfico y no aumentamos si hay un impacto negativo notable. Esperamos que para el final del En 2023, se habilitará hasta un 10% del tráfico de Chrome para la API de Protected Audience. y pruebas.

Resumen del flujo de entrega

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

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 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 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 las solicitudes de oferta para obtener más información.
7. El ofertante muestra una respuesta de oferta que incluye el mensaje InterestGroupBidding, que es necesario para participar en la subasta del grupo de intereses. En OpenRTB, esto se especifica con el campo BidResponse.ext.igbid, y en el protocolo de RTB de Google obsoleto, se especifica 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 carga subasta. En OpenRTB, esto 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 Cambios en la respuesta de la oferta 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 de 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 buyerdata de OpenRTB o del RTB de Google per_buyer_signals del protocolo anterior), información contextual del ganador y 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 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 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. En este paso, se calcula la oferta y se selecciona una creatividad. generateBid() tiene acceso a los indicadores opcionales del comprador que proporcionan 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. La oferta contextual con la clasificación más alta participa en la subasta en el navegador.
16. Después de la subasta, si hay un ganador de 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 de grupo de intereses, 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 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.
• Los sistemas de revisión de creatividades sin conexión de Google deben poder acceder a renderUrl y recuperarlo durante un máximo de 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 para subir creatividades para las ofertas de grupos de intereses.

Análisis automático de creatividades

Los ofertantes pueden configurar el análisis automático de creatividades para las creatividades que no subirse 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 del comprador 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 de la creatividad es de 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 por 15 días. Si envías creatividades con la API de ofertas en tiempo real, deberás volver a enviarlas 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 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 del grupo de intereses, especifica un buyerAndSellerReportingId para tu anuncio cuando agregues el dispositivo del usuario al grupo de intereses. Consulta detalles adicionales en la documentación de Protected Audience.

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);

El buyer_reporting_id aparecerá como una dimensión nueva en la herramienta de informes del comprador autorizado, como dimensión de ID de informes 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:

• Vínculo anticipado de OpenRTB
• Vinculación anticipada del protocolo de RTB de Google (obsoleto)

Cómo indicar la compatibilidad con la subasta de grupos de interés

Las solicitudes de oferta tienen campos nuevos 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 entre 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 de intercambio tradicional del servidor. El La enumeración 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 mercado.
• ON_DEVICE_INTEREST_GROUP_AUCTION (JSON de OpenRTB: 1): Solicitudes con compatibilidad con Protected Audience, en las que se ejecuta una subasta contextual en los servidores del mercado y las ofertas del grupo de intereses y la subasta final se ejecutan en el navegador.
• SERVER_SIDE_INTEREST_GROUP_AUCTION (JSON de OpenRTB: 3): El código contextual la subasta se ejecuta en los servidores del intercambio, y la lógica de ofertas según el interés las ofertas y la lógica de puntuación para determinar el anuncio ganador final se ejecutan en servidores de ofertas y subastas.

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:

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

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

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

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

• 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 oferta contextuales que se encuentran 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 BidRequest.user.id y BidRequest.user.buyerid, o BidRequest.google_user_id y BidRequest.hosted_match_data en el protocolo de RTB de Google obsoleto. La presencia de esos identificadores en las solicitudes de oferta está sujeta a las políticas de privacidad existentes. Te recomendamos no depender de identificadores basados en cookies para la orientación y las ofertas durante pruebas para prepararse mejor para una compra eficiente cuando no hay cookies de terceros ya estén disponibles.

Google también podría ejecutar experimentos a pequeña escala en los que los identificadores basados en cookies se oculten de las solicitudes de oferta en el alcance de las pruebas de la API de Protected Audience. Esto sirve para evaluar el impacto potencial de la baja de las cookies de terceros.

Pruebas de baja de las cookies de terceros facilitadas por Chrome

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 en 3PCD. En la prueba, se asignan navegadores Chrome 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:

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

Cambios en las respuestas a la oferta

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 mostrando el objeto InterestGroupBidding en la respuesta de la 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 elemento origin para cada InterestGroupBuyer, que debe coincidir con uno de los orígenes configurado por el ofertante para su cuenta. Se agrega origin a la subasta. el interestGroupBuyers de la configuración cuando Google Publisher Tag llama runAdAuction()

Cómo propagar indicadores contextuales del comprador

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:

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

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, los indicadores de renderización se pueden usar para personalizar el aspecto 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 con el navegador deprecatedRenderURLReplacements.

Puedes incluir los indicadores de renderización de un comprador serializados como una cadena segura para URLs en la respuesta de oferta contextual, que Google reemplazará en la URL de renderización del grupo de intereses ganador mediante la construcción de 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

Se pueden incluir hasta 3 conjuntos de indicadores de renderización con diferentes sufijos de macro en la respuesta de oferta para distinguir los 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 intereses para que participe en la subasta de Protected Audience si los indicadores no son seguros para la URL, 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 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:

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

Cómo atribuir impresiones a varias cuentas

Un ofertante debe seleccionar un ID de facturación para atribuir las impresiones de su oferta de grupo de intereses 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 al que se deben atribuir las impresiones de ofertas del grupo de intereses, 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 otro para la inversión en grupos de intereses. 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 para establecer 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

Genera 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 a la subasta. Debe expresarse 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, o 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 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 que se muestra de generateBid, y debe ser un código alfa válido de ISO 4217, 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 de 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.

Verificaciones de calidad de anuncios

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 relacionada con 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 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 intereses pueden determinar para qué oportunidades deberán renderizar la transparencia para el comprador tomando nota de 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 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.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render in el protocolo RTB de Google, que ya no está disponible). 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 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 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 pruebas de la API de Protected Audience y es posible que no sean compatibles 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 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í se aplica. Ver la documentación.
${GDPR_CONSENT_XXXX}	Se expande a la Transparencia & 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]}	Es una macro que contiene los indicadores del comprador en el tiempo de renderización especificados 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 de 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 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 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, 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

Toda la inversión de un ofertante de las subastas en el navegador de Protected Audience se atribuye a una sola cuenta de ofertante según la asignación de los orígenes del propietario del grupo de intereses 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 alcanzar el límite de Protected Audience. Por ejemplo, una cuenta de oferta que alcanza el límite de Protected Audience puede recibir una solicitud de oferta con auction_environment = SERVER_SIDE_AUCTION (JSON de 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 de grupo de intereses que un ofertante especifique en una respuesta a la oferta recibirá un objeto de comentarios, independientemente de la cantidad de ofertas que realice 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
• Es el origen del comprador del grupo de intereses.
• 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 posibles códigos de estado se definen 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 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 contengan comentarios sobre una oferta de Protected Audience. Esta notificación incluirá 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 utilizará para enviar notificaciones de comentarios de depuración de ofertas 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. 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 OpenRTB, esto se especifica con BidRequest.ext.google_query_id, mientras que el protocolo de RTB de Google obsoleto usa BidRequest.google_query_id.
• %%INTEREST_GROUP_OWNER%%: Es el origen del propietario del grupo de interés.
• %%BID_CPM%%: Es el precio de 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 la oferta se rechazó dentro de 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. Infórmale a tu administrador de cuentas durante la integración si planeas probar PLTD, ya que se requieren recursos y configuraciones 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 que se configura la cuenta, Google y el socio pueden verificar la integración a través de los pasos que se indican en Fases 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 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 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 establece 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 los propietarios de los grupos de intereses y agrégalos a la cuenta de comprador autorizado.
  • 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 la cuenta o envía un ticket a través del Centro de ayuda de compradores autorizados 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 confiables.
• (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.
• Habilita los comentarios en tiempo real en tu cuenta (opcional) para recibir comentarios sobre los compradores de grupos de intereses que se solicitaron para incluirlos en una subasta de Protected Audience.
• (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 protegido 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 proporcionada por el ofertante para agregar un navegador al grupo de intereses que pertenece al 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 intereses integrado en el navegador debe ofertar lo suficientemente alto como para ganar la subasta, ya que podría competir con las ofertas convencionales del servidor. 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 intereses de la oferta.
      • accepted: Este campo es true si se aceptó la oferta y false si scoreAd() la rechazó.
      • externalBidStatus: un código de estado si la oferta se rechazó en un plazo de scoreAd() Los valores son códigos de estado de la creatividad.

Etapa 2: Experimento sin renderización (opcional)

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

Google asigna una pequeña cantidad de tráfico en vivo para ejecutar subastas de Protected Audience. Luego, ni Google ni el socio deberán activar manualmente un 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 Comprador autorizado cuando tengas todo listo. Google habilitará la cuenta para esta etapa.

Etapa 3: Experimento de renderización

Una vez que Google y el socio hayan verificado las subastas de Protected Audience a gran escala sin renderización, Google podrá permitir que el socio renderice el anuncio ganador de Protected Audience. 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 del Centro de ayuda de Comprador autorizado cuando tengas 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 subasta de extremo a extremo, ya que inicia la solicitud de anuncio contextual en paralelo con las solicitudes a los servidores de confianza del comprador 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. 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 publicación

A continuación, se muestra un resumen del flujo de subastas en paralelo:

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 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 de subasta restantes 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, la respuesta del anuncio contextual (incluidas las respuestas a la oferta) no se puede usar para elegir qué compradores participan en la subasta paralela para la solicitud determinada. 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. Los indicadores de subasta que no son necesarios para las solicitudes de servidor de confianza del comprador, como perBuyerSignals, se pueden seguir especificando en las respuestas de ofertas de RTB de la misma manera que en las subastas no paralelas. 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 almacenar en caché la lista de compradores del grupo de interés, Google no siempre ejecuta una subasta en paralelo, ya que la caché de paralelización puede estar vacía o vencida. Si la caché está vacía o vencida, Google ejecuta una subasta estándar de la API de Protected Audience no paralela y usa la intención del comprador para participar en la subasta no paralela y crear la caché del comprador del grupo de intereses.

3. Si al menos un comprador para cualquier ofertante está almacenado en caché para el dominio del publicador actual, Google ejecutará una subasta en paralelo, 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 intereses registrado para un ofertante determinado que se incluyó en la subasta paralela tendrá una entrada 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 un origen de comprador específico no está presente en la caché, no se podrá agregar ese comprador determinado al subasta. Esto se indica con una solicitud con parallelized=True que no tiene una entrada ParallelAuctionBuyer para un origen de comprador de grupo de intereses 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. La intención de participar en subastas de grupos de intereses 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 en paralelo) para los que un ofertante no indica la 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 en paralelo.