Serviços de lances e leilões

Na proposta inicial da Protected Audience, os lances e o leilão para demanda de anúncios de remarketing são feitos localmente no dispositivo. Esse requisito pode exigir condição de computação impraticável em dispositivos com capacidade de processamento limitada ou talvez seja muito lento selecionar e renderizar anúncios devido à latência da rede.

A proposta de serviços de lances e leilões (B&A, na sigla em inglês) descreve uma maneira de permitir que a computação de Protected Audience ocorra em servidores na nuvem em um ambiente de execução confiável (TEE), em vez de localmente no dispositivo do usuário. O objetivo da proposta de B&A é oferecer suporte a um fluxo unificado para considerar a demanda de anúncios contextuais e de remarketing. Transferir a computação para os servidores ajuda a otimizar o leilão de Protected Audience, liberando ciclos computacionais e largura de banda da rede para um dispositivo.

O Google oferece os componentes de B&A, que são disponibilizados como código aberto. As adtechs interessadas podem hospedar as próprias instâncias com provedores de nuvem pública compatíveis. Leia mais sobre a proposta de B&A no GitHub. As datas apresentadas neste documento refletem a implementação do Chrome, e vamos publicar mais informações sobre a integração com o Android no futuro. Este documento serve como uma introdução ao B&A, e as novas APIs que o Android vai oferecer para interagir com ele. Vamos publicar mais informações técnicas sobre como usar essas novas APIs em atualizações futuras.

Onde os serviços de B&A se encaixam

O B&A ofecere uma opção adicional para realizar um leilão em servidores confiáveis de adtechs que executam um binário de código aberto fornecido pelo Google. Os dados do usuário ainda são armazenados no dispositivo, e o Google vai oferecer APIs para transferir esses dados com segurança para o TEE. Saiba mais sobre nossa estratégia de criptografia abaixo.

Isso significa que algumas partes do processo de leilão acontecem no dispositivo e outras na nuvem. Do ponto de vista de um DSP, os públicos-alvo personalizados (incluindo anúncios candidatos para campanhas de remarketing) ainda são gerenciados no dispositivo usando as mesmas APIs de gerenciamento de público-alvo personalizado usadas quando o leilão é feito no dispositivo. Do ponto de vista das SSPs, as solicitações ainda são acionadas no dispositivo, e este documento descreve as novas APIs que vão ser usadas. Para todas as partes, a geração de relatórios do resultado de um leilão ainda começa no dispositivo depois que a chamada de B&A é concluída.

A principal diferença é o local em que a lógica de geração de URL de relatórios, lances, pontuação é realizada. Em vez de realizar a lógica de lances, leilão e relatórios no dispositivo, a lógica de generateBid(), scoreAd(), reportResult() e reportWin() é executada no TEE. As lógicas de lances e de pontuação do vendedor são executadas no próprio ambiente de B&A, no meio do fluxo do leilão de Protected Audience:

Criptografia de dados

Com o B&A, as informações de Protected Audience, como públicos-alvo personalizados e valores de lance, são transmitidas do dispositivo para os servidores de adtech do comprador e novamente ao dispositivo. Por isso, a plataforma criptografa os dados que vão para os serviços de Protected Audience, que só podem ser descriptografados por serviços atestados. Leia mais sobre estratégias de criptografia no GitHub.

Fluxo de leilão e arquitetura

Esta proposta inclui a necessidade de vários novos componentes detalhados no GitHub, incluindo o fluxo de dados do dispositivo para B&A.

De modo geral, o fluxo de dados é descrito da seguinte maneira:

1. No dispositivo, os vendedores coletam informações da Protected Audience usando a API getAdSelectionData.
2. O SDK no dispositivo envia uma solicitação ao serviço de publicidade do vendedor. Essa solicitação inclui payload contextual e ProtectedAudienceInput criptografado.
3. O serviço de publicidade do vendedor envia uma solicitação ao serviço de lances em tempo real (RTB) dos compradores em execução fora de um TEE para receber anúncios candidatos contextuais e, em seguida, pontua e seleciona um anúncio contextual vencedor.
4. O serviço de publicidade do vendedor envia uma solicitação ao serviço SellerFrontEnd em execução em um TEE.
5. O serviço SellerFrontEnd envia solicitações com dados específicos do comprador para serviços BuyerFrontEnd.
6. Os compradores usam os próprios serviços de chave-valor e serviços de lances, que geram lances para candidatos ao anúncio provenientes do dispositivo para todos os públicos-alvo personalizados considerados para remarketing.
7. O serviço SellerFrontEnd lê o serviço de chave-valor e pontua os anúncios candidatos. O resultado é criptografado e retornado ao serviço de publicidade do vendedor.
8. O serviço de publicidade do vendedor retorna o resultado vencedor criptografado e, opcionalmente, um resultado contextual, ao SDK no dispositivo.
9. No dispositivo, os vendedores recuperam o anúncio vencedor usando a API processAdSelectionResult, que descriptografa a resposta do serviço de publicidade do vendedor.

Uma descrição detalhada de cada etapa e como os dados são criptografados está disponível no GitHub. Esses componentes vão ser disponibilizados como código aberto. O código oferecido vai processar as solicitações unificadas do serviço SellerFrontEnd para serviços BuyerFrontEnd.

Implantação na nuvem

As adtechs vão implantar serviços de B&A em uma plataforma de nuvem pública compatível. Essas implantações são gerenciadas por adtechs que vão ser responsáveis por definir um objetivo de nível de serviço de disponibilidade.

Fazer um leilão

A primeira etapa para fazer o leilão de B&A é coletar os dados de públicos-alvo personalizados no dispositivo e criptografar essas informações para envio aos leilões do lado do servidor. Para isso, use a API getAdSelectionData:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

O método getAdSelectionData gera a entrada necessária para componentes de B&A, como BuyerInput e ProtectedAudienceInput, e criptografa os dados. antes de disponibilizar o resultado para o autor da chamada. Para evitar o vazamento de dados entre apps, esses dados contêm informações de todos os compradores presentes no dispositivo. Leia mais sobre essa decisão na seção de considerações sobre privacidade.

Essa API retorna um objeto AdSelectionData:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

Usando esse AdSelectionData, o SDK no dispositivo pode enviar uma solicitação ao serviço de publicidade do vendedor incluindo os dados em uma solicitação POST ou PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

O SDK no dispositivo é responsável por codificar esses dados. É recomendável usar uma solução eficiente em termos de espaço, como enviar a solicitação ao serviço de publicidade do vendedor como multipart/form-data.

Depois que a solicitação é iniciada, o serviço de publicidade do vendedor a encaminha ao serviço SellerFrontEnd executado em um TEE. Ao configurar um serviço do FrontFront, os vendedores oferecem uma lista de endereços de domínio correspondentes aos serviços do BuyerFrontEnd operados pelos compradores com que o vendedor tem parceria. As solicitações são unificadas para os vários serviços do BuyerFrontEnd que o vendedor ofereceu, de modo que os compradores possam gerar lances para os anúncios candidatos selecionados. Para um comprador específico, a B&A só vai enviar informações sobre públicos-alvo personalizados que pertencem a ele para que não haja vazamento de dados entre compradores. Depois de gerar os lances, a lista de anúncios candidatos retorna ao serviço SellerFrontEnd, em que um vencedor é selecionado. Por fim, o serviço SellerFrontEnd retorna o anúncio vencedor criptografado para o dispositivo.

Com a resposta da solicitação ao serviço de publicidade do vendedor novamente no dispositivo, a plataforma oferece uma segunda API nova para descriptografar o resultado e enviar um AdSelectionOutcome, o mesmo objeto retornado de um leilão no dispositivo.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Relatórios

Os URLs de relatórios vão ser gerados nos serviços de B&A. Os pings nesses URLs para gerar relatórios de impressões e interações para leilões ainda precisam ser acionados no dispositivo. O SDK no dispositivo ainda vai precisar invocar as APIs reportImpression() e reportInteraction() usando o AdSelectionId gerado durante o fluxo de B&A. Os beacons gerados para relatórios de interação e os URLs correspondentes estão contidos na resposta criptografada. Portanto, durante a descriptografia, os eventos e os mapeamentos de URL são armazenados no dispositivo.

