Indicadores de apps protegidos para oferecer suporte a anúncios relevantes de instalação de apps

Esta proposta está sujeita ao processo de inscrição no Sandbox de privacidade e atestados de segurança. Para mais informações sobre os atestados, consulte link de atestado fornecido. Futuras atualizações desta proposta serão descrevem os requisitos para obter acesso a esse sistema.

Os anúncios de instalação de apps para dispositivos móveis, também conhecidos como anúncios de aquisição de usuários, são um tipo de publicidade para dispositivos móveis criada para incentivar os usuários a fazer o download de um app. Normalmente, esses anúncios são veiculados aos usuários com base nos interesses e informações demográficas, e costumam aparecer em outros apps para dispositivos móveis, como jogos, mídias sociais e apps de notícias. Quando um usuário clica em um anúncio de instalação de apps, ele é direcionado diretamente à app store para fazer o download.

Por exemplo, um anunciante que está tentando gerar instalações de um novo app de entrega de comida para dispositivos móveis nos Estados Unidos pode segmentar os anúncios para usuários localizados no país e que já interagiram com outros apps de serviço de entrega de comida.

Isso geralmente é implementado com a inclusão de indicadores contextuais, próprios e de terceiros entre as adtechs para criar perfis de usuário com base nos IDs de publicidade. Os modelos de machine learning de adtech usam essas informações como entradas para escolher anúncios relevantes para o usuário e com maior probabilidade de resultar em uma conversão.

As seguintes APIs foram propostas para oferecer suporte a anúncios eficazes de instalação de apps que melhoram a privacidade do usuário, eliminando a dependência de identificadores de usuários entre partes diferentes:

1. API Protected App Signals: é centrada no armazenamento e na criação de recursos de engenharia de adtech que representam os possíveis interesses de um usuário. As adtechs armazenam indicadores de evento autodefinidos por app, como o app instalações, primeiros acessos, ações do usuário (nivelamento no jogo, conquistas) atividades de compra ou tempo no aplicativo. Os indicadores são gravados e armazenados dispositivo para proteção contra vazamento de dados e são disponibilizados apenas lógica de adtech que armazenou o indicador fornecido durante um leilão protegido em um ambiente seguro.
2. API Ad Selection: fornece uma API para configurar e executar uma Leilão protegido em execução em um ambiente de execução confiável (TEE) em que as adtechs recuperam candidatos, executam inferências, calculam lances e para escolher uma "vencedora" usando as APIs Protected App Signals e informações contextuais em tempo real fornecidas pelo editor.

Confira uma visão geral de alto nível sobre como os indicadores de apps protegidos oferecem suporte a anúncios de instalação de apps relevantes. As seções a seguir deste documento dão mais detalhes sobre cada uma dessas etapas.

• Seleção de indicadores: à medida que os usuários usam apps para dispositivos móveis, as adtechs selecionam os indicadores. armazenando eventos do app definidos pela adtech para veicular anúncios relevantes usando o API Protected App Signals. Esses eventos são armazenados em dispositivos armazenamento, semelhante aos públicos-alvo personalizados, e são criptografados antes de serem enviados para fora do dispositivo para que apenas os serviços de lances e leilões sejam executados nos ambientes de execução confiáveis com as medidas de segurança e o controle de privacidade pode descriptografá-los para lances e pontuação de anúncios.
• Codificação de indicadores: os indicadores são preparados em uma cadência programada, por uma lógica personalizada de adtech. Um job do Android em segundo plano executa essa lógica para realizar a codificação no dispositivo para gerar um payload de indicadores de apps protegidos que pode ser usada em tempo real para seleção de anúncios durante uma fase Leilão. O payload é armazenado com segurança no dispositivo até ser enviado para um leilão.
• Seleção de anúncios: para selecionar anúncios relevantes para o usuário, os SDKs do vendedor envia um payload criptografado da API Protected App Signals e configura uma Leilão protegido. No leilão, a lógica personalizada do comprador prepara a categoria Indicadores de apps com os dados contextuais fornecidos pelo editor (dados geralmente compartilhada em uma solicitação de anúncio de RTB aberto) para engenheiros para seleção de anúncios (recuperação de anúncios, inferência e lances geração de imagens). Assim como na API Protected Audience, os compradores enviam anúncios para para a pontuação final em um leilão protegido.
  • Recuperação de anúncios: os compradores usam a API Protected App Signals e dados contextuais fornecidos pelo editor para criar atributos relevantes para os interesses do usuário. Esses recursos são usados para fazer a correspondência de anúncios que atendem aos critérios de segmentação. Os anúncios que não estão dentro do orçamento são filtrados. Em seguida, os anúncios Top-K são selecionados para lances.
  • Lances: a lógica de lances personalizados dos compradores prepara os dados contextuais fornecidos pelo editor e os indicadores de apps protegidos para criar recursos. Eles são usados como entrada para modelos do machine learning do comprador para inferência e lances em anúncios candidatos dentro de limites confiáveis que preservam a privacidade. O comprador vai retornar o anúncio escolhido ao vendedor.
  • Pontuação do vendedor: vendedores Anúncios com pontuações de lógica de pontuação personalizada enviado pelos Compradores participantes e escolhe um anúncio vencedor para ser enviado ao aplicativo para renderização.
• Relatórios: os participantes do leilão recebem os relatórios de vitórias e de perdas aplicáveis. Estamos analisando mecanismos que preservam a privacidade para incluir dados para o treinamento de modelo no relatório vencedor.

Cronograma

Selecionar indicadores de apps protegidos

