Guia para desenvolvedores da API FLEDGE

Qual é o público deste artigo?

Esta postagem é uma referência técnica à iteração atual da API Protected Audience experimental.

O que é a API Protected Audience?

A API Protected Audience é uma proposta do Sandbox de privacidade para atender a casos de uso de remarketing e de públicos-alvo personalizados, criada para que ela não possa ser usada por terceiros para rastrear o comportamento de navegação do usuário em sites. A API permite leilões no dispositivo pelo navegador para escolher anúncios relevantes para sites que o usuário já visitou.

A API Protected Audience é o primeiro experimento a ser implementado no Chromium na família de propostas TURTLEDOVE.

O diagrama abaixo fornece uma visão geral do ciclo de vida do FLEDGE:

Ilustração oferecendo uma visão geral de cada estágio do ciclo de vida do FLEDGE
Ciclo de vida do FLEDGE.

Como posso testar a API Protected Audience?

Demonstração da API Protected Audience

Um tutorial de uma implantação básica da API Protected Audience nos sites de anunciantes e editores está disponível em secure-audience-demo.web.app.

O vídeo de demonstração explica como o código de demonstração funciona e mostra como usar o Chrome DevTools para depuração da API Protected Audience.

Participe de um teste de origem da API Protected Audience

Um teste de origem de relevância e medição do Sandbox de privacidade foi disponibilizado no Chrome Beta 101.0.4951.26 e versões mais recentes em computadores para as APIs Protected Audience, Topics e Attribution Reporting.

Para participar, registre-se para receber um token de teste de origem.

Depois de se inscrever no teste, é possível testar a API Protected Audience JavaScript nas páginas que fornecem um token de teste válido. Por exemplo, para pedir que o navegador participe de um ou mais grupos de interesse e, em seguida, faça um leilão de anúncios para selecionar e exibir um anúncio.

A demonstração da Protected Audience oferece um exemplo básico de uma implantação completa da Protected Audience.

Forneça um token de teste para cada página em que você quer executar o código da API Protected Audience:

  • Como uma metatag em <head>:

    <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">

  • Como um cabeçalho HTTP:

    Origin-Trial: TOKEN_GOES_HERE

  • Ao fornecer um token de maneira programática:

    const otMeta = document.createElement('meta');
    otMeta.httpEquiv = 'origin-trial';
    otMeta.content = 'TOKEN_GOES_HERE';
    document.head.append(otMeta);
    

Um iframe que executa o código da API Protected Audience, como uma chamada navigator.joinAdInterestGroup() de um proprietário de grupo de interesse, precisa fornecer um token que corresponda à origem dele.

Detalhes propostos de teste de origem do primeiro público protegido fornecem mais detalhes sobre as metas do primeiro teste e explica quais recursos são compatíveis.

Testar esta API

Você pode testar a API Protected Audience para um único usuário no Chrome Beta 101.0.4951.26 e versões mais recentes no computador:

  • Ativando todas as APIs de privacidade de anúncios em chrome://settings/adPrivacy
  • Definindo sinalizações na linha de comando.

Renderizar anúncios em iframes ou frames delimitados

Os anúncios podem ser renderizados em um <iframe> ou um <fencedframe>, dependendo das sinalizações definidas.

Para usar <fencedframe> na renderização de anúncios:

--enable-features=InterestGroupStorage,AdInterestGroupAPI,Fledge,FencedFrames

Para usar <iframe> na renderização de anúncios:

--enable-features=InterestGroupStorage,AdInterestGroupAPI,Fledge,AllowURNsInIframes --disable-features=FencedFrames

Inclua a flag BiddingAndScoringDebugReportingAPI para ativar os métodos temporários de geração de relatórios de perda/vitória de depuração.

Executar o Chromium com sinalizações explica como definir sinalizações ao executar o Chrome e outros navegadores baseados no Chromium na linha de comando. A lista completa de sinalizações da API Protected Audience está disponível na Pesquisa de código do Chromium.

Quais recursos são compatíveis com a versão mais recente do Chrome?

A API Protected Audience está sendo disponibilizada por trás das sinalizações de recursos no Chromium como um primeiro experimento para testar os seguintes recursos da proposta da Protected Audience:

  • Grupos de interesse: armazenados pelo navegador, com metadados associados para configurar os lances e a renderização de anúncios.
  • Lances no dispositivo por compradores (DSP ou anunciante): com base em grupos de interesse armazenados e indicadores do vendedor.
  • Seleção de anúncios no dispositivo pelo vendedor (SSP ou editor): com base nos lances de leilão e nos metadados dos compradores.
  • Renderização de anúncios em uma versão temporariamente reduzida de Fenced Frames: com acesso à rede e geração de registros permitidos para a renderização de anúncios.

A explicação da API fornece mais detalhes sobre o suporte e as restrições de recursos.

Permissões do grupo de interesse

O padrão na implementação atual da API Protected Audience é permitir chamar joinAdInterestGroup() de qualquer lugar da página, mesmo de iframes de vários domínios. No futuro, quando os proprietários de sites tiverem tempo de ajustar as políticas de permissões de iframe entre domínios, o plano será proibir chamadas de iframes de vários domínios, conforme descrito na explicação.

