Respostas para perguntas frequentes relacionadas às APIs de relevância e medição do Sandbox de privacidade.
Como a API Topics se compara aos públicos-alvo definidos pelo vendedor (SDA)?
A API Topics e o SDA fornecem tipos complementares de informações e estão sob controle do editor. Não acreditamos que eles estejam competindo entre si. Em vez disso, ambos trabalham lado a lado ou em contextos diferentes para maximizar as oportunidades de compra. Os compradores consideram e usam muitos indicadores ao avaliar as impressões de forma programática, e esperamos que a API Topics seja uma dessas considerações. Historicamente, os vendedores não incluem segmentos de público-alvo em leilões de marketplace aberto. Nesse caso, provavelmente a API Topics vai ser usada. Em vez disso, os vendedores disponibilizaram os públicos-alvo para compra programática em transações feitas com anunciantes, agências ou DSPs. Nesses casos, o vendedor e o comprador estão fazendo transações propositais no SDA. Se o Topics for usado nesses casos, ele pode ser para um ou mais dos seguintes:
- O vendedor aprimora a definição do público-alvo com a API Topics.
- O comprador usando a API Topics como um indicador para definir o valor do lance
- O comprador que usa a API Topics para validar se o SDA é preciso
A API Protected Audience coloca o Google no controle da criação de públicos-alvo?
Não. Os sites podem continuar criando os próprios públicos-alvo dentro e fora do Sandbox de privacidade. Quando os sites criam públicos-alvo no Sandbox de privacidade, o proprietário ou o proxy escolhido determina quem pode criar os públicos-alvo, quais são esses públicos-alvo, como eles são atualizados, como vão dar lances e se querem remover usuários de um público-alvo.
A API Protected Audience oferece suporte a grupos de interesse criados pelo editor?
Sim. Sabemos que os editores estão receosos de colocar o público-alvo em leilões baseados no OpenRTB hoje por medo de vazamento de dados. Os editores podem criar públicos-alvo hoje na Protected Audience que não oferecem ao bidder uma visualização cross-site do usuário do editor individual. Estamos animados para continuar descobrindo maneiras de os editores aproveitarem o ambiente reduzido de vazamento de dados da Protected Audience.
Como as regras de qualidade de anúncios são aplicadas nos leilões da Protected Audience?
Há várias maneiras de aplicar as regras de qualidade de anúncios nos leilões da Protected Audience. Cada uma delas
é semelhante à forma atual de aplicação das regras de qualidade de anúncios pelas SSPs. Uma delas é permitir
que um leilão com um criativo desconhecido acione o criativo para entrar em uma fila de
verificação. Ouvimos o feedback de que as SSPs querem um suporte melhor para esse
caso de uso e estão desenvolvendo um mecanismo que possa criar um feed de renderUrls
que o SSP pode auditar fora de banda e armazenar informações no servidor de
chave-valor. Outra maneira é exigir o pré-registro de anúncios. Como no caso anterior, quando o criativo é verificado, os resultados podem ser vinculados ao servidor de chave-valor. Depois, quando um comprador definir um lance com esse criativo, conforme indicado
por um ID do criativo que provavelmente segue o mesmo formato do OpenRTB, a lógica de pontuação
do vendedor poderá fazer uma pesquisa no servidor de chave-valor e decidir como pontuar
adequadamente.
A API Protected Audience oferece suporte a anúncios em vídeo?
Sim. Os URLs VAST podem ser transmitidos de e para Protected Audience. Quando um URL VAST é enviado, a tecnologia de venda pode coordenar como vai unir o URL VAST do comprador antes que ele seja enviado ao player. Antes do requisito de migrar para os Fenced Frames (a partir de 2026) e reforçar ainda mais as proteções de privacidade do usuário, esperamos que o ecossistema participe de discussões de design que certamente incluem vídeos.
A API Protected Audience oferece suporte a anúncios nativos?
Sim. Os URLs JSON podem ser transmitidos para dentro e para fora da Protected Audience. À medida que um URL JSON é enviado, a tecnologia de venda pode coordenar como adicionar os eventos desejados antes que o JSON final seja transmitido para o código de renderização. Antes do requisito de migração para o Fenced Frames (a partir de 2026) para fortalecer ainda mais as proteções de privacidade do usuário, esperamos que o ecossistema participe de discussões de design que provavelmente incluirão anúncios nativos.
A renderização de anúncios da Protected Audience inibe a inovação?
Não. A renderização de anúncios sempre contou com tecnologias de navegadores. Isso não muda. Talvez essa preocupação seja específica para planos de exigir o uso de Fenced Frames com a Protected Audience no futuro. Parte do motivo pelo qual esses planos estão "no futuro" é porque queremos que a tecnologia Fenced Frames ofereça suporte à inovação e à diferenciação do ecossistema quando se trata da renderização de anúncios. Há tempo para que desenvolvedores e empresas interessados opinem sobre a direção do Fenced Frames, que inclui como as abordagens dos anúncios nativos podem ser compatíveis.
A API Protected Audience permite abordagens sofisticadas de ritmo e avaliação de lances que existem hoje em leilões tradicionais?
A API Protected Audience oferece uma
opção em tempo real para que os compradores entendam o ritmo e os orçamentos da campanha. Do ponto de vista do
inventário, é possível que o vendedor forneça indicadores de leilão
ao comprador sobre o contexto da página e qualquer outra coisa. Se um vendedor
optar por enviar uma solicitação de lance contextual, o comprador também poderá saber mais sobre o
inventário por esse mecanismo e fornecer indicadores de contexto (via perBuyerSignals) que podem ser usados na geração de lances da API Protected Audience. Os usuários iniciais já estão conectando sistemas de machine learning à
Protected Audience. Sabemos que vai levar tempo para ajustar esses sistemas para
lances em ambientes da Protected Audience, mas é fundamental observar que o
ajuste é possível e já está acontecendo.
O padrão OpenRTB funcionará na Protected Audience?
Sim. Esse trabalho está em andamento no IAB Tech Lab por meio de um grupo bem assistido de DSPs e SSPs representativos. Parece que o caminho a seguir será usar partes do protocolo OpenRTB como um padrão de comunicação dentro dos leilões da Protected Audience. Estamos sabendo dos usuários iniciais que já criam dessa forma.
A API Protected Audience exige que as empresas mantenham duas arquiteturas separadas para a veiculação de anúncios?
Não. A Protected Audience não exige a manutenção de duas arquiteturas separadas. As opções de arquitetura são suas próprias. À medida que a publicidade on-line progrediu ao longo dos anos, a complexidade dos sistemas que a alimentam também. Tornar a Internet mais particular para os usuários apresenta mais complexidade e exige trabalho. As empresas de adtech podem manter duas arquiteturas separadas ou criar a Protected Audience em uma arquitetura combinada com leilões tradicionais.
O que vai acontecer com os leilões tradicionais quando mais empresas de adtech passarem a aceitar a API Protected Audience?
Esperamos que os leilões contextuais vão continuar relevantes por diversos motivos, incluindo transações, campanhas segmentadas por público-alvo que não são próprias e muitos outros cenários contextuais. Eles também permanecem valiosos quando não há grupos de interesse presentes ou quando os lances na API Protected Audience não atingem os mínimos nem obedecem às regras de qualidade do anúncio.
O leilão da Protected Audience vai contra os esforços de otimização do caminho de fornecimento (SPO, na sigla em inglês) do ecossistema para reduzir a quantidade total de intermediários entre um anunciante e um editor e/ou a duplicação de uma determinada oportunidade de anúncio?
Não. Um anúncio vencedor na Protected Audience passará por, no máximo, duas entidades de vendedor (por exemplo, uma plataforma de fornecimento (SSP, na sigla em inglês) e um servidor de anúncios do editor) e apenas nenhuma se o comprador criar uma integração direta com o editor.
A duplicação da mesma solicitação usando vários intermediários continua a ser escolha do editor. A API Protected Audience não pode afetar de outra maneira.
Os leilões da API Protected Audience ocorrem fora do sistema em tempo real de servidor para servidor atual para não vazar dados do usuário entre sites. Alguns podem dizer que isso duplica uma solicitação de anúncio. Chegar a uma privacidade tecnicamente demonstrável exige algumas compensações. No entanto, é possível que, a longo prazo, o ecossistema decida usar a Protected Audience sem leilões tradicionais do lado do servidor. Essa escolha pode levar a caminhos de fornecimento ainda mais otimizados.
A Protected Audience reduz o valor da infraestrutura de modelagem de tráfego atual?
Pelo que entendemos, o que está mudando em relação às consultas por segundo é que muitas SSPs usam IDs entre sites como um recurso para determinar se devem ou não enviar uma solicitação de DSP. Portanto, a redução nos IDs entre sites afeta as técnicas atuais de modelagem de tráfego. Isso seria verdadeiro se o editor quiser realizar um leilão da Protected Audience ou não.
Exploramos a modelagem de tráfego com muitas SSPs e encontramos soluções, incluindo armazenamento em cache e filtragem baseada em contexto. Com o tempo, esperamos que os desenvolvedores aproveitem a agregação particular para ajudar ainda mais no entendimento das preferências de lances de DSP e na filtragem adequada.
Em última análise, algumas infraestruturas legadas criadas com base em identificadores entre sites não serão mais úteis.
As novas solicitações resultantes de um leilão da Protected Audience vão limitar a capacidade das SSPs?
Algumas SSPs nos disseram que a capacidade não é um problema ou uma parte importante da proposta de valor de uma SSP do ponto de vista da integração. Para as SSPs que se preocupam com novas chamadas no processo de leilão, estamos cientes de empresas que já ajudam as SSPs com preocupações de capacidade e querem expandir esses serviços para oferecer suporte à Protected Audience. Entre em contato se quiser que possamos conectar você a uma dessas empresas.
Como a prioridade é abordada na Protected Audience quando há recursos concorrentes no navegador?
A Protected Audience geralmente seguiu o paradigma padrão de criação de controles, que permite aos vendedores decidir quanto tempo e recursos os bidders podem consumir e criar ferramentas que permitem aos compradores decidir a melhor forma de usar os recursos disponíveis. Esses controles e ferramentas já estão disponíveis, mas todos os benefícios serão aproveitados após a adoção por compradores e vendedores. Além disso, o Chrome continua trabalhando em uma variedade de melhorias de infraestrutura para a velocidade do leilão (por exemplo, crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev32/119).
Como a Protected Audience aborda as questões de latência?
Antes, antes da Protected Audience, os lances em tempo real acontecidos nos servidores tinham vendedores especificando tempos limite rigorosos nas respostas dos compradores
para manter a latência sob controle. Adicionamos vários controles de tempo limite
especificados pelo vendedor muito semelhantes (consulte a
documentação de
perBuyerCumulativeTimeouts, perBuyerTimeouts, sellerTimeout) à API Protected Audience para alcançar
a mesma meta de manter a latência sob controle. Esses
controles também incentivam os participantes do leilão a otimizar a lógica para garantir
que os recursos sejam usados com mais eficiência para oferecer suporte ao ecossistema de adtech e
à experiência do usuário de alta qualidade.
O Chrome também continua trabalhando em uma variedade de melhorias de infraestrutura na velocidade do leilão (por exemplo, crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/119732). Convidamos feedback sobre as duas partes desse esforço de latência: outras ferramentas que compradores e vendedores considerariam úteis e relatórios de gargalos observados que os engenheiros do Chrome precisam investigar.
Criar para a API Protected Audience no dispositivo é um esforço desperdiçado quando há serviços de lances e leilões (B&A, na sigla em inglês)?
Não. O dispositivo é suficiente para casos de uso de adtech. Os serviços de lances e leilões são uma solução opcional de escala horizontal para quando as adtechs querem investir mais em recursos de computação de lances do que o navegador permite. O desenvolvimento no dispositivo é um bom investimento, porque a maior parte do trabalho seria reutilizável, mesmo que os desenvolvedores decidam mais tarde participar dos ambientes de serviços de lances e leilões. A maioria dos pipes e da infraestrutura criados continuaria funcionando da mesma forma.
Os requisitos de ambientes de execução confiáveis (TEE) baseados na nuvem para a Protected Audience vão levar as empresas a usar o Google Cloud?
O Sandbox de privacidade projetou as APIs para oferecer privacidade e segurança robustas, e não tomamos nenhuma decisão de design para beneficiar o Google Cloud. Nosso suporte a provedores de nuvem começou com a AWS porque reconhecemos quantos provedores de adtech escolhem a Amazon. Além da AWS e do Google Cloud, esperamos oferecer suporte a outros provedores de nuvem no futuro, e estamos abertos a sugestões para outros provedores de nuvem. Se a latência for uma preocupação, as nuvens oferecem aos clientes opções de localização que encurtam as distâncias para outros provedores de nuvem.
O Sandbox de privacidade permite que ambientes de execução confiáveis (TEEs, na sigla em inglês) sejam executados em data centers de nuvem não públicos?
Os ambientes de execução confiáveis (TEEs, na sigla em inglês) auditáveis fazem parte do nosso modelo de privacidade e segurança. Começamos com os TEEs oferecidos por provedores de nuvem pública devido a medidas de segurança rigorosas. Para deixar claro, as únicas APIs que exigem o uso de ambientes de execução confiáveis no curto prazo são a API Attribution Reporting e a API Private agregação, e nenhuma delas envolve chamar o TEE em tempo real durante um leilão. Continuamos a buscar suporte para opções além das soluções baseadas em nuvem pública.
Não será mais caro executar ambientes de execução confiáveis em nuvens públicas, em vez de data centers locais de adtech?
Nosso modelo de privacidade TEE atual se beneficia das práticas de segurança de implementações de nuvem pública, e questionamos qualquer suposição de que seja mais barato operar um ambiente de execução confiável no local. Confira algumas considerações sobre o custo dessas práticas:
Os provedores de nuvem pública precisam ter um alto padrão de segurança. Por exemplo, a AWS é um provedor de nuvem respeitável com práticas de segurança estabelecidas. Em particular, o AWS Nitro tem um modelo de segurança documentado para garantir que os Nitro Enclaves impeçam que os operadores acessem os dados processados no enclave, e os recursos protegidos (como chaves de descriptografia) estão disponíveis apenas para o código autorizado em execução no Enclave. Há também o acesso físico a ser considerado. A AWS projetou e implementou mitigações de riscos de acesso físico, inclusive de funcionários da Amazon. Os TEEs baseados em hardware podem não se defender contra todos os ataques físicos, que as nuvens públicas foram projetadas para fazer. Além disso, a Amazon recentemente contratou o NCC Group, uma empresa de pesquisa independente, para revisar seus projetos Nitro, com foco em afirmações de segurança relacionadas ao acesso por funcionários internos. O relatório público indica que os designs da AWS atendem às respectivas declarações.
Essas práticas custam dinheiro para implementar, apoiar e melhorar com o tempo. Com nuvens públicas distribuídas globalmente e amplamente disponíveis, esses custos são distribuídos por uma ampla base de clientes.
O Sandbox de privacidade muda o faturamento?
Não. As empresas de adtech e outros autores de chamadas de API podem continuar a conferir se algo é renderizado em uma página e o preço dela.
É possível limitar a frequência no Sandbox de privacidade?
A API Protected Audience oferece suporte
ao limite de frequência entre sites no mesmo grupo de interesse usando o
objeto prevWinsMs. A função generateBid() de um comprador no leilão
da Protected Audience pode criar uma lógica que informa a estratégia de lances com base no
resultado de exposições de anúncios anteriores no mesmo navegador.
Algumas soluções podem ser usadas para o limite de frequência fora da Protected Audience, mas não são totalmente mapeadas para as técnicas entre sites que as adtechs têm com cookies de terceiros.
- Cookies primários: as adtechs podem usar dados próprios para limitar a frequência no site delas.
- CHIPs: as adtechs podem gerenciar limites de frequência por site usando um cookie particionado.
- Armazenamento compartilhado
SelectURL(): depois que uma adtech vence um leilão e antes de renderizar o criativo, ela pode chamar o Armazenamento compartilhado para acessar dados entre sites e escolher o criativo certo com base na frequência usando o portão de saída "Selecionar URL".
Uma solução de limite de frequência não protegida pela privacidade e que oferece um utilitário de tecnologia de anúncio significativo é desafiador pelos seguintes motivos:
- No momento, não está claro com base no feedback da adtech se um indicador de frequência pode tolerar ruído.
- Recebemos feedbacks consistentes de adtechs de que um indicador de frequência entre sites precisaria estar disponível durante o momento do leilão. Isso exige que indicadores entre sites sem ruído estejam disponíveis para uso em qualquer leilão de publicidade. Isso pode revelar uma grande quantidade de informações sobre a atividade de um usuário nos sites, prejudicando as metas de privacidade do Sandbox de privacidade.
- Somos sensíveis à introdução de latência e uma solução no dispositivo que possa fornecer esse sinal poderia causar latência e interromper o ambiente do leilão
- Uma solução provavelmente seria uma nova API, que precisaria passar pelo processo de proposta do W3C.
Dessa forma, criar uma solução de limite de frequência fora da Protected Audience não está no nosso roteiro imediato, mas estamos abertos a feedback sobre possíveis maneiras de resolver esse caso de uso.
E os casos de uso que não são cobertos pelo Sandbox de privacidade?
As APIs do Sandbox de privacidade oferecem os principais elementos básicos para a publicidade que preserva a privacidade, em que os desenvolvedores têm a flexibilidade de determinar como eles são reunidos. A abordagem de elementos básicos permite que as empresas inovem e desenvolvam soluções que agregam valor aos clientes. O Sandbox de privacidade não pretende ser uma solução completa para todos os casos de uso. Acreditamos que esse seria um resultado ruim. Em vez disso, desenvolvedores e empresas vão continuar a dar vida às ideias usando várias tecnologias, incluindo as APIs do Sandbox de privacidade que se integram às soluções.