Suporte para a segmentação por público-alvo personalizado usando o FLEDGE

Enviar feedback

Atualizações recentes

  • Foi adicionada uma proposta para delegação de público-alvo personalizado.
  • O requisito de k-anonimato foi removido do URL de atualização diária.

Visão geral

Na publicidade para dispositivos móveis, os anunciantes procuram mostrar anúncios para usuários possivelmente interessados com base em interações anteriores com o app do anunciante. Por exemplo, o desenvolvedor do SportingGoodsApp pode querer mostrar um anúncio para usuários que tenham deixado itens no carrinho como um lembrete para concluir a compra. Geralmente, o setor descreve essa ideia geral com termos como "remarketing" e "segmentação por público-alvo personalizado".

Atualmente, esses casos de uso são implementados ao compartilhar com plataformas de adtech as informações contextuais sobre como o anúncio é mostrado (por exemplo, o nome do app em que ele aparece) e informações particulares, como listas de público-alvo. Com essas informações, os anunciantes podem selecionar anúncios relevantes nos respectivos servidores.

O FLEDGE no Android engloba as APIs apresentadas abaixo para ajudar plataformas de adtech e anunciantes a oferecer suporte a casos de uso comuns de interação. Esse suporte limita o compartilhamento dos identificadores entre apps e dificulta o acesso de terceiros às informações de interação do usuário no app:

  1. API Custom Audience: essa API é focada na abstração do "público-alvo personalizado", que representa um público-alvo com intenções comuns designado pelo anunciante. As informações do público-alvo ficam armazenadas no dispositivo e podem ser associadas a possíveis anúncios relevantes para esse público e a metadados arbitrários, como indicadores de lances. Essas informações podem ser usadas para orientar os lances do anunciante, a filtragem de anúncios e a renderização.
  2. API Ad Selection: oferece um framework para organizar os fluxos de trabalho das plataformas de adtech. Esses fluxos usam os indicadores do dispositivo para escolher um anúncio "vencedor", considerando anúncios candidatos armazenados localmente e realizando mais processamento dos anúncios candidatos que a plataforma retorna para o dispositivo.
Figura 1. Fluxograma que mostra o fluxo de trabalho para gerenciar um público-alvo personalizado e a escolha de anúncios no Sandbox de privacidade no Android.

De modo geral, a integração funciona desta maneira:

  1. O SportingGoodsApp quer lembrar os usuários de comprar itens deixados no carrinho de compras por mais de dois dias. O app usa a API Custom Audience para adicionar o usuário à lista de público-alvo "produtos no carrinho". A plataforma gerencia e armazena essa lista de público-alvo no dispositivo, limitando o compartilhamento com terceiros. O SportingGoodsApp usa uma plataforma de adtech para veicular anúncios para usuários na lista de público-alvo. A plataforma, por sua vez, gerencia os metadados de listas de público-alvo e apresenta anúncios candidatos, que serão analisados pelo fluxo de trabalho de seleção de anúncios. A plataforma pode ser configurada para buscar periodicamente anúncios atualizados baseados no público-alvo em segundo plano. Isso ajuda a manter a lista de anúncios candidatos com base no público-alvo atualizada e não correlacionada às solicitações enviadas a servidores de anúncios de terceiros durante a oportunidade de anúncio, ou seja, solicitações de anúncios contextuais.

  2. Ao jogar o FrisbeeGame no mesmo dispositivo, o usuário pode receber um anúncio com um lembrete para concluir a compra de itens deixados no carrinho de compras do SportingGoodsApp. Para fazer isso, o FrisbeeGame (com um SDK de anúncios integrado) invoca a API Ad Selection, que seleciona um anúncio vencedor para o usuário com base nas listas de público-alvo de que ele faz parte. Neste exemplo, o público-alvo personalizado é "produtos no carrinho", criado pelo SportingGoodsApp. O fluxo de trabalho de seleção de anúncios pode ser configurado para considerar dois tipos de anúncios: aqueles extraídos dos servidores das plataformas e os encontrados no dispositivo, associados aos públicos-alvo personalizados e outros indicadores no aparelho. O fluxo de trabalho também pode ser personalizado pela plataforma de adtech e pelo SDK de anúncios com lances personalizados e uma lógica de pontuação para atingir as metas de publicidade adequadas. Essa abordagem permite que os dados de interesses ou de interações em apps do usuário sejam usados para selecionar os anúncios, limitando o compartilhamento desses dados com terceiros.

  3. O SDK do app que veicula o anúncio ou da plataforma de adtech renderiza o anúncio selecionado.

  4. A plataforma facilita a geração de relatórios sobre resultados da seleção de anúncios e impressões. Esse recurso de geração de relatórios é complementar à API Attribution Reporting. As plataformas adtech podem ser personalizadas de acordo com cada relatório.

