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 a anunciantes e empresas de adtech mostrar anúncios segmentados por grupos de interesse sem depender de cookies de terceiros e proteger os usuários contra o rastreamento entre sites.

O Chrome está executando um teste de origem para a API Protected Audience. Os compradores do Authorized Buyers estão qualificados para participar dos testes da API Protected Audience no inventário do editor do Ad Manager. Os bidders podem alcançar as seguintes metas ao testar a API Protected Audience:

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

Os compradores do Authorized Buyers interessados em testes precisam conferir a seção Integração para mais detalhes.

Resumo do fluxo de veiculação

Confira um resumo do fluxo de veiculação de anúncios da API 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 nos grupos de interesse.
  2. Um usuário final visita a página de um anunciante. A página pode conter a tag do bidder.
  3. A tag do bidder invoca a API Protected Audience joinAdInterestGroup(). Essa chamada solicita que o navegador adicione o usuário a um grupo de interesse.
  4. O usuário final visita 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 editor do Google faz uma solicitação de anúncio contextual para um servidor do Google.
  6. O Google envia solicitações de lance contextuais aos bidders participantes. Consulte a seção Alterações na solicitação de lance para mais informações.
  7. O bidder retorna um BidResponse com o campo interest_group_bidding. Se o bidder não especificar interest_group_bidding, o Google não vai incluir a origem dele em interestGroupBuyers na configuração do leilão. A resposta do lance também pode conter interest_group_bidding.per_buyer_signals. per_buyer_signals vai ser transmitido para a função de lances do bidder durante o leilão no navegador. Consulte a seção Alterações na resposta do lance para mais informações.
  8. O Google realiza o leilão do lado do servidor e retorna uma resposta de lance para o 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 para o leilão no navegador. Isso pode incluir indicadores de contexto de cada comprador participante (que foram enviados por interest_group_bidding.per_buyer_signals), informações contextuais do vencedor e configurações de qualificação de lance.
  10. A tag do editor do Google invoca a API Protected Audience runAdAuction() para iniciar o leilão do grupo de interesse no dispositivo. O Google inclui apenas compradores que já retornaram interest_group_bidding como interestGroupBuyers na configuração do leilão.
  11. O Google transmite o per_buyer_signals de cada bidder qualificado para a configuração do leilão da Protected Audience.
  12. Se os grupos de interesse de um determinado bidder especificaram o trustedBiddingSignalsUrl, o navegador faz uma solicitação para o trustedBiddingSignalsUrl de cada grupo para buscar indicadores em tempo real para cada grupo. 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 e está qualificado para participar do leilão no navegador. Esta etapa calcula o lance e seleciona um criativo. generateBid() tem acesso ao per_buyer_signals fornecido pelo bidder e aos indicadores de lances confiáveis para o grupo de interesse especificado.
  14. O navegador invoca o scoreAd() do vendedor (neste caso, do 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 anúncios e em outras restrições.
  15. O navegador gera um leilão com os lances do grupo de interesse qualificado. O lance contextual melhor classificado participa do leilão no navegador.
  16. Após o 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 exibição

Antes da veiculação do anúncio

Revisão do criativo

Os criativos precisam ser revisados e aprovados pelo Google antes de serem veiculados em leilões no navegador da Protected Audience. É possível enviar criativos para revisão usando a API de lances em tempo real ou a verificação automática de criativos. Os criativos para leilões de anúncios do grupo de interesse no navegador da Protected Audience precisam incluir renderUrls para revisão.

Requisitos de renderUrls:

  • Os renderUrl enviados pela API precisam corresponder aos renderUrl usados no leilão de anúncios do grupo de interesse.
  • Cada renderUrl só pode representar um único anunciante ou campanha publicitária. Um 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 buscável pelos sistemas de revisão de criativos off-line do Google por até sete 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 do grupo de interesse.

Verificação automática de criativos

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

Se você configurar a verificação automática de criativos, o Google encontrará criativos no leilão no navegador e vai verificá-los automaticamente para que se qualifiquem para leilão 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 Buyers.

  • 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 RFC2396 (link em inglês).

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 de lances em tempo real, será necessário reenviá-los depois de 15 dias. Se você confiar na verificação automática de criativos, o processo de verificação fará uma nova verificação automática.

ID de relatório do comprador

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

Confira a seguir 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 aparecerá como uma nova dimensão na ferramenta de relatórios do Authorized Buyers, como a dimensão ID de relatório do comprador.

Leilão do lado do servidor

Alterações na solicitação de lance

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

Indicar compatibilidade com leilão de grupo de interesse

As solicitações de lance têm um novo campo: auction_environment.

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

É possível usar esse campo para diferenciar entre oportunidades de impressão que oferecem suporte ao leilão de grupos de interesse no navegador da Protected Audience e aquelas que oferecem suporte apenas ao leilão tradicional de trocas do lado do servidor. O tipo enumerado auction_environment pode ter os seguintes valores:

  • SERVER_SIDE_AUCTION (JSON do OpenRTB: 0): leilões tradicionais do lado do servidor
  • ON_DEVICE_INTEREST_GROUP_AUCTION (JSON do OpenRTB: 1): solicitações com suporte da Protected Audience, em que um leilão contextual é realizado nos servidores da troca, nos lances do grupo de interesse e no leilão final, no navegador.
Indicar o tamanho do espaço do anúncio da Protected Audience

A solicitação de lance inclui os seguintes campos para informar o tamanho do espaço do anúncio da Protected Audience:

  • Protocolo RTB do 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

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

Esse tamanho pode ser diferente dos da solicitação contextual (Adslot.width e Adslot.height ou no OpenRTB: BidRequest.imp.banner.format).

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

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

Os anúncios da API Protected Audience podem ou não ser renderizados, dependendo do estágio de integração atual. Consulte 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.

  • Protocolo RTB do Google: BidRequest.adslot.interest_group_auction.render_interest_group_ads
  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
Reduzir a dependência de identificadores de usuários

As solicitações de lance contextual no escopo do teste da API Protected Audience podem continuar com identificadores tradicionais baseados em cookies quando disponíveis no navegador, como os campos google_user_id (BidRequest.user.id no OpenRTB) e hosted_match_data (BidRequest.user.buyerid no OpenRTB). A presença desses identificadores nas solicitações de lance vai continuar sujeita às Políticas de Privacidade existentes. Não dependa dos identificadores baseados em cookies para segmentação e lances durante os testes, o que ajuda a se preparar melhor para compras eficientes quando os cookies de terceiros não estiverem mais disponíveis.

O Google também pode realizar experimentos de pequena escala em que identificadores baseados em cookies são editados nas solicitações de lance no escopo do teste da API Protected Audience. O objetivo é avaliar o possível impacto da descontinuação dos cookies de terceiros.

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

Sites e fornecedores podem usar testes facilitados pelo Chrome para testar os sistemas com base no 3PCD. No teste, os navegadores Chrome são atribuídos a um grupo experimental 3PCD, modo A ou modo B. Cada navegador recebe um rótulo consistente correspondente a um grupo experimental específico do 3PCD, que você pode acessar por meio da API do Chrome no navegador.

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

Veja os campos em que você pode visualizar o marcador:

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

Alterações 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 contextual do lance:

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

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

Propagar indicadores de contexto do comprador (perBuyerSignals)

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

  • RTB do Google: BidResponse.interest_group_bidding.per_buyer_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
Especificar o preço máximo do lance no navegador

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

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

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

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

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

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

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

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

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

Contas filhas podem ter até dois IDs de faturamento. O comprador pode usar um ID de faturamento para gastos contextuais e outro para gastos do grupo de interesse. Entre em contato com seu gerente de contas se quiser configurar dois IDs de faturamento para uma conta filha.

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

Os IDs de faturamento de todas as contas filhas com orçamento disponível qualificadas para dar lances na impressão aparecem na solicitação de lance para a seleção de atribuição de gasto. Entre em contato com seu gerente de contas para modificar o orçamento de um ID de faturamento do 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 dos mesmos indicadores fornecidos pelo bidder 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 em micros).
  • render: o URL renderizado para exibir o criativo se o lance vencer o leilão. O Google precisa analisar e aprovar esse URL. Caso contrário, ele será filtrado do leilão.
  • allowComponentAuction: precisa ser true. No momento, o Google é compatível com testes de leilões com 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 Protected Audience para conferir uma explicação sobre a função generateBid().