Um indicador é uma representação das várias interações do usuário em um app. Elas são determinadas pela adtech como úteis para veicular anúncios relevantes. Um app ou o O SDK integrado pode armazenar ou excluir indicadores de apps protegidos definidos por adtechs com base na atividade do usuário, como aberturas de apps, conquistas, atividade de compra ou no app. Os indicadores de apps protegidos são armazenados com segurança no dispositivo e criptografados antes de serem enviados para fora do dispositivo, de modo que somente os recursos de Lances e Leilões serviços em execução em ambientes de execução confiáveis com os devidos e o controle de privacidade pode descriptografá-los para lances e pontuação de anúncios. Semelhante ao API Custom Audience, os indicadores armazenados em um dispositivo não poderão ser lidos ou inspecionados por apps ou SDKs. não há API para ler valores de indicadores, e as APIs são criada para evitar o vazamento da presença de sinais. A lógica personalizada de adtech protege o acesso aos indicadores selecionados a fim de criar recursos que servem como base para a seleção de anúncios em um leilão protegido.

API Protected App Signals

A API Protected App Signals oferece suporte para o gerenciamento de indicadores usando um mecanismo de delegação semelhante ao usado para públicos-alvo personalizados. A API Protected App Signals permite o armazenamento de indicadores na forma de um único valor escalar ou como uma série temporal. Indicadores de série temporal podem ser usados para armazenar itens como a duração da sessão do usuário. Os indicadores de série temporal oferecem um utilitário para aplicar uma determinada duração usando uma regra de remoção por ordem de chegada. O tipo de dado de um indicador escalar ou cada um dos elementos de um indicador de série temporal é uma matriz de bytes. Cada valor é aprimorado com o nome do pacote do aplicativo que armazenou o indicador e o carimbo de data/hora de criação da chamada de API de armazenamento de indicadores. Essas informações extras estão disponíveis no JavaScript de codificação de indicadores. Este exemplo mostra a estrutura dos indicadores de uma determinada adtech:

Este exemplo demonstra um indicador escalar e um de série temporal associados a adtech1.com:

• Um indicador escalar com a chave de valor base64 "A1c" e o valor "c12Z". O armazenamento de indicadores foi acionado por com.google.android.game_app em 1º de junho de 2023.
• Uma lista de indicadores com a chave "dDE" que foram criados por dois aplicativos diferentes.

As adtechs recebem uma determinada quantidade de espaço para armazenar indicadores no dispositivo. Os indicadores terão um TTL máximo, a ser determinado.

Os indicadores de apps protegidos serão removidos do armazenamento se o aplicativo gerador for desinstalado, impedido de usar a API Protected App Signals ou se os dados do app forem apagados pelo usuário.

A API Protected App Signals é composta pelas seguintes partes:

• APIs Java e JavaScript para adicionar, atualizar ou remover indicadores.
• Uma API JavaScript para processar os indicadores persistentes e prepará-los para fazer engenharia de atributos adicional em tempo real durante um leilão protegido em execução em um ambiente de execução confiável (TEE).

Adicionar, atualizar ou remover indicadores

As adtechs podem adicionar, atualizar ou remover indicadores com a API fetchSignalUpdates(). Essa API oferece suporte para a delegação semelhante à delegação de público-alvo personalizado da API Protected Audience.

Para adicionar um indicador, as adtechs do comprador que não têm uma presença em relação a SDK em apps precisam colaborar com aquelas que têm uma presença no dispositivo, como parceiros de medição para dispositivos móveis (MMPs, na sigla em inglês) e plataformas de fornecimento (SSPs). O objetivo da API Protected App Signals é oferecer suporte a essas adtechs, fornecendo soluções flexíveis para o gerenciamento de indicadores de apps protegidos, permitindo que os autores de chamadas no dispositivo invoquem a criação desses indicadores em nome dos compradores. Esse processo é chamado de delegação e usa a API fetchSignalUpdates(). fetchSignalUpdates() usa um URI e recupera uma lista de atualizações de indicador. Para ilustrar, fetchSignalUpdates() emite uma solicitação GET para o URI fornecido para recuperar o lista de atualizações a serem aplicadas ao armazenamento de indicador local. O endpoint do URL, de propriedade o comprador responde com uma lista JSON de comandos.

Os comandos JSON aceitos são:

• put: insere ou substitui um valor escalar para a chave especificada.
• put_if_not_present: insere um valor escalar para a chave especificada, se nenhum valor estiver armazenado. Essa opção pode ser útil, por exemplo, para definir um ID do experimento para o usuário fornecido e evite substituí-lo se já tiver sido é definido por outro aplicativo.
• append: adiciona um elemento à série temporal associada à chave especificada. O parâmetro maxSignals especifica o número máximo de indicadores no período Google Workspace. Se o tamanho for excedido, os elementos anteriores serão removidos. Se a chave contiver um valor escalar, ele será automaticamente transformado em uma série temporal.
• remove: remove o conteúdo associado à chave especificada.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

Todas as chaves e valores são expressos em Base64.

Os comandos listados acima visam fornecer semânticas de inserção, substituição e exclusão para indicadores escalares, além de inserção, anexação e substituição completa de séries para indicadores de séries temporais. A semântica de exclusão e substituição em elementos específicos de um indicador de série temporal precisa ser gerenciada durante o processo de codificação e compactação. Por exemplo, durante a codificação, ignore valores em uma série temporal que são substituídos ou corrigidos por erros mais recentes e os exclua durante o processo de compactação.

