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 carreguem rapidamente. Isso significa que os desenvolvedores precisam criar com a API Protected Audience de maneira eficiente para não utilizar recursos limitados do dispositivo, como recursos de computação ou de rede, que são necessários para carregar sites e os anúncios incorporados.
• Os editores querem que os sites sejam carregados rapidamente, oferecendo aos usuários uma experiência eficiente e responsiva. Os editores também querem publicidade eficaz para maximizar a receita.
• Os anunciantes e as adtechs querem que os anúncios sejam exibidos rapidamente para oferecer a melhor utilidade.

Este documento descreve algumas práticas recomendadas para a implementação da API Protected Audience, para garantir que seu site opere com a máxima eficiência.

Práticas recomendadas para compradores (licitantes)

Para garantir a otimização da eficiência do leilão da API Protected Audience, siga estas práticas recomendadas.

Menos proprietários de grupos de interesse

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

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

Menos lances de grupos de interesse

O navegador precisa fazer uma configuração e 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().

• Os grupos de interesses que representam usuários que não são o público-alvo atual de uma campanha publicitária ativa precisam ter listas de criativos de anúncios vazias. Isso impede que a API Protected Audience execute generateBid() para grupos de interesse sem anúncios relevantes.
• A combinação de grupos de interesses semelhantes diminui o número de vezes que o generateBid() precisa ser executado. A propriedade userBiddingSignals de um grupo de interesse pode ser usada para armazenar metadados adicionais sobre o usuário. Portanto, ter menos grupos de interesse não significa que a segmentação será menos eficaz.
• A API Protected Audience oferece suporte a limites especificados pelo vendedor no número 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.

Filtrar 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 devem dar lances (por exemplo, a campanha está desativada, pausada ou sem orçamento, ou não pode dar lances nesse editor específico), ele pode indicar isso ao navegador com a resposta priorityVector para a busca de indicadores de lances confiáveis. Se o produto de ponto esparsa resultante do priorityVector e do 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" do texto explicativo.

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, equivalente ao tempo que uma generateBid() mínima pode levar para ser executada. Esse tempo pode ser economizado usando os modos de execução de agrupamento por origem ou de contexto congelado.

O modo group-by-origin pode reutilizar ambientes de execução em casos em que os grupos de interesse são agrupados 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 do frozen-context na explicação.

Reutilizar scripts de lances

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

Sem os cabeçalhos de controle de cache HTTP, o script de lances não é armazenado em cache. Especifique cabeçalhos apropriados para garantir que o script não seja buscado desnecessariamente. Se houver vários leilões na página em execução em paralelo, o script de lance do mesmo bidder será reutilizado se já estiver na memória, ignorando a semântica de armazenamento em cache. Se os leilões forem executados sequencialmente, o navegador vai aderir ao mecanismo de armazenamento em cache HTTP.

O navegador carrega o script de lance durante o tempo de lance (para generateBid()) e também durante o tempo de geração de relatórios (para reportWin()). Se os cabeçalhos de controle de cache não estiverem definidos, o navegador vai buscar o mesmo script duas vezes, uma para cada período.

Portanto, recomendamos definir cabeçalhos de controle de cache em todos os scripts.

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.

Os busca de indicadores de lances confiáveis podem ser combinados quando o trustedBiddingSignalsUrl é reutilizado entre vários grupos de interesse. Sempre que 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 os retornos de chamada de indicador confiáveis sejam armazenados em cache em todos os slots de anúncios em uma página da Web específica. Evite definir trustedBiddingSignalsSlotSizeMode como slot-size, porque isso impede o armazenamento em cache nos slots de anúncio quando os tamanhos dos slots são diferentes, já que o URL solicitado também é diferente.

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

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

Prefira armazenar dados específicos do anúncio ou do grupo de interesse no grupo de interesse, em vez de usar o serviço de indicador de lances confiáveis em tempo real. Reserve os dados de indicadores de lances confiáveis em tempo real apenas para indicadores realmente em tempo real, como o orçamento da campanha ou o desligamento.

Qualquer indicador que possa ser atualizado diariamente ou por um período maior precisa ser armazenado no grupo de interesse e atualizado usando 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 seu serviço de chave-valor".

