API Protected Audience (anteriormente FLEDGE)

Como parte do Sandbox de privacidade, o Chrome propôs a API Protected Audience, uma API no navegador que permite que anunciantes e empresas de tecnologia de publicidade mostrem anúncios segmentados por grupo de interesse sem depender de cookies de terceiros, protegendo os usuários contra o rastreamento entre sites.

O Chrome está executando um teste de origem da API Protected Audience. Os compradores do Authorized Buyers podem participar do teste da API Protected Audience no inventário do editor do Ad Manager. Ao testar a API Protected Audience, os bidders podem:

  • Iterar e aprender sobre a eficácia dos fluxos da API Protected Audience.
  • Gerar feedback sobre possíveis melhorias na API em fóruns públicos, como o GitHub.
  • Prepare-se para oferecer suporte à publicidade personalizada pela API sem depender de cookies de terceiros.

Os compradores interessados em testar precisam consultar a seção de integração para mais detalhes.

Resumo do fluxo de veiculação

Confira um resumo do fluxo de veiculação de anúncios da Protected Audience para parceiros do Authorized Buyers:

Diagrama de fluxo

  1. Um bidder trabalha com os anunciantes para manter grupos de interesse para cada anunciante. Muitas vezes, os anunciantes adicionam a tag de um bidder à página do anunciante para incluir um navegador em grupos de interesse.
  2. Um usuário final visita a página de um anunciante. A página pode conter a tag do proponente.
  3. A tag do bidder invoca a API Protected Audience joinAdInterestGroup(). Essa chamada pede ao navegador para adicionar o usuário a um grupo de interesse.
  4. O usuário final acessa uma página da Web do editor. O navegador do usuário solicita a tag de anúncio do editor do Google.
  5. A tag de anúncio do publisher do Google faz uma solicitação de anúncio contextual a um servidor do Google.
  6. O Google envia solicitações de lance contextual aos bidders participantes. Consulte a seção "Mudanças na solicitação de lance" para mais informações.
  7. O bidder retorna uma resposta de lance, incluindo a mensagem InterestGroupBidding, que é necessária para participar do leilão do grupo de interesse. No OpenRTB, isso é especificado com o campo BidResponse.ext.igbid, e no protocolo RTB do Google descontinuado, com o campo BidResponse.interest_group_bidding. Se o bidder não especificar essas informações, o Google não vai incluir a origem do bidder em interestGroupBuyers na configuração do leilão. O InterestGroupBidding também pode conter indicadores opcionais específicos do comprador que serão transmitidos à função de lances do bidder durante o leilão no navegador. No OpenRTB, isso é especificado com o campo BidResponse.ext.igbid.igbuyer.buyerdata. No protocolo RTB do Google descontinuado, isso é especificado com o campo BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals. Consulte a seção Mudanças na resposta do lance para mais informações.
  8. O Google executa o leilão do lado do servidor e retorna uma resposta de lance ao navegador. O leilão do lado do servidor considera lances tradicionais do lado do servidor. A resposta do lance pode conter informações sobre um lance vencedor contextual (se houver).
  9. A resposta do lance contém uma configuração de leilão para o leilão no navegador. Isso pode incluir indicadores contextuais de cada comprador participante (enviados anteriormente pelo buyerdata do OpenRTB ou pelo per_buyer_signals do protocolo RTB do Google descontinuado), informações sobre o vencedor contextual e configurações de qualificação para o lance.
  10. A tag do editor do Google invoca a API Protected Audience runAdAuction() para iniciar o leilão de grupo de interesse no dispositivo. O Google inclui apenas os compradores que foram incluídos como um InterestGroupBuyer em InterestGroupBidding durante a configuração do leilão.
  11. O Google transmite os indicadores opcionais específicos do comprador de cada bidder qualificado para a configuração de leilão do Protected Audience.
  12. Se os grupos de interesse de um determinado bidder especificarem o trustedBiddingSignalsUrl, o navegador fará uma solicitação para o trustedBiddingSignalsUrl de cada grupo para buscar indicadores em tempo real. Confira os detalhes na especificação da API Protected Audience.
  13. O navegador invoca o generateBid() do bidder para cada grupo de interesse que ativou a participação e está qualificado para participar do leilão no navegador. Esta etapa calcula o lance e seleciona um criativo. generateBid() tem acesso aos indicadores opcionais do comprador fornecidos pelo bidder e aos indicadores de lances confiáveis do grupo de interesse.
  14. O navegador invoca o scoreAd() do vendedor (neste caso, o Google) para atribuir uma classificação a cada lance no leilão de anúncios do grupo de interesse. Os lances são classificados e filtrados com base nas proteções do editor, nas políticas de publicidade e em outras restrições.
  15. O navegador realiza um leilão com os lances qualificados do grupo de interesse. O lance contextual com classificação mais alta participa do leilão no navegador.
  16. Depois do leilão, se houver um vencedor do grupo de interesse, o navegador vai invocar o reportResult() do vendedor e o reportWin() do bidder para notificar cada parte sobre o vencedor do leilão no navegador.
  17. Se um anúncio de grupo de interesse vencer, a tag do editor do Google vai renderizar o anúncio em um iframe.

