O serviço de agregação gera relatórios resumidos de dados detalhados de conversão e medições de alcance com base em relatórios agregáveis brutos. As adtechs têm dois pontos de entrada principais no lado do cliente para encaminhar relatórios ao serviço de agregação, seja pela API Attribution Reporting ou pela API Private Aggregation.
Status da implementação
- O serviço de agregação foi movido para disponibilidade geral.
- O Serviço de agregação pode ser usado com a API Attribution Reporting e a API Private Aggregate na API Protected Audience e na API Shared Storage.
Disponibilidade
| Proposta | Status |
|---|---|
| Suporte ao serviço de agregação para Amazon Web Services (AWS) pela API Attribution Reporting e pela API Private Aggregate
Explicação |
Disponível |
| Suporte do serviço de agregação para o Google Cloud na API Attribution Reporting e na API Private Aggregation Explicação |
Disponível |
| Inscrição do site do serviço de agregação e agregação de várias origens. A inscrição de site inclui o mapeamento de um site para contas de nuvem (AWS ou GCP). Para agregar várias origens, elas precisam ser do mesmo site.
Perguntas frequentes no GitHub Documentação da API de agregação de sites |
Disponível |
| O valor de epsilon do serviço de agregação será mantido em um intervalo de até 64, para facilitar a experimentação e o feedback sobre diferentes parâmetros.
Enviar feedback épsilon da ARA. Enviar feedback épsilon do PAA. |
Disponível. Vamos avisar com antecedência ao ecossistema antes que os valores do intervalo de epsilon sejam atualizados. |
| Filtragem de contribuição mais flexível para consultas do serviço de agregação
Explicação |
Disponível |
| Processo de recuperação do orçamento após um desastre (erros, configurações incorretas etc.)
Explicação |
Mecanismo disponível para analisar a porcentagem de IDs compartilhados recuperados por uma adtech usando a recuperação de orçamento e suspender recuperações futuras para recuperações excessivas planejadas para o primeiro semestre de 2025 |
| A Accenture opera como um dos coordenadores na AWS
Blog para desenvolvedores |
Disponível |
| Parte independente que atua como um dos coordenadores no Google Cloud
Blog para desenvolvedores |
Disponível |
| Suporte ao serviço de agregação para gerar relatórios de depuração agregados na API Attribution Reporting
Explicação |
Disponível |
Principais termos e conceitos
Se você está pensando em usar o serviço de agregação no seu fluxo de trabalho de adtech, os termos e conceitos a seguir devem fornecer mais insights sobre o que esse novo fluxo de agregação pode oferecer para sua equipe:
| 术语 | 说明 |
|---|---|
| 汇总服务 | 由广告技术平台运营的服务，用于处理可汇总报告以创建摘要报告。 |
| 可汇总的报告 |
Os relatórios agregáveis são relatórios criptografados enviados de dispositivos de usuários específicos. Esses relatórios contêm dados sobre o comportamento do usuário em vários sites e as conversões. As conversões (às vezes chamadas de eventos acionadores de atribuição) e as métricas associadas são definidas pelo anunciante ou pela adtech. Cada relatório é criptografado para evitar que várias partes acessem os dados. 详细了解可汇总的报告。 |
| 可汇总报告的会计核算 | 位于两个协调器中的分布式账本，用于跟踪分配的隐私预算并强制执行“无重复”规则。这是一种隐私保护机制，位于协调者中并在其中运行，可确保通过汇总服务传递的报告不会超出分配的隐私预算。 详细了解批处理策略与可汇总报告的关系。 |
| 可汇总报告的会计核算预算 | 对预算的引用，用于确保报告不会被处理多次。 |
| 可信执行环境 (TEE) |
Um ambiente de execução confiável é uma configuração especial de hardware e software de computador que permite as partes para verificar as versões exatas do software em execução no computador. TEEs permitem que partes externas verifiquem se o software faz exatamente o que fabricante do software afirma que sim, nada mais ou menos. Para saber mais sobre os TEEs usados para as propostas do Sandbox de privacidade, leia a explicação dos serviços da API Protected Audience e a explicação do serviço de agregação. |
| 协调员 |
Um coordenador é uma entidade responsável pelo gerenciamento de chaves e pela contabilidade de relatórios agregáveis. O coordenador mantém uma lista de hashes de configurações aprovadas do serviço de agregação e configura o acesso às chaves de descriptografia. |
| 共享 ID |
计算值，由以下各项组成：shared_info、reporting_origin、destination_site（仅适用于 Attribution Reporting API）、source_registration-time（仅适用于 Attribution Reporting API）、scheduled_report_time、version。
这意味着，如果多个报告具有相同的 shared_info 字段属性，则它们属于同一共享 ID。这在可汇总报告会计中起着重要作用。
详细了解可信服务器。
|
| 汇总报告 |
Um relatório de resumo é um tipo de relatório da API Attribution Reporting e da API Private Aggregation. Um resumo inclui dados agregados do usuário e pode conter dados de conversão detalhados, com adição de ruído. Os relatórios de resumo são compostos por relatórios agregados. Os relatórios de resumo oferecem mais flexibilidade e um modelo de dados mais rico do que os relatórios de evento, principalmente para alguns casos de uso, como valores de conversão. |
| 举报来源 |
A origem do relatório é a entidade que recebe relatórios agregáveis, ou seja, a adtech que chamou a API Attribution Reporting. Os relatórios agregáveis são enviados de dispositivos dos usuários para um URL conhecido associado ao relatório origem. Essa origem de relatórios precisa ser designada durante a inscrição. |
| 贡献债券 | 可汇总的报告可以包含任意数量的计数器增量。例如，报告中可能包含用户在广告客户网站上查看过的商品数量。与单个来源事件相关的所有可汇总报告中的增量之和不得超过给定限制“L1=2^16”。 如需了解详情，请参阅可汇总报告说明。 |
| 噪声和缩放 | 在汇总过程中，系统会向摘要报告添加一定量的统计噪声，这也有助于保护隐私并确保最终报告提供匿名化效果衡量信息。详细了解加法噪声机制，该机制是从拉普拉斯分布中提取的。 |
| 证明 |
O atestado é um mecanismo para autenticar a identidade do software, geralmente com hashes criptográficos ou assinaturas. Para a proposta de serviço de agregação, o atestado corresponde o código em execução no serviço de agregação operado por tecnologias de publicidade com o código-fonte aberto. 详细了解证明。 |
Leia mais sobre o histórico do serviço de agregação em nosso texto explicativo e na lista completa de termos.
Casos de uso de agregação
Considere as seguintes jornadas de desenvolvedores para a medição de anúncios e as bibliotecas de cliente correspondentes.
| Caso de uso | Ponto de entrada | Descrição |
|---|---|---|
| Otimização de lances | API Attribution Reporting (Chrome e Android) | Use relatórios agregados para processar indicadores de conversão com o objetivo de otimizar os lances. |
| Medição entre plataformas | API Attribution Reporting (Chrome e Android) | Use os recursos de medição entre a Web e apps para ter visibilidade do desempenho no Chrome e no Android. |
| Relatórios de conversão | API Attribution Reporting (Chrome e Android) | Criar relatórios de conversão agregados adaptados às necessidades de campanha dos clientes (inclui CTCs e VTCs). |
| Medição do alcance da campanha | API Shared Storage e API Private Aggregation (Chrome) | Use as variáveis de visualização de anúncios entre sites para medir o alcance da campanha. |
| Relatórios demográficos | API Shared Storage e API Private Aggregate (Chrome) | Use a visualização de anúncios entre sites e as informações demográficas para medir o alcance por dados demográficos. |
| Análise do caminho de conversão | API Shared Storage e API Private Aggregate (Chrome) | Armazene as variáveis de conversão e visualização de anúncios em vários sites para analisar o caminho de conversão agregado. |
| Brand e Conversion Lift | API Shared Storage e API Private Aggregation (Chrome) | relatórios sobre grupos de teste/controle e informações de pesquisa para medir o Brand Lift e a incrementabilidade. |
| Depuração do leilão | API Protected Audience e API Private Aggregate (Chrome) | Use relatórios agregados para depuração. |
| Distribuição de lances | API Protected Audience e API Private Aggregation (Chrome) | Use relatórios agregados para capturar a distribuição dos valores de lances para leilões. |
Fluxo completo
O diagrama a seguir mostra o serviço de agregação em ação. Vamos nos concentrar no fluxo completo, desde o recebimento dos relatórios da Web e de dispositivos móveis até a criação dos relatórios de resumo no serviço de agregação.
- Busque a chave pública para gerar relatórios criptografados.
- Relatórios agregáveis criptografados enviados aos servidores de adtechs para serem coletados, transformados e agrupados.
- O servidor de adtech agrupa relatórios (formato avro) e os envia para o serviço de agregação implantado. Precisa ser preenchido pela adtech.
- Extrair relatórios agregados para descriptografar.
- Recupere as chaves de descriptografia dos coordenadores.
- O serviço de agregação descriptografa relatórios para agregação e ruído.
- O serviço de contabilidade de relatórios agregáveis verifica se há algum orçamento de privacidade restante para gerar um relatório de resumo dos relatórios agregáveis fornecidos.
- Envie o relatório de resumo final.
No diagrama, é possível ver a relação geral que o serviço de agregação tem com as principais APIs de medição de clientes API Attribution Reporting, API Private Aggregation e os coordenadores.
O fluxo começa com diferentes APIs de medição, como a API Attribution Reporting ou a API Private Aggregate, que geram relatórios usando várias instâncias do navegador. O Chrome usa a chave pública do serviço de hospedagem de chaves no coordenador para criptografar os relatórios antes que eles sejam enviados à origem de relatórios da adtech. As chaves públicas são alternadas a cada sete dias.
Depois que a origem de relatórios da adtech recebe esses relatórios, ela precisa ser configurada para coletar e converter esses relatórios para o formato avro e enviados à instância do serviço de agregação implantada. Confira as estratégias de lote.
Quando a adtech estiver pronta para gerar lotes, ela vai criar uma solicitação em lote para o serviço de agregação, em que os relatórios são descriptografados com a recuperação das chaves de descriptografia do serviço de hospedagem de chaves, agregados e ruídos para criar um relatório de resumo. Isso depende se há orçamento de privacidade suficiente para gerar os relatórios de resumo finais.
O endpoint de origem de relatórios da adtech, onde os relatórios são coletados, é hospedado pela adtech, e o serviço de agregação é implantado na nuvem da adtech.
Relatórios agregáveis em lote
O fluxo de relatórios não estaria completo sem a ajuda do servidor de origem de relatórios designado. Essa é a origem que uma adtech teria enviado no processo de registro. As principais ações pelas quais a origem do relatório é responsável seriam coletar, transformar e agrupar em lote os relatórios agregáveis recebidos e prepará-los para serem enviados ao serviço de agregação implantado pela adtech no Google Cloud ou na Amazon Web Services. Saiba como preparar seus relatórios agregáveis.
Agora que você já tem o conceito geral, confira os componentes que serão implantados no serviço de agregação.
Componentes do Cloud
O serviço de agregação consiste em vários componentes de serviço de nuvem. Os scripts do Terraform fornecidos provisionam e configuram todos os componentes necessários do serviço de nuvem.
Serviço de front-end
Serviço gerenciado do Cloud: função do Cloud (Google Cloud) / gateway de API (Amazon Web Services)
O serviço de front-end é um gateway sem servidor que serve como ponto de entrada para chamadas da API Aggregation para criação e recuperação do estado de jobs. Ele é responsável por receber solicitações de usuários do serviço de agregação, validar parâmetros de entrada e iniciar o processo de programação do job de agregação.
Duas APIs estão disponíveis no serviço de front-end:
| Endpoint | Descrição |
|---|---|
createJob |
Essa API aciona um job do serviço de agregação. Ele exige informações para acionar um job, como o ID do job, detalhes do armazenamento de entrada, detalhes do armazenamento de saída, origem dos relatórios e muito mais. |
getJob |
Essa API retorna o status de um job para um ID de job especificado. Ele fornece informações sobre o estado do job, como "Recebido", "Em andamento" ou "Concluído". Além disso, se o job for concluído, ele vai mostrar o resultado, incluindo as mensagens de erro encontradas durante a execução. |
Confira a documentação da API Aggregation Service.
Fila de jobs
Serviço de nuvem gerenciado: Pub/Sub (Google Cloud) / Amazon SQS (Amazon Web Services)
A fila de jobs é uma fila de mensagens que armazena solicitações de jobs para o serviço de agregação. O serviço de front-end insere mensagens de solicitação de job na fila, que são consumidas pelo Aggregation Worker para processar a solicitação de job.
Cloud Storage
Serviço de nuvem gerenciado: Google Cloud Storage (Google Cloud) / Amazon S3 (Amazon Web Services). O armazenamento em nuvem é usado para armazenar arquivos de entrada e saída usados pelo serviço de agregação (exemplos: arquivos de relatório criptografados, relatórios de resumo de saída etc.).
Banco de dados de metadados do job
Serviço de nuvem gerenciado: Spanner (Google Cloud) / DynamoDB (Amazon Web Services)
O Job Metadata Database armazena e rastreia o status dos jobs de agregação. O banco de dados registra metadados, como hora de criação, hora solicitada, hora atualizada e estado (exemplos: Recebido, Em andamento, Concluído etc.). O Aggregation Worker atualiza o banco de dados de metadados do job conforme o job avança.
Worker de agregação
Serviço de nuvem gerenciado:Compute Engine com Confidential Space (Google Cloud) / Amazon Web Services EC2 com Nitro Enclave (Amazon Web Services)
O worker de agregação processa as solicitações de job iniciadas por uma solicitação na fila de jobs, descriptografando as entradas criptografadas usando chaves buscadas no serviço de geração e distribuição de chaves (KGDS, na sigla em inglês) nos coordenadores. Para minimizar a latência de processamento do job, as chaves de descriptografia são armazenadas em cache no worker de agregação por um período de oito horas. Elas podem ser usadas em todos os jobs processados por essa instância de worker.
O worker opera em uma instância de ambiente de execução confiável (TEE). Cada worker lida com apenas um job por vez. A adtech pode configurar vários workers para processar jobs em paralelo definindo a configuração de escalonamento automático. Por meio do escalonamento automático, o número de workers é ajustado dinamicamente pelo número de mensagens restantes na fila de jobs. Os números mínimo e máximo de workers para escalonamento automático podem ser configurados no arquivo de ambiente do Terraform. Confira mais informações sobre o escalonamento automático nos scripts do Terraform a seguir. [Amazon Web Services / Google Cloud]
O worker de agregação chama o serviço de contabilização de relatórios agregáveis para a contabilização de relatórios agregáveis. O serviço de contabilidade de relatórios agregáveis vai garantir que os jobs sejam executados apenas enquanto o limite do orçamento de privacidade ainda não tiver sido excedido. Consulte a regra "Sem cópias". Se o orçamento estiver disponível, um relatório resumido será gerado usando os agregados com ruído. Leia mais detalhes sobre a contabilização de relatórios agregáveis.
O worker de agregação atualiza os metadados do job no banco de dados de metadados do job, incluindo códigos de retorno de job apropriados e contadores de erros de relatório em caso de falhas parciais do relatório. Os usuários podem buscar o estado usando a API de recuperação do estado do job (getJob).
Confira uma descrição mais detalhada do serviço de agregação na nossa explicação.
Próximas etapas
Agora que você já conhece os destaques do serviço de agregação, é hora de implantar sua própria instância dele pelo Google Cloud ou Amazon Web Services. Confira a seção de início. Se precisar de mais informações sobre como operar um serviço de agregação implantado, clique neste link para saber mais sobre como operar o serviço de agregação.
Solução de problemas
Consulte nosso documento Códigos de erro comuns e mitigações para descrições mais detalhadas das mensagens de erro, o que pode ter causado o erro que você está enfrentando e as próximas etapas para mitigação.
Receber suporte e enviar feedback
- Para problemas técnicos, dúvidas sobre produtos, feedback e solicitações de recursos, crie um problema no nosso repositório do GitHub (link em inglês).
- Para dúvidas em que você precisa fornecer informações sensíveis ou confidenciais para solução de problemas, entre em contato com aggregation-service-support@google.com.
- Verifique os problemas conhecidos no Painel de status público.