Melhorar a latência do leilão da API Protected Audience

É do interesse de todos garantir que a API Protected Audience funcione de maneira eficiente:

  • As pessoas que navegam na Web querem que os sites sejam carregados rapidamente. Isso significa que os desenvolvedores precisam criar com a API Protected Audience de maneira eficiente para não usar excessivamente recursos limitados do dispositivo, como recursos de computação ou de rede, que são necessários para carregar sites e anúncios incorporados.
  • Os editores querem que os sites carreguem rapidamente, oferecendo aos usuários uma experiência eficiente e responsiva. Os editores também querem uma publicidade eficaz para maximizar a receita.
  • Os anunciantes e as adtechs querem que os anúncios sejam mostrados rapidamente para oferecer o máximo de utilidade.

Neste documento, descrevemos algumas práticas recomendadas para a implementação da API Protected Audience. O objetivo é garantir que seu site funcione com a máxima eficiência.

Práticas recomendadas para compradores (bidder)

Para garantir que você esteja otimizando para a eficiência do leilão da API Protected Audience, siga estas práticas recomendadas.

Menos proprietários de grupos de interesse

Para proteger os bidders da API Protected Audience da mesma forma que o navegador protege diferentes origens na Web usando o isolamento de sites, o navegador usa recursos caros (como processos do sistema operacional) para proteger proprietários de grupos de interesse individuais.

Para minimizar os gastos com esses recursos muito caros, ter o menor número de proprietários de grupos de interesse é crucial. Evite ter diferentes grupos de interesse pertencentes a vários subdomínios. Por exemplo, se adtech.example tivesse grupos de interesse de propriedade de cats.adtech.example e dogs.adtech.example, o navegador provavelmente usaria dois processos separados para executar os scripts de lances.

Lances menores de grupos de interesse

O navegador precisa fazer a configuração e a preparação significativas antes de invocar o script generateBid() de um comprador, como configurar um novo ambiente de execução JavaScript limpo e analisar e carregar o código generateBid().

  • Grupos de interesse que representam usuários que não são o alvo atual de uma campanha publicitária ativa devem ter listas vazias de criativos de anúncios. Isso impede que a API Protected Audience execute generateBid() para grupos de interesse sem anúncios relevantes.
  • Combinar grupos de interesse semelhantes vai diminuir o número de vezes que generateBid() precisa ser executado. A propriedade userBiddingSignals de um grupo de interesse pode ser usada para armazenar outros metadados sobre o usuário. Assim, menos grupos de interesse não precisam significar uma segmentação menos eficaz.
  • A API Protected Audience oferece suporte a limites especificados pelo vendedor para os números de grupos de interesse e uma API para que os compradores especifiquem a prioridade relativa dos grupos de interesse. Esses limites podem ser usados para reduzir significativamente o número de scripts de lances a serem executados.

Filtre grupos de interesse dos lances no seu serviço de chave-valor

Se um comprador puder determinar no servidor de indicadores de lances confiáveis em tempo real que determinados grupos de interesse não podem definir lances (por exemplo, a campanha está desativada, pausada ou sem orçamento ou não pode dar lances para esse editor específico), ele poderá indicar isso ao navegador com a resposta priorityVector à busca de indicadores de lances confiáveis. Se o produto escalar esparso resultante de priorityVector e prioritySignals for negativo, o navegador vai pular a invocação de generateBid() para esse grupo de interesse. Leia mais sobre esse mecanismo na seção"Como filtrar e priorizar grupos de interesse" da explicação.

Reutilizar o ambiente de execução do JavaScript

Antes que o navegador possa executar generateBid(), ele precisa inicializar um novo ambiente de execução do JavaScript. Isso pode levar um tempo significativo, igual ao tempo que uma generateBid() mínima pode levar para ser executada. É possível poupar esse tempo usando os modos de execução grupo por origem ou contexto congelado.

O modo group-by-origin pode reutilizar ambientes de execução quando os grupos de interesse são unidos na mesma origem e provavelmente não exigem mudanças no script de lances. Para saber mais, consulte a descrição de group-by-origin na explicação. O modo de contexto congelado pode reutilizar todos os ambientes de execução, mas pode exigir mudanças no script de lances. Para saber mais, consulte a descrição de frozen-context na explicação.

Reutilizar scripts de lances

Use o mesmo script de lances para grupos de interesse, se possível. Isso evita que o navegador precise fazer o download, analisar e compilar vários scripts (o que incorre em solicitações de rede extras). Os bidders ainda podem diferenciar lances com base nas informações do grupo de interesse (por exemplo, name ou userBiddingSignals) usando o mesmo script.

Reutilizar trustedBiddingSignalsUrls

A latência da rede e o uso de recursos podem ser muito significativos. Menos buscas de indicadores de lances confiáveis em tempo real podem ajudar a reduzir essa latência.

As buscas dos indicadores de lances confiáveis podem ser combinadas quando o trustedBiddingSignalsUrl é reutilizado em vários grupos de interesse. Quando possível, use o mesmo trustedBiddingSignalsUrl para todos os grupos de interesse.

Especifique os cabeçalhos de controle de cache HTTP apropriados para garantir que as buscas de indicadores de lances confiáveis sejam armazenadas em cache nos espaços de anúncio em uma determinada página da Web. Evite definir trustedBiddingSignalsSlotSizeMode como slot-size porque isso impede o armazenamento em cache nos espaços de anúncio quando os tamanhos deles são diferentes porque o URL solicitado é diferente.