Acessar o FLEDGE para buscar APIs do Android

As plataformas de adtech precisam se registrar para acessar o FLEDGE para APIs do Android. Consulte Registrar uma conta do Sandbox de privacidade para saber mais.

Gerenciamento de público-alvo personalizado

Público-alvo personalizado

Um público-alvo personalizado representa um grupo de usuários, conforme determinado pelo anunciante, com intenções ou interesses comuns. Um SDK ou app pode especificar um público-alvo personalizado, por exemplo, alguém que "deixou itens no carrinho de compras" ou "concluiu os níveis para iniciantes" de um jogo. A plataforma mantém e armazena informações de público-alvo localmente no dispositivo. Além disso, ela não expõe a que públicos-alvo personalizados o usuário pertence. Os públicos-alvo personalizados são diferentes do FLEDGE nos grupos de interesse do Chrome e não podem ser compartilhados na Web nem nos apps. Isso ajuda a limitar o compartilhamento de informações do usuário.

Um app do anunciante ou o SDK integrado pode aderir ou sair de um público-alvo personalizado com base em informações como o engajamento do usuário em determinado app.

Metadados de público-alvo personalizado

Cada público-alvo personalizado contém os metadados abaixo:

  • Proprietário: nome do pacote do app proprietário. Isso é definido implicitamente como o nome do pacote do app autor da chamada.
  • Comprador: rede de publicidade do comprador, que gerencia anúncios para esse público-alvo personalizado. O comprador também representa as partes que podem acessar o público-alvo personalizado e buscar informações relevantes sobre anúncios. O comprador é especificado de acordo com o formato eTLD+1.
  • Nome: um nome ou identificador arbitrário para o público-alvo personalizado, como um usuário que "abandonou o carrinho de compras". Por exemplo, esse atributo pode ser usado como um dos critérios de segmentação nas campanhas de publicidade do anunciante ou como uma string de consulta no URL para buscar o código de lance.
  • Prazo de ativação e validade: esses campos definem o período pelo qual esse público-alvo personalizado vai permanecer válido. A plataforma usa essas informações para remover a associação a um público-alvo personalizado. O prazo de validade não pode exceder uma janela de duração máxima, para limitar a vida útil de um público-alvo personalizado.
  • URL de atualização diária: o URL usado pela plataforma para buscar anúncios candidatos e outros metadados definidos nos campos "Indicadores de lances do usuário" e "Indicadores de lances confiáveis" de maneira recorrente. Confira mais detalhes na seção sobre como buscar anúncios candidatos para públicos-alvo personalizados.
  • Indicadores de lances do usuário: indicadores específicos da plataforma de adtech para estabelecer lances de anúncios de remarketing. Exemplos de indicadores incluem a localização aproximada do usuário, a localidade de preferência, entre outros.
  • Dados de lances confiáveis: as plataformas de adtech contam com dados em tempo real para orientar o processo de escolha e pontuação dos anúncios. Por exemplo, um anúncio pode esgotar o orçamento definido e ter a veiculação interrompida imediatamente. Uma plataforma de adtech pode definir um endpoint do URL em que esses dados em tempo real podem ser buscados e o conjunto de chaves para as quais a pesquisa em tempo real precisa ser realizada. Essa solicitação será processada por um servidor confiável, gerenciado pela plataforma de adtech.
  • URL da lógica de lances: o URL usado pela plataforma para buscar o código de lances da plataforma de demanda. A plataforma realiza essa etapa quando um leilão de anúncios é iniciado.
  • Anúncios: uma lista de anúncios candidatos para o público-alvo personalizado. Isso inclui metadados de anúncios específicos da plataforma de adtech e um URL para renderizar o anúncio. Quando um leilão é iniciado para o público-alvo personalizado, essa lista de metadados do anúncio é considerada. A lista de anúncios vai ser atualizada usando o endpoint do URL de atualização diária, quando possível. Devido a restrições de recursos em dispositivos móveis, apenas um número limitado de anúncios pode ser armazenado para um público-alvo personalizado.