Detalhes do fluxo de veiculação

Antes da veiculação de anúncios

Revisão do criativo

Os criativos precisam ser revisados e aprovados pelo Google antes de serem veiculados em leilões no navegador do Protected Audience. É possível enviar criativos para revisão pela API Real-time Bidding ou pela verificação automática de criativos. Os criativos para leilões de anúncios de grupos de interesse no navegador da API Protected Audience precisam incluir renderUrls para revisão.

Requisitos para renderUrls:

  • O renderUrl enviado pela API precisa corresponder ao renderUrl usado no leilão de anúncios do grupo de interesse.
  • Cada renderUrl só pode representar um único anunciante ou campanha publicitária. Um determinado renderUrl não pode ser usado para renderizar anúncios em nome de vários anunciantes. Cada renderUrl precisa ser mapeado para um único criativo.
  • O renderUrl precisa estar acessível e ser buscável pelos sistemas de revisão de criativos off-line do Google por até 7 dias após o último lance do anúncio.
API Real-time Bidding

Os bidders podem usar a API de lances em tempo real para fazer upload de criativos para lances de grupo de interesse.

Verificação automática de criativos

Os bidders podem configurar a verificação automática de criativos que não são enviados pela API Real-time Bidding.

Se você configurar a verificação automática de criativos, o Google vai encontrar os criativos no leilão no navegador e fazer a verificação automaticamente para que eles se qualifiquem para leilões futuros.

Veja como ativar a verificação automática de criativos:

  • Adicione todas as origens renderUrl do criativo do grupo de interesse à conta do Authorized Buyer.

  • Adicione os seguintes cabeçalhos HTTP personalizados à resposta HTTP do criativo:

    Authorized-Buyers-Creative-ID

    string

    ID do criativo específico do comprador. O comprimento máximo do ID do criativo é de 128 bytes.
    Authorized-Buyers-Click-Through-URLs

    string

    O conjunto de URLs de destino declarados para o criativo codificado de acordo com a RFC2396.

Exemplo:

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>
Expiração do criativo

Os criativos são aprovados por 15 dias. Se você enviar criativos com a API Real-time Bidding, será necessário reenviar o criativo após 15 dias. Se você usa a verificação automática de criativos, o processo é repetido automaticamente.

ID de relatório do comprador

É possível detalhar as métricas de relatórios (como impressões) usando dimensões fornecidas pelo comprador (por exemplo, ID da campanha ou do anunciante). Para adicionar uma dimensão ao gasto do grupo de interesse, especifique um buyerAndSellerReportingId para seu anúncio ao adicionar o dispositivo do usuário ao grupo de interesse. Confira mais detalhes na documentação da API Protected Audience.

Confira um exemplo de como adicionar buyerAndSellerReportingId à configuração do grupo de interesse:

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

O buyer_reporting_id vai aparecer como uma nova dimensão na ferramenta de relatórios do Authorized Buyer, como ID de relatório do comprador.

Leilão do lado do servidor

Mudanças na solicitação de lance

Confira a seguir as versões iniciais dos protocolos compatíveis para uso no experimento:

Indicar suporte a leilão de grupo de interesse

As solicitações de lances têm novos campos para indicar suporte a leilões de grupos de interesse:

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

Use esse campo para diferenciar as oportunidades de impressão que oferecem suporte ao leilão de grupo de interesse no navegador da API Protected Audience e aquelas que oferecem suporte apenas ao leilão de troca tradicional do lado do servidor. O tipo enumerado AuctionEnvironment pode ter os seguintes valores:

  • SERVER_SIDE_AUCTION (JSON do OpenRTB: 0): o leilão que determina o anúncio vencedor é executado nos servidores da troca.
  • ON_DEVICE_INTEREST_GROUP_AUCTION (JSON do OpenRTB: 1): solicitações com suporte à API Protected Audience, em que um leilão contextual é executado nos servidores da exchange, e a disputa de grupo de interesse e o leilão final são executados no navegador.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (JSON do OpenRTB: 3): o leilão contextual é executado nos servidores da exchange, e a lógica de lances para lances de grupo de interesse e a lógica de pontuação para determinar o anúncio vencedor final são executadas nos servidores de lances e leilões.
