É 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 usar demais os recursos limitados do dispositivo, como recursos de computação ou de rede, necessários para carregar sites e os anúncios incorporados.
- Os editores querem que os sites carreguem rapidamente, oferecendo aos usuários uma experiência eficiente e responsiva. Os publishers 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 maior utilidade.
Este documento descreve algumas práticas recomendadas para uma implementação da API Protected Audience, garantindo que seu site opere com eficiência máxima.
Práticas recomendadas para compradores (bidders)
Para garantir que você está otimizando 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 os proprietários de grupos de interesse individuais.
Para minimizar o gasto desses recursos muito caros, é fundamental 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
tiver grupos de interesse de propriedade de cats.adtech.example e dogs.adtech.example,
o navegador provavelmente usará dois processos separados para executar os scripts
de lances.
Menos grupos de interesse participando da licitação
O navegador precisa fazer uma configuração e preparação significativas antes de invocar um script
generateBid() do comprador, como configurar um novo ambiente de execução
JavaScript limpo e analisar e carregar o código generateBid().
- Os grupos de interesse 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. - Combinar grupos de interesse semelhantes diminui o número de vezes que
generateBid()precisa ser executado. A propriedadeuserBiddingSignalsde um grupo de interesse pode ser usada para armazenar metadados adicionais 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 no número de grupos de interesse e uma API para os compradores especificarem 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 fora do orçamento, ou não deve dar lances nesse editor específico), ele poderá indicar isso ao navegador com a resposta priorityVector para a 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"Filtragem e priorização de 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, equivalente ao tempo que um generateBid() mínimo leva para ser executado. Esse tempo pode ser economizado usando os modos de execução "group-by-origin" ou "frozen-context".
O modo group-by-origin pode reutilizar ambientes de execução em casos em que os grupos de interesse são unidos na mesma origem e provavelmente não exigirá mudanças no script de lances. Para saber mais, consulte a descrição do group-by-origin no explicador. O modo de contexto congelado pode reutilizar potencialmente 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 baixar, analisar e compilar vários scripts, o que gera solicitações de rede extras. Os bidders ainda podem diferenciar os lances com base nas informações do grupo de interesse (por exemplo, name ou userBiddingSignals) usando o mesmo script.
Sem cabeçalhos de controle de cache HTTP, o script de lances não é armazenado em cache. Especifique cabeçalhos adequados para garantir que o script não seja buscado sem necessidade. Se houver vários leilões na página sendo executados em paralelo, o script de lances do mesmo bidder será reutilizado se já estiver na memória, ignorando a semântica de cache. Se os leilões forem executados em sequência, o navegador vai aderir ao mecanismo de cache HTTP.
O navegador carrega o script de lances durante o período de lances (para generateBid()) e também durante o período 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.
Por isso, recomendamos definir cabeçalhos de controle de cache em todos os seus 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.
As busca de indicadores de lances confiáveis podem ser combinadas
quando o trustedBiddingSignalsUrl é reutilizado em vários grupos de interesse.
Sempre que possível, use o mesmo trustedBiddingSignalsUrl para todos os grupos de interesse.
Especifique cabeçalhos de controle de cache HTTP adequados para garantir que as buscas de indicadores de lances confiáveis sejam armazenadas em cache em todos os espaços de anúncio em uma página da Web específica. Evite definir trustedBiddingSignalsSlotSizeMode como slot-size, porque isso impede o armazenamento em cache em todos os slots de anúncio quando os tamanhos dos slots são diferentes, já que o URL solicitado também será diferente.
Buscas menores de indicadores de lances confiáveis em tempo real
A latência da rede pode ser muito significativa e é afetada diretamente pela quantidade de dados transferidos durante as buscas de indicadores de lances confiáveis em tempo real.
É melhor armazenar dados específicos de anúncios ou grupos de interesse no grupo de interesse, em vez de 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 aqueles que são realmente em tempo real, como orçamento de campanha ou chaves de interrupção.
Qualquer indicador que possa ser atualizado diariamente ou em 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 de lances no seu serviço de chave/valor".
Priorizar grupos de interesse
Os vendedores usam 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 houver 10 grupos de interesse em um dispositivo, apenas metade dos grupos de interesse terá a chance de calcular lances. O comprador neste exemplo deve priorizar os grupos de interesse na ordem de maior para menor probabilidade de vitória.
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 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 junção, o que pode prejudicar a otimização do group-by-origin.
Práticas recomendadas para vendedores
Monitore e otimize a eficiência do leilão da API Protected Audience.
Paralelizar leilões
As conexões de rede modernas e os processadores multi-core fazem um ótimo trabalho ao realizar várias atividades simultaneamente. O navegador pode executar um leilão com Protected Audience em paralelo com outras atividades. Isso pode ser facilitado chamando runAdAuction() assim que possível. Como algumas entradas para runAdAuction() podem não estar disponíveis no início, por exemplo, aquelas enviadas de volta ao navegador na resposta contextual, o navegador permite chamar runAdAution() antes que elas estejam disponíveis e fornecer essas entradas posteriormente 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 comecem imediatamente, incluindo a busca de indicadores de lances em tempo real do bidder.
Monitore seus leilões
Colete métricas sobre seus leilões. O navegador pode informar métricas de latência per-buyer aos vendedores, o que fornece muitas informações sobre como 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 tempos limite da maneira mais eficaz. Os vendedores podem compartilhar as métricas de latência de um comprador específico com ele para ajudar na otimização.
Os bidders podem ter insights sobre a performance de lances dos próprios grupos de interesse, mas não podem comparar isso com outros bidders. 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 porque os grupos de interesse nunca geraram lances viáveis ou porque houve lances excessivos com criativos não aprovados.
Proteção contra scripts de lances lentos
Scripts de lances que levam muito tempo podem diminuir a velocidade do leilão da API Protected Audience para todos os envolvidos. O uso de tempos limite pode evitar leilões lentos e recuperar a receita quando o leilão é lento.
Os vendedores precisam usar perBuyerCumulativeTimeouts para evitar leilões lentos e ainda aceitar lances quando o leilão estiver lento e atingir o tempo limite. É melhor usar perBuyerCumulativeTimeouts em vez de perBuyerTimeouts e perBuyerGroupLimits porque perBuyerCumulativeTimeouts não tem uma opinião sobre o número de grupos de interesse ou a velocidade de generateBid(). Por exemplo, muitos grupos de interesse que fazem lances rápidos 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 as buscas de indicadores de pontuação confiáveis 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.