Delegação de público-alvo personalizado

A configuração e a definição tradicionais de público-alvo personalizado geralmente dependem de tecnologias e integrações do lado do servidor impulsionadas por adtechs em parceria com clientes e parceiros de agências e anunciantes. O FLEDGE permite a definição e a configuração de públicos-alvo personalizados de maneira que preserva a privacidade. Para participar de um público-alvo personalizado, 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 em dispositivos, como parceiros de medição para dispositivos móveis (MMPs, na sigla em inglês) e plataformas de fornecimento (SSPs). O objetivo das APIs do FLEDGE é oferecer suporte a esses SDKs, fornecendo soluções flexíveis para o gerenciamento de públicos-alvo personalizados, permitindo que os autores de chamadas no dispositivo invoquem a criação de públicos-alvo personalizados em nome dos compradores. Esse processo é chamado de delegação de público-alvo personalizado. Configure a delegação de público-alvo personalizado seguindo estas etapas:

Aderir a um público-alvo personalizado

Há duas maneiras de aderir a um público-alvo personalizado:

joinCustomAudience()

Um app ou SDK pode solicitar a adesão a um público-alvo personalizado chamando o método joinCustomAudience() após instanciar o objeto CustomAudience com os parâmetros esperados. Confira um exemplo de snippet de código ilustrativo:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchCustomAudience()

Um app ou SDK pode solicitar a adesão a um público-alvo personalizado em nome de uma adtech que não tem uma presença no dispositivo, chamando fetchCustomAudience() com os parâmetros esperados, como no exemplo abaixo:

CustomAudienceFetchRequest fetchRequest = new CustomAudienceFetchRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchCustomAudience(fetchRequest);

O endpoint do URL, de propriedade do comprador, responde com um objeto JSON CustomAudience no corpo da resposta. Os campos de comprador e proprietário do público-alvo personalizado são ignorados e preenchidos automaticamente pela API. Além disso, a API impõe que o URL de atualização diária também corresponda ao eTLD+1 do comprador.

