O serviço de agregação gera relatórios de resumo com dados detalhados de conversão e medições de alcance de relatórios agregáveis brutos. Para manter os dados do usuário privados e seguros, o serviço de agregação usa uma estrutura compatível com a privacidade diferencial (DP, na sigla em inglês) para quantificar e limitar a quantidade de informações que esses relatórios revelam sobre usuários individuais.
Neste guia, abordamos ferramentas e estratégias para criar relatórios agregáveis que ajudam a manter os dados de usuários individuais seguros:
- Crie relatórios de resumo com ruído adicionado
- Definir um orçamento de contribuição
- Estratégias para agrupar relatórios
- Processar relatórios duplicados em lotes
- Processar relatórios com um ID compartilhado comum
- Usar chaves de agregação predefinidas
Relatórios de resumo com ruído adicionado
Quando você envia um lote de relatórios agregáveis, o serviço de agregação cria um relatório de resumo. Esse relatório de resumo é um agregado de todas as contribuições de todas as chaves de domínio predefinidas, com ruído estatístico adicionado.
O ruído adicionado aos relatórios não depende do número de relatórios agregados, dos valores de relatórios individuais ou dos valores de relatórios agregados. O ruído é extraído de uma versão discreta da distribuição de Laplace e é dimensionado para o orçamento de contribuição (sensibilidade L1
) que é aplicado pelo cliente dependente da API de medição correspondente e do parâmetro de privacidade epsilon
.
Para saber mais sobre o ruído e as implicações dele para os dados do relatório, consulte Como entender o ruído nos relatórios de resumo.
Orçamento de contribuição
Para controlar a sensibilidade de um relatório de resumo, o número de contribuições transmitidas em uma chamada é vinculado a um limite de contribuição específico, também conhecido como orçamento de contribuição. O orçamento de contribuição varia de acordo com o uso da API Attribution Reporting ou da API Private Aggregation.
Para saber mais sobre como definir orçamentos de contribuição para cada API, consulte as seções a seguir da documentação da API:
- Limite e orçamento de contribuição da API Attribution Reporting
- Limites de contribuição da API Private Aggregation
- Limite e orçamento de contribuição da API Private Aggregation
Estratégias para agrupar relatórios
Ao agrupar relatórios que podem ser agregados, é importante otimizar as estratégias de agrupamento para que os limites de privacidade não sejam excedidos. Dois conceitos importantes para agrupar relatórios corretamente são a regra"sem duplicações" e a ideia de lotes distintos.
Regra "Sem duplicações"
O serviço de agregação aplica uma regra "sem duplicações". Essa regra determina que um relatório agregável, identificado exclusivamente por report_id
, só pode aparecer uma vez em um único lote. Se um relatório agregável aparecer mais de uma vez por lote, o primeiro será incluído na agregação, os relatórios subsequentes com o mesmo report_id
serão descartados e o lote será concluído.
A regra também determina que o mesmo ID compartilhado não pode aparecer em mais de um lote. Se um ID compartilhado já tiver sido incluído em um lote anterior, um lote posterior que também incluir o mesmo ID compartilhado vai falhar.

Sem a regra "sem duplicatas", um invasor poderia ter insights sobre o conteúdo de um lote específico manipulando o conteúdo dos lotes incluindo cópias duplicadas de um relatório em um único lote ou vários lotes.
Para saber mais sobre como aplicar a regra "sem duplicatas" em um lote de relatórios ou em vários lotes, consulte Duplicar relatórios em lotes.
Lotes separados
Para evitar situações em que há sobreposição entre lotes, o serviço de agregação impõe lotes distintos. Isso significa que dois ou mais lotes não podem conter relatórios que compartilham um ID compartilhado. Um ID compartilhado é uma combinação de dados coletados do campo shared_info
de um relatório agregável, junto com o ID de filtragem da solicitação de trabalho. Se nenhum ID de filtragem for especificado, o padrão 0 será usado.
No exemplo de campo shared_info
abaixo, é possível ver a API, attribution_destination
(para o relatório de atribuição), reporting_origin
, scheduled_report_time
, source_registration_time
(para o relatório de atribuição) e version
. Esses campos, exceto report_id
, contribuem para o ID compartilhado, assim como o ID de filtragem da solicitação de trabalho.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
Como source_registration_time
é truncado por dia e scheduled_report_time
é truncado por hora, há relatórios com o mesmo ID compartilhado. Neste exemplo, Relatório1 e Relatório2 têm campos de informações compartilhadas. Ambos os relatórios têm a mesma API, versão, attribution_destination
, reporting_origin
e source_registration_time
. Como report_id
não faz parte do ID compartilhado, ignore essa diferença.
Nos exemplos a seguir para Relatório1 e Relatório2, o valor de scheduled_report_time
é o mesmo.
Report1 compartilhou as seguintes informações:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Report2 compartilhou as seguintes informações:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Os horários programados dos relatórios são "19 de fevereiro de 2024, 21h08min10s" para o Relatório1 e "19 de fevereiro de 2024, 21h55min10s" para o Relatório2. Como o valor do campo scheduled_report_time
é truncado para a hora, os dois relatórios têm 1708376890
(o valor codificado de "19 de fevereiro de 2024, 21h") como o valor do campo scheduled_report_time
.
Com todos os outros campos e o ID de filtragem iguais, os dois relatórios têm o mesmo ID compartilhado. Como os dois relatórios têm o mesmo ID compartilhado, eles precisam ser incluídos no mesmo lote.
Se o Relatório1 foi agrupado em um lote anterior e o Relatório2 foi processado em um lote subsequente, o lote com o Relatório2 falha com um erro PRIVACY_BUDGET_EXHAUSTED
. Se isso acontecer, remova os relatórios com o ID compartilhado que foram agrupados em lotes anteriores e tente novamente. Para mais informações sobre esse erro, consulte Códigos de erro e mitigações do serviço de agregação.

Chaves de agregação predeclaradas
Quando você envia um lote para o serviço de agregação, ele precisa incluir os relatórios agregáveis recebidos da origem de relatórios e o arquivo de domínio de saída. O domínio de saída contém as chaves ou buckets que são extraídas dos relatórios agregáveis.
Do ponto de vista da privacidade, o ruído é adicionado a todas as chaves pré-declaradas no domínio de saída, mesmo quando nenhum relatório real corresponde a uma chave específica. Especificar o domínio de saída protege contra um ataque em que a presença de uma chave na saída revela algo sobre um único usuário ou evento. Por exemplo, se você mostrou uma campanha apenas para um usuário, o recebimento de uma chave na saída revela que o usuário converteu mais tarde, mesmo com a adição de ruído. Ao especificar esse domínio primeiro, você tem a certeza de que ele não revela nada sobre as contribuições do usuário.
É possível declarar essas chaves de 128 bits na API Attribution Reporting ou na API Private Aggregation e usá-las para codificar as dimensões que você quer acompanhar.
Somente as chaves predeclaradas são consideradas para agregação e incluídas no relatório de resumo. Os valores agregados dos buckets no relatório de resumo têm ruído estatístico adicionado, o que é refletido no relatório de resumo criado.

Se uma chave de agregação for incluída no arquivo de domínio de saída, mas não estiver localizada em um relatório em lote, mesmo que o valor agregado seja zero, o relatório de resumo final provavelmente não será zero devido ao ruído adicionado para preservar a privacidade.