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 bidders podem fazer o seguinte ao testar a API Protected Audience:

  • 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 — para exemplo: GitHub.
  • Prepare-se para oferecer suporte à publicidade personalizada usando a API sem e 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 API Protected Audience para o Authorized Buyers parceiros:

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 API Protected Audience joinAdInterestGroup(). Essa chamada solicita que o navegador adicione o usuário a um grupo de interesse.
  4. O usuário final acessa a página da Web de um editor. As solicitações do navegador do usuário à 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 a um servidor do Google.
  6. O Google envia solicitações de lance contextuais aos bidders participantes. Consulte a Seção de alterações da 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 especifica interest_group_bidding, o Google não incluir a origem do bidder em interestGroupBuyers no leilão configuraçã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 leilão no navegador. Confira as 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 os 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 (enviadas pelo interest_group_bidding.per_buyer_signals), informações contextuais sobre o vencedor e configurações de 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 os compradores que já devolveram 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 API Protected Configuração do leilão de público-alvo.
  12. Se os grupos de interesse de um determinado proponente especificaram o trustedBiddingSignalsUrl, o navegador faz uma solicitação ao arquivo trustedBiddingSignalsUrl para buscar indicadores em tempo real para cada grupo. 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 a o per_buyer_signals fornecido pelo bidder e os lances confiáveis para o grupo de interesse específico.
  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. A o lance contextual com melhor classificação 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 disponibilização

Antes da veiculação do anúncio

Revisão de criativo

Os criativos precisam ser revisados e aprovados pelo Google antes de serem veiculados Leilões no navegador da API Protected Audience. É 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 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 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 de 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 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>
Validade 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 um para o gasto do grupo de interesse, especifique um buyerAndSellerReportingId para ao seu anúncio quando você adicionar o dispositivo do usuário ao grupo de interesse. Ver mais mais detalhes em Protected Audience Documentação.

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

Alterações nas solicitações de lance

A seguir estão as versões iniciais dos protocolos compatíveis para uso no experimento:

Indicar suporte ao leilão do 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 oportunidades de impressão que serão compatíveis com o leilão do grupo de interesse no navegador da API Protected Audience e aqueles que aceitar apenas o leilão tradicional de troca do lado do servidor; A 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 à API Protected Audience, em que um leilão contextual é realizado no nos servidores da troca e nos lances do grupo de interesse, e o leilão final é realizado no navegador
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:

  • 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 tamanhos da solicitação contextual (Adslot.widtheAdslot.height ou no OpenRTB: BidRequest.imp.banner.format).

A solicitação contextual pode ter vários tamanhos. O leilão no dispositivo vencedor deve preencher somente um único tamanho fixo de espaço.

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 da situação fase de integração (consulte não renderização experimento). O render_interest_group_ads na solicitação de lance indica se o anúncio vencedor serão processados.

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

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 google_user_id (BidRequest.user.id no OpenRTB) e Campos hosted_match_data (BidRequest.user.buyerid no OpenRTB). A presença desses identificadores em solicitações de lance vão continuar políticas de privacidade. Recomendamos que você não dependa de identificadores baseados em cookies para para fins de segmentação e lance durante os testes, para se preparar melhor para campanhas eficientes comprar quando cookies de terceiros não estiverem mais disponíveis.

O Google também pode realizar experimentos de pequena escala com identificadores baseados em cookies editados de solicitações de lance no escopo do teste da API Protected Audience. Isso é avaliar o possível impacto da descontinuação dos 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 a pequenas parcelas de tráfego de um marcador individual, o Google nem sempre inclui o rótulo em contextos com limitação de privacidade.

Estes são os campos em que você pode ver o marcador:

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

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 no resposta de lance contextual:

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

Você precisa fornecer uma resposta de lance contextual. A resposta não é necessária para incluir um lance contextual. O objeto InterestGroupBidding precisa conter o origin do proprietário do grupo de interesse, que deve corresponder a uma das origens configurado pelo bidder para a conta dele. 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 (perBuyerSignals)