{
 "name": "running-shoes",
 "activation_time": 1680603133,
 "expiration_time": 1680803133,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": "key1",
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": "key2",
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

A API fetchCustomAudience() determina a identidade do comprador usando o eTLD+1 de fetchUri. A identidade do comprador CustomAudience é usada para executar as mesmas verificações de autorização e registro de app feitas por joinCustomAudience(). Essa ação não pode ser alterada pela resposta de busca. O proprietário de CustomAudience é o nome do pacote do aplicativo que fez a chamada. Não há outra validação de fetchUri além da verificação do eTLD+1 e, especificamente, não há verificação de k-anonimato. A API fetchCustomAudience() emite uma solicitação HTTP GET para fetchUri e espera um objeto JSON que represente o público-alvo personalizado. Os mesmos valores obrigatórios e opcionais e os valores padrão dos campos de objeto de público-alvo personalizado são aplicados à resposta. Saiba mais sobre os requisitos e as limitações atuais no nosso guia para desenvolvedores. Toda resposta de erro HTTP do comprador faz com que o CustomAudience falhe. Especificamente, uma resposta de status HTTP 429 (solicitações em excesso) bloqueará solicitações do aplicativo atual por um período a ser definido. As falhas são informadas ao autor da chamada de API, que tem a responsabilidade de tentar de novo em caso de falhas temporárias (por exemplo, servidor que não responde ou tempos limite) ou lidar com falhas persistentes (como falhas de validação de dados ou qualquer outro erro não temporário na comunicação com o servidor).

O objeto CustomAudienceFetchRequest permite que o autor da chamada de API defina algumas informações para o público-alvo personalizado usando as propriedades opcionais mostradas no exemplo acima. Se especificados, esses valores não podem ser substituídos pela resposta do comprador recebida pelo comprador. O FLEDGE vai ignorar os campos na resposta. Uma representação JSON do conteúdo de CustomAudience, parcialmente definida pelo autor da chamada de API, está incluída na solicitação GET para fetchUri em um cabeçalho X-CUSTOM-AUDIENCE-DATA especial. O tamanho dos dados especificados para o público-alvo personalizado é limitado a 8 KB.

Como não há uma verificação k-anonimato, é possível usar fetchUri para a verificação do comprador e ativar o compartilhamento de informações entre o comprador e o SDK. Para facilitar a verificação de público-alvo personalizado, o comprador pode fornecer um token de verificação. O SDK no dispositivo precisa incluir esse token em fetchUri para que o endpoint hospedado pelo comprador possa buscar o conteúdo do público-alvo personalizado e usar o token de verificação para checar se a operação fetchCustomAudience() corresponde ao comprador e se a origem é de um parceiro confiável no dispositivo. Para compartilhar informações, o comprador pode concordar com o autor da chamada no dispositivo para que algumas informações usadas para criar o público-alvo personalizado sejam adicionadas como parâmetros de consulta ao fetchUri. Isso permite que o comprador audite as chamadas e detecte se um token de validação foi usado por uma adtech maliciosa para criar diferentes públicos-alvo personalizados.

Observação sobre armazenamento e definição do token de verificação

  • O token de verificação não é usado pelo FLEDGE e é opcional.

    • O token de verificação pode ser usado pelo comprador para checar se os públicos-alvo estão sendo criados em nome dele.
    • A proposta do FLEDGE não especifica um formato para o token de verificação nem como o comprador transfere o token de verificação para o autor da chamada. Por exemplo, o token de verificação pode ser pré-carregado no SDK ou no back-end do proprietário ou extraído em tempo real pelo SDK do proprietário no servidor do comprador.

Sair de um público-alvo personalizado

O proprietário de um público-alvo personalizado pode sair desse grupo. Para isso, é necessário chamar o método leaveCustomAudience(), conforme mostrado no snippet de código ilustrativo abaixo:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

Para reduzir o uso do armazenamento e de outros recursos do dispositivo, os públicos-alvo personalizados expiram e são removidos do dispositivo após um período predeterminado. O valor padrão precisa ser determinado. Esse valor pode ser modificado pelo proprietário.

Controle do usuário

  • A proposta tem o objetivo de proporcionar aos usuários acesso à lista de apps instalados que criaram pelo menos um público-alvo personalizado.
  • Os usuários podem remover apps dessa lista. Após a remoção, todos os públicos-alvo personalizados associados ao app são excluídos, e o app não pode ser incluído em novos grupos.
  • Os usuários podem redefinir o FLEDGE completamente. Quando isso acontece, todos os públicos-alvo personalizados no dispositivo são excluídos.
  • Os usuários podem desativar completamente o Sandbox de privacidade do Android, o que inclui o FLEDGE. Quando isso acontece, as APIs do FLEDGE retornam uma mensagem de exceção padrão: SECURITY_EXCEPTION.

Ainda estamos trabalhando na elaboração desse recurso. Mais detalhes serão incluídos em uma atualização futura.

Permissões e controle do app

A proposta tem como objetivo permitir que os apps controlem os públicos-alvo personalizados:

  • Os apps podem gerenciar as associações realizadas com públicos-alvo personalizados.
  • Os apps podem conceder permissões a plataformas de tecnologias de publicidade de terceiros para gerenciar públicos-alvo personalizados em nome do app.

Ainda estamos trabalhando na elaboração desse recurso. Mais detalhes serão incluídos em uma atualização futura.

Controle da plataforma de adtech

Esta proposta descreve maneiras que as adtechs podem usar para controlar públicos-alvo personalizados:

  • As adtechs se inscrevem no Sandbox de privacidade e fornecem um domínio eTLD+1 que corresponde a todos os URLs de um público-alvo personalizado.
  • As adtechs podem fazer parcerias com apps ou SDKs para fornecer tokens de verificação usados para checar a criação de um público-alvo personalizado. Quando esse processo é delegado a um parceiro, a criação de públicos-alvo personalizados pode ser configurada para exigir o reconhecimento da adtech.
  • Uma adtech pode desativar as chamadas de joinCustomAudience em nome delas e permitir que a API fetchCustomAudience ative todas as chamadas de públicos-alvo personalizados. O controle pode ser atualizado durante o registro no Sandbox de privacidade. O controle permite todas as adtechs ou nenhuma delas. Devido a limitações da plataforma, as permissões de delegação não podem ser feitas para cada adtech específica.

Ainda estamos trabalhando na elaboração desse recurso. Mais detalhes serão incluídos em uma atualização futura.

Resposta de metadados e anúncios candidatos

Os anúncios candidatos e os metadados retornados de uma plataforma de compra precisam incluir os campos abaixo:

  • Metadados: metadados de anúncios para compra específicos de tecnologias de publicidade. Por exemplo, isso pode incluir informações sobre a campanha publicitária e critérios de segmentação, como local e idioma.
  • URL de renderização: o endpoint para renderizar o criativo do anúncio.
  • Filtro: informações opcionais necessárias para que o FLEDGE filtre anúncios com base nos dados no dispositivo. Para mais detalhes, consulte Lógica de filtragem da compra.

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

O objetivo desta proposta é melhorar a privacidade com a introdução da API Ad Selection, que organiza a execução de leilões para plataformas de adtech.

Atualmente, as plataformas de adtech costumam realizar processos de lance e seleção de anúncios exclusivamente em servidores próprios. Com essa proposta, os públicos-alvo personalizados e outros indicadores sensíveis de comportamento do usuário, como informações de pacotes instalados disponíveis, só poderão ser acessados usando a API Ad Selection. Além disso, para o caso de uso de remarketing, os anúncios candidatos serão buscados fora da banda, ou seja, fora do contexto em que são mostrados. As plataformas de adtech vão precisar se preparar para que partes da lógica atual de leilão e seleção de anúncios sejam implantadas e executadas no dispositivo. Essas plataformas podem estudar estas mudanças no fluxo de trabalho de seleção de anúncios:

  • Quando as informações sobre os pacotes instalados não estiverem disponíveis no servidor, as plataformas de adtech poderão enviar vários anúncios contextuais ao dispositivo e invocar o fluxo de trabalho de seleção de anúncios para ativar o filtro com base na instalação de apps e maximizar as chances de mostrar um anúncio relevante.
  • Como os anúncios de remarketing são buscados fora da banda, pode ser necessário atualizar os modelos de lances atuais. As plataformas de adtech podem criar submodelos de lances, que têm uma implementação baseada em um padrão conhecido como modelo de duas torres (link em inglês). Os submodelos analisam recursos de anúncios e indicadores de contexto separadamente e combinam os resultados no dispositivo para prever lances. Esse processo se beneficia dos leilões do lado do servidor e dos leilões para qualquer oportunidade de anúncio.

Essa abordagem permite que os dados de interações no app do usuário sejam usados para selecionar anúncios e limita o compartilhamento desses dados com terceiros.

Figura 2. Fluxograma que mostra a iniciação do fluxo de trabalho de seleção de anúncios.

Esse fluxo de trabalho de seleção de anúncios organiza a execução no dispositivo do código JavaScript fornecido pelas tecnologias de publicidade com base nesta sequência:

  1. Execução da lógica de lances da compra
  2. Filtragem e processamento de anúncios de compra
  3. Execução de lógica de decisão da venda

Para seleções de anúncios que envolvem públicos personalizados, a plataforma vai buscar o código JavaScript de compra com base no endpoint do URL público definido pelos metadados "URL da lógica de lances" do público-alvo personalizado. O endpoint do URL para o código de decisão da venda também vai ser transmitido como uma entrada para iniciar o fluxo de trabalho de seleção de anúncios.

O modelo de seleções de anúncios que não envolvem públicos-alvo personalizados está em fase de desenvolvimento.

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

Quando um app precisa mostrar um anúncio, o SDK da plataforma de tecnologias de publicidade pode iniciar o fluxo de trabalho de seleção de anúncios chamando o método selectAds() depois de instanciar o objeto AdSelectionConfig com os parâmetros esperados:

  • Vendedor: identificador da plataforma de venda de anúncios, seguindo o formato eTLD+1.
  • URL da lógica de decisão: quando um leilão de anúncios é iniciado, a plataforma usa esse URL para buscar o código JavaScript da plataforma de venda e escolher um anúncio vencedor.
  • Compradores de públicos-alvo personalizados: uma lista de plataformas de compra que têm como demanda o público personalizado para o leilão. Ela segue o formato eTLD+1.
  • Indicadores de seleção de anúncios: informações sobre o leilão (tamanho e formato do anúncio, entre outros).
  • Indicadores do vendedor: indicadores específicos da plataforma de fornecimento.
  • URL de indicadores de pontuação confiáveis: o URL do endpoint dos indicadores confiáveis da plataforma de venda, em que é possível buscar informações específicas sobre o criativo, em tempo real.
  • Indicadores por comprador: os lados participantes podem usar esse parâmetro para fornecer informações sobre o leilão. Por exemplo, esse parâmetro pode incluir informações contextuais abrangentes que são úteis para determinar os lances.

O snippet de código ilustrativo abaixo mostra um SDK da plataforma de tecnologias de publicidade que inicia o fluxo de trabalho de seleção de anúncios definindo primeiro a AdSelectionConfig e depois invocando selectAds para receber o anúncio vencedor:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

Lógica de lances de compra

A lógica de lances normalmente é fornecida pelas plataformas de compra. O objetivo do código é determinar os lances que são feitos para anúncios candidatos. Ele pode aplicar outra lógica de negócios para determinar esse resultado.

A plataforma usa os metadados do "URL da lógica de lances" do público-alvo personalizado para buscar o código JavaScript, que precisa incluir a assinatura de função abaixo:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

O método generateBid() retorna o valor do lance calculado. A plataforma invoca essa função para todos os anúncios, contextuais ou de remarketing, em sequência. Caso haja vários provedores de lógica de lances, o sistema não vai poder garantir a sequência de execução desses provedores.

A função espera receber os parâmetros abaixo:

  • Anúncio: o anúncio considerado pelo código do lance da plataforma de compra. Ele vai ser um anúncio de um público-alvo personalizado qualificado.
  • Indicadores de leilão: indicadores específicos da plataforma de venda.
  • Indicadores por comprador: os lados participantes podem usar esse parâmetro para fornecer informações sobre o leilão. Por exemplo, esse parâmetro pode incluir informações contextuais abrangentes que são úteis para determinar os lances.
  • Indicadores de lances confiáveis: as plataformas de tecnologias de publicidade contam com dados em tempo real para orientar o processo de escolha e pontuação dos anúncios. Por exemplo, uma campanha publicitária pode esgotar o orçamento definido e ter a veiculação dos anúncios interrompida imediatamente. Uma plataforma de tecnologias de publicidade pode definir um endpoint do URL em que esses dados em tempo real podem ser buscados e o conjunto de chaves para as quais a pesquisa em tempo real precisa ser realizada. O servidor gerenciado da plataforma de tecnologias de publicidade que atender a essa solicitação vai passar a ser um servidor confiável gerenciado pela plataforma.
  • Indicadores contextuais: podem incluir o carimbo de data/hora aproximadas ou informações do local aproximado.
  • Indicadores do usuário: podem incluir informações disponíveis, como o pacote instalado.

Lógica de filtragem da compra

As plataformas de compra vão poder filtrar anúncios com base em outros indicadores no dispositivo, que ficam disponíveis durante a fase de seleção de anúncios. Por exemplo, as plataformas de adtech podem implementar recursos de limite de frequência nesse momento. Quando há vários provedores de lógica de filtragem, o sistema garante a sequência de execução desses provedores.

A lógica de filtragem da compra pode ser implementada como parte da lógica de lances e retornar um valor de lance 0 para um determinado anúncio.

Além disso, as plataformas de compra vão poder indicar que um determinado anúncio precisa ser filtrado de acordo com outros indicadores no dispositivo, que estão disponíveis para o FLEDGE e não saem do dispositivo. À medida que solidificamos os projetos da lógica de filtragem extra, as plataformas de compra vão passar a seguir essa mesma estrutura para indicar que a filtragem é necessária.

Lógica de pontuação de venda

A lógica de pontuação geralmente é apresentada pela plataforma de venda. O objetivo do código é definir um anúncio vencedor com base nos resultados da lógica de lances. Ele pode aplicar outra lógica de negócios para determinar o resultado. Caso haja vários provedores de lógica de decisão, o sistema não vai poder garantir a sequência de execução desses provedores. A plataforma usa o parâmetro de entrada "URL da lógica de decisão" da API selectAds() para buscar o código JavaScript, que precisa incluir a assinatura de função abaixo:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

A função espera receber os parâmetros abaixo:

  • Anúncio: o anúncio que está sendo avaliado, resultante da função generateBid().
  • Lance: valor do lance resultante da função generateBid().
  • Configuração do leilão: parâmetro de entrada para o método selectAds().
  • Indicadores de pontuação confiáveis: as plataformas de tecnologias de publicidade contam com dados em tempo real para orientar o processo de filtragem e pontuação de anúncios. Por exemplo, o editor de um app pode bloquear a exibição de anúncios de uma campanha publicitária no respectivo app. Para isso, o app busca dados do parâmetro de URL dos indicadores de pontuação confiáveis da configuração do leilão. O servidor que atende a essa solicitação precisa ser um servidor confiável, gerenciado por uma plataforma de tecnologias de publicidade.
  • Indicadores contextuais: podem incluir o carimbo de data/hora aproximadas ou informações do local aproximado.
  • Indicador do usuário: pode incluir informações como a app store que iniciou a instalação do app.
  • Indicador de público-alvo personalizado: se o anúncio que está sendo pontuado for originado de um público-alvo personalizado gerado no dispositivo, o anúncio vai incluir informações como o leitor e o nome do público alvo personalizado.

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

Na proposta, o sistema vai buscar o código de leilão fornecido pela plataforma de tecnologias de publicidade em endpoints de URL configuráveis e executará esse código no dispositivo. Devido às restrições de recursos em dispositivos móveis, o código do leilão precisa seguir estas diretrizes:

  • A execução do código precisa ser concluída em um período previamente definido. Esse limite vai ser aplicado de maneira uniforme a todas as redes de publicidade do comprador. Os detalhes sobre esse limite vão ser compartilhados em uma atualização futura.
  • O código precisa ser autônomo e não ter dependências externas.

Já que o código do leilão, assim como a lógica de lances, pode precisar acessar dados particulares do usuário, como fontes de instalação de apps, o ambiente de execução não fornece acesso à rede ou ao armazenamento.

Linguagem de programação

O código do leilão fornecido pela plataforma de tecnologias de publicidade precisa ser programado em JavaScript. Isso permite que as plataformas de tecnologias de publicidade compartilhem códigos de lances entre plataformas que oferecem suporte ao Sandbox de privacidade, por exemplo.

Renderização de anúncios vencedores

O anúncio com a maior pontuação é considerado o vencedor do leilão. Nesta proposta inicial, o anúncio vencedor é transmitido ao SDK para renderização.

O objetivo é ampliar essa solução para garantir que o app e o SDK não consigam usar as informações sobre o anúncio vencedor para descobrir se um usuário faz parte de determinado público-alvo personalizado ou descobrir o histórico de engajamento com apps do usuário, de modo semelhante à proposta de frames isolados (link em inglês) do Chrome.

Relatórios de impressões

Depois que o anúncio for renderizado, a impressão vencedora poderá ser informada às plataformas de compra e venda participantes. A plataforma vai invocar a lógica de geração de relatórios nesta ordem:

  1. Relatórios de venda.
  2. Relatórios de compra.

Usando os relatórios, as plataformas de compra e venda conseguem enviar informações importantes contidas no dispositivo aos servidores, como informações sobre lances, nome do público-alvo personalizado, entre outras, o que permite que eles habilitem os recursos necessários, como adequação de orçamento em tempo real, atualizações do modelo de lances e fluxos de trabalho de faturamento precisos. Esse suporte oferecido para geração de relatórios de impressão é complementar à API Attribution Reporting.

Relatórios de venda

A plataforma vai invocar a função JavaScript reportResult() no código informado pela plataforma de fornecimento que foi transferido por download do parâmetro do URL da lógica de decisão do vendedor para a API selectAds():

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    return reporting_url, signals_for_buyer;
}

