Limite de frequência da API Protected Audience

O limite de frequência é uma prática de publicidade que limita o número de anúncios de uma determinada categoria que são mostrados a um usuário em um determinado período. O limite de frequência melhora a experiência do usuário final, mantendo as impressões de anúncios atualizadas e interessantes, e ajuda os anunciantes a gerenciar os gastos com publicidade.

Esta proposta mostra como a API Protected Audience no Android pode ser usada para implementar a funcionalidade de limite de frequência de maneira precisa e que preserve a privacidade.

A API Protected Audience implementa o limite de frequência combinando dois recursos: o armazenamento de contadores no dispositivo para eventos específicos do anúncio e a capacidade de filtrar anúncios de acordo com um conjunto predefinido de estratégias de filtro. Com o limite de frequência, os anunciantes podem indicar um limite de contagem em uma soma dos valores de histograma para um determinado período.

Os contadores são exclusivos para cada combinação de perfil do dispositivo, adtech e chave de contador. Cada anúncio precisa conter um conjunto de chaves de contador a serem usadas caso uma visualização ou impressão do anúncio seja registrada. Para cada chave, a API Protected Audience armazena um conjunto de contadores, e cada um deles conta todos os eventos específicos de anúncios que ocorrem em um intervalo de tempo específico. Os contadores no dispositivo são incrementados quando ocorre uma impressão ou visualização, e os dados de contador são mantidos no dispositivo. O tempo de persistência exato será definido posteriormente.

A lógica de filtragem de anúncios no fluxo de trabalho de seleção de anúncios da API Protected Audience tem acesso a contadores, anúncios de remarketing e anúncios contextuais. Isso dá ao limite de frequência da API a capacidade de trabalhar com todos esses tipos de solicitações de anúncios.

Observação: a filtragem de anúncios está disponível apenas no Sandbox de privacidade do Android. No momento, a implementação da API Protected Audience do Chrome não implementa um mecanismo para filtrar anúncios segmentados por contexto e que não são dessa API. Esta proposta abrange apenas o suporte para a compra. Se houver demanda, vamos adicionar suporte de venda mais tarde.

O limite de frequência da Protected Audience oferece suporte a uma ampla variedade de requisitos, incluindo:

  • Filtragem em tempo real, com atraso mínimo do lado do servidor quando os contadores no dispositivo são atualizados.
  • Hierarquia flexível de chaves, incluindo anúncios individuais, campanhas ou qualquer outro agrupamento.
  • Consistência com outros métodos de limite de frequência, sem dependência de AdID.
  • Funciona em vários apps no perfil de usuário de um dispositivo.
  • Contadores precisos e completos.
  • Suporte a definições personalizadas de eventos de anúncios, como visualizações ou impressões.
  • Uma função para anúncios de remarketing e contextuais.

Para configurar o limite de frequência, siga estas etapas:

Etapa 1: adicionar informações sobre o limite de frequência aos anúncios

Os anúncios contextuais e de remarketing indicam os contadores de histograma relevantes a serem atualizados no caso de uma visualização ou impressão usando o campo ad_counter_keys, que contém uma lista de números inteiros arbitrários. O campo não está incluído no campo metadata, que não é analisado pela API Protected Audience.

O exemplo abaixo mostra o formato de dados para o campo adsData em AdSelectionConfig. Para o remarketing, o formato da lista de anúncios para um determinado público-alvo personalizado é consistente com o conteúdo do campo ads mostrado neste exemplo:

'adsData': [
  {
    "buyer": "ads.example.com",
    "ads": [
      {
        'render_url': 'exampleUrl',
        'metadata': {...},   /* metadata are opaque to Protected Audience are
                                required to be in valid JSON format */
        'ad_counter_keys': [1234, 5678]
      }]
  }]
}

Etapa 2: registrar uma visualização ou uma impressão

As adtechs podem invocar o método updateAdCounterHistogram para registrar ocorrências de eventos usados para o limite de frequência. Um método pode ser invocado repetidamente no mesmo evento para as chaves especificadas no eventType do anúncio vencedor.

void updateAdCounterHistogram(@EventType eventType, long adSelectionId)

Entradas:

  • eventType: identifica se um evento é contado como uma visualização, uma impressão, um clique ou a vitória do processo de seleção de anúncios.
  • adSelectionId: valores de ID no objeto AdSelectionOutcome retornados por chamadas selectAds.

A chamada updateAdCounterHistogram atualiza o histograma do conjunto de chaves definido como parte dos anúncios de remarketing buscados por um CustomAudience ou dos anúncios contextuais incluídos no parâmetro AdSelectionConfig para selectAds.

Se você presumir que o anúncio na Etapa 1 é o vencedor de uma AdSelection com um id no valor de 9999, uma chamada para updateAdCounterHistogram(FrequencyCapFilters.AD_EVENT_TYPE_VIEW, adSelectionId: 999) incrementa os contadores destas três chaves primárias:

  • {'ads.example.com', 1234, VIEW}
  • {'ads.example.com', 5678, VIEW}

O nome da adtech vem do campo do comprador, seja de anúncios contextuais ou de públicos-alvo personalizados, dependendo da origem dos anúncios vencedores.

A API Protected Audience para Android incrementa automaticamente todos os contadores mencionados acima do tipo de evento FrequencyCapFilters.AD_EVENT_TYPE_WIN para anúncios retornados por uma chamada de API selectAds. Isso é funcionalmente equivalente a adicionar o argumento prev_wins a browser_signals em generateBid na implementação da API Protected Audience do Chrome.

Etapa 3: implementar filtros de limite de frequência