Serviço de chave-valor

Como parte de um leilão de anúncios da API Protected Audience, o navegador pode acessar um serviço de chave-valor que retorna pares de chave-valor simples para fornecer informações a um comprador de anúncios, como orçamento restante de campanha. A proposta da Protected Audience exige que esse servidor "não execute registros no nível do evento e não tenha outros efeitos colaterais com base nessas solicitações".

O código de serviço de chave-valor da API Protected Audience agora está disponível em um repositório do GitHub do Sandbox de privacidade (link em inglês). Esse serviço pode ser usado por desenvolvedores do Chrome e do Android. Confira o anúncio no blog (em inglês) para saber mais sobre a atualização do status. Saiba mais sobre o serviço de chave-valor da API Protected Audience na explicação da API e na explicação do modelo de confiança.

Para o teste inicial, é usado o modelo "traga seu próprio servidor". A longo prazo, as adtechs vão precisar usar os serviços de chave-valor de público-alvo protegido de código aberto em execução em ambientes de execução confiável para recuperar dados em tempo real.

Para garantir que o ecossistema tenha tempo suficiente para testes, não esperamos exigir o uso dos serviços de chave-valor de código aberto ou TEEs até algum tempo após a descontinuação dos cookies de terceiros. Antes dessa transição, vamos enviar avisos para os desenvolvedores começarem os testes e a adoção.

Detectar suporte a recursos

Antes de usar a API, verifique se ela é compatível com o navegador e está disponível no documento:

'joinAdInterestGroup' in navigator &&
  document.featurePolicy.allowsFeature('join-ad-interest-group') &&
  document.featurePolicy.allowsFeature('run-ad-auction') ?
  console.log('navigator.joinAdInterestGroup() is supported on this page') :
  console.log('navigator.joinAdInterestGroup() is not supported on this page');

Como posso desativar a API Protected Audience?

É possível bloquear o acesso à API Protected Audience como proprietário do site ou como usuário individual.

Como os sites podem controlar o acesso?

A API Protected Audience vai exigir que os sites definam uma Política de permissões para que a funcionalidade dela fique disponível. Isso garante que terceiros arbitrários não possam usar a API sem o conhecimento do site. No entanto, para facilitar os testes durante o primeiro teste de origem, esse requisito é renunciado por padrão. Os sites que quiserem desativar explicitamente a funcionalidade da API Protected Audience durante o período de teste podem usar a política de permissões relevante para bloquear o acesso.

Há duas políticas de permissões da API Protected Audience que podem ser definidas de forma independente:

  • O join-ad-interest-group ativa/desativa a funcionalidade para adicionar um navegador aos grupos de interesse.
  • O run-ad-auction ativa/desativa a funcionalidade para fazer um leilão no dispositivo.

O acesso às APIs Protected Audience pode ser desativado completamente em contextos próprios especificando a seguinte política de permissões em um cabeçalho de resposta HTTP:

Permissions-Policy: join-ad-interest-group=(), run-ad-auction=()

Para desativar o uso das APIs em um iframe, adicione o seguinte atributo allow a um elemento de iframe:

<iframe src="https://example.com" allow="join-ad-interest-group 'none'; run-ad-auction 'none'"></iframe>

A seção Permissões propostas de permissão de teste de origem do primeiro público-alvo protegido oferece mais detalhes.

Desativação do usuário

Um usuário pode bloquear o acesso à API Protected Audience e a outros recursos do Sandbox de privacidade usando qualquer um dos mecanismos abaixo:

  • Desative os testes do Sandbox de privacidade nas configurações do Chrome: Configurações > Segurança e privacidade > Sandbox de privacidade. Ele também pode ser acessado em chrome://settings/adPrivacy.
  • Desative cookies de terceiros nas configurações do Chrome: Configurações > Segurança e privacidade.
  • Defina Cookies e outros dados do site como "Bloquear cookies de terceiros" ou "Bloquear todos os cookies" em chrome://settings/cookies.
  • Usar o modo de navegação anônima.

A explicação da API Protected Audience oferece mais detalhes sobre os elementos de design da API e descreve como ela busca atender às metas de privacidade.

Depurar worklets da API Protected Audience

No Chrome Canary 98.0.4718.0, é possível depurar os worklets da Protected Audience no Chrome DevTools.

A primeira etapa é definir pontos de interrupção por meio de uma nova categoria no painel Pontos de interrupção do listener de eventos no painel Origens.

Captura de tela do
   DevTools no Chrome Canary, destacando o painel Event Listener Breakpoints no painel Values.
   O início da fase de lances do bidder está selecionado em &quot;Objeto de leilão de anúncios&quot;.

Quando um ponto de interrupção é acionado, a execução é pausada antes da primeira instrução no nível superior do script do worklet. É possível usar pontos de interrupção regulares ou comandos de etapa para chegar à própria função de lances/pontuação/geração de relatórios.

Os scripts de worklet ativos também vão aparecer no painel Threads.

Captura de tela do
DevTools no Chrome Canary, destacando o painel &quot;Threads&quot; no painel &quot;Sources&quot;, mostrando o script
de worklet atual que foi pausado.