Indicar o tamanho do espaço do anúncio da API Protected Audience

A solicitação de lance inclui os seguintes campos para fornecer o tamanho do slot de anúncio do público-alvo protegido:

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • Protocolo RTB do Google (descontinuado):
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

Esses campos indicam o tamanho do espaço do anúncio para o leilão do Protected Audience em pixels.

Esse tamanho pode ser diferente daqueles na solicitação contextual, como os vistos nos campos BidRequest.imp.banner.format.w e BidRequest.imp.banner.format.h do OpenRTB ou nos campos BidRequest.adslot.width e BidRequest.adslot.height do protocolo Google RTB descontinuado.

A solicitação contextual pode ter vários tamanhos. O anúncio vencedor do leilão no dispositivo deve preencher apenas um único tamanho de slot fixo.

Indicar a capacidade de renderização de anúncios da API Protected Audience

Os anúncios do Protected Audience podem ou não ser renderizados, dependendo da fase atual de integração (consulte o experimento de não renderização). O campo render_interest_group_ads na solicitação de lance indica se o anúncio vencedor da API Protected Audience será renderizado.

  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • Protocolo de RTB do Google (descontinuado): BidRequest.adslot.interest_group_auction.render_interest_group_ads
Minimizar a dependência de identificadores de usuário

As solicitações de lances contextuais no escopo dos testes da API Protected Audience podem continuar usando identificadores tradicionais baseados em cookies quando disponíveis no navegador, como os campos BidRequest.user.id e BidRequest.user.buyerid ou BidRequest.google_user_id e BidRequest.hosted_match_data no protocolo RTB do Google descontinuado. A presença desses identificadores em solicitações de lances está sujeita às políticas de privacidade atuais. Recomendamos que você não use identificadores baseados em cookies para segmentação e lances durante os testes. Assim, você se prepara melhor para uma compra eficiente quando os cookies de terceiros não estiverem mais disponíveis.

O Google também pode realizar experimentos em pequena escala em que os identificadores baseados em cookies são omitidos das solicitações de lances no escopo do teste da API Protected Audience. Isso é para avaliar o possível impacto da descontinuação do uso de cookies de terceiros.

Em preparação para a descontinuação dos cookies de terceiros (3PCD) em 2024, o Chrome agora oferece testes facilitados pelo Chrome.

Sites e fornecedores podem usar o teste facilitado pelo Chrome para testar os sistemas deles no 3PCD. No teste, os navegadores Chrome são atribuídos a um grupo experimental de 3PCD, no modo A ou no modo B. Cada navegador recebe um rótulo consistente correspondente a um grupo de teste específico de 3PCD que pode ser acessado pela API do Chrome no navegador.

O Google transmite o rótulo não modificado da API Chrome na solicitação de bid de RTB. Devido às pequenas parcelas de tráfego de um rótulo individual, o Google nem sempre inclui o rótulo em contextos com restrições de privacidade.

Confira os campos em que o rótulo aparece:

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

Mudanças na resposta do lance

Indicar participação no leilão do grupo de interesse

Você é responsável por indicar explicitamente sua intenção de participar do leilão no navegador retornando o objeto InterestGroupBidding na resposta de lance contextual:

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

Você precisa fornecer uma resposta de bid contextual. A resposta não precisa incluir um lance contextual. O objeto InterestGroupBidding precisa conter o origin para cada InterestGroupBuyer, que deve corresponder a uma das origens configuradas pelo bidder para a conta dele. O origin é adicionado ao interestGroupBuyers da configuração do leilão quando a Tag do editor do Google chama runAdAuction().

Propagar indicadores contextuais do comprador

É possível incluir os indicadores de um comprador na resposta de lance contextual, que o Google propaga como um objeto JSON para a função de lance no dispositivo usando o argumento perBuyerSignals. Isso pode ser incluído na resposta de lance com os seguintes campos, dependendo do protocolo:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • RTB do Google (descontinuado): BidResponse.interest_group_bidding.per_buyer_signals
Propagar indicadores de renderização contextual do comprador

Os criativos de grupo de interesse podem usar indicadores contextuais limitados durante a renderização enviando esses indicadores pela resposta de lance contextual e recebendo-os na solicitação de URL de renderização usando a expansão de macro. Por exemplo, os indicadores de renderização podem ser usados para personalizar a aparência de um criativo e melhorar a performance no contexto de um determinado espaço de anúncio ou página do publisher.

É possível incluir os indicadores de renderização de um comprador serializados como uma string segura para URL na resposta do lance contextual. O Google vai substituir isso no URL de renderização do grupo de interesse vencedor construindo a macro ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

