API Protected Audience (anteriormente FLEDGE)

Como parte do Sandbox de privacidade, o Chrome propôs a API Protected Audience API: uma API no navegador que permite que anunciantes e empresas de adtech mostrem anúncios segmentados por grupo de interesse sem depender de cookies de terceiros e, ao mesmo tempo, proteger os usuários monitoramento.

O Chrome está executando uma origem período de teste da API Protected Audience. Os compradores do Authorized Buyers podem participar o teste da API Protected Audience no inventário do editor do Ad Manager. Os anunciantes podem fazer o seguinte 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 de 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 devem conferir o Guia 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 próprios anunciantes para manter os grupos de interesse para cada anunciante. Muitas vezes, os anunciantes adicionam a tag de um proponente ao página do anunciante para adicionar um navegador aos grupos de interesse.
  2. Um usuário final visita a página de um anunciante. A página pode conter o valor tag.
  3. A tag do bidder invoca a joinAdInterestGroup() da API Protected Audience. 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 de mudanças na solicitação de lances para mais informações.
  7. O bidder retorna uma resposta de lance que inclui a mensagem InterestGroupBidding, necessária para participar do leilão do grupo de interesse. Em OpenRTB especificado no campo BidResponse.ext.igbid e em o protocolo RTB descontinuado do Google, que é especificado com o BidResponse.interest_group_bidding. Se o proponente não especificar essas informações, o Google não inclui a origem do proponente no interestGroupBuyers no configuração do leilão. O InterestGroupBidding também pode conter indicadores opcionais específicos do comprador que serão transmitidos para a função de lances do proponente durante o leilão no navegador. No OpenRTB, isso é especificado com BidResponse.ext.igbid.igbuyer.buyerdata e na versão descontinuada protocolo RTB do Google, isso é especificado com o BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals . Consulte a seção Mudanças na resposta de lances 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 nenhum).
  9. A resposta do lance contém uma configuração de leilão para o navegador leilão. Isso pode incluir indicadores de contexto de cada comprador participante (que foram enviados pelo buyerdata do OpenRTB ou pelo RTB do Google descontinuado do protocolo per_buyer_signals anterior), informações contextuais do vencedor e para qualificação de lances.
  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 só inclui compradores que foram incluídos como InterestGroupBuyer em InterestGroupBidding durante a configuração do leilão.
  11. O Google transmite os indicadores opcionais específicos do comprador de cada proponente qualificado para a configuração do leilão da API 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. Consulte na API Protected Audience spec.
  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. Isso 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 para o grupo de interesse especificado.
  14. O navegador invoca o scoreAd() do vendedor (neste caso, o 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 filtradas com base nas proteções do editor, políticas de anúncios e outros restrições.
  15. O navegador realiza um leilão com os lances qualificados do grupo de interesse. O lance contextual de classificação mais alta participa do leilão no navegador.
  16. Após o leilão, se houver um vencedor do grupo de interesse, o navegador invoca a reportResult() do vendedor e a reportWin() do bidder para que sejam notificadas 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 processará o anúncio em uma iframe.

Detalhes do fluxo de veiculação

Antes da veiculação do anúncio

Revisão do criativo

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

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 anunciante campanha. Um renderUrl não pode ser usado para renderizar anúncios em nome de vários anunciantes. Cada renderUrl precisa ser associado a um único criativo.
  • O renderUrl precisa ser acessível e buscado pelo Google off-line. por até sete dias após o último lance do anúncio.
API Real-time Bidding

Os bidders podem usar o recurso Lances em tempo real API para fazer o upload de criativos lances de grupos de interesse.

Verificação automática de criativos

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

Se você configurar a verificação automática de criativos, o Google encontrará os criativos na no navegador e as verifica automaticamente, de modo que se qualificam 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 de comprador autorizado.

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

    Authorized-Buyers-Creative-ID

    string

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

    string

    O conjunto de URLs de destino declarados para o criativo codificado de acordo para 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 o Relatório de tempo real Bidding API, vai ser preciso reenviar o criativo após 15 dias. Se você depende verificação automática de criativos, o processo verifica novamente de forma automática.

ID de relatório do comprador

É possível detalhar as métricas de relatórios (como impressões) usando as dimensões. fornecidos pelo comprador (por exemplo, ID da campanha ou do anunciante). Para adicionar uma dimensão para o 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 Protected Audience.

Confira abaixo um exemplo de como adicionar buyerAndSellerReportingId a 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 tabela Ferramenta de relatórios do comprador, como dimensão do 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 anteriores dos protocolos compatíveis para uso no experimento:

Indicar suporte para leilões de grupos de interesse

As solicitações de lance 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

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

  • SERVER_SIDE_AUCTION (OpenRTB JSON: 0): o leilão que determina o anúncio vencedor é veiculado 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 troca, e o lance do grupo de interesse e o leilão final são executados no navegador.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): o leilão contextual é executado nos servidores da troca, e a lógica de lances para lances de grupos de interesse e a lógica de pontuação para determinar o anúncio vencedor final são executadas em 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 campos a seguir para fornecer a API Tamanho do espaço de anúncio do público-alvo:

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • Protocolo de 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 da Protected Audience em pixels.