Para ter o melhor desempenho, a função de filtragem do limite de frequência é executada em AdServices. A API Protected Audience entende se uma mensagem precisa ser filtrada lendo o campo de filtros no objeto AdsData. Uma lista de filtros é especificada em frequency_cap. Os valores das chaves event_type e interval_in_seconds são usados para extrair um histograma de eventos usados para filtragem e para a API.

As informações de filtragem podem ser especificadas para anúncios de remarketing fornecidos por um público-alvo personalizado e para anúncios contextuais como parte do objeto AdSelectionConfig.

Para anúncios contextuais com filtros de limite de frequência, os anúncios são transmitidos usando o campo de anúncios no objeto AdSelectionConfig. Os anúncios são filtrados, e o anúncio com o lance mais alto é retornado como resultado da chamada selectAds.

Para anúncios de remarketing com filtros de limite de frequência, os anúncios são filtrados antes que a função JavaScript generateBid() fornecida pelo comprador seja invocada.

O exemplo abaixo mostra uma mensagem com filtragem de limite de frequência:

{
  'render_url': 'url',
  'metadata': {...},   /* metadata are opaque to Protected Audience and assumed
                        to be in valid JSON format */

  'ad_counter_keys': [1234, 5678],

  "filters": {
    "frequency_cap": {
      "view": [
        {
          "ad_counter_key": 1234
          "max_count": 10,
          "interval_in_seconds": 86400
        },
        {
          "ad_counter_key": 5678
          "max_count": 10,
          "interval_in_seconds": 86400
        },
      ],
      "win": [
        {
          "ad_counter_key": 1234
          "max_count": 5,
          "interval_in_seconds": 604800
        },
        {
          "ad_counter_key": 5678
          "max_count": 5,
          "interval_in_seconds": 345600
        },
      ]
    },

  // This field is only required in contextual ads and is used in
  // reportImpression calls to fetch the reportWin function.
  'reportingJS': "https://ads.example.com?reportWin.js"
}

Etapa 4: gerar relatórios sobre os anúncios vencedores

Depois que o processo de seleção de anúncios for concluído, ele vai retornar um objeto AdSelectionOutcome contendo renderUri e adSelectionId, um identificador numérico para a chamada de selectAds. Esse ID pode ser usado para invocar a API reportImpression, que atualmente oferece suporte a relatórios de eventos. Na versão Beta 1, esse método oferece suporte a geração de relatórios de anúncios de remarketing, e será estendido para relatórios de anúncios contextuais em uma versão mais recente. Para anúncios contextuais, o comprador precisa indicar onde a função reportWin pode ser extraída durante uma chamada reportImpression usando um campo extra chamado reportingJS na estrutura do anúncio, conforme mostrado no exemplo acima.

Práticas recomendadas para a seleção de candidatos

A API Protected Audience move a aplicação do limite de frequência do servidor para o dispositivo. Os lances vencedores são informados no Sandbox de privacidade, mas os desenvolvedores não sabem por que um anúncio não está sendo mostrado. Talvez eles não sejam mostrados devido a um lance perdido ou ao limite de frequência. Sem uma visibilidade completa dos motivos por que alguns anúncios não vencem, os sistemas de lances vão exigir mais trabalho para garantir que os mais adequados sejam veiculados. Essas práticas recomendadas vão ajudar a garantir a veiculação ideal de anúncios com a Protected Audience.

Enviar anúncios de remarketing suficientes

Não é possível otimizar anúncios de remarketing por usuário. Se um usuário encontrar um número significativo de anúncios de um público-alvo personalizado e os limites de anúncio forem baixos, todos os anúncios poderão ser filtrados. Os anúncios de remarketing são atualizados periodicamente. Assim, um número suficiente de inventários de anúncios precisa passar pelo limite de frequência para garantir que os anúncios de remarketing continuem a ser veiculados. Ele precisa ser equilibrado com limitações no tamanho dos anúncios que podem ser especificados durante a chamada joinCustomAudience e durante a atualização diária personalizada do público-alvo. Os compradores precisam considerar que pode haver um aumento na latência durante a fase de lances. Para minimizar o impacto desses problemas, a filtragem do limite de frequência é executada antes da chamada para generateBid.

Manter contadores contextuais no servidor

Com a estimativa do lado do servidor, um desenvolvedor pode ter estimativas aproximadas para quando o limite de frequência pode estar ativo. Essas estimativas podem indicar que um anúncio provavelmente atingiu o limite de frequência e, portanto, precisa ser enviado com mais candidatos ao anúncio ou ser totalmente eliminado.

Enviar vários candidatos na resposta contextual

Envie vários candidatos de anúncios com uma resposta contextual antes de um leilão da Protected Audience. Isso garante que, se vários anúncios são filtrados, os demais ainda são mostrados. É possível priorizar os candidatos para que alguns anúncios sejam fornecidos como backup.

Como a execução é limitada pelo tempo, os candidatos de anúncios precisam ser escolhidos de acordo com a probabilidade de vencer um leilão e não serem filtrados.

Limitações

Confira abaixo as limitações conhecidas do sistema de limite de frequência da API Protected Audience:

  1. O limite de frequência da Protected Audience opera no nível do perfil do usuário do dispositivo, sem contadores compartilhados em outros dispositivos e perfis. Os incrementos de anúncios mostrados de outros dispositivos precisam ser incorporados manualmente, se você precisar.
  2. Os contadores são armazenados e acessados no dispositivo. Os contadores do servidor precisam ser gerenciados separadamente.
  3. Como o limite de frequência e a filtragem de anúncios são processados em um dispositivo, as plataformas de adtech não têm controle direto sobre essas operações. Para ignorar o limite de frequência do dispositivo, as plataformas das adtechs podem enviar vários anúncios candidatos com filtros diferentes.
  4. Não é possível ajustar os lances com base na frequência registrada. As funções generateBid não podem visualizar os contadores de frequência.