Conheça a prévia para desenvolvedores do Sandbox de privacidade do Android. Veja como começar e envie feedback.

Limite de frequência de FLEDGE

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

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 o FLEDGE no Android pode ser usado para implementar a funcionalidade de limite de frequência de maneira precisa e com preservação de privacidade.

O FLEDGE 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, o FLEDGE 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 do FLEDGE tem acesso a contadores, anúncios de remarketing e anúncios contextuais. Isso dá ao limite de frequência do FLEDGE 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 do FLEDGE do Chrome não implementa um mecanismo para filtrar anúncios segmentados por contexto e que não são do FLEDGE. Esta proposta abrange apenas o suporte para a compra. Se houver demanda, vamos adicionar suporte de venda mais tarde.

O limite de frequência do FLEDGE oferece suporte a uma grande 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

Anúncios contextuais e de remarketing indicam quais são os contadores de histograma relevantes para serem atualizados no caso de uma visualização ou impressão usando um novo campo on_device_counters_keys que vai conter uma lista de chaves-valor arbitrárias. O campo não está incluído no campo metadata, que não é analisado pelo FLEDGE.

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 abaixo:

'adsData': [
  {
    "buyer": "ads.example.com",
    "ads": [
      {
        'render_url': 'exampleUrl',
        'metadata': {...},   /* metadata are opaque to FLEDGE and
                                just required to be in valid JSON
                                format */
        'on_device_counters_keys': [
          'campaign_id:1234',
          'campaign_id:1234+adgroup_id:5678'
        ]
      }]
  }]
}

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

As adtechs podem invocar o método updateEventHistogram 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 updateEventHistogram(@EventType eventType, long adSelectionId)

Entradas:

  • eventType: identifica se um evento é contado como uma visualização, uma impressão 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 updateEventHistogram atualiza o histograma do conjunto de chaves definido como parte dos anúncios de remarketing buscados por um CustomAudience ou anúncios contextuais incluídos no parâmetro AdSelectionConfig para selectAds. Além das chaves em on_device_counters_keys, a chamada também vai atualizar o histograma para um contador identificado pelo valor render_url do anúncio.

Se presumirmos que o anúncio na Etapa 1 é o vencedor de uma AdSelection com um id no valor de 9999, uma chamada para updateEventHistogram(EventType.VIEW, adSelectionId: 999) incrementa os contadores destas três chaves principais:

  • {'ads.example.com', 'campaign_id:1234', VIEW}
  • {'ads.example.com', 'campaign_id:1234+adgroup_id:5678', VIEW}
  • {'ads.example.com', 'exampleUrl', 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.

O FLEDGE para Android incrementa automaticamente todos os contadores mencionados acima para o tipo de evento EventType.AD_SELECTION_WIN para anúncios retornados por uma chamada de API selectAds. Isso é funcionalmente equivalente à adição do argumento prev_wins a browser_signals em generateBid na implementação FLEDGE 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. O FLEDGE 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_seconds são usados para extrair um histograma de eventos usados para filtragem e para o FLEDGE.

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 FLEDGE and assumed
                        to be in valid JSON format */

  'on_device_counters_keys': [
    'campaign_id:1234',
    'campaign_id:1234+adgroup_id:5678'
  ],

  "filters": {
    "frequency_cap": {
      "view": {
        "campaign_id:1234": {
          "cap": 10,
          "interval_seconds": 86400
        },
        "adgroup_id:5678": {
          "cap": 10,
          "interval_seconds": 86400
        },
      },
      "win": {
        "campaign_id:1234": {
          "cap": 5,
          "interval_seconds": 604800
        },
        "adgroup_id:5678": {
          "cap": 5,
          "interval_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

O FLEDGE 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 os anúncios não sejam mostrados devido a um lance perdido ou ao limite de frequência. Sem uma visibilidade completa dos motivos para alguns anúncios não vencerem, os sistemas de lances vão exigir mais trabalho para garantir que os anúncios mais adequados sejam veiculados. Essas práticas recomendadas vão ajudar a garantir a veiculação ideal de anúncios com o FLEDGE.

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 inventário de anúncios suficiente 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 o processo de busca personalizada em segundo plano 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 de FLEDGE. Isso garante que, se vários anúncios forem filtrados, os demais ainda serã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 do FLEDGE:

  1. O limite de frequência do FLEDGE opera no nível do perfil do usuário do dispositivo, sem contadores compartilhados em outros dispositivos e outros perfis. Os incrementos de anúncios mostrados de outros dispositivos precisam ser incorporados manualmente, se você quiser.
  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 atingir o limite de frequência do dispositivo, as plataformas de adtech podem enviar vários anúncios candidatos.
  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.