Esse tamanho pode ser diferente do tamanho da solicitação contextual, como aqueles encontrados 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. Espera-se que o anúncio vencedor do leilão no dispositivo preencha apenas um único tamanho de slot fixo.

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

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

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

As solicitações de lance contextuais no escopo do teste da API Protected Audience podem continuem a transportar 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 pol. o protocolo descontinuado RTB do Google. A presença desses identificadores nos lances solicitações estão sujeitas às Políticas de Privacidade existentes. Recomendamos que você não depender de identificadores baseados em cookies para fins de segmentação e lance durante testes para se preparar melhor para compras eficientes quando cookies de terceiros não estiverem mais disponível.

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

Com o objetivo de se preparar para descontinuação dos cookies de terceiros (3PCD, na sigla em inglês) em 2024, o Chrome agora oferece Testes facilitados pelo Chrome.

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

O Google passa o rótulo não modificado da API do Chrome no lance de RTB solicitação. Devido às pequenas fatias de tráfego de um rótulo individual, o Google nem sempre inclui o rótulo em contextos limitados à privacidade.

Confira os campos em que o rótulo aparece:

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

Alterações na resposta do lance

Indicar a 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 lance contextual. A resposta não precisa incluir um lance contextual. O objeto InterestGroupBidding precisa conter o origin para cada InterestGroupBuyer, que precisa corresponder a uma das origens configuradas pelo bidder para a conta. O origin é adicionado ao leilão da configuração interestGroupBuyers quando a Tag do editor do Google chamar runAdAuction()

Propagar indicadores de contexto 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. Pode ser incluído na resposta do lance com o parâmetro campos a seguir, 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 do grupo de interesse podem usar indicadores de contexto limitados durante a renderização por: enviar esses sinais por meio da resposta de lance contextual e recebê-los na solicitação do 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 e a sensação de um criativo e melhorar o desempenho no contexto de um determinado espaço de anúncio ou página do editor.

É possível incluir os indicadores de renderização de um comprador serializados como uma string segura para URL na resposta do lance contextual, que o Google vai substituir no URL de renderização do grupo de interesse vencedor criando 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 do lance para distinguir sinais diferentes. Por exemplo, um sufixo possam ser usadas para corresponder a um conjunto específico de indicadores aplicáveis somente a criativos com a macro correspondente no URL de renderização, reduzindo assim a transferência de dados tamanho.

O comprador do grupo de interesse não poderá participar do leilão de audiência protegida 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.

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

Na proposta da Protected Audience, a computação do lance e o leilão final são 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 mitigação com suporte durante os testes 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 a função de lances deve retornar. Se o lance vencedor informado do 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, você pode especificar o valor de lance máximo esperado no campo 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 interesse as impressões do lance de grupo usando os seguintes campos:

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

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

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

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

As contas filhas podem ter até dois IDs de faturamento. O comprador poderia usar ID do faturamento para gastos contextuais e o 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 infantil.

É 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 para os IDs de faturamento das contas filhas.

Os IDs de faturamento de todas as contas filhas com orçamento disponível qualificado para lances na impressão aparecer na solicitação de lance para a seleção de atribuição de gasto. Entrar em contato ao gerente da conta 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 oferece os seguintes parâmetros:

  • auctionSignals: vazio
  • perBuyerSignals: um objeto JavaScript dos mesmos indicadores fornecidos pelo licitante na resposta contextual

Os seguintes parâmetros são retornados:

  • ad: o Google ignora esse campo.
  • bid: um lance numérico que participa do leilão. Precisa estar em unidades de CPM, não em 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. Atualmente, o Google oferece suporte a 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 API Protected Audience para uma explicação da função generateBid().

Moeda do lance

Os lances de leilão no navegador são colocados em unidades de CPM da moeda de lance escolhida.

A moeda do lance deve ser indicada na resposta de lance contextual e no o valor de retorno de generateBid e precisa ser um código alfa ISO 4217 válido, como 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 na resposta do lance.

Veja um exemplo:

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

Bidders As funções generateBid precisam retornar lances na mesma moeda que indicado na resposta de 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 retornado por generateBid, ou se algum deles retornar uma moeda inválida, o lance será filtrado antes do leilão.

Verificações de qualidade dos anúncios

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

Apoio à Lei dos Serviços Digitais

