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

Enviar feedback

Na publicidade para dispositivos móveis, os anunciantes geralmente querem exibir 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 aos usuários que tenham deixado itens no carrinhos de compras para os lembrar de 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 tecnologias de publicidade as informações contextuais sobre como o anúncio é exibido, como 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 que plataformas de tecnologias de publicidade e anunciantes ofereçam suporte a casos de uso comuns com base em interação de maneiras que limitem o compartilhamento dos identificadores entre apps e das informações de interação do usuário com apps de terceiros:

  1. API Custom Audience: essa API é focada na abstração do "público-alvo personalizado", que representa um público-alvo designado pelo anunciante com intenções comuns. As informações do público-alvo ficam armazenadas no dispositivo e podem ser associadas a anúncios candidatos relevantes ao público-alvo 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: essa API oferece um framework que organiza os fluxos de trabalho das plataformas de tecnologias de publicidade que fazem uso dos indicadores do dispositivo para escolher um anúncio "vencedor", considerando anúncios candidatos armazenados localmente e realizando mais processamento de anúncios candidatos que a plataforma retorna para o dispositivo.
Figura 1. Fluxogramas que mostram o fluxo de trabalho personalizado de gerenciamento de público-alvo e a escolha de anúncios no Sandbox de privacidade no Android.

Em um nível mais alto, a integração funciona desta maneira:

  1. O SportingGoodsApp quer lembrar os usuários de comprar itens deixados no carrinho de compras para casos em que o usuário não concluiu a compra em até dois dias. O SportingGoodsApp 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 estabelece uma parceria com uma plataforma de tecnologias de publicidade para exibir anúncios aos usuários na lista de público-alvo. A plataforma de tecnologias de publicidade gerencia os metadados de listas de público-alvo e apresenta anúncios candidatos, que são disponibilizados ao fluxo de trabalho de seleção de anúncios para análise. A plataforma pode ser configurada para buscar periodicamente anúncios atualizados com base 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ção de anúncio contextual).

  2. Ao jogar o FrisbeeGame no mesmo dispositivo, o usuário pode ver um anúncio com um lembrete para que ele conclua 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 a fim de selecionar 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 anúncios extraídos dos servidores de plataformas de tecnologia de anúncios, além de anúncios no dispositivo associados aos públicos-alvo personalizados e outros indicadores no dispositivo. O fluxo de trabalho também pode ser personalizado pela plataforma de tecnologias de publicidade e pelo SDK de anúncios com lances personalizados e uma lógica de pontuação, a fim de atingir as metas de publicidade adequadas. Essa abordagem permite que os dados de interações ou de interesses 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 tecnologias de publicidade renderiza o anúncio selecionado.

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

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 usar um público-alvo personalizado para indicar um público-alvo específico, 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. 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:

  • Leitor: rede de publicidade do comprador, que gerencia anúncios para esse público-alvo personalizado.
  • Nome: um nome ou identificador arbitrário para o público-alvo personalizado, como um usuário que "deixou itens no carrinho de compras". Esse atributo pode ser usado como, por exemplo, um dos critérios de segmentação nas campanhas de publicidade do anunciante ou uma string de consulta no URL para buscar o código de lance.
  • Prazo de criaçã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 participação de usuários de 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 no campo "Indicadores de lances do usuário" de maneira recorrente. Veja 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 tecnologias de publicidade para estabelecer filtros e lances de anúncios de remarketing. Exemplos de indicadores incluem a localização aproximada do usuário, a localidade de preferência, entre outros.
  • 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, um anúncio pode esgotar o orçamento definido e ter a veiculação 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 com as quais a pesquisa em tempo real precisa ser realizada. O servidor que processa essa solicitação vai ser um servidor confiável, gerenciado pela plataforma de tecnologias de publicidade.
  • 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 tecnologias de publicidade 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, há um limite do número de anúncios que 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(), conforme apresentado no snippet de código ilustrativo abaixo:

CustomAudience audience = new CustomAudience(
    "com.sporting-goods.app",      // Owner. Defaults to the calling app's
                                   // package name.
    "com.example-dsp",             // Reader.
    "running-shoes",               // A logical name for the custom audience.
    currentTime,                   // Creation time.
    expirationTime,                // Expiration time.
    Uri.parse("https://..."),      // Daily update URL.
    biddingData,                   // Trusted Bidding Data key/value pairs.
    candidateAdsList,              // List of candidate ads related to
                                   // this custom audience.
    biddingLogicUrl
);

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