Como alguns worklets podem ser executados em paralelo, várias linhas de execução podem ficar no estado "pausada". Você pode usar a lista de linhas de execução para alternar entre elas e retomá-las ou inspecioná-las mais de perto, conforme apropriado.

Observar eventos da API Protected Audience

No painel Application do Chrome DevTools, é possível observar os eventos de leilão e o grupo de interesse da API Protected Audience.

Se você acessar o site de compras de demonstração da API Protected Audience em um navegador com a API Protected Audience ativada, o DevTools vai mostrar informações sobre o evento join.

O
   painel DevTools Application no Chrome Canary, mostrando informações sobre um evento de participação no grupo de interesse da
   Protected Audience.

Agora, se você acessar o site do editor de demonstração da API Protected Audience em um navegador com a API Protected Audience ativada, o DevTools vai mostrar informações sobre os eventos bid e win.

O
   painel DevTools Application no Chrome Canary, mostrando informações sobre lances de leilão da Protected Audience e
   eventos vencedores.

Como a API Protected Audience funciona?

Neste exemplo, um usuário navega no site de uma montadora de bicicletas personalizada, depois visita um site de notícias e recebe um anúncio de uma nova bicicleta desse fabricante.

1. Um usuário visita o site de um anunciante

Ilustração que mostra
  uma pessoa acessando o site de um fabricante de bicicletas personalizado usando um navegador no laptop.

Imagine que um usuário acessa o site de um fabricante de bicicletas personalizada (o anunciante neste exemplo) e passa algum tempo na página do produto de uma bicicleta de aço artesanal. Isso dá ao fabricante de bicicletas uma oportunidade de remarketing.

2. O navegador do usuário precisa adicionar um grupo de interesse

Ilustração que mostra uma pessoa visualizando um site em um navegador no laptop. O código JavaScript joinAd InterestGroup() está em execução no navegador.

Seção de explicação:Os navegadores registram grupos de interesse

A plataforma de demanda (DSP) do anunciante ou o próprio anunciante chama navigator.joinAdInterestGroup() para pedir que o navegador adicione um grupo de interesse à lista de grupos de que o navegador faz parte. Neste exemplo, o grupo é chamado custom-bikes e o proprietário é dsp.example. O proprietário do grupo de interesse (neste caso, a DSP) será um comprador no leilão de anúncios descrito na etapa 4. A associação ao grupo de interesse é armazenada pelo navegador, no dispositivo do usuário e não é compartilhada com o fornecedor do navegador nem com qualquer outra pessoa.

O app joinAdInterestGroup() precisa da permissão de:

  • o site que está sendo visitado;
  • O proprietário do grupo de interesse

Por exemplo, não é possível que malicious.example chame joinAdInterestGroup() com dsp.example como proprietário sem a permissão de dsp.example.

Permissão do site que está sendo visitado

Mesma origem: por padrão, a permissão é concedida implicitamente para chamadas joinAdInterestGroup() da mesma origem do site que está sendo visitado, ou seja, da mesma origem que o frame de nível superior da página atual. Os sites podem usar uma diretiva join-ad-interest-group do cabeçalho da política de permissões da API Protected Audience para desativar chamadas joinAdInterestGroup().

Origem cruzada: chamar joinAdInterestGroup() de origens diferentes da página atual só vai funcionar se o site que está sendo visitado tiver definido uma política de permissões que permita chamadas para joinAdInterestGroup() de iframes de origem cruzada.

Permissão do proprietário do grupo de interesse

A permissão do proprietário do grupo de interesse é concedida implicitamente ao chamar joinAdInterestGroup() em um iframe com a mesma origem do proprietário do grupo de interesse. Por exemplo, um iframe dsp.example pode chamar joinAdInterestGroup() para grupos de interesse de dsp.example.

A proposta é que joinAdInterestGroup() possa ser executado em uma página ou iframe no domínio do proprietário ou delegado a outros domínios fornecidos usando uma lista em um URL .well-known.

Como usar o Navigator.joinAdInterestGroup()

Aqui está um exemplo de como a API pode ser usada:

const interestGroup = {
  owner: 'https://dsp.example',
  name: 'custom-bikes',
  biddingLogicUrl: ...,
  biddingWasmHelperUrl: ...,
  dailyUpdateUrl: ...,
  trustedBiddingSignalsUrl: ...,
  trustedBiddingSignalsKeys: ['key1', 'key2'],
  userBiddingSignals: {...},
  ads: [bikeAd1, bikeAd2, bikeAd3],
  adComponents: [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2],
};

navigator.joinAdInterestGroup(interestGroup, 7 * kSecsPerDay);

O objeto interestGroup transmitido para a função não pode ter mais de 50 kiB de tamanho. Caso contrário, a chamada falhará. O segundo parâmetro especifica a duração do grupo de interesse, com um limite de 30 dias. Chamadas sucessivas substituem os valores armazenados anteriormente.

Propriedades do grupo de interesse