Os indicadores armazenados são automaticamente associados ao aplicativo que executa busca e o responsável pela solicitação (o "site" ou a "origem" de um adtech registrada), além do horário de criação da solicitação. Todos os indicadores estão sujeitos ao armazenamento em nome de uma adtech registrada no Sandbox de privacidade. O "site"ou a "origem" do URI precisa corresponder aos dados de uma adtech inscrita. Se a adtech solicitante não estiver inscrita, a solicitação será rejeitada.

Cota de armazenamento e remoção

Cada adtech tem um espaço limitado no dispositivo do usuário para armazenar indicadores. Essa cota é definida por adtech. Portanto, os indicadores selecionados de diferentes apps compartilham a cota. Se a cota for excedida, o sistema vai liberar espaço removendo valores de indicadores anteriores por ordem de chegada. Para evitar que a remoção seja executada com muita frequência, o sistema implementa uma lógica de lote para permitir uma quantidade limitada de cotas excedente e liberar algum espaço extra quando a lógica de remoção for acionada.

Codificação no dispositivo para transmissão de dados

Para preparar os indicadores para a seleção de anúncios, a lógica personalizada por comprador tem acesso protegido aos indicadores e eventos armazenados por app. Um job em segundo plano do sistema Android é realizado de hora em hora para executar a lógica de codificação personalizada por comprador, que é transferida por download para o dispositivo. A lógica de codificação personalizada por comprador codifica os indicadores por app e, em seguida, compacta esses indicadores em um payload que esteja em conformidade com a cota por comprador. O payload é criptografado dentro dos limites do armazenamento do dispositivo protegido e transmitido para os serviços de lances e leilões.

As adtechs definem o nível de processamento de indicador processado pela própria lógica personalizada. Por exemplo, é possível instrumentar sua solução para descartar indicadores anteriores e agregar os semelhantes ou de reforço de aplicativos diferentes em novos indicadores que usam menos espaço.

Se um comprador não tiver registrado um codificador, os indicadores não serão preparados, e nenhum dos indicadores selecionados no dispositivo será enviado aos serviços de lances e leilões.

Mais detalhes sobre armazenamento, payload e cotas de solicitação serão disponibilizados em uma atualização futura. Além disso, vamos apresentar mais informações sobre como fornecer funções personalizadas.

Fluxo de trabalho de seleção de anúncios

Com essa proposta, o código personalizado de adtechs só pode acessar os indicadores de apps em um leilão protegido (API Ad Selection) em execução em um TEE. Para atender ainda mais às necessidades do caso de uso de instalação do app, os anúncios candidatos são buscados durante o leilão protegido em tempo real. Isso contrasta com o caso de uso de remarketing, em que os anúncios candidatos são conhecidos antes do leilão.

Esta proposta usa um fluxo de trabalho de seleção de anúncios semelhante ao da proposta da API Protected Audience com atualizações para oferecer suporte ao caso de uso de instalação de apps. Para oferecer suporte aos requisitos de computação da engenharia de atributos e da seleção de anúncios em tempo real, os leilões de anúncios de instalação de apps precisam ser executados em serviços de lances e leilões em execução em TEEs. O acesso a indicadores de apps protegidos durante um leilão protegido não tem suporte em leilões no dispositivo.

.

O fluxo de trabalho de seleção de anúncios é o seguinte:

1. O SDK do vendedor envia o payload criptografado dos indicadores de app protegido no dispositivo.
2. O servidor do vendedor cria uma configuração de leilão e a envia ao serviço de lances e leilões confiáveis do vendedor, junto com o payload criptografado, para iniciar um fluxo de trabalho de seleção de anúncios.
3. O serviço de lances e leilões do vendedor transmite o payload para os servidores de front-end dos compradores confiáveis participantes.
4. O serviço de lances do comprador executa a lógica de seleção de anúncios do lado do comprador
   1. Execução da lógica de recuperação de anúncios de compra.
   2. Execução da lógica de lances da compra.
5. A lógica de pontuação da venda é executada.
6. O anúncio é renderizado e a geração de relatórios é iniciada.

Iniciar o fluxo de trabalho da seleção de anúncios

Quando um aplicativo está pronto para mostrar um anúncio, o SDK de adtech (normalmente SSPs) inicia o fluxo de trabalho de seleção de anúncios enviando todos os dados contextuais relevantes do o editor e os payloads criptografados por comprador a serem incluídos na solicitação seja enviada ao leilão protegido usando a chamada getAdSelectionData. Isso é a mesma API usada para o fluxo de trabalho de remarketing e descrita na seção Lances e de integração de leilão para Android.

Para iniciar a seleção de anúncios, o vendedor transmite uma lista de compradores participantes e o payload criptografado dos indicadores de apps protegidos no dispositivo. Com essas informações, o servidor de anúncios do lado do vendedor prepara uma SelectAdRequest para o serviço SellerFrontEnd confiável.

O vendedor define o seguinte:

• O payload recebido do getAdSelectionData, que contém os indicadores de apps protegidos.

• Os indicadores de contexto que usam:

  • auction_config.auction_signals (por informações sobre o leilão)

  • auction_config.seller_signals (para os indicadores do vendedor)

  • auction_config.per_buyer_config["buyer"].buyer_signals (para o dos compradores indicadores)

• É a lista de compradores incluída nos leilões que usam o campo buyer_list.

Execução da lógica de seleção de anúncios de compra