Devido ao Artigo 26 da Lei dos Serviços Digitais, os editores podem exigir que os compradores exibam informações de transparência no anúncio. Quando o controle "Pedir que os compradores mostrem apenas anúncios 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 quais oportunidades eles precisam mostrar 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 descontinuado do Google RTB).

Quando um bidder quer participar de 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 precisa avaliar se ele poderá exibir corretamente as informações necessárias e especificar BidResponse.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render pol. o protocolo descontinuado do RTB do Google). Caso contrário, o comprador não será incluído no leilão da API Protected Audience.

Para mais informações sobre a Lei dos Serviços Digitais de transparência em anúncios, consulte a Artigo da Central de Ajuda: Suporte à Lei dos Serviços Digitais.

Filtragem de lances

O Google aplica restrições controles e anúncios políticas 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 os Relatórios de compradores sobre renderização e anúncios Eventos 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 o leilão do grupo de interesse é concluído, mas antes da renderização, as macros são substituídas pelo código valores. A renderUrl usada no leilão no dispositivo pode incluir o seguinte :

${GDPR} Aumenta para 0 se o GDPR não se aplica ou 1 se ele for aplicável. 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 será expandida.

Use essa macro para transmitir a string de TC a um fornecedor registrado na GVL do IAB em um URL. Substitua XXXX pelo ID da GVL do IAB registrada na GVL do IAB. vendor. 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} podem se tornar será bloqueado se o fornecedor registrado na GVL do IAB associado ao ID que você inserida não tem 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.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

Macro contendo indicadores do comprador no tempo de renderização especificado na resposta do lance.

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

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, em seguida, buscar o URL de relatórios do Google em uma chamada para sendReportTo().

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

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

Atribuição de impressões faturáveis

Todo o gasto do bidder em leilões no navegador da API Protected Audience é atribuídas a uma única conta de proponente com base no mapeamento do valor de interesse origens do proprietário do grupo configuradas para o bidder. Atribuir gastos a diferentes As contas de vagas secundárias de um bidder não são compatíveis.

Limite de orçamento diário

Durante o teste da API Protected Audience, cada conta tem uma conta Limite de orçamento diário de gastos da API Protected Audience. 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, o ela 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 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 JSON: 0), mesmo que a solicitação de lance seja qualificada para um leilão da Protected Audience.

Feedback em tempo real e lance mínimo para vencer

Bidders que optaram por receber feedback em tempo real receberá comentários para compradores de grupos de interesse solicitados para serem incluídos em um leilão com Protected Audience no dispositivo. Cada comprador de grupo de interesse que um proponente especifica em uma resposta de lance vai receber um objeto de feedback, independentemente de quantos lances o comprador de 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 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 vencer o leilão geral.
  • O lance mínimo para vencer do comprador do grupo de interesse para superar o lance mais bem classificado 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 definido em interest-group-buyer-status-codes.txt.

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

Notificação de feedback de lance

O Chrome oferece um recurso de depuração temporário API para a API Protected Audience, que permite ao Ad Manager enviar e-mails em tempo real notificações de depuração de servidor para servidor que contêm feedback sobre um Lance de público-alvo. Essa notificação incluirá os motivos pelos quais os lances podem ter sido do leilão da API Protected Audience no navegador, 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 será usada para enviar notificações de feedback de lance para depuração de público-alvo protegido. Isso o URL estático será buscado nos servidores do Google, e as macros selecionadas serão substituídas após a conclusão do leilão da Protected Audience. As macros a seguir são suportado:

  • %%GOOGLE_QUERY_ID%%: essa macro é substituída pelo ID da consulta do Google enviado na solicitação de lance contextual com a API Protected Audience. Em o protocolo OpenRTB que é especificado BidRequest.ext.google_query_id, enquanto o RTB do Google foi descontinuado 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.

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

TURTLEDOVE no nível do produto

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

Integração

Confira 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 envie um arquivo um tíquete usando a Ajuda do Authorized Buyers de Ajuda.
  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 de 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 em renderUrl para o contêiner do anúncio componente (também chamado de renderUrl de nível superior) para distinguir o renderUrls de nível superior durante a revisão do criativo.
  • Renderizar um criativo representativo quando o contêiner do anúncio do componente for buscada para uma revisão de criativo pelo Google. Para entender quando um renderização de anúncios representativa seja retornada, consulte a É 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 associar o navegador do usuário ao grupo de interesse.
  • Implemente generateBid() e reportWin().
  • Selecione as origens de proprietários de grupos de interesse e adicione-as à conta de comprador autorizado.
    • As origens do proprietário do grupo de interesse devem corresponder às origens em que o As funções generateBid() estão hospedadas.
    • Entre em contato com o gerente de contas ou envie um tíquete usando a Central de Ajuda do Comprador Autorizado para concluir esta etapa.
  • Configurar a pré-segmentação para inventário relevante para a API Protected Audience testes.
  • Envie criativos para revisão e aprovação na guia Criativos API.
  • (Opcional) Configure os endpoints dos indicadores de lances confiáveis.
  • (Opcional) Configure uma página de teste do anunciante que permita aos engenheiros do Google adicionar seu navegador para os grupos de interesse pertencentes ao grupo de interesse origem. Isso nos permite acionar manualmente os leilões com Protected Audience.
  • (Opcional) Ative o feedback em tempo real na sua conta para receber feedback dos compradores de grupos de interesse que solicitaram a 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 para receber uma notificação de servidor para servidor que dá o lance da API Protected Audience. feedback sobre o status de um lance de uma API no dispositivo leilão para ajudar na depuração de problemas inesperados. Consulte a notificação de feedback de lances para mais detalhes.