Propriedade Obrigatório Exemplo Papel
owner Obrigatório 'https://dsp.example' Origem do proprietário do grupo de interesse.
name Obrigatório 'custom-bikes' Nome do grupo de interesse.
biddingLogicUrl** Opcional* 'https://dsp.example/bid/custom-bikes/bid.js' URL para lances em JavaScript executado no worklet.
biddingWasmHelperUrl** Opcional* 'https://dsp.example/bid/custom-bikes/bid.wasm' URL do código do WebAssembly gerado por biddingLogicUrl.
dailyUpdateUrl** Opcional 'https://dsp.example/bid/custom-bikes/update' URL que retorna JSON para atualizar os atributos do grupo de interesse. Consulte Atualizar o grupo de interesse.
trustedBiddingSignalsUrl** Opcional 'https://dsp.example/trusted/bidding-signals' URL de base para solicitações de chave-valor ao servidor confiável do bidder.
trustedBiddingSignalsKeys Opcional ['key1', 'key2' ...] Chaves para solicitações ao servidor confiável de chave-valor.
userBiddingSignals Opcional {...} Metadados adicionais que o proprietário pode usar durante os lances.
ads Opcional* [bikeAd1, bikeAd2, bikeAd3] Anúncios que podem ser renderizados para este grupo de interesse.
adComponents Opcional [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2] Componentes de anúncios compostos por várias partes.

* Todas as propriedades são opcionais, exceto owner e name. As propriedades biddingLogicUrl e ads são opcionais, mas obrigatórias para participar de um leilão. Pode haver casos de uso para criar um grupo de interesse sem essas propriedades. Por exemplo, um proprietário de grupo de interesse pode querer adicionar um navegador a um grupo de interesse de uma campanha que ainda não está em exibição ou para algum outro uso futuro, ou ele pode ter temporariamente sem orçamento de publicidade.

** Os URLs biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl e trustedBiddingSignalsUrl precisam ter a mesma origem que o proprietário. Os URLs ads e adComponents não têm essa restrição.

Atualizar os atributos do grupo de interesse

dailyUpdateUrl especifica um servidor da Web que retorna JSON que define as propriedades do grupo de interesse, correspondente ao objeto do grupo de interesse transmitido para navigator.joinAdInterestGroup(). Isso fornece um mecanismo para o proprietário do grupo atualizar periodicamente os atributos do grupo de interesse. Na implementação atual, os seguintes atributos podem ser alterados:

  • biddingLogicUrl
  • biddingWasmHelperUrl
  • trustedBiddingSignalsUrl
  • trustedBiddingSignalsKeys
  • ads
  • priority

Qualquer campo não especificado no JSON não será substituído (apenas os campos especificados no JSON serão atualizados), enquanto que chamar navigator.joinAdInterestGroup() substitui qualquer grupo de interesse existente.

As atualizações são feitas da melhor maneira possível e podem falhar nas seguintes condições:

  • Tempo limite da solicitação de rede (atualmente 30 segundos).
  • Outra falha de rede.
  • Falha na análise de JSON.

As atualizações também podem ser canceladas se muito tempo contíguo tiver sido gasto atualizando, embora isso não imponha nenhuma limitação de taxa para atualizações canceladas (restantes). As atualizações são limitadas por taxa a um máximo de uma por dia. As atualizações que falham devido a erros de rede são repetidas após uma hora, e as que falham devido à desconexão da Internet são repetidas imediatamente após a reconexão.

Atualizações manuais

As atualizações em grupos de interesse da origem do frame atual podem ser acionadas manualmente por navigator.updateAdInterestGroups(). A limitação de taxa impede que as atualizações aconteçam com muita frequência: chamadas repetidas para navigator.updateAdInterestGroups() não fazem nada até que o período de limitação de taxa (atualmente um dia) tenha passado. O limite de taxa será redefinido se navigator.joinAdInterestGroup() for chamado novamente para os mesmos grupos de interesse owner e name.

Atualizações automáticas

Todos os grupos de interesse carregados para um leilão são atualizados automaticamente após a conclusão dele e estão sujeitos às mesmas limitações de taxa das atualizações manuais. Para cada proprietário com pelo menos um grupo de interesse participando de um leilão, é como se navigator.updateAdInterestGroups() fosse chamado de um iframe com origem que corresponde a esse proprietário.

Especificar anúncios para um grupo de interesse

Os objetos ads e adComponents incluem um URL para um criativo de anúncio e, opcionalmente, metadados arbitrários que podem ser usados no momento do lance. Exemplo:

{
  renderUrl: 'https://cdn.example/.../bikeAd1.html',
  metadata: bikeAd1metadata // optional
}

Como os compradores dão lances?

O script em biddingLogicUrl fornecido por um proprietário de grupo de interesse precisa incluir uma função generateBid(). Quando um vendedor de espaço publicitário chama navigator.runAdAuction(), a função generatedBid() é chamada uma vez para cada um dos grupos de interesse de que o navegador participa, caso o proprietário do grupo de interesse seja convidado a dar um lance. Em outras palavras, generateBid() é chamado uma vez para cada anúncio candidato. O vendedor fornece uma propriedade decisionLogicUrl no parâmetro de configuração do leilão transmitido para navigator.runAdAuction(). O código nesse URL precisa incluir uma função scoreAd(), que é executada para cada bidder no leilão, para pontuar cada um dos lances retornados por generateBid().

O script em biddingLogicUrl fornecido por um comprador de espaço publicitário precisa incluir uma função generateBid(). Essa função é chamada uma vez para cada anúncio candidato. runAdAuction() verifica individualmente cada anúncio, com o lance e os metadados associados a ele, e atribui a ele uma pontuação numérica de desejabilidade.