Você pode incluir os sinais de um comprador na resposta de lance contextual, que o Google é propagado como um objeto JSON para a função de lances no dispositivo por meio do argumento perBuyerSignals. Pode ser incluído na resposta do lance com o parâmetro campos a seguir, dependendo do protocolo:

  • RTB do Google: BidResponse.interest_group_bidding.per_buyer_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
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, a renderização podem ser usados para personalizar a aparência 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 sinais de renderização de um comprador serializados como uma string segura para URL no a resposta de lance contextual, que o Google substituirá na campanha de interesse vencedor URL de renderização do grupo criando o Macro ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

Os sinais de renderização podem ser especificados na resposta do lance com o seguinte , dependendo do protocolo:

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

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 vai mais participar do programa leilão de público-alvo se os indicadores não forem seguros para URL e os sufixos de macro não forem únicos; ou mais de três conjuntos de indicadores são fornecidos.

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

Na seção Protected Audience proposta, o cálculo do lance e o leilão final será realizado localmente no dispositivo. Isso pode criar vetores de abuso em potencial que podem afetar a integridade do leilão final resultados, como o preço do lance vencedor.

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

Na resposta de lance, você pode especificar o valor de lance máximo esperado no campo 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 bidder precisa selecionar um ID de faturamento para atribuir interesse as impressões do lance de grupo 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 de faturamento selecionado precisa ser um ID de faturamento 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 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 fornece os seguintes parâmetros:

  • auctionSignals: vazio
  • perBuyerSignals: um objeto JavaScript dos mesmos indicadores fornecidos pelo 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. Deve estar em unidades de CPM (não micros).
  • render: o URL renderizado para exibir 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};
}

Confira as especificações da API Protected Audience no dispositivo Lances para conferir uma explicação sobre a função generateBid().

Moeda do lance

Os lances de leilão no navegador são colocados em unidades de CPM na 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 do 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 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 renderizem declarações de transparência no anúncio. Quando a opção "Pedir aos compradores para exibir somente anúncios com DSA informações de transparência do meu site ou app no EEE" é ativado por um editores, os compradores do grupo de interesse podem determinar quais oportunidades serão necessário para exibir a transparência para o comprador, observando os seguintes campos em solicitações de lance recebidas: BidRequest.dsa.dsa_support e BidRequest.dsa.publisher_rendering_support para o protocolo do Google Authorized Buyers e BidRequest.regs.dsa.required e BidRequest.dsa.pubrender para o protocolo OpenRTB.

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.interest_group_bidding.interest_group_buyers.dsa_buyer_render para o protocolo do Google Authorized Buyers ou BidResponse.ext.igbid.igbuyer.dsaadrenderpara o protocolo OpenRTB. 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 espaços reservados, chamados 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 e a distribuição dos valores dos dados. 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 transparência e String de consentimento (TC) associada à solicitação. Se a seção Transparência e A string de consentimento (TC) está em branco ou é inválida. Essa macro não se expande.

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. fornecedor. 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} deve ocorrer apenas uma vez em o renderUrl.
${ADDL_CONSENT} Expande-se na seção Outras String de consentimento associada à solicitação.
${AD_WIDTH}, ${AD_HEIGHT) Essas macros inserem a largura e a altura do espaço do 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. Você pode incluir um _OPTIONAL_SUFFIX para fornecer até três tipos para renderizar valores dos indicadores.

Contagem de impressões

Durante o teste da API Protected Audience com parceiros de RTB, o Google contará impressões quando o navegador chama a função reportResult() e em seguida, busca 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 os leilões no navegador podem ser diferentes do evento usado para a contagem impressões pelos parceiros compradores de RTB, as contagens de impressões poderão ser diferentes.