Moeda do lance

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

A moeda do lance precisa ser indicada na resposta contextual do lance e no valor de retorno de generateBid, além de 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 RTB do Google, use o novo campo currency na mensagem InterestGroupBuyer na 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 os 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 de lance contextual for diferente da moeda retornada por generateBid ou se uma delas retornar uma moeda inválida, o lance vai 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 editor pode ser mais restritiva para lances de grupo de interesse no navegador durante o teste da API Protected Audience para parceiros de RTB.

Suporte da Lei dos Serviços Digitais

Devido à Lei dos Serviços Digitais Artigo 26, os editores podem exigir que os compradores renderizem declarações de transparência no anúncio. Quando o controle "Pedir aos compradores para exibir apenas anúncios com informações de transparência do DSA no meu site ou app no EEE" é ativado por um editor, os compradores do grupo de interesse podem determinar quais oportunidades serão necessárias para renderizar a transparência do comprador. Para isso, observe os seguintes campos nas solicitações de lance recebidas: BidRequest.dsa.dsa_support e BidRequest.dsa.publisher_rendering_support para o protocolo do Authorized Buyers do Google e BidRequest.regs.dsa.required e BidRequest.dsa.pubrender para o protocolo do OpenRTB.

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

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

Filtragem de lances

O Google aplica controles do editor e políticas de anúncios 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 de compradores sobre eventos de renderização e 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. Após a conclusão do leilão do grupo de interesse, mas antes da renderização, as macros são substituídas pelos valores correspondentes. A renderUrl usada no leilão no dispositivo pode incluir as seguintes macros:

${GDPR} Expande para 0 se o GDPR não se aplicar ou para 1 se o GDPR se aplicar. 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 se expandirá.

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

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

A macro ${GDPR_CONSENT_XXXX} precisa ocorrer apenas uma vez no renderUrl.
${ADDL_CONSENT} Expande-se para a string de consentimento adicional (AC, na sigla em inglês) associada à solicitação.
${AD_WIDTH}, ${AD_HEIGHT) Essas macros inserem a largura e a altura do espaço de anúncio.

Contagem de impressões

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

Como o evento usado pelo Google para contar impressões nos leilões da API Protected Audience no navegador pode ser diferente do evento usado para contar impressões pelos parceiros compradores de RTB, a contagem pode ser diferente.

Uma das metas do Google para 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 da API Protected Audience no navegador é atribuído a uma única conta 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 filhas 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 Protected Audience no nível da conta. Esse limite 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 alcançar o limite da API Protected Audience. Por exemplo, uma conta de bidder que atinge o limite da Protected Audience pode receber uma solicitação de lance com auction_environment = SERVER_SIDE_AUCTION (OpenRTB: 0), mesmo que a solicitação esteja qualificada para um leilão da Protected Audience.

Feedback em tempo real e lance mínimo para vencer

Os bidders que optaram por receber feedback em tempo real vão receber feedback sobre os compradores do grupo de interesse solicitados para inclusão em um leilão da API Protected Audience no dispositivo. Cada comprador do grupo de interesse especificado por um bidder em uma resposta do lance vai receber um objeto de feedback, independente de quantos lances o comprador do grupo de interesse fizer no leilão da Protected Audience. As seguintes informações vão estar 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 que o comprador do grupo de interesse precisa ganhar para vencer o leilão geral.
  • O lance mínimo que o comprador do grupo de interesse precisa vencer para superar o lance com a classificação mais alta do componente do lado do servidor do leilão geral.
  • O código de status do comprador do grupo de interesse. Os possíveis códigos de status são definidos em interest-group-buyer-status-codes.txt.

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

Notificação de feedback do lance

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

Os bidders podem entrar em contato com o gerente de contas para configurar um URL estático que vai ser usado para enviar notificações de feedback sobre os lances de depuração da API Protected Audience. Esse URL estático vai ser buscado nos servidores do Google com as macros selecionadas substituídas após a conclusão do leilão da Protected Audience. Há suporte para as seguintes macros:

  • %%GOOGLE_QUERY_ID%%: essa macro é substituída pelo ID de consulta do Google (BidRequest.google_query_id no protocolo do Authorized Buyers e BidRequest.ext.google_query_id no protocolo do OpenRTB) que foi enviado na solicitação de lance contextual ativado pela API Protected Audience.
  • %%INTEREST_GROUP_OWNER%%: a origem do proprietário do grupo de interesse.
  • %%BID_CPM%%: o preço do lance em CPM que foi 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 for rejeitado em scoreAd(). Os valores são códigos de status do criativo.

Confira um exemplo de URL estático que um bidder pode fornecer ao gerente da conta:

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 lance é um recurso temporário dependente da API ForDebuggingOnly temporária do Chrome.

