O Sandbox de privacidade no Android Beta chegou. Aprenda a usar e envie feedback.

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

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Enviar feedback

Na publicidade para dispositivos móveis, os anunciantes procuram mostrar anúncios para usuários potencialmente interessados com base em interações anteriores com o app do anunciante. Por exemplo, o desenvolvedor do SportingGoodsApp pode querer mostrar um anúncio a usuários que tenham deixado itens no carrinho de compras 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" (entre aqueles com mais potencial armazenados localmente) e realizando mais processamento dos anúncios em potencial 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 em potencial, 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. Nesse 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, que são 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 com 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 de adtech podem fazer personalizações de acordo com suas demandas de relatórios.

Acessar o FLEDGE para 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 com intenções ou interesses em comum. Um SDK ou app pode especificar um público-alvo personalizado, como 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 em que públicos-alvo personalizados o usuário está conectado. 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 podem ser armazenados para um público-alvo personalizado.

Aderir a um público-alvo personalizado

Um app 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);

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 vão ser excluídos e o app não poderá ser incluído em novos grupos.

A elaboração desse recurso está em andamento. Mais detalhes vão ser incluídos em uma atualização futura.

Permissões e controle da plataforma de adtech

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 adtech terceirizadas para gerenciar públicos-alvo personalizados em nome do app.
  • A proposta tem como objetivo permitir que o usuário redefina o FLEDGE. Quando isso acontece, todos os públicos-alvo personalizados que foram gerados no dispositivo são excluídos.
  • A proposta também inclui dar aos usuários a opção de recusar completamente o Sandbox de privacidade no Android, o que inclui o FLEDGE. Quando isso acontece, as APIs do FLEDGE falham silenciosamente.

A elaboração desse recurso está em andamento. Mais detalhes vão ser incluídos em uma atualização futura.

Buscar anúncios candidatos para públicos-alvo personalizados

As plataformas de compra podem armazenar no dispositivo anúncios candidatos baseados na interação do usuário. Esses anúncios podem ser avaliados no momento em que um leilão para esse público-alvo personalizado é realizado. Há duas maneiras complementares de buscar anúncios candidatos e os metadados relacionados referentes a um público-alvo personalizado.

  1. Busca diária do sistema: ao aderir a um público-alvo personalizado, o app pode especificar um URL de atualização diária que vai ser consultado pela plataforma diariamente. As plataformas de adtech podem usar esse recurso para manter a lista de anúncios atualizada e remover os inativos ou sem orçamento. A plataforma vai garantir que um endpoint de URL transmita o limite de privacidade de k-anonimato (link em inglês) antes de processar a solicitação de busca de anúncio.
  2. Busca personalizada orientada pelo proprietário do público-alvo: ao adicionar um usuário a um público-alvo personalizado, o proprietário pode buscar anúncios candidatos em uma plataforma de compra. Os anúncios e metadados retornados podem ser armazenados no campo "anúncios" do público personalizado. As plataformas de adtech podem usar esse recurso caso queiram mostrar anúncios a um usuário imediatamente.

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 adtech. 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 as mudanças no fluxo de trabalho de seleção de anúncios abaixo:

  • 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 de base instalada do app 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 adtechs 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 adtech 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 adtech 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 adtech 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 adtech 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. Caso haja vários provedores de lógica de filtragem, o sistema não vai garantir 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 adtech 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 adtech.
  • 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 adtech 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 adtech precisa ser programado em JavaScript. Isso permite que as plataformas de adtech 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 cercados (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 adtech

Atualmente, a lógica de seleção de anúncios precisa de informações em tempo real, como o nível de uso de um orçamento, para determinar se os anúncios candidatos podem 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.