generateBid(interestGroup, auctionSignals, perBuyerSignals,
    trustedBiddingSignals, browserSignals) {
  ...
  return {
    ad: adObject,
    bid: bidValue,
    render: renderUrl,
    adComponents: [adComponentRenderUrl1, ...]
   };
}

generateBid() usa os seguintes argumentos:

  • interestGroup
    O objeto transmitido para joinAdInterestGroup() pelo comprador do anúncio. O grupo de interesse pode ser atualizado em dailyUpdateUrl.

  • auctionSignals
    Uma propriedade do argumento da configuração do leilão transmitida para navigator.runAdAuction() pelo vendedor do espaço publicitário. Ela fornece informações sobre o contexto da página (como o tamanho do anúncio e o ID do editor), o tipo de leilão (primeiro ou segundo preço) e outros metadados.

  • perBuyerSignals
    Assim como em auctionSignals, uma propriedade do argumento de configuração do leilão transmitida a navigator.runAdAuction() pelo vendedor. Isso pode fornecer indicadores de contexto do servidor do comprador sobre a página, se o vendedor for uma SSP que executa uma chamada de lances em tempo real para os servidores do comprador e encaminha a resposta de volta, ou se a página do editor entrar em contato diretamente com o servidor do comprador. Nesse caso, o comprador pode conferir uma assinatura criptográfica desses sinais em generateBid() como proteção contra adulterações.

  • trustedBiddingSignals
    Um objeto com chaves que são trustedBiddingSignalsKeys do grupo de interesse e valores que são retornados na solicitação trustedBiddingSignals.

  • browserSignals
    Um objeto criado pelo navegador, que pode incluir informações sobre o contexto da página (como o hostname da página atual, que o vendedor poderia simular) e dados do próprio grupo de interesse (como um registro de quando o grupo venceu um leilão anteriormente, para permitir o limite de frequência no dispositivo).

O objeto browserSignals tem as seguintes propriedades:

{
  topWindowHostname: 'publisher.example',
  seller: 'https://ssp.example',
  joinCount: 3,
  bidCount: 17,
  prevWins: [[time1,ad1],[time2,ad2],...],
  wasmHelper: ... /* WebAssembly.Module object based on interest group's biddingWasmHelperUrl. */
  dataVersion: 1, /* Data-Version value from the buyer's Key/Value service response(s). */
}

Para calcular um valor de bid, o código em generateBid() pode usar as propriedades dos parâmetros da função. Exemplo:

function generateBid(interestGroup, auctionSignals, perBuyerSignals,
    trustedBiddingSignals, browserSignals) {
  return {
    ...
    bid: auctionSignals.is_above_the_fold ? perBuyerSignals.atf_value : perBuyerSignals.btf_value,
    ...
  }
}