Resultado:

  • URL do relatório: a plataforma vai invocar esse URL retornado da função.

A plataforma de fornecimento pode codificar os indicadores relevantes no URL do relatório para os ajudar a ter mais informações sobre o leilão e o anúncio vencedor. Por exemplo, ela pode incluir os indicadores abaixo:

  • URL de renderização do anúncio
  • Valor do lance vencedor
  • Nome do app
  • Identificadores de consulta
  • Indicadores para o comprador: para oferecer suporte ao compartilhamento de dados entre o fornecimento e a demanda, a plataforma vai transmitir esse valor de retorno como um parâmetro de entrada ao código de relatório da demanda.

Relatórios de compra

A plataforma vai invocar a função JavaScript reportResult() no código informado por demanda que foi transferido por download dos metadados do URL da lógica de lances do público-alvo personalizado associado ao leilão.

reportResult(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    return reporting_url;
}

Entrada:

  • auction_signals e per_buyer_signals serão buscados em AuctionConfig. Qualquer informação que a plataforma de compra precise transmitir ao URL de relatório pode ser proveniente desse dado.
  • signals_for_buyer é o resultado de reportResult da plataforma de venda. Isso proporciona à plataforma de venda a oportunidade de compartilhar dados com a plataforma de compra para fins de geração de relatórios.
  • contextual_signals contém informações como o nome do app, ao passo que custom_audience_signals contém informações do público-alvo personalizado. Outras informações podem ser adicionadas no futuro.

