Guia de integração e teste da API Protected Audience (antes conhecida como FLEDGE) para SSPs

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 selecionem e segmentem grupos de interesse (listas de público-alvo) sem depender de cookies de terceiros, protegendo os usuários do rastreamento entre sites. Desenvolvedor guia

As SSPs podem testar a API Protected Audience com Display & Video 360 e Google Ads para:

  • Iterar e aprender sobre a eficácia dos fluxos da API Protected Audience.
  • Propor e gerar feedback sobre possíveis melhorias na API em público fóruns, como o GitHub.
  • Prepare-se para apoiar a publicidade personalizada com a Protected Audience a API sem depender de cookies de terceiros.

O guia a seguir descreve os detalhes de integração entre uma SSP e o Display & Video 360 e Google Ads. As SSPs interessadas em coordenar um teste devem entrar contato com as equipes de Representante da parceria com o Video 360.

Registro

As SSPs devem registrar se use a API Protected Audience.

Resumo do fluxo de veiculação

O diagrama a seguir mostra o fluxo genérico que descreve os principais pontos de interação entre Chrome, SSP, Display e Video 360 e Google Ads.

Diagrama de sequência mostrando solicitações entre o Chrome, a SSP e
DSP

Opções de integração

Opção 1: direto / vendedor único

Fluxo de solicitação detalhado para vendedor único
leilões

Etapas:

  1. A tag de anúncio SSP envia uma solicitação de anúncio ao servidor SSP indicando que o navegador oferece suporte à API Protected Audience.
  2. O servidor SSP envia uma solicitação de lance contextual do OpenRTB para o DSP indicando que o navegador compatível com a API Protected Audience
  3. O DSP responde com uma resposta do lance do OpenRTB com indicadores para o leilão no dispositivo.
  4. O servidor da SSP envia uma resposta do anúncio com configuração de leilão para a tag de anúncio da SSP.
  5. A tag de anúncio SSP inicia um leilão no dispositivo chamando runAdAuction(), transmitindo sinais da resposta de lance do openRTB da DSP por meio perBuyerSignals.
  6. O Chrome chama o servidor de lances DSP confiável de chave-valor para buscar indicadores de lances em tempo real.
  7. O Chrome chama generateBid() A função JavaScript DSP para cada grupo de interesse participante.
  8. O Chrome chama o servidor de pontuação de SSP confiável de chave-valor para buscar sinais de pontuação em tempo real.
  9. O Chrome chama scoreAd() Função JavaScript da SSP para cada grupo de interesse participante.
  10. O Chrome chama reportWin() Função JavaScript DSP para informar o vencedor ao DSP.
  11. O Chrome chama reportResult() Função JavaScript da SSP para informar o vencedor à SSP.

Alterações mínimas no lado da SSP

  • A tag de anúncio SSP precisa ser atualizada para

    • Detectar se o navegador oferece suporte à API Protected Audience
    • envie essas informações como parte da solicitação de anúncio para o servidor SSP [1]
    • iniciar um leilão no dispositivo chamando runAdAuction() transmitindo indicadores da resposta de lance do OpenRTB do DSP [5] (consulte o campo "buyerdata" em solicitação de lance e estrutura de resposta abaixo).
  • O servidor SSP precisa

    • propagar informações sobre o suporte da API Protected Audience para a DSP no campo na solicitação de lance do OpenRTB [2] (consulte a seção sobre o lance) solicitação e resposta abaixo).
    • propagar os indicadores do comprador da DSP na resposta do lance do OpenRTB para o anúncio SSP tag (consulte a seção sobre solicitação de lance / estrutura de resposta do lance abaixo) [4]
  • [Optional] A SSP precisa implementar um servidor SSP confiável para fazer buscas em tempo real indicadores de pontuação para apoiar as verificações de qualidade dos anúncios e a aplicação das configurações do editor [8]

  • A SSP precisa implementar o JavaScript com "scoreAd(...)" e "reportResult(...)". funções [9], [11]

Opção 2: vários vendedores

Fluxo de solicitação detalhado para leilões com vários vendedores