generateBid() retorna um objeto com quatro propriedades:

  • ad
    Metadados arbitrários sobre o anúncio, como informações que o vendedor espera ter acesso a esse lance ou criativo de anúncio. O vendedor](/privacy-sandbox/resources/glossary#ssp) usa essas informações no leilão e no criativo de anúncio de decisão. O vendedor usa essas informações no leilão e na lógica de decisão.

  • bid
    Um lance numérico que vai entrar no leilão. O vendedor precisa estar em posição para comparar lances de diferentes compradores. Portanto, os lances precisam estar em alguma unidade escolhida pelo vendedor (por exemplo, "USD por mil"). Se o lance for zero ou negativo, esse grupo de interesse não participará do leilão do vendedor. Com esse mecanismo, o comprador pode implementar qualquer regra de anunciante que defina onde os anúncios podem ou não aparecer.

  • render
    Um URL ou uma lista de URLs que será usado para renderizar o criativo se o lance vencer o leilão. (Consulte Anúncios compostos de várias peças na explicação da API.) O valor precisa corresponder ao renderUrl de um dos anúncios definidos para o grupo de interesse.

  • adComponents
    Uma lista opcional de até 20 componentes para anúncios compostos por várias partes, extraída da propriedade adComponents do argumento do grupo de interesse transmitido para navigator.joinAdInterestGroup().

Pedir para um navegador sair de um grupo de interesse

O proprietário do grupo de interesse pode solicitar que um navegador seja removido de um grupo de interesse. Em outras palavras, o navegador é solicitado a remover o grupo de interesse da lista de membros.

navigator.leaveAdInterestGroup({
  owner: 'https://dsp.example',
  name: 'custom-bikes'
});

Se um usuário retornar ao site que solicitou ao navegador a adição de um grupo de interesse, o proprietário do grupo poderá chamar a função navigator.leaveAdInterestGroup() para solicitar que o navegador remova o grupo de interesse. O código de um anúncio também pode chamar essa função para seu grupo de interesse.

3. O usuário visita um site que vende espaço publicitário.

Ilustração que mostra uma pessoa acessando um site de notícias em um navegador no laptop. O site
  tem um espaço de anúncio vazio.

Mais tarde, o usuário visita um site que vende espaço publicitário, neste exemplo, um site de notícias. O site tem inventário de anúncios, que é vendido de maneira programática usando lances em tempo real.

4. Um leilão de anúncios é realizado no navegador

Ilustração que mostra uma pessoa acessando um site de notícias em um navegador no laptop. Um leilão
  de anúncios está sendo realizado usando a API Protected Audience.

Seção explicativa: os vendedores realizam leilões no dispositivo

É provável que o leilão de anúncios seja realizado pela SSP do editor ou pelo próprio editor. O objetivo do leilão é selecionar o anúncio mais apropriado para um único espaço de anúncio disponível na página atual. O leilão considera os grupos de interesse de que o navegador faz parte, além de dados dos compradores do espaço publicitário e dos vendedores dos serviços de chave-valor.

O vendedor do espaço publicitário faz uma solicitação ao navegador do usuário para iniciar um leilão de anúncios chamando navigator.runAdAuction().

Exemplo:

const auctionConfig = {
  seller: 'https://ssp.example',
  decisionLogicUrl: ...,
  trustedScoringSignalsUrl: ...,
  interestGroupBuyers: ['https://dsp.example', 'https://buyer2.example', ...],
  auctionSignals: {...},
  sellerSignals: {...},
  sellerTimeout: 100,
  perBuyerSignals: {
    'https://dsp.example': {...},
    'https://another-buyer.example': {...},
    ...
  },
  perBuyerTimeouts: {
    'https://dsp.example': 50,
    'https://another-buyer.example': 200,
    '*': 150,
    ...
  },
  componentAuctions: [
    {
      'seller': 'https://some-other-ssp.example',
      'decisionLogicUrl': ...,
      ...
    },
    ...
  ]
};

const auctionResultPromise = navigator.runAdAuction(auctionConfig);

runAdAuction() retorna uma promessa que é resolvida com um URN (urn:uuid:<something>) que representa o resultado do leilão de anúncios. Só pode ser decodificado pelo navegador quando transmitido para um frame isolado para renderização: a página do editor não pode inspecionar o anúncio vencedor.

O script decisionLogicUrl considera cada anúncio individual, junto com o lance e os metadados associados, um de cada vez, e atribui a ele uma pontuação de desejabilidade numérica.

auctionConfig propriedades

Propriedade Obrigatório Exemplo Papel
seller Obrigatório 'https://ssp.example' Origem do vendedor.
decisionLogicUrl Obrigatório 'https://ssp.example/auction-decision-logic.js' URL para JavaScript do worklet de leilão.
trustedScoringSignalsUrl Opcional 'https://ssp.example/scoring-signals' URL do servidor confiável do vendedor.
interestGroupBuyers* Obrigatório ['https://dsp.example', 'https://buyer2.example', ...] Origens de todos os proprietários de grupos de interesse que solicitaram lances no leilão.
auctionSignals Opcional {...} Informações do vendedor sobre o contexto da página, o tipo de leilão etc.
sellerSignals Opcional {...} Informações com base nas configurações do editor, como fazer uma solicitação de anúncio contextual etc.
sellerTimeout Opcional 100 Tempo de execução máximo (ms) do script scoreAd() do vendedor.
perBuyerSignals Opcional {'https://dsp.example': {...},
  'https://another-buyer.example': {...},
...}
Indicadores de contexto sobre a página de cada comprador específico do servidor.
perBuyerTimeouts Opcional 50 Tempo de execução máximo (ms) dos scripts generateBid() de um comprador específico.
componentAuctions Opcional [{'seller': 'https://www.some-other-ssp.com',
  'decisionLogicUrl': ..., ...},
  ...]
Configurações adicionais para leilões de componentes.

* O vendedor pode especificar interestGroupBuyers: '*' para permitir que todos os grupos de interesse deem lances. Os anúncios são então aceitos ou rejeitados com base em critérios diferentes da inclusão do proprietário do grupo de interesse. Por exemplo, o vendedor pode revisar criativos de anúncios para confirmar a conformidade com as políticas.

** additionalBids não é compatível com a implementação atual da API Protected Audience. Leia a seção Participantes do leilão na explicação da Protected Audience para saber mais.

Como os anúncios são selecionados?

O código em decisionLogicUrl (uma propriedade do objeto de configuração de leilão transmitido para runAdAuction()) precisa incluir uma função scoreAd(). Isso é executado uma vez para cada anúncio para determinar o atratividade.

scoreAd(adMetadata, bid, auctionConfig, trustedScoringSignals, browserSignals) {
  ...
  return desirabilityScoreForThisAd;
}

scoreAd() usa os seguintes argumentos:

  • adMetadata
    Metadados arbitrários fornecidos pelo comprador.
  • bid
    Um valor de lance numérico.
  • auctionConfig
    O objeto de configuração do leilão transmitido para navigator.runAdAuction().
  • trustedScoringSignals
    Valores recuperados no momento do leilão pelo servidor confiável do vendedor, que representam a opinião do vendedor sobre o anúncio.
  • browserSignals
    Um objeto criado pelo navegador, incluindo informações que o navegador conhece e que o script de leilão do vendedor pode querer verificar:
{
  topWindowHostname: 'publisher.example',
  interestGroupOwner: 'https://dsp.example',
  renderUrl: 'https://cdn.example/render',
  adComponents: ['https://cdn.com/ad-component-1', ...],
  biddingDurationMsec: 12,
  dataVersion: 1 /* Data-Version value from the seller's Key/Value service response. */
}

Antes do início de um leilão, ele encontra o melhor anúncio contextual para o espaço de anúncio disponível. Parte da lógica scoreAd() dela é rejeitar qualquer anúncio que não possa superar o vencedor contextual.

5. O vendedor e os compradores participantes recebem dados em tempo real do serviço de chave-valor.

Ilustração que mostra uma pessoa acessando um site de notícias em um navegador no laptop. Está ocorrendo um leilão
  de anúncios usando a API Protected Audience e um participante recebendo dados do serviço de chave-valor.

Seção de explicação:Como buscar dados em tempo real do serviço de chave-valor da API Protected Audience.

Durante um leilão de anúncios, o vendedor do espaço publicitário pode receber dados em tempo real sobre criativos de anúncios específicos fazendo uma solicitação para um serviço de chave-valor usando o argumento trustedScoringSignalsUrl da propriedade de configuração de leilão transmitido para navigator.runAdAuction(), além das chaves das propriedades renderUrl de todas as entradas nos campos ads e adComponents de todos os grupos de interesse no leilão.

Da mesma forma, um comprador de espaço publicitário pode solicitar dados em tempo real do serviço de chave-valor usando as propriedades trustedBiddingSignalsUrl e trustedBiddingSignalsKeys do argumento do grupo de interesse transmitido para navigator.joinAdInterestGroup().

Quando runAdAuction() é chamado, o navegador faz uma solicitação ao servidor confiável de cada comprador de anúncios. O URL da solicitação pode ser assim:

https://kv-service.example/getvalues?hostname=publisher.example&keys=key1,key2
  • O URL de base vem de trustedBiddingSignalsUrl.
  • O hostname é fornecido pelo navegador.
  • O valor keys é extraído de trustedBiddingSignalsKeys.

A resposta a essa solicitação é um objeto JSON que fornece valores para cada uma das chaves.

6. O anúncio vencedor é exibido

Ilustração que mostra uma pessoa acessando um site de notícias em um navegador no laptop. Um anúncio de uma bicicleta (20% de desconto) é exibido, com um cadeado na parte superior, mostrando que o anúncio é exibido em um quadro isolado.

Seção de explicação:Os navegadores renderizam o anúncio vencedor

Conforme descrito anteriormente: a promessa retornada por runAdAuction() é resolvida em um URN, que é transmitido para um frame cercado para renderização, e o site exibe o anúncio vencedor.

7. O resultado do leilão é informado

Seção explicativa: relatórios no nível do evento (por enquanto)

O vendedor informa o resultado

Seção de explicação:Relatórios do vendedor sobre renderização

O JavaScript do vendedor fornecido em decisionLogicUrl (que também forneceu scoreAd()) pode incluir uma função reportResult() para informar o resultado do leilão.

reportResult(auctionConfig, browserSignals) {
  ...
  return signalsForWinner;
}

Os argumentos passados para essa função são:

  • auctionConfig
    O objeto de configuração do leilão transmitido para navigator.runAdAuction().

  • browserSignals
    Um objeto criado pelo navegador que fornece informações sobre o leilão. Por exemplo:

    {
      'topWindowHostname': 'publisher.example',
      'interestGroupOwner': 'https://dsp.example',
      'renderUrl': 'https://cdn.example/url-of-winning-creative.wbn',
      'bid:' <bidValue>,
      'desirability': <winningAdScore>
    }
    

O valor de retorno dessa função é usado como o argumento sellerSignals para a função reportWin() do bidder vencedor.

O bidder vencedor informa o resultado

Seção de explicação:Relatórios de compradores sobre eventos de renderização e anúncio

O JavaScript do bidder vencedor, que também forneceu generateBid(), pode incluir uma função reportWin() para informar o resultado do leilão.

reportWin(auctionSignals, perBuyerSignals, sellerSignals, browserSignals) {
  ...
}

Os argumentos passados para essa função são:

  • auctionSignals e perBuyerSignals
    Os mesmos valores transmitidos a generateBid() para o bidder vencedor.
  • sellerSignals
    O valor de retorno de reportResult(), que dá ao vendedor a oportunidade de transmitir informações ao comprador.
  • browserSignals
    Um objeto criado pelo navegador para fornecer informações sobre o leilão. Por exemplo:

    {
      'topWindowHostname': 'publisher.example',
      'seller': 'https://ssp.example',
      'interestGroupOwner': 'https://dsp.example',
      'interestGroupName': 'custom-bikes',
      'renderUrl': 'https://cdn.example/winning-creative.wbn',
      'bid:' <bidValue>
    }
    

Implementação temporária de relatórios de perda/vitória

Há dois métodos disponíveis temporariamente no Chrome para relatórios de leilão:

  • forDebuggingOnly.reportAdAuctionLoss()
  • forDebuggingOnly.reportAdAuctionWin()

Cada um desses métodos usa um único argumento: um URL a ser buscado após a conclusão do leilão. Elas podem ser chamadas várias vezes, tanto em scoreAd() quanto em generateBid(), com argumentos de URL diferentes.

O Chrome só envia relatórios de perda/vitória de depuração quando um leilão é concluído. Se um leilão for cancelado (por exemplo, devido a uma nova navegação), nenhum relatório será gerado.

Esses métodos estão disponíveis por padrão no Chrome. Para testar os métodos, ative todas as APIs de privacidade de anúncios em chrome://settings/adPrivacy. Se você estiver executando o Chrome com sinalizações de linha de comando para ativar a API Protected Audience, será necessário ativar os métodos de forma explícita, incluindo a sinalização BiddingAndScoringDebugReportingAPI. Se a sinalização não estiver ativada, os métodos ainda estarão disponíveis, mas não farão nada.

8. Um clique no anúncio é registrado

Ilustração que mostra
  uma pessoa clicando em um anúncio de uma bicicleta, dentro de um quadro cercado, em um site de notícias, com dados
  do relatório indo para o vendedor e os compradores.

Um clique em um anúncio renderizado em um frame isolado é informado. Para saber mais sobre como isso pode funcionar, consulte Relatórios de anúncios de frame isolado.



O diagrama abaixo descreve cada etapa de um leilão de anúncios da API Protected Audience:

Ilustração que apresenta uma visão geral de cada etapa de um leilão de anúncios da API Protected Audience


Qual é a diferença entre Protected Audience e TURTLEDOVE?

A API Protected Audience é o primeiro experimento implementado no Chromium na família de propostas TURTLEDOVE.

A API Protected Audience segue os princípios gerais da TURTLEDOVE. Algumas publicidades on-line têm como base a exibição de um anúncio a uma pessoa potencialmente interessada que já interagiu com o anunciante ou a rede de publicidade. Historicamente, isso tem funcionado porque o anunciante reconhece uma pessoa específica enquanto ela navega em sites, uma questão importante de privacidade na Web atual.

O objetivo da iniciativa TURTLEDOVE é oferecer uma nova API para lidar com esse caso de uso, oferecendo alguns avanços importantes na privacidade:

  • O navegador, não o anunciante, contém as informações sobre o que o anunciante pensa que uma pessoa tem interesse.
  • Os anunciantes podem veicular anúncios com base em um interesse, mas não podem combinar esse interesse com outras informações sobre uma pessoa, em especial quem ela é ou qual página está visitando.

A Protected Audience surgiu com o TURTLEDOVE e uma coleção de propostas relacionadas de modificações para atender melhor aos desenvolvedores que usam a API:

  • No SPARROW: a Criteo propôs a adição de um modelo de serviço ("Gatekeeper") executado em um ambiente de execução confiável (TEE). A API Protected Audience inclui um uso mais limitado de TEEs para pesquisa de dados em tempo real e geração de relatórios agregados.
  • As propostas TERN e PARRROT da NextRoll (link em inglês) descreviam as diferentes funções dos compradores e vendedores no leilão no dispositivo. O fluxo de pontuação/lances de anúncios da API Protected Audience é baseado nesse trabalho.
  • As modificações TURTLEDOVE com base em resultados e no nível do produto da RTB House melhoraram o modelo de anonimato e os recursos de personalização do leilão no dispositivo
  • A PARAKEET é a proposta da Microsoft de um serviço de anúncios semelhante ao TURTLEDOVE que depende de um servidor proxy em execução em um TEE entre o navegador e os provedores de adtech para anonimizar solicitações de anúncios e aplicar propriedades de privacidade. A API Protected Audience não adotou esse modelo de proxy. Estamos alinhando as APIs JavaScript para PARAKEET e Protected Audience para trabalhar no futuro e combinar ainda mais os melhores recursos das duas propostas.

A API Protected Audience ainda não impede que a rede de publicidade de um site saiba quais anúncios uma pessoa vê. Esperamos modificar a API para que ela se torne mais particular com o tempo.

Qual configuração de navegador está disponível?

Os usuários podem ajustar a participação nos testes do Sandbox de privacidade no Chrome ativando ou desativando a configuração de nível superior em chrome://settings/adPrivacy. Durante os testes iniciais, as pessoas poderão usar essa configuração de alto nível do Sandbox de privacidade para desativar a API Protected Audience. O Chrome planeja permitir que os usuários vejam e gerenciem a lista de grupos de interesse a que foram adicionados nos sites que visitaram. Assim como acontece com as próprias tecnologias do Sandbox de privacidade, as configurações do usuário podem evoluir com feedback de usuários, reguladores e outros.

Vamos continuar atualizando as configurações disponíveis no Chrome à medida que a proposta da API Protected Audience progride, com base em testes e feedback. No futuro, planejamos oferecer configurações mais granulares para gerenciar a API Protected Audience e os dados associados.

Os autores das chamadas de API não podem acessar a associação a grupos quando os usuários navegam no modo de navegação anônima. Além disso, a associação é removida quando os usuários limpam os dados do site.



Interaja e compartilhe feedback

Receber suporte

Para fazer uma pergunta sobre sua implementação, sobre a demonstração ou sobre a documentação:

Para bugs e problemas com a implementação da API Protected Audience no Chrome: * Confira os problemas atuais relatados para a API. * Informe um novo problema em crbug.com/new.

Receber atualizações

Saiba mais


Foto de Ray Hennessy no Unsplash.