Resultado:

  • URL do relatório: a plataforma vai invocar esse URL retornado da função.

Servidor confiável gerenciado pela plataforma de tecnologias de publicidade

Atualmente, a lógica de seleção de anúncios exige informações em tempo real, como o nível de uso de um orçamento, a fim de determinar se os anúncios candidatos precisam ser selecionados para o leilão. As plataformas de compra e venda poderão receber essas informações nos servidores em que operam. Para minimizar o vazamento de informações sensíveis por esses servidores, a proposta estabelece estas restrições:

  • O comportamento desses servidores, descrito posteriormente nesta seção, não causa vazamento de informações dos usuários.
  • Os servidores não criam perfis de pseudônimos com base nos dados visto, ou seja, eles precisam ser "confiáveis".

Compra: após iniciar a lógica de lances de compra, a plataforma realiza uma busca HTTP de dados de lances confiáveis no servidor confiável. O URL é composto anexando o URL e as chaves presentes nos metadados de indicadores de lances confiáveis do público-alvo personalizado que está sendo processado. A busca é feita apenas ao processar anúncios dos públicos-alvo personalizados contidos no dispositivo. Nesta etapa, a plataforma de compra pode aplicar orçamentos, verificar o estado de pausa e retomada da campanha, executar segmentação, entre outros.