Eventos de clique

Os bidders podem informar eventos de clique em anúncios da Protected Audience para o Google usando a API Fenced Frame Reporting. Os bidders precisam usar o tipo de evento click para notificar o Google sobre cliques. Veja um exemplo:

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 no nível do produto

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

Integração

Confira como testar a API Protected Audience:

Passos

  1. Preencha o formulário de solicitação (link em inglês) 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 crie um tíquete usando a Central de Ajuda do Authorized Buyers.
  3. Depois de configurar a conta, o Google e o parceiro podem verificar a integração seguindo as etapas nas etapas de teste.

Revisão de criativo

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

  • Inclua o parâmetro de consulta &pltd=True no renderUrl para o contêiner do anúncio do componente (também chamado de renderUrl de nível superior) para distinguir renderUrls de nível superior durante a revisão do criativo.
  • Renderize um criativo representativo quando o contêiner do anúncio do componente for buscado para uma revisão do criativo pelo Google. Para entender quando uma renderização representativa de anúncios precisa 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 preencha os campos relacionados à API Protected Audience na resposta de lance contextual, por exemplo, interest_group_bidding.
  • Implemente a inclusão de tags nas páginas do anunciante para fazer parte do navegador do usuário e participar do grupo de interesse.
  • Implemente generateBid() e reportWin().
  • Selecione as origens do proprietário do grupo de interesse e adicione-as à conta do Authorized Buyers.
    • 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 contas ou crie um tíquete usando a Central de Ajuda do Authorized Buyers para concluir essa etapa.
  • Configure a pré-segmentação do inventário relevante para os testes da API Protected Audience.
  • Envie criativos para revisão e aprovação por meio da API Criativos.
  • (Opcional) Configure os endpoints dos indicadores de lances confiáveis.
  • (Opcional) Configure uma página de anunciante de teste que permita aos engenheiros do Google adicionar o navegador aos grupos de interesse da origem do comprador do seu grupo de interesse. Isso nos permite acionar manualmente os leilões da API Protected Audience.
  • (Opcional) Ative o feedback em tempo real sobre sua conta para receber feedback de compradores do grupo de interesse solicitados para inclusão em um leilão da API Protected Audience.
  • (Opcional) Entre em contato com o gerente de contas para configurar um URL estático e receber uma notificação de servidor para servidor que forneça feedback de lance da API Protected Audience sobre o status de um lance de um leilão no dispositivo para ajudar a depurar problemas inesperados. Consulte a notificação de feedback de lance para ver detalhes.

Estágios de teste

Etapa 1: teste manual

Confira como acionar manualmente um leilão da 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 no artigo Testar o Sandbox de privacidade.
  3. Envie um criativo para aprovação usando a API de lances em tempo real.
  4. Use a página do anunciante fornecida pelo bidder para adicionar um navegador ao grupo de interesse do bidder.

  5. Use a seguinte página do editor de teste fornecida pelo Google para acionar um leilão da API Protected Audience:

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

    O grupo de interesse no navegador precisa dar lances altos o suficiente para vencer o leilão, já que pode competir com lances convencionais do lado do servidor. O Google também oferece uma página dedicada do editor de teste para cada parceiro, em que apenas um parceiro pode participar do leilão. Pode ser mais fácil vencer leilões no navegador de maneira confiável 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 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: este campo será true se o lance foi aceito e false se o lance 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.

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

Depois que o Google e o parceiro verificarem manualmente que o parceiro pode participar do leilão da Protected Audience, o Google habilitará o parceiro para a próxima etapa do teste.

O Google aloca uma pequena quantidade de tráfego em tempo real para executar leilões da API Protected Audience. Em seguida, o Google e o parceiro não vão mais precisar acionar manualmente um leilão da Protected Audience. O resultado do leilão da Protected Audience não é renderizado. Isso nos permite testar a integração em grande escala.

Entre em contato com seu gerente de contas ou crie um tíquete por meio da Central de Ajuda do Authorized Buyers 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 Protected Audience em 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 execução, e os anúncios do grupo de interesse vencedor são renderizados. Os lances no navegador dos bidders participantes concorrem com os lances tradicionais.

Entre em contato com seu gerente de contas ou crie um tíquete por meio da Central de Ajuda do Authorized Buyers quando estiver tudo pronto. O Google vai ativar a conta para essa etapa.