Os indicadores de renderização podem ser especificados na resposta de lance com os seguintes campos, dependendo do protocolo:

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

Até três conjuntos de indicadores de renderização com diferentes sufixos de macro podem ser incluídos na resposta de lance para distinguir indicadores diferentes. Por exemplo, um sufixo pode ser usado para corresponder a um conjunto específico de indicadores aplicáveis apenas a criativos com a macro correspondente no URL de renderização, reduzindo assim o tamanho da transferência de dados.

O comprador do grupo de interesse será impedido de participar do leilão de público-alvo protegido se os indicadores não forem seguros para URL, se os sufixos de macro não forem exclusivos ou se mais de três conjuntos de indicadores forem fornecidos.

Especifique o preço máximo do lance no navegador

Na proposta da Protected Audience, o cálculo do lance e o leilão final devem ser executados localmente no dispositivo. Isso pode criar possíveis vetores de abuso que podem afetar a integridade dos resultados finais do leilão, como o preço do lance vencedor.

Como uma mitigação compatível durante o teste da API Protected Audience pelo Google para os parceiros de RTB, é possível especificar um valor máximo esperado de lance em cada resposta de lance contextual. O lance máximo esperado é o preço máximo que sua função de lances deve retornar. Se o lance vencedor informado pelo leilão no navegador exceder esse valor, ele não será contabilizado como um evento faturável. Essa abordagem está sujeita a mudanças.

Na resposta de lance, é possível especificar o valor máximo esperado do lance nos seguintes campos:

  • OpenRTB: BidResponse.igbid.igbuyer.maxbid(expresso em unidades de moeda de CPM)
  • Protocolo RTB do Google (descontinuado): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (expresso em microCPM)
Atribuir impressões a várias contas

Um bidder precisa selecionar um ID de faturamento para atribuir as impressões do lance do grupo de interesse usando os seguintes campos:

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

O ID de faturamento selecionado precisa ser um ID qualificado da solicitação de lance:

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

Se o ID de faturamento para atribuir impressões de lance do grupo de interesse não for fornecido, o bidder não vai participar do leilão da API Protected Audience.

As contas secundárias podem ter até dois IDs de faturamento. O comprador pode usar um ID de faturamento para gastos contextuais e outro para gastos com grupos de interesse. Entre em contato com seu gerente de contas se quiser configurar dois IDs de faturamento para uma conta secundária.

É possível definir um orçamento diário para cada ID de faturamento. Entre em contato com seu gerente de conta para definir o orçamento diário dos IDs de faturamento das contas secundárias.

Os IDs de faturamento de todas as contas secundárias com orçamento disponível e qualificadas para dar lances na impressão aparecem na solicitação de lance para seleção de atribuição de gasto. Entre em contato com o gerente de contas para modificar o orçamento de um ID de faturamento de grupo de interesse.

Durante o leilão no navegador

Gerar lances no navegador

Use generateBid() para gerar lances no navegador.

O Google fornece os seguintes parâmetros:

  • auctionSignals: vazio
  • perBuyerSignals: um objeto JavaScript com os mesmos indicadores fornecidos pelo proponente na resposta contextual.

Os seguintes parâmetros são retornados:

  • ad: o Google ignora esse campo.
  • bid: um lance numérico que entra no leilão. Precisa estar em unidades de CPM (não micros).
  • render: o URL renderizado para mostrar o criativo se o lance vencer o leilão. O Google precisa analisar e aprovar esse URL, ou ele será filtrado do leilão.
  • allowComponentAuction: precisa ser true. No momento, o Google oferece suporte a testes de leilões de vários vendedores.

Veja um exemplo:

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

Consulte a seção Lances no dispositivo da especificação da API Protected Audience para uma explicação da função generateBid().

Moeda do lance

Os lances de leilão no navegador são feitos em unidades de CPM na moeda escolhida.

A moeda do lance precisa ser indicada na resposta de lance contextual e no valor de retorno de generateBid. Além disso, ela precisa ser um código alfa ISO 4217 válido, como "USD", "EUR" ou "JPY".

No OpenRTB, use o novo campo cur no objeto InterestGroupBuyer na extensão de resposta de lance do Google.

Veja um exemplo:

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

No protocolo de RTB do Google, use o novo campo currency na mensagem InterestGroupBuyer da resposta do lance.

Veja um exemplo:

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

As funções generateBid dos bidders precisam retornar lances na mesma moeda indicada na resposta do lance contextual. Preencha a nova propriedade bidCurrency no valor de retorno de generateBid:

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

Se a moeda da resposta do lance contextual for diferente da moeda retornada por generateBid ou se qualquer uma delas retornar uma moeda inválida, o lance será filtrado antes do leilão.