Etapas:

  1. O adaptador de SSP envia uma solicitação de anúncio para o servidor SSP indicando que o navegador oferece suporte à API Protected Audience.
  2. O servidor SSP envia uma solicitação de lance contextual do OpenRTB para o DSP indicando que o navegador oferece suporte à API Protected Audience,
  3. O servidor DSP responde com uma resposta do lance do openRTB que contém sinais para leilão no dispositivo.
  4. O servidor da SSP envia uma resposta do anúncio com configuração de leilão para a tag de anúncio da SSP.
  5. O adaptador do Prebid de SSP fornece configuração de leilão do componente para o servidor de anúncios do editor tag.
  6. A tag do servidor de anúncios do editor envia uma solicitação de anúncio para o servidor do servidor de anúncios do editor.
  7. A tag do servidor de anúncios do editor inicia um leilão no dispositivo chamando runAdAuction(...) API.
  8. O Chrome chama o servidor de lances DSP confiável de chave-valor para buscar indicadores de lances em tempo real.
  9. O Chrome chama generateBid() Função DSP JavaScript para cada grupo de interesse participante.
  10. O Chrome chama o servidor de pontuação de SSP confiável de chave-valor para buscar sinais de pontuação em tempo real.
  11. O Chrome chama scoreAd() Função JavaScript da SSP para cada grupo de interesse participante.
  12. O Chrome chama reportWin() Função JavaScript DSP para informar o vencedor ao DSP.
  13. O Chrome chama reportResult() Função JavaScript da SSP para informar o vencedor à SSP.

Alterações mínimas no lado da SSP

  • O adaptador de SSP precisa ser atualizado para

  • O servidor SSP precisa

    • propagam informações sobre o suporte da API Protected Audience para a DSP usando o campo na solicitação de lance do OpenRTB [2] (consulte a seção sobre o lance) solicitação e resposta abaixo).
    • propagar os indicadores do comprador da DSP na resposta do lance do OpenRTB para o anúncio SSP tag (consulte a seção sobre solicitação de lance / estrutura de resposta do lance abaixo) [4]
  • [Optional] A SSP precisa implementar um servidor SSP confiável para fazer buscas em tempo real indicadores de pontuação para apoiar as verificações de qualidade dos anúncios e a aplicação das configurações do editor [10]

  • A SSP precisa expor o JavaScript com scoreAd() e reportResult(). funções [11], [14].

Serviços de lances e leilões

Estamos avaliando a estratégia de lances e Serviços de leilão (B&A) proposal

Quando exibir e O Video 360 está pronto para testar a API Protected Audience com B&A. vamos entrar em contato com mais detalhes.

Protocolo OpenRTB

Solicitação de lance