Priorizar grupos de interesse

Os vendedores vão usar os tempos limite para limitar o uso de recursos do navegador nas páginas do editor. 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 os mais propensos a vencer o leilão sejam executados primeiro. Por exemplo, se perBuyerCumulativeTimeouts estiver definido como 100 ms e a busca de indicadores de lances confiáveis de um bidder levar 50 ms, e cada invocação de generateBid() levar 10 ms, e eles tiverem 10 grupos de interesse presentes em um dispositivo, apenas metade dos grupos de interesse terá a chance de calcular os lances. O comprador neste exemplo precisa priorizar os grupos de interesse em ordem, do mais provável ao menos provável de ganhar.

Os grupos de interesse podem conter prioridades estáticas definidas com o campo priority. Os grupos de interesses 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 para a busca de indicadores de lances confiáveis.

Quando o navegador executa grupos de interesse da maior para a menor prioridade, isso pode intercalar grupos de interesse de diferentes origens de mesclagem, o que pode prejudicar a otimização de group-by-origin.

Práticas recomendadas para vendedores

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

Leilões em paralelo

Conexões de rede modernas e processadores multicore são ótimos para realizar várias atividades ao mesmo tempo. O navegador pode executar um leilão da Protected Audience em paralelo com outras atividades. Para facilitar isso, chame runAdAuction() o mais cedo possível. Como 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 que elas estejam disponíveis e fornecer essas entradas mais tarde usando promessas do JavaScript. Para alcançar a menor latência possível do leilão, runAdAuction() precisa ser chamado quando a entrada interestGroupBuyers for conhecida. Isso permite que muitas partes do leilão sejam iniciadas 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 per-buyer aos vendedores, que fornecem muitos insights sobre o tempo gasto nos leilões de um vendedor. Os vendedores podem usar essas métricas para encontrar maneiras de otimizar os leilões, incluindo informações sobre como definir o tempo limite de forma mais eficaz. Os vendedores podem compartilhar as métricas de latência de um comprador específico com ele para ajudar a otimizar ainda mais.

Os proponentes podem ter insights sobre a performance dos lances dos próprios grupos de interesse, mas talvez não consigam comparar isso com outros proponentes. Comparar as taxas de vitória e de rejeição de lances relativas de diferentes bidders 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 lances lentos

Os scripts de lances que demoram muito podem atrasar o leilão da API Protected Audience para todos os envolvidos. O uso de tempos limite pode evitar leilões lentos, mas ainda recuperar a receita quando o leilão é lento.

Os vendedores devem usar o perBuyerCumulativeTimeouts para evitar leilões lentos e continuar aceitando lances quando o leilão for lento e atingir o tempo limite. O uso de perBuyerCumulativeTimeouts é preferível ao uso de perBuyerTimeouts e perBuyerGroupLimits porque perBuyerCumulativeTimeouts não tem opinião sobre o número de grupos de interesse ou a velocidade de generateBid(). Por exemplo, muitos grupos de interesse que fazem lances rapidamente e poucos grupos de interesse que fazem lances lentamente podem ser concluídos antes do tempo limite.

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

Importante: observação sobre o tempo do leilão: as pessoas costumam perguntar "quanto tempo dura um leilão da Protected Audience?" "Qual deve ser o tempo limite definido pelo vendedor?" ou "Para qual latência um comprador deve otimizar?". A resposta a essas perguntas depende do resultado do leilão que os participantes estão otimizando. Os vendedores podem querer maximizar a receita de anúncios do site. Nesse caso, eles devem testar diferentes tempos limite para encontrar a configuração que maximiza a receita. Ter tempos limite diferentes para computadores e dispositivos móveis pode ser útil. O uso da API Protected Audience pode mudar com o tempo à medida que a adoção aumenta, os participantes do leilão otimizam a lógica ou os computadores evoluem. Por isso, a experimentação contínua pode ser benéfica. Se os compradores estão otimizando para ganhar a maioria dos leilões, eles precisam monitorar e otimizar a latência dos sinais de lances confiáveis e a latência de generateBid() e considerar priorizar os grupos de interesse para que, quando os vendedores definirem tempos limite rígidos, eles gerem os melhores lances primeiro.

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.