Confira abaixo um exemplo de URL para buscar dados de lances confiáveis com base nos metadados do indicador de lances confiáveis do público-alvo personalizado:

https://www.kv-server.example/getvalues?keys=key1,key2

A resposta do servidor precisa ser um objeto JSON com chaves key1, key2 etc., e com os valores que vão ser disponibilizados para as funções de lance do comprador.

Venda: semelhante ao fluxo de compra acima, a plataforma de venda pode querer buscar informações sobre criativos considerados no leilão. Por exemplo, é possível que um editor queira garantir que determinados criativos não sejam mostrados no app devido a questões de brand safety. Essas informações podem ser buscadas e disponibilizadas para a lógica de leilão da venda. Semelhante à pesquisa no servidor confiável da plataforma de compra, a pesquisa no servidor confiável da plataforma de venda também acontece por uma busca HTTP. O URL é composto anexando o URL de indicadores de pontuação confiáveis a URLs de renderização dos criativos para os quais os dados precisam ser buscados.

Confira abaixo um exemplo de URL para buscar informações sobre criativos considerados no leilão, com base nos URLs de renderização de criativos:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

A resposta do servidor precisa ser um objeto JSON com chaves de URLs de renderização enviados na solicitação.

Esses servidores funcionam de maneira confiável para oferecer vários benefícios de segurança e privacidade:

  • O valor de retorno do servidor para cada chave só pode ser considerado confiável de acordo com a própria chave.
  • O servidor não realiza a geração de registros do evento.
  • O servidor não tem outros efeitos colaterais relacionados a essas solicitações.

Como mecanismo temporário, o comprador e o vendedor podem buscar esses indicadores de lance em qualquer servidor, incluindo aqueles que eles mesmos operam. No entanto, na versão de lançamento, a solicitação vai ser enviada somente a um servidor de tipo de chave-valor confiável.

Compradores e vendedores podem usar um mesmo servidor de tipo de chave-valor confiável para plataformas compatíveis com o Sandbox de privacidade no Android e na Web.