Em um alto nível, a lógica personalizada do comprador usa dados contextuais fornecidos pelo editor e pelos indicadores de apps protegidos para selecionar e aplicar um lance aos anúncios relevantes para a solicitação de anúncio. A plataforma permite que os compradores restrinjam um grande conjunto de anúncios disponíveis aos mais relevantes (os Top-K), para os quais os lances são calculados antes dos anúncios serem retornados ao vendedor para a seleção final.

Antes de dar lances, os compradores começam com um grande conjunto de anúncios. Calcular um lance para cada anúncio é muito lento. Por isso, os compradores precisam selecionar os candidatos Top-K do grande conjunto. Em seguida, os compradores precisam calcular os lances para cada um desses candidatos Top-K. Então, esses anúncios e lances são retornados ao vendedor para a seleção final.

1. O serviço BuyerFrontEnd recebe uma solicitação de anúncio.
2. O serviço BuyerFrontEnd envia uma solicitação ao serviço de lances do comprador. O serviço de lances do comprador executa uma UDF chamada prepareDataForAdRetrieval(), que cria uma solicitação para obter os candidatos Top-K da ferramenta de recuperação de anúncios, Serviço. O serviço de lances envia essa solicitação para a recuperação configurada endpoint do servidor da Web.
3. O serviço de recuperação de anúncios executa a UDF getCandidateAds(), que filtra até o conjunto de anúncios-candidatos Top-K, que são enviados ao endereço de e-mail no serviço de lances.
4. O serviço de lances do comprador executa a UDF generateBid(), que escolhe o melhor candidato, calcula o lance e o retorna ao serviço BuyerFrontEnd.
5. O serviço BuyerFrontEnd retorna os anúncios e os lances ao vendedor.

Há vários detalhes importantes sobre esse fluxo, especialmente em relação a como as peças se comunicam entre si e como a plataforma fornece recursos como a capacidade de fazer previsões de machine learning para recuperar os anúncios Top-K e calcular os lances.

Antes de analisarmos mais detalhadamente as partes, há algumas observações importantes sobre a arquitetura dos TEEs no diagrama acima.

O serviço de lances do comprador contém internamente um serviço de inferência. As adtechs podem fazer upload de modelos de machine learning para o serviço de lances do comprador. Vamos fornecer APIs JavaScript para que as adtechs façam previsões ou gerem embeddings desses modelos nas UDFs em execução no serviço de lances do comprador. Ao contrário do serviço de recuperação de anúncios, o serviço de lances do comprador não tem um serviço de chave-valor para armazenar metadados de anúncios.

O serviço de recuperação de anúncios inclui internamente um serviço de chave-valor. As adtechs podem materializar pares de chave-valor nesse serviço usando os próprios servidores, fora do limite de privacidade. Vamos fornecer uma API JavaScript para que as adtechs leiam esse serviço de chave-valor nas UDFs em execução no serviço de recuperação de anúncios. Ao contrário do serviço de lances do comprador, o serviço de recuperação de anúncios não contém um serviço de inferência.

Uma pergunta central que esse design aborda é como fazer previsões no momento da recuperação e do lance. A resposta para ambos pode envolver uma solução chamada fatoração de modelo.

Fatoração de modelos

A fatoração de modelos é uma técnica que permite dividir um único modelo em várias partes e, em seguida, combiná-las em uma previsão. No caso de uso de instalação de apps, os modelos geralmente usam três tipos de dados: dados do usuário, contextuais e de anúncios.

No caso não fatorado, um único modelo é treinado nos três tipos de dados. No caso fatorado, dividimos o modelo em várias partes. Apenas a parte que contém os dados do usuário é confidencial. Isso significa que apenas o modelo com a parte do usuário precisa ser executado dentro do limite de confiança, no serviço de inferência do serviço de lances do comprador.

Isso possibilita o seguinte design:

1. Dividir o modelo em uma parte particular (os dados do usuário) e uma ou mais partes não particulares (os dados contextuais e do anúncio).
2. Transmitir algumas ou todas as partes não particulares como argumentos para uma UDF que precisa fazer previsões. Por exemplo, embeddings contextuais são transmitidos para UDFs no per_buyer_signals.
3. As adtechs podem criar modelos para partes não particulares e materializar os embeddings desses modelos no armazenamento de chave-valor do serviço de recuperação de anúncios. As UDFs no serviço de recuperação de anúncios podem buscar esses embeddings no ambiente de execução.
4. Para fazer uma previsão durante uma UDF, combine embeddings particulares do serviço de inferência com embeddings não particulares de argumentos de função da UDF ou do armazenamento de chave-valor com uma operação como um produto escalar. Esta é a previsão final.

Com isso explicado, podemos analisar cada UDF em mais detalhes. Vamos explicar o que elas fazem, como se integram e como podem fazer as previsões necessárias para escolher os anúncios Top-K e calcular os lances.

A UDF prepareDataForAdRetrieval()

A prepareDataForAdRetrieval() em execução no serviço de lances do comprador é responsável por criar o payload da solicitação que será enviado ao serviço de recuperação de anúncios para buscar os anúncios candidatos Top-K.

A prepareDataForAdRetrieval() recebe as seguintes informações:

• O payload por comprador recebido de getAdSelectionData. Esse payload contém os indicadores de apps protegidos.
• Os indicadores de contexto auction_signals (para informações sobre o leilão) e buyer_signals (para compradores indicadores).

A prepareDataForAdRetrieval() faz duas coisas:

• Caracterização: se a inferência no tempo de recuperação for necessária, ela vai transformar os indicadores de entrada em atributos para uso durante chamadas ao serviço de inferência e receber embeddings particulares para recuperação.
• Calcula embeddings particulares para recuperação: se as previsões de recuperação forem necessários, ele faz a chamada no serviço de inferência usando o atributos e recebe um embedding particular para previsões de tempo de recuperação.