Verificações de qualidade do anúncio

A aplicação da política de criativos e dos controles do publisher pode ser mais restritiva para lances de grupo de interesse no navegador durante o teste da API Protected Audience para parceiros de RTB.

Suporte à Lei dos Serviços Digitais

De acordo com o Artigo 26 da Lei de Serviços Digitais, os publishers podem exigir que os compradores renderizem divulgações de transparência no anúncio. Quando o controle "Pedir que os compradores mostrem anúncios apenas com informações de transparência da DSA no meu site ou app no EEE" é ativado por um editor, os compradores de grupos de interesse podem determinar em quais oportunidades eles precisarão renderizar a transparência do comprador observando os valores de BidRequest.regs.dsa.required e BidRequest.dsa.pubrender na solicitação de lance (BidRequest.dsa.dsa_support e BidRequest.dsa.publisher_rendering_support, respectivamente, no protocolo Google RTB descontinuado).

Quando um bidder que quer participar dos leilões da API Protected Audience recebe o indicador na solicitação de lance de que a transparência da DSA precisa ser mostrada para anúncios veiculados pela API Protected Audience, ele deve avaliar se consegue mostrar as informações necessárias e especificar definindo BidResponse.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render no protocolo RTB do Google descontinuado). Caso contrário, o comprador não será incluído no leilão da API Protected Audience.

Para mais informações sobre a transparência de anúncios da Lei de Serviços Digitais, consulte o artigo da Central de Ajuda: apoio à Lei de Serviços Digitais.

Filtragem de lances

O Google aplica controles do editor e políticas de publicidade durante o leilão no dispositivo.

Após o leilão no navegador

Informar o resultado do leilão ao comprador: reportWin()

O Google não preenche os seguintes argumentos:

  • auctionSignals
  • sellerSignals

Use reportWin() para informar o resultado do leilão ao comprador.

Consulte a seção Relatórios do comprador sobre eventos de renderização e de anúncio da explicação da API Protected Audience para mais informações.

Macros

O renderUrl que faz referência ao criativo da API Protected Audience pode incluir um ou mais marcadores de posição, chamados de macros. Depois que o leilão do grupo de interesse é concluído, mas antes da renderização, as macros são substituídas pelos valores correspondentes. O renderUrl usado no leilão no dispositivo pode incluir as seguintes macros:

${GDPR} Expande para 0 se o GDPR não se aplica ou 1 se ele se aplica. Consulte a documentação.
${GDPR_CONSENT_XXXX} Expande-se para a string de transparência e consentimento (TC) associada à solicitação. Se a string de Transparência e Consentimento (TC) estiver em branco ou for inválida, essa macro não vai se expandir.

Use essa macro para transmitir a string de TC a um fornecedor registrado na GVL do IAB por um URL. Substitua XXXX pelo ID da GVL do IAB do fornecedor registrado na GVL do IAB. Se a string de TC estiver em branco ou for inválida, essa macro não será expandida.

Criativos com a macro ${GDPR_CONSENT_XXXX} podem ser bloqueados se o fornecedor registrado na GVL do IAB associado ao ID na GVL do IAB inserido não tiver o consentimento do usuário.

A macro ${GDPR_CONSENT_XXXX} deve ocorrer apenas uma vez no renderUrl.
${ADDL_CONSENT} Expande-se para a string de consentimento adicional (AC) associada à solicitação.
${AD_WIDTH}, ${AD_HEIGHT) Essas macros inserem a largura e a altura do espaço de anúncio.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

Macro que contém indicadores do comprador no momento da renderização especificados na resposta do lance.

Substitua o marcador de posição buyer.origin.example pela origem do comprador do grupo de interesse, que deve corresponder a interest_group_buyers.origin na resposta do lance. Você pode incluir um _OPTIONAL_SUFFIX para fornecer até três valores de sinal de renderização diferentes.

Contagem de impressões

Durante o teste da API Protected Audience com parceiros de RTB, o Google vai contar impressões quando o navegador chamar a função reportResult() e buscar o URL de relatório do Google em uma chamada para sendReportTo().

Como o evento usado pelo Google para contar impressões em leilões no navegador da API Protected Audience pode ser diferente do evento usado para contar impressões pelos parceiros compradores de RTB, as contagens de impressões podem ser diferentes.

Um dos objetivos do Google ao testar a API Protected Audience é identificar e reduzir essas discrepâncias.

Atribuição de impressões faturáveis

Todo o gasto de um bidder nos leilões no navegador da Protected Audience é atribuído a uma única conta de bidder com base no mapeamento das origens do proprietário do grupo de interesse configuradas para o bidder. Não é possível atribuir gastos a diferentes contas secundárias de um bidder.

