Suporte a leilões de vários vendedores com a mediação da API Protected Audience

Enviar feedback

As plataformas de publicidade de venda geralmente diversificam as origens de demanda de anúncios para otimizar a receita de publicidade. Com a mediação de anúncios, uma rede de publicidade ou um serviço invoca várias redes de publicidade para determinar o melhor anúncio para um certo espaço. Esta proposta mostra como a API Protected Audience no Android pode ser estendida para implementar a funcionalidade de mediação em hierarquia preservando a privacidade. Atualmente, as redes de publicidade oferecem aos desenvolvedores de apps várias maneiras de mediar leilões de anúncios de vários vendedores:

  1. Mediação em hierarquia: os desenvolvedores de apps definem uma lista ordenada de redes de publicidade, geralmente classificadas por eCPMs (link em inglês) históricos para a rede especificada. Essa lista é conhecida como uma cadeia de mediação. A plataforma de mediação do desenvolvedor do app chama as redes de publicidade na ordem em que estão listadas para determinar as origens de demanda de anúncios relevantes.
  2. Mediação programática: várias redes de publicidade são configuradas pelo desenvolvedor do app para participar dos lances em oportunidades de anúncios. Essas redes têm permissão para dar lances em tempo real com base no valor que elas atribuem a cada oportunidade.
  3. Mediação híbrida: uma combinação de técnicas de mediação programáticas e em hierarquia.

Mediação em hierarquia

Na mediação em hierarquia, quando há uma oportunidade de anúncio, um SDK de anúncios envia uma solicitação ao servidor de back-end. Em vez de responder à solicitação com um criativo de anúncio vencedor, o servidor responde com uma cadeia de mediação que contém uma lista de redes de publicidade ordenadas pelo eCPM histórico.

Diagrama do modelo de mediação em hierarquia
Figura 1. Modelo de mediação em hierarquia.

No modelo de hierarquia tradicional, um SDK de anúncios chama cada rede de publicidade, ou o próprio SDK de leilão, na ordem especificada pela cadeia de mediação. Se uma rede de publicidade puder atender à solicitação de anúncio, ela vai renderizar o anúncio. Caso contrário, a solicitação vai ser enviada para a próxima rede na cadeia. Esse processo é repetido até a solicitação ser atendida ou a cadeia chegar ao fim.

Em geral, a mediação em hierarquia é otimizada pela reorganização frequente da cadeia de mediação com base na reavaliação do eCPM de origens de demanda de anúncios próprias.

Mediação programática

A mediação programática, também conhecida como "lances de cabeçalho", é uma alternativa ao uso do eCPM histórico para determinar qual rede de publicidade tem a chance de veicular uma solicitação de anúncio. Com a mediação programática, os provedores usam os valores de lances em tempo real para encontrar o anúncio vencedor.

Diagrama do modelo de mediação programática
Figura 2: o modelo de mediação programática

Mediação híbrida

Algumas soluções de mediação programática combinam redes de publicidade em um modo híbrido de hierarquia e lances para fornecer mais controle ao anúncio, além de se beneficiar do uso de eCPMs ativos para maximizar a receita das redes participantes.

Em modelos de mediação híbrida, as redes de publicidade e os provedores de mediação podem oferecer mais flexibilidade aos desenvolvedores de apps, combinando elementos de hierarquia e lances em tempo real. Os modelos híbridos permitem que os desenvolvedores de apps configurem redes de publicidade com base em eCPMs históricos, dando a eles a oportunidade de mostrar um anúncio antes de executar lances em tempo real com as redes participantes para preencher oportunidades de anúncio.

Mediação em hierarquia da API Protected Audience

A API Protected Audience para Android oferece suporte à mediação em hierarquia, já que pode realizar vários leilões, cada um para um nó individual no gráfico de mediação. Se ninguém vencer um leilão, o próximo nó do leilão de rede vai ser chamado até que a cadeia chegue ao fim. O processo de mediação em hierarquia ocorre desta forma:

  1. O SDK de mediação busca a cadeia de mediação no endpoint do servidor de anúncios contextuais, que pode retornar anúncios contextuais ou cadeias de mediação.
  2. Se o endpoint do servidor de anúncios retornar uma cadeia de mediação, o SDK de mediação itera em cada item da cadeia em ordem, invocando o método SDK da rede de publicidade do Google para executar uma seleção de anúncios contextuais e de remarketing. Cada item na cadeia representa uma solicitação de uma rede de publicidade para comprar espaço publicitário para um o preço específico para uma determinada quantidade de impressões, cliques ou tempo de anúncio.
  3. Se nenhum dos itens de linha na cadeia escolher um anúncio vencedor, o SDK de mediação vai poder mostrar um anúncio da própria rede de publicidade executando uma seleção de anúncios da Protected Audience que considera o remarketing e os anúncios contextuais.