A prepareDataForAdRetrieval() retorna:

• Indicadores de apps protegidos: payload de indicadores selecionados por adtechs.
• Indicadores específicos de leilão: indicadores do vendedor específicos da plataforma e informações contextuais, como auction_signals e per_buyer_signals, (incluindo embeddings contextuais) de SelectAdRequest. Isso é semelhante à API Protected Audience.
• Indicadores adicionais: informações extras, como embeddings particulares recuperados do serviço de inferência.

Essa solicitação é enviada ao serviço de recuperação de anúncios, que faz a correspondência de candidatos e executa a UDF getCandidateAds().

A UDF getCandidateAds()

A getCandidateAds() é executada no serviço de recuperação de anúncios. Recebe a solicitação criada por prepareDataForAdRetrieval() no serviço de lances do comprador. O serviço executa getCandidateAds(), que busca os candidatos Top-K para lances convertendo a solicitação em uma série de consultas definidas, buscas de dados e executando lógica de negócios personalizada e outra lógica de recuperação personalizada.

A getCandidateAds() recebe as seguintes informações:

• Indicadores de apps protegidos: payload de indicadores selecionados por adtechs.
• Indicadores específicos de leilão: indicadores do vendedor específicos da plataforma e informações contextuais, como auction_signals e per_buyer_signals, (incluindo embeddings contextuais) de SelectAdRequest. Isso é semelhante à API Protected Audience.
• Indicadores adicionais: informações extras, como embeddings particulares recuperados do serviço de inferência.

A getCandidateAds() realiza as seguintes ações:

1. Buscar um conjunto inicial de candidatos de anúncios: buscados usando critérios de segmentação, como idioma, região geográfica, tipo e tamanho do anúncio ou orçamento, para filtrar os candidatos.
2. Busca de embedding de recuperação: se os embeddings do serviço de chave-valor forem necessários para fazer uma previsão do tempo de recuperação para a seleção do Top-K, eles precisarão ser recuperados do serviço de chave-valor.
3. Seleção de candidato Top-K: calcule uma pontuação leve para o conjunto filtrado de candidatos de anúncios com base nos metadados buscados no armazenamento de chave-valor e nas informações enviadas do serviço de lances do comprador para escolher os candidatos Top-K com base nessa pontuação. Por exemplo, a pontuação pode ser a chance de instalar um app de acordo com o anúncio.
4. Busca de embedding de lances: se os embeddings do serviço de chave-valor forem necessárias pelo código de lances para fazer previsões no momento do lance, elas podem ser recuperados do serviço de chave-valor.

A pontuação de um anúncio pode ser o resultado de um modelo preditivo, que, por exemplo, prevê a probabilidade de um usuário instalar um app. Esse tipo de geração de pontuação envolve um tipo de fatoração do modelo: como getCandidateAds() é executada no serviço de recuperação de anúncios e ela não tem um serviço de inferência, as previsões podem ser geradas com a combinação de:

• Embeddings contextuais transmitidos usando os indicadores específicos do leilão entrada.
• Os embeddings particulares são transmitidos usando a entrada de indicadores adicionais.
• Todas as adtechs de embedding não particulares se materializaram dos próprios servidores no serviço de chave-valor do serviço de recuperação de anúncios.

A UDF generateBid() executada no serviço de lances do comprador também pode aplicar o próprio tipo de fatoração de modelos para fazer previsões de lances. Caso seja necessário algum embedding de um serviço de chave-valor para fazer isso, ele precisa ser buscado agora.

A getCandidateAds() retorna:

• Anúncios candidatos: os anúncios Top-K a serem transmitidos para a generateBid(). Cada anúncio é composto pelo seguinte:
  • URL de renderização: o endpoint para renderizar o criativo do anúncio.
  • Metadados: metadados de anúncios para compra específicos de tecnologias de publicidade. Por exemplo, este pode incluir informações sobre a campanha publicitária e critérios de segmentação como localização e idioma. Os metadados podem incluir campos embeddings usados quando a fatoração do modelo for necessária para executar inferência durante os lances.
• Indicadores adicionais: opcionalmente, o serviço de recuperação de anúncios pode incluir informações extras, como embeddings adicionais ou indicadores de spam a serem usados em generateBid().

Estamos investigando outros métodos para fornecer anúncios que recebem pontuação, incluindo a disponibilização deles como parte da chamada SelectAdRequest. Esses anúncios podem ser recuperados com uma solicitação de lance de RTB. Nesses casos, os anúncios precisam ser recuperados sem os indicadores de apps protegidos. As adtechs vão avaliar as compensações antes de escolher a melhor opção, incluindo o tamanho do payload da resposta, a latência, o custo e a disponibilidade dos indicadores.

A UDF generateBid()

Depois de recuperar o conjunto de anúncios candidatos e os embeddings durante a recuperação, é possível prosseguir para os lances, que são executados no serviço de lances do comprador. Esse serviço executa a UDF generateBid() fornecida pelo comprador para selecionar o anúncio para dar lances no Top-K e o retornar com o lance.

A generateBid() recebe as seguintes informações:

• Anúncios candidatos: os anúncios Top-K retornados pelo serviço de recuperação de anúncios.
• Indicadores específicos de leilão: indicadores do vendedor específicos da plataforma e informações contextuais, como auction_signals e per_buyer_signals, (incluindo embeddings contextuais) de SelectAdRequest.
• Indicadores adicionais: informações extras a serem usadas no momento dos lances.