Fases de teste

Fase 1: teste manual

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

  1. Use o Chrome 101 ou mais recente.
  2. Ative a API Privacy Sandbox e o frame fechado usando chrome://flags/#privacy-sandbox-ads-apis e chrome://flags/#enable-fenced-frames. Saiba mais em Teste a privacidade sandbox.
  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 à conta do bidder grupo de interesse.

  5. Use a seguinte página do editor de teste fornecida pelo Google para acionar uma API Leilão de público-alvo:

    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, pois poderá competir com lances convencionais do lado do servidor. O Google também oferece uma página dedicada de editores de teste para cada parceiro, em que apenas o parceiro 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, o bidder vencedor recebe um ping de retorno de reportWin().
    3. O console da página de teste do editor 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 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: experimento sem renderização (opcional)

Depois que o Google e o parceiro verificarem manualmente que pode participam do leilão da Protected Audience, o Google permite que o parceiro para a próxima etapa dos testes.

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 precisarão mais acionar manualmente leilão com Protected Audience. O resultado do leilão da API Protected Audience não renderizado. Isso nos permite testar a integração em grande escala.

Entre em contato com seu gerente de contas ou abra um tíquete por meio da plataforma Central de Ajuda. O Google vai ativar a conta para essa etapa.

Etapa 3: experimento de renderização

Depois que o Google e o parceiro tiverem verificado 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 vencedor 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 Buyers quando estiver tudo pronto. O Google vai ativar a conta para esta etapa.

Outros recursos

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

Carregamento em paralelo

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

A paralelização reduz a latência, mas afeta a qualificação do comprador do grupo de interesse e o suporte a 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 de participar de leilões paralelos, mas precisa conhecer como o carregamento em paralelo pode afetar a qualificação deles em leilões no dispositivo. Os IDs de grupo de experimentos para experimentos coordenados ainda não são compatíveis com 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 da resposta do anúncio contextual ser retornada. Para iniciar o processo de autorização chamadas de servidor, navigator.runAdAuction requer que o O parâmetro interestGroupBuyers deve ser transmitido como um valor, enquanto os outros parâmetros de leilão aceitam JavaScript. Promessas que podem ser resolvidas após a resposta do anúncio contextual. Como interestGroupBuyers é transmitido antes da resposta do anúncio contextual, a resposta do anúncio contextual (incluindo respostas de lance) não pode ser usada para escolher quais compradores participam do leilão paralelo para a solicitação. Em vez disso, a tag do editor do Google armazena em cache, no navegador do usuário, o parâmetro interestGroupBuyers de execuções navigator.runAdAuction anteriores no mesmo domínio.

O carregamento em paralelo tem várias considerações importantes:

  1. indicadores de leilão que não são necessários para solicitações do servidor confiável do comprador como perBuyerSignals, podem continuar a ser especificadas nas respostas de lances de RTB da mesma forma que nos leilões sem paralelismo. Depois que as promessas para esses indicadores são resolvidas, as etapas restantes o leilão no dispositivo será concluído da mesma forma que o leilão não paralelo de leilão aberto.

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

  3. Se pelo menos um comprador de qualquer proponente estiver armazenado 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ída 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 atual no dispositivo. Isso é indicado por uma solicitação com parallelized=True que não tem uma Entrada ParallelAuctionBuyer para uma determinada origem de comprador do grupo de interesse. No entanto, os bidders que indicarem interesse incluindo anúncios válidos e InterestGroupBuyer na resposta do lance terá o comprador do grupo de interesse correspondente de origem adicionadas ao cache, que poderão ser usadas futuras solicitações em paralelo do mesmo navegador e domínio. 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 do comprador em cache (incluídas no parâmetro interestGroupBuyers do leilão paralelo) em que um bidder não indica a intenção de participar da resposta de lance podem receber uma chamada de servidor confiável do comprador, mas não vão participar do leilão paralelo.