Buscas menores de indicadores de lances confiáveis em tempo real

A latência da rede pode ser muito significativa, e isso é diretamente afetado pela quantidade de dados transferidos durante as buscas de indicadores de lances confiáveis em tempo real.

Prefere armazenar dados específicos do anúncio ou do grupo de interesse no grupo em vez de dados no serviço de indicadores de lances confiáveis em tempo real. Reserve dados de indicadores de lances confiáveis em tempo real apenas para indicadores em tempo real, como orçamento de campanha ou chaves de desativação.

Qualquer indicador que possa ser atualizado diariamente ou por um período mais longo precisa ser armazenado no grupo de interesse e atualizado com as atualizações diárias.

Não retorne indicadores de lances confiáveis para grupos de interesse filtrados conforme descrito na seção Filtrar grupos de interesse dos lances no serviço de chave-valor.

Priorizar grupos de interesse

Os vendedores usam tempos limite para limitar como os recursos do navegador são usados nas páginas dos editores. Quando os perBuyerCumulativeTimeouts são usados para limitar o tempo que os compradores têm para buscar os indicadores de lances confiáveis e executar os scripts de lances, é fundamental que eles priorizem os grupos de interesse para que aqueles com mais chances de vencer o leilão sejam executados primeiro. Por exemplo, se perBuyerCumulativeTimeouts for definido como 100 ms, e a busca de indicadores de lances confiáveis de um bidder levar 50 ms, cada invocação de generateBid() vai levar 10 ms e o dispositivo tiver 10 grupos de interesse, apenas metade dos grupos de interesse vai poder calcular lances. O comprador neste exemplo deve priorizar seus grupos de interesse na ordem do mais provável para vencer ao menos provável de vencer.

Os grupos de interesse podem conter prioridades estáticas definidas com o campo priority. Os grupos de interesse também podem usar prioridades dinâmicas que podem ser calculadas no serviço de indicadores de lances confiáveis e retornadas ao navegador com a resposta priorityVector à busca dos indicadores de lances confiáveis.

Quando o navegador executa grupos de interesse da prioridade mais alta para a mais baixa, isso pode intercalar grupos de interesse de diferentes origens de mesclagem, o que pode impedir a otimização da group-by-origin.

Práticas recomendadas para vendedores

Monitore e otimize para aumentar a eficiência do leilão da API Protected Audience.

Carregar leilões em paralelo

Conexões de rede modernas e processadores com vários núcleos fazem um ótimo trabalho executando várias atividades ao mesmo tempo. O navegador pode realizar um leilão da Protected Audience em paralelo com outras atividades. Para fazer isso, chame runAdAuction() o quanto antes. Reconhecendo que algumas entradas para runAdAuction() podem não estar disponíveis no início, por exemplo, aquelas que são enviadas de volta ao navegador na resposta contextual, o navegador permite chamar runAdAution() antes de estarem disponíveis e fornecer essas entradas mais tarde usando promessas do JavaScript. Para alcançar a menor latência de leilão possível, runAdAuction() precisará ser chamado quando a entrada interestGroupBuyers for conhecida. Isso permite que muitas partes do leilão comecem imediatamente, incluindo a busca dos indicadores de lances em tempo real do bidder.

Monitorar seus leilões

Colete métricas dos seus leilões. O navegador pode informar métricas de latência de per-buyer aos vendedores com muitos insights sobre como o tempo é gasto nos leilões de um vendedor. Os vendedores podem usar essas métricas para buscar formas de otimizar os leilões, inclusive para receber informações sobre como definir tempos limite com mais eficiência. Os vendedores podem compartilhar as métricas de latência de um comprador específico com ele para otimizar ainda mais.

Os bidders podem ter insights sobre a performance dos lances dos próprios grupos de interesse, mas não conseguem comparar isso com outros bidders. Comparar as taxas de vitória e de rejeição relacionadas a lances diferentes pode ajudar a identificar casos em que os recursos de computação de lances foram desperdiçados devido a grupos de interesse que nunca produziram lances viáveis ou lances excessivos com criativos não aprovados.

Proteger contra scripts de lance lentos

Scripts de lances que levam tempo excessivo podem retardar o leilão da API Protected Audience para todos os envolvidos. O uso de tempos limite pode evitar leilões lentos e ainda recuperar receita quando o leilão está lento.

Os vendedores precisam usar perBuyerCumulativeTimeouts para evitar leilões com lentidão e ainda aceitar lances quando o leilão estiver lento e atingir o tempo limite. É melhor usar perBuyerCumulativeTimeouts do que perBuyerTimeouts e perBuyerGroupLimits porque perBuyerCumulativeTimeouts não opina sobre o número de grupos de interesse ou a velocidade de generateBid(). Por exemplo, muitos grupos de interesse que definem lances rapidamente e poucos grupos de interesse que fazem lances lentos podem ser concluídos antes do tempo limite.

Usar o campo signal da configuração do leilão para implementar um tempo limite geral do leilão também é uma boa ideia para evitar leilões muito longos nos casos em que a busca do indicador de pontuação confiável e a execução de scoreAd() levam muito tempo.

A seguir

Queremos conversar com você para garantir a criação de uma API que funcione para todos.

Converse sobre a API

Assim como outras APIs do Sandbox de privacidade, essa API é documentada e discutida publicamente.

Teste a API

Você pode fazer testes e participar de conversas sobre a API Protected Audience.