Limite de orçamento diário

Durante o teste da API Protected Audience, cada conta tem um limite de orçamento diário de gasto da API Protected Audience no nível da conta. O limite de orçamento diário limita o risco no ambiente de leilão no navegador. Quando o limite de orçamento diário é atingido, a conta não recebe mais solicitações de lance qualificadas para a API Protected Audience.

A conta pode continuar participando de leilões contextuais do lado do servidor depois de atingir o limite da API Protected Audience. Por exemplo, uma conta de bidder que atinge o limite da API Protected Audience pode receber uma solicitação de lance com auction_environment = SERVER_SIDE_AUCTION (JSON OpenRTB: 0), mesmo que a solicitação de lance esteja qualificada para um leilão da API Protected Audience.

Feedback em tempo real e lance mínimo para vencer

Os bidders que ativaram o recebimento de feedback em tempo real vão receber feedback para os compradores de grupos de interesse que pediram inclusão em um leilão da API Protected Audience no dispositivo. Cada comprador de grupo de interesse especificado por um bidder em uma resposta de lance vai receber um objeto de feedback, não importa quantos lances o comprador de grupo de interesse faça no leilão da API Protected Audience. As seguintes informações estarão disponíveis no objeto de feedback do comprador do grupo de interesse:

  • O tipo de feedback do objeto de feedback será INTEREST_GROUP_BUYER_FEEDBACK.
  • A origem do comprador do grupo de interesse.
  • O lance mínimo para vencer do comprador do grupo de interesse para ganhar o leilão geral.
  • O lance mínimo para vencer do comprador do grupo de interesse para superar o lance mais alto do componente do lado do servidor do leilão geral.
  • O código de status do comprador do grupo de interesse. Os códigos de status possíveis são definidos em interest-group-buyer-status-codes.txt.

Consulte a documentação do protocolo para RTB do Authorized Buyers e extensões do OpenRTB para ver os nomes de campos específicos.

Notificação de feedback de lance

O Chrome oferece uma API de depuração temporária para a API Protected Audience, que permite ao Ad Manager enviar notificações de depuração de servidor para servidor em tempo real com feedback sobre um lance do Protected Audience. Essa notificação vai incluir os motivos pelos quais os lances podem ter sido filtrados no leilão no navegador das APIs Protected Audience, além de outras informações sobre um lance, conforme descrito abaixo.

Os bidders podem entrar em contato com o gerente de conta para configurar um URL estático que será usado para enviar notificações de feedback de depuração de lances da API Protected Audience. Esse URL estático será buscado nos servidores do Google com as macros selecionadas substituídas depois que o leilão com Protected Audience for concluído. As seguintes macros são compatíveis:

  • %%GOOGLE_QUERY_ID%%: essa macro é substituída pelo ID da consulta do Google enviado na solicitação de lances contextuais ativada para o público-alvo protegido. No protocolo OpenRTB, isso é especificado com BidRequest.ext.google_query_id, enquanto o protocolo RTB do Google desativado usa BidRequest.google_query_id.
  • %%INTEREST_GROUP_OWNER%%: a origem do proprietário do grupo de interesse.
  • %%BID_CPM%%: o preço do lance em CPM especificado pelo comprador na função generateBid().
  • %%RENDER_URL%%: o URL de renderização do criativo.
  • %%STATUS%%: um código de status se o lance foi rejeitado em scoreAd(). Os valores são códigos de status do criativo.

Este é um exemplo de URL estático que um bidder pode fornecer ao gerente de contas:

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

A notificação de feedback de lances é um recurso temporário que depende da API ForDebuggingOnly temporária do Chrome.

TURTLEDOVE no nível do produto

Anúncios compostos de várias partes ou TURTLEDOVE no nível do produto (PLTD) são aceitos para parceiros de RTB do Google durante o teste da API Protected Audience. Informe seu gerente de contas durante a integração se você planeja testar o PLTD, já que são necessários recursos e configuração extras.

Integração

Veja como testar a API Protected Audience:

Etapas

  1. Preencha o formulário de solicitação para participar do experimento da API Protected Audience.
  2. Depois de enviar o formulário de solicitação, entre em contato com seu gerente de contas ou abra um tíquete usando a Central de Ajuda do Authorized Buyer.
  3. Depois que a conta for configurada, o Google e o parceiro poderão verificar a integração seguindo as etapas em Etapas de teste.

Revisão do criativo