A implementação da generateBid() do comprador faz três coisas:

• Destaque: transforma indicadores em atributos para uso durante a inferência.
• Inferência: gera previsões usando modelos de machine learning para calcular valores como taxas de cliques e de conversão previstas.
• Lances: combinação de valores inferidos com outras entradas para calcular os dar um lance para um anúncio candidato.

A generateBid() retorna:

• O anúncio candidato.
• O valor do lance calculado.

A generateBid() usada para anúncios de instalação de apps e o usado para anúncios de remarketing são diferentes.

As seções a seguir descrevem a funcionalidades, a inferência e os lances em mais detalhes.

Caracterização

Os indicadores de leilão podem ser preparados em recursos pela generateBid(). Esses recursos pode ser usado durante a inferência para prever coisas como cliques as taxas de conversão. Também estamos analisando mecanismos de preservação de privacidade para transmitir alguns deles no relatório de ganhos para uso no treinamento de modelo.

Inferência

Ao calcular um lance, é comum realizar inferências em um ou mais modelos de machine learning. Por exemplo, cálculos de eCPM eficazes geralmente usam modelos para prever as taxas de cliques e de conversão.

Os clientes podem fornecer vários modelos de machine learning com a implementação da generateBid(). Também vamos fornecer uma API JavaScript na generateBid() para que os clientes possam realizar inferência no momento da execução.

A inferência é executada no serviço de lances do comprador. Isso pode afetar a latência e o custo de inferência, especialmente porque os aceleradores ainda não estão disponíveis nos TEEs. Alguns clientes vão perceber que as necessidades deles foram atendidas com modelos individuais em execução no serviço de lances do comprador. Outros clientes, por exemplo, aqueles com modelos muito grandes, podem querer considerar opções como fatoração de modelos para minimizar o custo de inferência e a latência no momento do lance.

Mais informações sobre recursos de inferência, como formatos de modelo com suporte e tamanhos máximos, serão fornecidas em uma atualização futura.

Implementar fatoração de modelos

Anteriormente, explicamos a fatoração de modelos. No momento do lance, a abordagem específica é:

1. Dividir o modelo único em uma parte particular (os dados do usuário) e uma ou mais partes não particulares (os dados contextuais e do anúncio).
2. Transmitir partes não particulares para generateBid(). Elas podem vir de per_buyer_signals ou de embeddings que as adtechs calculam externamente, se materializam no armazenamento de chave-valor do serviço de recuperação, buscam no momento da recuperação e retornam como parte dos indicadores. Isso não inclui embeddings particulares, porque eles não podem ser provenientes de fora do limite de privacidade.
3. Em generateBid():
   1. Realizar a inferência em modelos para receber embeddings particulares do usuário.
   2. Combinar embeddings particulares de usuários com contextuais de per_buyer_signals ou anúncios não particulares e embeddings contextuais do serviço de recuperação usando uma operação como um produto escalar. Esta é a previsão final que pode ser usada para calcular lances.

Com essa abordagem, é possível realizar inferências no momento do lance em modelos que seriam muito grandes ou lentos para execução no serviço de lances do comprador.

Lógica de pontuação de venda

Nessa etapa, os anúncios com lances recebidos de todos os compradores participantes são pontuados. O resultado da generateBid() é transmitido ao serviço de leilão do vendedor para executar scoreAd() e que scoreAd() considera apenas um anúncio por vez. Com base na pontuação, o vendedor escolhe um anúncio vencedor para retornar ao dispositivo para renderização.

A lógica de pontuação é a mesma usada para o fluxo de remarketing da API Protected Audience, e consegue selecionar um vencedor entre os candidatos à instalação de apps e remarketing. A função é chamada uma vez para cada anúncio candidato enviado no leilão protegido. Consulte a explicação sobre Lances e leilão para mais detalhes.

Tempo de execução do código de seleção de anúncios

Na proposta, o código de seleção de anúncios para instalação de aplicativos é especificado na mesma para o fluxo de remarketing da API Protected Audience. Para mais detalhes, consulte a Configuração de lances e leilões. O código de lance será disponível no mesmo local de armazenamento em nuvem daquele usado para remarketing.

Relatórios

Esta proposta usa as mesmas APIs Reporting que a API Protected Audience Reporting proposta (por exemplo, reportImpression(), que aciona a plataforma para enviar relatórios de vendedor e comprador).

Um caso de uso comum para gerar relatórios sobre o lado do comprador é receber os dados de treinamento para modelos usados durante a seleção de anúncios. Além das APIs já existentes, a plataforma vai fornecer um mecanismo específico para a saída de dados em nível de evento da para servidores de adtechs. Esses payloads de saída podem incluir determinados dados.

A longo prazo, estamos investigando soluções de preservação da privacidade para enfrentar treinamento de modelo com dados usados nos leilões protegidos sem o envio no nível do evento dados do usuário fora dos serviços executados em TEEs. Vamos compartilhar mais detalhes em uma atualização posterior.

A curto prazo, forneceremos uma forma temporária de saída de dados com ruído de generateBid(): Nossa proposta inicial para isso está abaixo, e vamos aprimorá-la (incluindo possíveis alterações incompatíveis com versões anteriores) em resposta a feedback.

Tecnicamente, isso funciona da seguinte maneira:

1. As adtechs definem um esquema para os dados que querem transmitir.
2. No generateBid(), eles criam o payload de saída desejado.
3. A plataforma valida o payload de saída em relação ao esquema e aplica limites de tamanho.
4. A plataforma adiciona ruído ao payload de saída.
5. O payload de saída é incluído no relatório de vitórias em formato de transmissão, recebido em servidores de adtechs, decodificados e usados para treinamento de modelos.

Como definir o esquema de payloads de saída

Para que a plataforma aplique os requisitos de privacidade em evolução, os payloads de saída precisam ser estruturados de uma forma que a plataforma consiga entender. As adtechs vão definir dos payloads de saída fornecendo um arquivo JSON de esquema. Esse esquema serão processados pela plataforma e mantidos em sigilo pelos Lances e serviços de leilão que usam os mesmos mecanismos que outros recursos de adtech como UDFs e modelos.

Forneceremos um arquivo CDDL que define a estrutura desse JSON. A O arquivo CDDL vai incluir um conjunto de tipos de recursos compatíveis (por exemplo, que são booleanos, números inteiros, buckets e assim por diante). O arquivo CDDL e o e o esquema fornecido terá controle de versão.

Por exemplo, um payload de saída que consiste em um único atributo booleano seguido por um atributo de bucket de tamanho dois teria esta aparência:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Detalhes sobre o conjunto de tipos de recursos com suporte estão disponíveis no GitHub (link em inglês).

Criar payloads de saída em generateBid()

Todos os indicadores de apps protegidos de um determinado comprador estão disponíveis para o UDF generateBid(). Depois de implementá-los, as adtechs criam seu payload JSON. Esse payload de saída será incluído no relatório de ganhos do comprador para transmissão aos servidores de adtechs.

Uma alternativa a esse design é que o cálculo do vetor de saída ocorra em reportWin() em vez de generateBid(). Há vantagens e desvantagens para cada abordagem, e finalizaremos essa decisão em resposta aos comentários do setor.

Validar o payload de saída

A plataforma vai validar qualquer payload de saída criado pela adtech. Validação garante que os valores dos atributos sejam válidos para os tipos, as restrições de tamanho sejam atendidas, e que usuários maliciosos não estejam tentando burlar os controles de privacidade, o empacotamento de informações adicionais nos payloads de saída.

Se um payload de saída for inválido, ele será descartado silenciosamente das entradas. enviados ao relatório de vitórias. Isso ocorre porque não queremos fornecer instruções de depuração informações a qualquer usuário de má-fé que tente invalidar a validação.

Vamos fornecer uma API JavaScript para que as adtechs garantam o payload de saída que Criar em generateBid() vai passar na validação da plataforma:

validate(payload, schema)

Essa API JavaScript é inteiramente para que os autores da chamada determinem se um payload específico será aprovada na validação da plataforma. A validação real deve ser feita na plataforma para proteger contra UDFs generateBid() maliciosas.

Fazer ruído do payload de saída

A plataforma vai ruídos de payloads de saída antes de incluí-los no relatório vencedor. O limite de ruído inicial será de 1%, e esse valor pode evoluir com o tempo. A plataforma não informará se um determinado payload de saída recebido ruído.

O método com ruído é:

1. A plataforma carrega a definição de esquema para o payload de saída.
2. 1% dos payloads de saída serão escolhidos para ruídos.
3. Se um payload de saída não for escolhido, o valor original inteiro será mantido.
4. Se um payload de saída for escolhido, o valor de cada recurso será substituído por um um valor válido aleatório para esse tipo de recurso (por exemplo, 0 ou 1 para um recurso booleano).

Transmissão, recebimento e decodificação do payload de saída para treinamento de modelos

O payload de saída validado e com ruído será incluído nos argumentos para reportWin() e transmitidas aos servidores de adtechs do comprador fora da área de privacidade limite para o treinamento de modelo. O payload de saída estará no formato de transmissão.

Detalhes sobre o formato de transmissão para todos os tipos de recursos e para o payload de saída estão disponíveis no GitHub.

Determinar o tamanho do payload de saída

O tamanho do payload de saída em bits equilibra utilidade e minimização de dados. Vamos trabalhar com a indústria para determinar o tamanho apropriado por meio de experimentação. Enquanto realizamos esses experimentos, vamos temporariamente dados de saída sem limitação de tamanho de bits. Esses dados de saída adicionais sem a limitação de tamanho será removida depois que os experimentos forem concluídos.

O método para determinar o tamanho é:

1. Inicialmente, ofereceremos suporte a dois payloads de saída em generateBid():
   1. egressPayload: o payload de saída com tamanho limitado que descrevemos até agora neste documento. Inicialmente, o tamanho deste payload de saída será de 0 bits. ou seja, ele sempre será removido durante a validação.
   2. temporaryUnlimitedEgressPayload: uma saída temporária de tamanho ilimitado payload para experimentos de tamanho. A formatação, a criação e o processamento desse payload de saída usa os mesmos mecanismos que egressPayload.
2. Cada um desses payloads de saída terá o próprio arquivo JSON de esquema: egress_payload_schema.json e temporary_egress_payload_schema.json.
3. Fornecemos um protocolo de experimento e um conjunto de métricas para determinar o modelo em vários tamanhos de payload de saída (por exemplo, 5, 10, ... bits).
4. Com base nos resultados do experimento, determinamos o tamanho do payload de saída com o as compensações corretas de utilidade e privacidade.
5. Definimos o tamanho de egressPayload de 0 bits para o novo tamanho.
6. Após um período de migração definido, removemos temporaryUnlimitedEgressPayload, deixando apenas egressPayload com o novo tamanho.