Diagrama do fluxo de mediação em hierarquia da Protected Audience
Figura 3. Mediação em hierarquia com a API Protected Audience.

O diagrama acima representa um exemplo de um algoritmo de mediação em hierarquia que um SDK de mediação pode implementar, mas sem a capacidade de otimização da rede de publicidade. A API Protected Audience oferece suporte à otimização das redes de publicidade, permitindo o encadeamento de fluxos de trabalho da seleção de anúncios e relatando impressões vencedoras.

Resultado da AdSelection

O tipo de retorno de selectAds() é um objeto AdSelectionOutcome. AdSelectionOutcome contém o URI de renderização do anúncio vencedor e um AdSelectionId, que é um número inteiro opaco que identifica o vencedor criativo do anúncio do item de linha.

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

O AdSelectionId funciona como um ponteiro para o AdSelectionOutcome. Atualmente, o AdSelectionId é transmitido ao método reportResult() como o parâmetro ReportImpressionInput para ajudar a identificar os anúncios corretos dos métodos reportWin() e reportResult() invocados.

Proposta de seleção de anúncios da cadeia

Sugerimos sobrecarregar selectAds() com AdSelectionFromOutcomesConfig.

val config = AdSelectionFromOutcomesConfig.Builder()
        .setSeller(seller)
        .setAdSelectionIds(listOf(outcome1pAdSelectionId))
        .setSelectionSignals({"bid_floor": bidFloorOfNextNetworkInline})
        .setSelectionLogicUri(selectionLogicUri)
        .build()
adSelectionClient.selectAds(config)

Assim, o SDK de mediação pode comparar o lance do anúncio vencedor com o lance mínimo da próxima rede inline.

Exemplo 1:

Exemplo 2:

Gerar relatórios das impressões vencedoras

Se houver um vencedor de selectAds(AdSelectionFromOutcomes), esse anúncio vai ganhar a mediação. Em seguida, a reportImpression é chamada com o ID de seleção do anúncio vencedor de selectAds(AdSelectionFromOutcomes) e a AdSelectionConfig correspondente.

Se o vencedor for retornado por selectAds(AdSelectionConfig) para qualquer uma das redes, a reportImpression será chamada com o ID e a configuração da seleção de anúncios dessa chamada.

Executar a mediação em hierarquia

Esta é a ordem das operações executadas no processo de mediação em hierarquia.

  1. Executar a seleção de anúncios próprios.
  2. Iterar na cadeia de mediação. Para cada rede de terceiros, faça o seguinte:
    1. Crie a AdSelectionFromOutcomeConfig, incluindo o outcomeId próprio e o lance mínimo do SDK de terceiros
    2. Chame selectAds() com a config da etapa anterior.
    3. Se o resultado não estiver vazio, o anúncio será retornado.
    4. Chame o método selectAds() do adaptador de rede do SDK atual. Se o resultado não estiver vazio, o anúncio será retornado.
  3. Se nenhum vencedor for encontrado na cadeia, o anúncio próprio será retornado.

Práticas recomendadas

Fazer leilões de anúncios contextuais antes da otimização

A demanda de remarketing pode gerar lances altos que podem encontrar resultados vencedores em uma cadeia de mediação. Truncamento é um processo usado com frequência para permitir a otimização ao refinar a lista de público-alvo de remarketing.

A demanda de remarketing da API Protected Audience só está disponível para o cliente com os leilões da Protected Audience. Ela pode dificultar a ativação da otimização no lado do servidor. Para eliminar os problemas com a otimização, primeiro execute o leilão contextual e depois faça a otimização com base no resultado do anúncio vencedor, conforme descrito anteriormente nesta página.

Reduzir o número de cadeias de mediação no dispositivo

Para melhorar a performance, é necessário manter o número de cadeias de mediação no dispositivo pequeno. O custo de computação para execução no dispositivo pode ser linear no número de leilões avaliados como parte da cadeia de mediação. Em outras palavras, mais nós levam a mais exigências do ciclo computacional e mais latência. Considere o impacto da latência na receita ao transmitir nós para a avaliação de mediação no dispositivo.

Outras considerações

No momento, a API Protected Audience não oferece uma solução abrangente para a mediação de vários espaços de anúncio. Cada espaço de anúncio precisa ser processado de forma independente.

Atualmente, a API Protected Audience Mediation oferece suporte à mediação em hierarquia e à mediação programática limitada. Vamos compartilhar mais detalhes sobre como oferecer suporte a outros casos de uso de mediação programática no futuro.

Como a seleção de anúncios da Protected Audience é executada após a busca de anúncios contextuais, invocar a API Protected Audience pode afetar a latência de ponta a ponta das solicitações de anúncios.