Proteções de privacidade para relatórios agregáveis

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:

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:

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.

O mesmo relatório só pode ser usado uma vez por lote.
Figura 1. Se um relatório aparecer mais de uma vez em um lote, a agregação vai incluir a primeira instância e descartar os relatórios posteriores com o mesmo ID.

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.

Os relatórios com um ID compartilhado comum precisam ser incluídos no mesmo lote.
Figura 2. O lote 2 contém um relatório que tem um ID compartilhado em comum com um relatório do lote 1. Portanto, o lote 2 falha.

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.

Um lote de privacidade no serviço de agregação.
Figura 3. Um relatório de resumo contém apenas chaves pré-declaradas, também conhecidas como buckets.

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.