Uma das metas 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 a participar de leilões contextuais do lado do servidor após atingindo o limite da API Protected Audience. Por exemplo, uma conta de bidder que atinge o limite de Protected Audience pode receber uma solicitação de lance com auction_environment = SERVER_SIDE_AUCTION (OpenRTB: 0), mesmo que a solicitação de lance esteja qualificada para um leilão com 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 bidder especificar em uma resposta de lance receberá um objeto de feedback, independentemente de como muitos lances que o comprador do grupo de interesse faz no leilão da Protected Audience. A as informações a seguir estarão disponíveis no feedback do comprador do grupo de interesse objeto:

  • 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 a ser vencido pelo comprador do grupo de interesse para ganhar o no leilão geral.
  • O lance mínimo a ser vencido para o comprador do grupo de interesse a fim de superar o o lance com a melhor classificação do componente do servidor no 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%%: esta macro é substituída pelo ID da consulta do Google. (BidRequest.google_query_id no protocolo do Authorized Buyers e BidRequest.ext.google_query_id no protocolo OpenRTB) que foi enviado no dia Solicitação de lance contextual ativada para a 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 em a 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 status do criativo de código aberto.

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 dependente do API ForDebuggingOnly temporária.

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 PLTD, já que são necessários recursos e configurações extras.

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. Após a configuração da conta, o Google e o parceiro podem verificar os integração por meio das etapas em Estágios 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

  • Configurar um endpoint de solicitação de lance que vai preencher a API Protected Audience campos relacionados na resposta de lance contextual, por exemplo, interest_group_bidding:
  • Implemente a inclusão de tag nas páginas do anunciante para fazer parte do navegador do usuário e o grupo de interesse.
  • Implemente generateBid() e reportWin().
  • Selecionar as origens do proprietário do grupo de interesse e adicioná-las ao Authorized Buyers do Compute Engine.
    • 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 crie um tíquete usando o painel de controle Central de Ajuda do comprador para para concluir essa 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 sobre que compradores de grupos de interesse solicitaram inclusão em uma API Protected Audience leilão.
  • (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. Veja o feedback sobre lances para mais detalhes.

Etapas de teste

Etapa 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. Ativar 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 Teste a privacidade sandbox.
  3. Enviar um criativo para aprovação usando o recurso Lances em tempo real API.
  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 ao editor de teste para cada parceiro, podem participar do leilão. Pode ser mais fácil ganhar de maneira confiável no navegador em uma página específica de 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 será true se o lance for 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 status do criativo de código aberto.

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

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 em tempo real para executar a API Protected Audience leilões. 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 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 esta etapa.

Etapa 3: experimento de renderização

Depois que o Google e o parceiro verificarem os leilões com Protected Audience em grande escala sem renderização, o Google pode permitir que o parceiro renderize o arquivo Anúncio que conquista o público-alvo. O Google tem uma pequena quantidade de tráfego Os leilões por público-alvo estão qualificados para exibição, e os anúncios vencedores do grupo de interesse renderizado. Bidders participantes os lances no navegador concorrem com os lances lances.

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 esta etapa.

Outros recursos

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

Carregamento em paralelo

O carregamento em paralelo é uma otimização que diminui a latência de ponta a ponta do leilão em iniciar a solicitação de anúncio contextual em paralelo com as solicitações para o servidores confiáveis do comprador especificado em trustedBiddingSignalsUrl.

O carregamento em paralelo reduz a latência, mas afeta o grupo de interesse a qualificação e suporte do comprador experimentos coordenados. O carregamento em paralelo se aplica a todos os bidders que participam do do leilão do grupo 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 dos grupos para experimentos coordenados ainda não são compatíveis 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. a 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 usado para escolher quais compradores participam do leilão paralelo para a solicitação em questão. Em vez disso, a tag do editor do Google armazena em cache, no navegador do usuário, o parâmetro interestGroupBuyers da regra navigator.runAdAuction execuções 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 o carregamento em paralelo depende do armazenamento em cache da lista de compradores do grupo de interesse, O Google nem sempre realiza um leilão paralelo, já que o cache de carregamento em paralelo 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 bidder for armazenado em cache para o editor atual domínio, o Google vai executar uma que será indicado na solicitação de lance:

    • Protocolo 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 registrado para um determinado bidder que foi incluídos no leilão paralelo terão um Entrada ParallelAuctionBuyer:

    • Protocolo 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 realizado, mas não houver uma origem de comprador específica no o cache, o comprador em questão não poderá ser adicionado ao dispositivo atual leilão. 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, e essas origens estarão qualificadas para 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 RTB do Google: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: BidResponse.ext.igbid.igbuyer

  6. Origens dos compradores em cache (incluídas nos lances do leilão paralelo interestGroupBuyers) para os quais um bidder não indica a intenção para participar de sua resposta de lance pode receber uma chamada de servidor confiável do comprador mas não participam do leilão paralelo.