Para diferenciar as oportunidades de impressão compatíveis com a API Protected Leilões no dispositivo da API Audience daqueles que só são compatíveis com padrões leilão de troca do lado do servidor, um novo campo de tipo enumerado chamado ae para "leilão" ambiente" precisa ser adicionado como uma extensão ao objeto Imp no OpenRTB solicitação de lance para especificar qual ambiente de leilão é compatível com o espaço de impressão. O tipo enumerado ae pode ter os seguintes valores:

  • 0: leilões padrão do lado do servidor
  • 1: solicitações com suporte à API Protected Audience, em que um contexto o leilão é realizado nos servidores da troca e no grupo de interesse que dá lances e o leilão final é executado no navegador
{
  "id": 
  "imp": [{
    "id": "1"
    "video": {...}
    "ext": {
      "ae": 1
    }]
}

Resposta do lance

Além dos lances contextuais, uma resposta de lance também é usada para transmitir relevantes da Rede de Display e Participação do Video 360 e do Google Ads no Leilões de grupos de interesse da API Protected Audience. A resposta do lance é atualizada para oferecer suporte aos leilões de grupos de interesse da seguinte forma:

{
  "seatbid": [{
    "bid": [{
       // Traditional contextual bids
    }]
  }],

  "ext": {
    // InterestGroupBidding object which holds information for running an
    // in-browser interest group auction.
    "igbid": [{
      // ID of the Imp object of the impression to which
      // these interest group bidding signals apply to.
      "impid": "1",

      // InterestGroupBuyer object which holds DSP information for the in-browser
      // auction.
      "igbuyer": [{
        // Origin of Display & Video 360 and Google Ads to participate in the
        // interest group auction. For more info regarding the origin see:
        // https://developer.mozilla.org/en-US/docs/Glossary/Origin
        "origin": "https://td.doubleclick.net",

        // Buyer-specific signals to use in auctionConfig as perBuyerSignals.
        // Used by the buyer's interest group bidding function. Can be left empty
        "buyerdata": ...,

        // Buyer experiment group id to support coordinated experiments with
        // buyers' trusted servers. This experiment id should be added to the
        // `perBuyerExperimentGroupIds` map in auctionConfig.
        "buyer_experiment_group_id": 12345
      }]
    }]
  }
}

Há suporte para os cenários a seguir.

  • CENÁRIO 1: Display e O Video 360 e o Google Ads só querem participar em um leilão contextual. Nesse cenário, não há um campo igbid.

  • CENÁRIO 2: Display e O Video 360 e o Google Ads só querem participar em um leilão de grupo de interesse. Neste cenário, Display & Video 360 e O Google Ads descartará o campo seatbid na resposta do lance e só retornar informações igbid. Em outras palavras, a presença do campo igbid indica o fato de que Display & O Video 360 e o Google Ads querem seus grupos de interesse para participar do leilão no dispositivo.

  • CENÁRIO 3: Display e A Video 360 e o Google Ads querem participar em leilões contextuais e de grupos de interesse. Neste cenário, Display & O Video 360 e o Google Ads retornam o campo seatbid na resposta do lance e informações de igbid.

Metadados com lance de anúncio

A API Protected Audience permite que passing arbitrary metadata sobre o anúncio com a função generateBid().

Rede de Display e O Video 360 planeja usar as seguintes ferramentas: specification para os metadados do anúncio: API Protected Audience e OpenRTB.

Ou seja, Display & O Video 360 retornará os seguintes campos como parte do anúncio objeto:

Atributo PA Tipo Descrição do OpenRTB
ad.seat String; obrigatório ID da licença do comprador (por exemplo, anunciante, agência) em nome de quem o lance é feito.
ad.adomain String[] Domínio do anunciante para verificação da lista de bloqueio (por exemplo, "ford.com"). Pode ser uma matriz de para o caso de rotação de criativos. As trocas podem determinar que apenas um domínio seja permitido.
ad.cid string ID da campanha para ajudar na verificação da qualidade do anúncio.
ad.crid string É o ID do criativo para ajudar na verificação de qualidade do anúncio.
ad.language string Idioma do criativo usando ISO-639-1-alpha-2. O código não padrão "xx" também poderá ser usado se o criativo não tiver conteúdo linguístico (por exemplo, um banner com apenas o logotipo da empresa). Apenas um idioma ou idioma deve estar presente.
ad.w número inteiro A largura do criativo em pixels independentes de dispositivo (DIPS, na sigla em inglês).
ad.h número inteiro A altura do criativo em pixels independentes de dispositivo (DIPS, na sigla em inglês).

Exemplo

{
  "seat": "123"
  "adomain": ["example.com"]
  "cid": "12345"
  "crid": "12345"
  "language": "en"
  "w": 300
  "h": 250
}

Relatórios de eventos

A API Protected Audience oferece a API de relatórios no nível do evento descrita neste Postagem no GitHub: Fenced Frame Ads Reporting (link em inglês). Embora o nome informe Fenced Frame Ads Reporting, a API está disponível no frames isolados e iframes (mais detalhes here).

A SSP pode registrar um URL com o navegador na função reportResult Ligando para registerAdBeacon() API.

Rede de Display e O Video 360 chamará reportEvent() API com o destino "component-seller" no criativo para informar impressões e eventos de clique. Isso resulta no envio de um beacon para o URL registrado.

Observe que a Rede de Display e O Video 360 vai chamar a API reportEvent() para impressões e cliques com dados de postagem vazios.

Exemplo

registerAdBeacon({
 'impression': 'https://ssp.example/impression?ssp_event_id=abc',
});
registerAdBeacon({
 'click': 'https://ssp.example/click?ssp_event_id=abc',
});

Rede de Display e O Video 360 vai participar de Chrome-facilitated testing de descontinuação dos cookies de terceiros. Para realizar os testes, pedimos aos parceiros que transmitir os rótulos do Chrome na solicitação de lance do OpenRTB de acordo com o seguinte: specification:

Objeto: Device.ext

Atributo Tipo Descrição
cdep String o rótulo como recebido do Chrome ou de um parceiro upstream.