Para dar lances com anúncios no nível do produto (anúncios compostos de várias partes) em leilões da API Protected Audience, siga estes requisitos:

  • Inclua o parâmetro de consulta &pltd=True no renderUrl do contêiner do anúncio de componente (também chamado de renderUrl de nível superior) para distinguir os renderUrls de nível superior durante a revisão do criativo.
  • Renderizar um criativo representativo quando o contêiner do anúncio de componente for buscado para uma revisão de criativo pelo Google. Para entender quando uma renderização de anúncio representativa deve ser retornada, consulte o parâmetro de consulta validation=True definido pelo sistema de revisão de criativos do Google.

Lista de verificação de integração

  • Configure um endpoint de solicitação de lance que vai preencher os campos relacionados à API Protected Audience na resposta de lance contextual, por exemplo, interest_group_bidding.
  • Implemente a inclusão de tag nas páginas do anunciante para associar o navegador do usuário ao grupo de interesse.
  • Implemente generateBid() e reportWin().
  • Selecione as origens dos proprietários de grupos de interesse e adicione-as à conta do Authorized Buyer.
    • As origens do proprietário do grupo de interesse precisam corresponder às origens em que as funções generateBid() estão hospedadas.
    • Entre em contato com o gerente de conta ou envie um tíquete usando a Central de Ajuda do comprador autorizado para concluir esta etapa.
  • Configure a pré-segmentação para o inventário relevante para o teste da API Protected Audience.
  • Envie criativos para revisão e aprovação usando a API Creatives.
  • (Opcional) Configure os endpoints de indicadores de lances confiáveis.
  • (Opcional) Configure uma página de anunciante de teste para que os engenheiros do Google adicionem o navegador deles aos grupos de interesse pertencentes à origem do comprador. Isso nos permite acionar manualmente os leilões da API Protected Audience.
  • (Opcional) Ative o feedback em tempo real na sua conta para receber feedback dos compradores de grupos de interesse que pediram inclusão em um leilão da API Protected Audience.
  • (Opcional) Entre em contato com seu gerente de contas para configurar um URL estático e receber uma notificação de servidor para servidor com feedback de lances do Protected Audience sobre o status de um lance de um leilão do Protected Audience no dispositivo. Isso ajuda a depurar problemas inesperados. Consulte a notificação de feedback de lance para mais detalhes.

Etapas de teste

Etapa 1: teste manual

Saiba como acionar manualmente um leilão com Protected Audience, garantir que o anúncio possa ser renderizado e registrar a impressão:

  1. Use o Chrome 101 ou mais recente.
  2. Ative a API do Sandbox de privacidade e o Fenced Frame usando chrome://flags/#privacy-sandbox-ads-apis e chrome://flags/#enable-fenced-frames. Saiba mais em Testar o Sandbox de privacidade.
  3. Envie um criativo para aprovação usando a API Real-time Bidding.
  4. Use a página do anunciante fornecida pelo bidder para adicionar um navegador ao grupo de interesse de propriedade do bidder.

  5. Use a página de publisher de teste fornecida pelo Google a seguir para acionar um leilão com Protected Audience:

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

    O grupo de interesse no navegador precisa dar um lance alto o suficiente para vencer o leilão, já que ele pode competir com lances convencionais do lado do servidor. O Google também oferece uma página de editor de teste dedicada para cada parceiro, em que apenas o parceiro em questão pode participar do leilão. Pode ser mais fácil ganhar leilões no navegador em uma página específica do parceiro.

  6. Confirme o seguinte:

    1. O anúncio vencedor esperado é renderizado.
    2. O resultado do leilão é enviado do lado do servidor, ou seja, um bidder vencedor recebe um ping de volta de reportWin().
    3. O console da página do editor de teste registra uma mensagem de depuração para cada lance com as seguintes informações:
      • renderUrl: o URL de renderização do lance.
      • interestGroupOwner: o proprietário do grupo de interesse do lance.
      • accepted: esse campo é true se o lance foi aceito e false se ele foi rejeitado por scoreAd().
      • externalBidStatus: um código de status se o lance foi rejeitado em scoreAd(). Os valores são códigos de status do criativo.

Etapa 2: (opcional) experimento sem renderização

Depois que o Google e o parceiro verificam manualmente que ele pode participar do leilão da API Protected Audience, o Google o habilita para a próxima etapa de teste.

O Google aloca uma pequena quantidade de tráfego ativo para realizar leilões de Protected Audience. Assim, o Google e o parceiro não precisam mais acionar manualmente um leilão da API Protected Audience. O resultado do leilão da Protected Audience não é renderizado. Isso permite testar a integração em grande escala.

Entre em contato com seu gerente de contas ou envie um tíquete pela Central de Ajuda do Authorized Buyer quando estiver tudo pronto. O Google vai ativar a conta para essa etapa.