Considerações sobre privacidade

A proposta da API Browser Bidding & Auction no GitHub descreve as considerações sobre privacidade. Essa proposta usa a nomenclatura do Chrome, mas os mesmos princípios se aplicam ao Android.

adSelectionData é criptografado para garantir que os dados em trânsito sejam acessíveis apenas pela PPAPI e pelos servidores confiáveis. Para reduzir o risco de vazamento de dados devido a mudanças de tamanho de adSelectionData, planejamos gerar o mesmo adSelectionData para todas as chamadas à API getAdSelectionData. Isso significa que todos os CustomAudience no dispositivo são usados para criar adSelectionData. Além disso, planejamos restringir a influência dos parâmetros de entrada GetAdSelectionData no adSelectionData gerado.

Gerar o mesmo adSelectionData para todas as adtechs que usam todos os dados de leilão no dispositivo cria um payload maior, que precisa ser transferido em todas as chamadas para o servidor da adtech, e pode abrir o ecossistema para abuso de entidades mal-intencionadas. Essas preocupações são abordadas nas seções Considerações sobre tamanho e Considerações antiabuso abaixo.

Considerações sobre tamanho

O SDK do cliente de adtech precisa empacotar os bytes criptografados de adSelectionData em uma chamada de anúncios contextuais feita para o servidor do vendedor. Para um desempenho ideal, é importante otimizar o tamanho de adSelectionData sem comprometer a funcionalidade. Planejamos introduzir otimizações, conforme mencionado em Explicação sobre otimização de payload, para reduzir o tamanho de adSelectionData. Essas otimizações incluem:

1. Adição de ad_render_id em CustomAudience para que ele seja enviado usando adSelectionData em vez de usar o URI e os metadados de renderização do anúncio. As tecnologias de publicidade podem otimizar ainda mais o app sem enviar dados de anúncios no adSelectionData. Essa opção vai ser compatível com CustomAudience API em versões futuras.
2. Verifique se user_bidding_signals não foi enviado em adSelectionData. Em vez disso, as adtechs podem buscar user_bidding_signals no servidor de chave-valor.
3. Permita que os compradores priorizem CustomAudience.
4. Permita que o comprador especifique a prioridade do vendedor.
5. Gere adSelectionData em alguns intervalos fixos para limitar o vazamento de bits e reduzir o tamanho do payload.

As otimizações de tamanho vão levar em conta as questões levantadas nas considerações sobre privacidade.

Considerações antiabuso

Como mencionado nas considerações sobre privacidade, adSelectionData é gerado usando todos os dados do comprador no dispositivo.

Isso abre o ecossistema para possíveis entidades mal-intencionadas que podem adicionar dados fraudulentos do comprador para prejudicar o desempenho, sobrecarregar payloads para aumentar os custos etc.

Para combater o abuso de adSelectionData, vamos adotar as seguintes medidas:

• Permitir que CustomAudience especifique explicitamente os vendedores aprovados e a prioridade do vendedor.
• Permitir que as SSPs especifiquem explicitamente o comprador, além da prioridade e da cota dele no payload gerado.
• Informar um mecanismo para que as SSPs definam um número máximo de compradores por chamada ou um tamanho máximo por comprador.

Essas medidas foram projetadas para permitir que as adtechs definam com que outras adtechs elas vão colaborar e os limites aceitáveis no payload adSelectionData que precisa ser processado. Sugerimos permitir que o vendedor especifique essa lista de compradores e prioridade em outra chamada. Essa especificação vai ser constante em um intervalo de tempo para evitar a exposição de dados adicionais sobre o usuário por chamadas repetidas.

As mitigações mencionadas acima estão em discussão e sujeitas a mudanças ao longo do tempo. Como mencionado anteriormente, todas as mitigações introduzidas para restrições contra abuso e tamanho precisam obedecer às considerações sobre privacidade.