Estamos investigando outras proteções técnicas para gerenciar essa mudança Por exemplo, criptografar egressPayload quando aumentamos o tamanho dele de 0 bits. Esses detalhes, além do cronograma do experimento e da remoção dos temporaryUnlimitedEgressPayload serão incluídos em uma atualização futura.

A seguir vamos explicar um possível protocolo de experimento para finalizar o tamanho egressPayload: Nosso objetivo é trabalhar com a indústria para encontrar um tamanho que equilibre e minimização de dados. O artefato que esses experimentos produzirão é um gráfico em que o eixo x é o tamanho do payload de treinamento em bits e o O eixo y é a porcentagem da receita gerada por um modelo desse tamanho em comparação para um valor de referência de tamanho ilimitado.

Vamos supor que estamos treinando um modelo pInstall e nossas fontes de dados de treinamento são os registros e o conteúdo das temporaryUnlimitedegressPayloads que que recebemos quando vencemos leilões. O protocolo das adtechs primeiro envolve off-line experimentos:

1. Determinar a arquitetura dos modelos que serão usados com o app protegido Indicadores. Por exemplo, eles precisarão determinar se use a fatoração de modelos.
2. Defina uma métrica para avaliar a qualidade do modelo. As métricas sugeridas são perda de AUC e registrar perdas.
3. Defina o conjunto de atributos que serão usados durante o treinamento do modelo.
4. Ao usar essa arquitetura de modelo, métrica de qualidade e conjunto de atributos de treinamento, executar estudos de ablação para determinar a contribuição de utilidade por bit para cada modelo que desejam usar no PAS. O protocolo sugerido para o estudo de ablação é:
   1. Treinar o modelo com todos os recursos e medir a utilidade essa é a para fins de comparação.
   2. Para cada atributo usado para produzir o valor de referência, treine o modelo com todas recursos exceto esse.
   3. Meça a utilidade resultante. Divida o delta pelo tamanho do atributo. em bits, essa é a utilidade esperada por bit para o recurso.
5. Determinar os tamanhos de payload de treinamento de interesse para experimentação. Qa sugerir [5, 10, 15, ..., size_of_all_training_features_for_baseline] bits. Cada um deles representa um tamanho possível para egressPayload que o experimental avaliará.
6. Para cada tamanho possível, selecione um conjunto de atributos menor ou igual a que maximizam a utilidade por bit, usando os resultados do estudo de ablação.
7. Treine um modelo para cada tamanho possível e avalie a utilidade dele como um porcentagem da utilidade do modelo de referência treinado em todos os atributos.
8. Representar os resultados em um gráfico em que o eixo x é o tamanho do treinamento em bits, e o eixo y é a porcentagem da receita gerada desse modelo em comparação com o valor de referência.

Em seguida, as adtechs podem repetir as etapas de 5 a 8 nos experimentos de tráfego em tempo real usando dados enviados via temporaryUnlimitedEgressPayload. As adtechs podem compartilhar os resultados dos experimentos de tráfego off-line e em tempo real com o Sandbox de privacidade para informar a decisão sobre o tamanho de egressPayload.

O cronograma desses experimentos, bem como o cronograma para definir o tamanho de egressPayload em relação ao valor resultante, está além do escopo deste documento e serão incluídos em uma atualização posterior.

Medidas de proteção de dados

Vamos aplicar várias proteções aos dados de saída, incluindo:

1. O egressPayload e o temporaryUnlimitedEgressPayload terão ruídos.
2. Para minimização e proteção de dados, o temporaryUnlimitedEgressPayload vai disponíveis apenas durante os experimentos de tamanho, em que vamos determinar o tamanho correto para egressPayload.

Permissões

Controle do usuário

• A proposta tem o objetivo de oferecer aos usuários acesso à lista de apps instalados que armazenaram pelo menos um indicador de app protegido ou um público-alvo personalizado.
• Os usuários podem bloquear e remover apps dessa lista. O bloqueio e a remoção fazem o seguinte:
  • Limpa todos os indicadores de apps protegidos e públicos-alvo personalizados associados a o app.
  • Impedem que os apps armazenem novos públicos-alvo personalizados e indicadores de app protegidos.
• Os usuários podem redefinir completamente os indicadores de apps protegidos e a API Protected Audience. Quando isso acontece, todos os apps protegidos Os indicadores e públicos-alvo personalizados no dispositivo são excluídos.
• Os usuários podem desativar completamente o Sandbox de privacidade do Android, que inclui a API Protected App Signals e a API Protected Audience. Quando esse é o caso, as APIs Protected Audience e Protected App Signals retornam uma mensagem de exceção padrão: SECURITY_EXCEPTION.

Permissões e controle do app

A proposta tem como objetivo oferecer aos apps controle sobre os indicadores de apps protegidos:

• Um app pode gerenciar as próprias associações com os indicadores de apps protegidos.
• Um app pode conceder permissões a plataformas de adtech terceirizadas para gerenciar Indicadores de apps protegidos em nome dele.

Controle da plataforma de adtech

Esta proposta descreve maneiras que as adtechs podem usar para controlar os indicadores de apps protegidos:

• Todas as adtechs precisam se inscrever no Sandbox de privacidade e fornecer um domínio "site" ou "origem" que corresponda a todos os URLs para indicadores de apps protegidos.
• As adtechs podem fazer parcerias com apps ou SDKs para fornecer tokens de verificação que são usados para verificar a criação de indicadores de apps protegidos. Quando esse processo é delegado a um parceiro, a criação de indicadores de apps protegidos pode ser configurada para exigir confirmação da adtech.