O app que chama joinCustomAudience() passa a ser o proprietário desse público-alvo personalizado. Ao chamar esse método, o app precisa especificar estas informações:

Leitor: representa as partes que podem acessar o público-alvo personalizado e buscar informações relevantes sobre anúncios.

Nome: o nome do público-alvo personalizado.

URL de atualização diária: o URL da lista de anúncios candidatos.

Anúncios candidatos: quando o proprietário de um público-alvo personalizado adere a um grupo de públicos-alvo, ele pode buscar anúncios candidatos em uma plataforma de compra. A plataforma também pode ser configurada para buscar anúncios periodicamente.

Sair de um público-alvo personalizado

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

// Define a custom audience populated with key fields.
CustomAudience audience = new CustomAudience(
    "com.sporting-goods.app",     // Owner. Defaults to
                                  // the calling app's package name.
    "com.example-dsp",            // Reader.
    "running-shoes"               // A logical name for the custom audience.
    ...
);

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

Para ajudar a preservar o uso do armazenamento e de outros recursos do dispositivo, os públicos-alvo personalizados expiram e são removidos do armazenamento do dispositivo após um período predeterminado. O valor padrão precisa ser determinado e 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 têm pelo menos um público-alvo personalizado associado ao app.
  • 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 será impedido de participar de novos públicos-alvo personalizados.

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 tecnologias de publicidade

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.

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 ter anúncios candidatos com base na interação do usuário armazenados no dispositivo. Assim, esses anúncios podem ser avaliadas no momento em que um leilão para esse público-alvo personalizado é realizado. É possível buscar anúncios candidatos e os metadados relacionados referentes a um público-alvo personalizado de duas maneiras complementares.

  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 tecnologias de publicidade podem usar esse recurso para manter a lista de anúncios atualizada e remover aqueles que não estiverem mais ativos ou sem orçamento restante. 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 tecnologias de publicidade podem querer usar esse recurso caso tenham a intenção de começar a 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 específicos de tecnologias de publicidade para compra. 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.

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 tecnologias de publicidade.

Atualmente, as plataformas de tecnologias de publicidade costumam realizar processos de lance e seleção de anúncios exclusivamente em servidores próprios. Com esta 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ó vão poder ser acessados usando a API Ad Selection. Além disso, para o caso de uso de remarketing, os anúncios candidatos vão ser buscados fora da banda, ou seja, fora do contexto em que são exibidos. As plataformas de tecnologias de publicidade 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 tecnologias de publicidade podem optar por 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 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 tecnologias de publicidade podem optar por criar submodelos de lances, cuja implementação pode ser baseada em um padrão chamado modelo de duas torres (link em inglês), que funciona com recursos de anúncios e indicadores de contexto separadamente e combina os resultados do submodelo no dispositivo para prever lances. Esse processo pode se beneficiar 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 fornecido pela plataforma 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ção 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 exibir 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 runAdAuction().

A API espera encontrar os parâmetros abaixo:

Vendedor: identificador da plataforma de venda de anúncios.

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.

Indicadores de leilão: 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:

AuctionConfig myAuctionConfig = new AuctionConfig {
    "com.example.app",         // Package name for the calling app.
    Uri.parse("https://..."),  // Decision logic URL.
    customAudienceBuyerList,   // List of package names
                               // for custom audience buyers.
    auctionSignals,            // Auction signals
    sellerSignals,             // Seller signals
    perBuyerSignals,           // Per buyer signals
    ...
};

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

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 vão ser feitos para anúncios candidatos, sendo que 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': ...};
}

A API 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. Pode ser um anúncio do público-alvo personalizado ou o anúncio retornado na resposta contextual.

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 tecnologias de publicidade 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 poder garantir a sequência de execução desses provedores.

A lógica de filtragem da compra vai ser executada após a lógica de lances.

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:

filterAd(ad, per_buyer_signals, trusted_bidding_signals, contextual_signals,
        user_signals) {
    // ...
    return is_filtered;
}

Essa função JavaScript espera receber parâmetros de entrada semelhantes aos da função de lógica de lances.

Lógica de decisã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, sendo que ele pode aplicar outra lógica de negócios para determinar esse 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 runAdAuction() 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 e o resultado das funções generateBid() e filterAd().

Lance: valor do lance resultante da função generateBid().

Configuração do leilão: parâmetro de entrada para o método runAdAuction().

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.

Visto 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 no app 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 vai 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, como informações sobre lances, nome do público-alvo personalizado, entre outras, para que os servidores 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 runAdAuction():

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 pela 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 vão ser 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 vão poder 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.

Veja 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 exibidos 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.

Veja 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.