Etapa 3: experimento de renderização

Depois que o Google e o parceiro verificarem os leilões da API Protected Audience em grande escala sem renderização, o Google poderá permitir que o parceiro renderize o anúncio vencedor da API Protected Audience. O Google tem uma pequena quantidade de tráfego em que os leilões da API Protected Audience estão qualificados para veiculação e os anúncios do grupo de interesse vencedores são renderizados. Os lances no navegador dos bidders participantes competem com os lances tradicionais.

Entre em contato com seu gerente de contas ou envie um tíquete pela Central de Ajuda do Authorized Buyer quando estiver tudo pronto. O Google vai ativar a conta para essa etapa.

Outros recursos

Os recursos a seguir são extensões do protocolo principal.

Paralelização

A paralelização é uma otimização que diminui a latência do leilão de ponta a ponta ao iniciar a solicitação de anúncio contextual em paralelo com as solicitações aos servidores confiáveis do comprador especificados em trustedBiddingSignalsUrl.

A paralelização reduz a latência, mas afeta a qualificação do comprador de grupo de interesse e o suporte para experimentos coordenados. A paralelização se aplica a todos os bidders que participam do leilão de grupos de interesse no dispositivo. Os bidders não precisam fazer nada para participar dos leilões paralelos, mas precisam entender como a paralelização pode afetar a qualificação deles nos leilões no dispositivo. Ainda não é possível usar IDs de grupo de experimento para experimentos coordenados em leilões paralelos.

Resumo do fluxo de veiculação

Confira um resumo do fluxo de leilão paralelo: Diagrama de fluxo

Qualificação do comprador do grupo de interesse no dispositivo

Para leilões paralelos, a chamada de navigator.runAdAuction acontece antes que a resposta do anúncio contextual seja retornada. Para iniciar chamadas de servidor confiáveis do comprador, o navigator.runAdAuction exige que o parâmetro interestGroupBuyers seja transmitido como um valor, enquanto os demais parâmetros do leilão aceitam promessas de JavaScript que podem ser resolvidas após a resposta do anúncio contextual. Como interestGroupBuyers é transmitido antes da resposta do anúncio contextual, ela (incluindo respostas de lance) não pode ser usada para escolher quais compradores participam do leilão paralelizado para a solicitação específica. Em vez disso, a tag do editor do Google armazena em cache, no navegador do usuário, o parâmetro interestGroupBuyers de execuções anteriores de navigator.runAdAuction no mesmo domínio.

A paralelização tem várias considerações importantes:

  1. Os indicadores de leilão que não são necessários para solicitações de servidor confiável do comprador, como perBuyerSignals, podem continuar sendo especificados em respostas de lance de RTB da mesma forma que em leilões não paralelizados. Depois que as promessas desses indicadores forem resolvidas, as etapas restantes do leilão no dispositivo serão concluídas da mesma forma que no fluxo de leilão não paralelo.

  2. Como a paralelização depende do armazenamento em cache da lista de compradores de grupos de interesse, o Google nem sempre realiza um leilão paralelo, já que o cache de paralelização pode estar vazio ou expirado. Se o cache estiver vazio ou expirado, o Google vai realizar um leilão padrão não paralelo da API Protected Audience e usar a intenção do comprador para participar do leilão não paralelo e criar o cache do comprador do grupo de interesse.

  3. Se pelo menos um comprador de qualquer bidder estiver em cache para o domínio do editor atual, o Google vai realizar um leilão paralelo, que será indicado na solicitação de lance:

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

  4. Cada origem de comprador de grupo de interesse registrada para um determinado bidder que foi incluído no leilão paralelo terá uma entrada ParallelAuctionBuyer correspondente:

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

  5. Se um leilão paralelo for executado, mas uma origem de comprador específica não estiver presente no cache, esse comprador não poderá ser adicionado ao leilão no dispositivo atual. Isso é indicado por uma solicitação com parallelized=True que não tem uma entrada ParallelAuctionBuyer para uma determinada origem do comprador de grupo de interesse. No entanto, os bidders que indicarem interesse incluindo InterestGroupBuyer(s) válidos e qualificados na resposta do lance terão as origens do comprador do grupo de interesse correspondente adicionadas ao cache, e essas origens estarão qualificadas para solicitações paralelizadas futuras do mesmo navegador e domínio. A intenção de participar de leilões de grupos de interesse pode ser indicada nos seguintes campos:

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

  6. As origens de compradores em cache (incluídas no parâmetro interestGroupBuyers do leilão paralelo) para as quais um bidder não indica a intenção de participar na resposta de lance podem receber uma chamada de servidor confiável do comprador, mas não participam do leilão paralelo.