Injeção de ruído

A injeção de ruído é uma técnica usada para proteger a privacidade do utilizador quando se consulta uma base de dados. Consiste em adicionar ruído aleatório a uma cláusula SELECT de agregação de uma consulta. Este ruído protege a privacidade do utilizador e oferece resultados razoavelmente precisos, eliminando a necessidade de verificações de diferenças e reduzindo o limite da agregação necessário para dados de saída. A maioria das consultas existentes podem ser executadas no modo de ruído, com algumas limitações.

Conheça as vantagens da utilização da injeção de ruído

As verificações de diferenças não se aplicam: quando executa consultas com injeção de ruído, o Ads Data Hub não filtra linhas devido à semelhança com os conjuntos de dados anteriores. Isto significa que pode continuar a ter uma vista holística dos dados e proteger a privacidade do utilizador.

A resolução de problemas é simplificada: as linhas só são omitidas devido a requisitos de agregação, o que simplifica a resolução de problemas e a adaptação das consultas.

Não há sintaxes novas para aprender: não tem de aprender sintaxes novas de consultas nem de conhecer os conceitos de privacidade para usar o ruído em vez das verificações de diferenças.

A precisão dos resultados é evidente: uma tarefa bem-sucedida mostra a percentagem total de dados com a quantidade de ruído esperada.

Saiba como o ruído afeta os requisitos de privacidade

Verificações de diferenças: a injeção de ruído não depende das verificações de diferenças atuais no Ads Data Hub. Quando usa a injeção de ruído, as verificações de diferenças são desativadas.

Requisito de agregação: a injeção de ruído produz dados de impressões representados por aproximadamente 20 ou mais utilizadores únicos, bem como dados de cliques ou conversão representados por aproximadamente 10 ou mais utilizadores únicos.

Verificações estáticas: sem impacto.

Limites de consulta e orçamentos: as consultas executadas com ruído partilham o número máximo de acessos aos dados usados com verificações de diferenças. Tal como acontece com as verificações de diferenças, se executar a mesma consulta no mesmo conjunto de dados muitas vezes, pode perder o acesso a datas consultadas frequentemente no conjunto de dados. Isto pode acontecer se executar consultas em janelas deslizantes ou se fizer o mesmo pedido várias vezes.

O modo de ruído impõe limites mais rígidos e adicionais quando são feitos novos cálculos dos mesmos resultados agregados em várias ou todas as consultas. Tal como acontece com o número máximo de acessos aos dados, pode perder acesso a datas consultadas frequentemente no conjunto de dados. No entanto, as limitações devido aos novos cálculos feitos aos mesmos resultados agregados apenas restringem consultas no modo de ruído e não consultas no modo de verificação de diferenças. Para mais informações, consulte a secção Resultados repetidos.

Saiba mais acerca das verificações de privacidade.

Saiba como a injeção de ruído afeta os resultados

O Ads Data Hub injeta ruído para mitigar o risco de divulgação, ou seja, de que alguém possa saber informações sobre um utilizador individual. Faz o equilíbrio entre a privacidade e a utilidade.

A injeção de ruído no Ads Data Hub transforma os resultados da consulta da seguinte forma:

• Restringe as contribuições dos utilizadores atípicos nos resultados agregados. Soma a contribuição de cada utilizador em cada agregação e, em seguida, limita cada contribuição com limites de restrição mínimos e máximos.
• Agrega as contribuições por utilizador restringidas.
• Adiciona ruído a cada resultado agregado, ou seja, o resultado de cada chamada de função de agregação em cada linha. A escala deste ruído aleatório é proporcional aos limites restringidos.
• Calcula um número de utilizadores com ruído para cada linha e elimina as linhas que têm utilizadores insuficientes. Isto é semelhante ao k-anonimato no modo de verificação de diferenças, mas devido ao ruído, os trabalhos executados no mesmo conjunto de dados podem levar a diferentes linhas. Além disso, o modo de ruído leva a menos linhas porque o requisito de agregação é inferior (aproximadamente 20 em comparação com exatamente 50).

O resultado final é um conjunto de dados em que cada linha tem resultados agregados com ruído e pequenos grupos foram eliminados. Isto oculta o efeito de um utilizador individual nos resultados devolvidos.

Acerca da restrição de agregação

A injeção de ruído no Ads Data Hub usa a restrição de agregação implícita ou explícita para limitar a contribuição dos valores atípicos. Pode escolher que tipo de restrição usar, dependendo do exemplo de utilização.

Restrição implícita

Na restrição implícita, os limites são determinados automaticamente. Não precisa de nenhuma sintaxe SQL especial para usar a restrição implícita. Se uma linha tiver um intervalo maior de valores do que outra, a restrição implícita encontra limites diferentes para esta linha. Normalmente, isto gera uma margem de erro menor para cada resultado. Por outro lado, cada agregação recebe diferentes limites de restrição e níveis de ruído, o que pode dificultar a comparação das mesmas.

A restrição implícita pode falhar quando uma agregação recebe dados de um número insuficiente de utilizadores, por exemplo, uma chamada COUNTIF() com uma condição rara. Estes casos devolvem NULL resultados. Além disso, tenha em atenção que COUNT(DISTINCT user_id) usa automaticamente restrição explícita com limites de 0 e 1.

Restrição explícita

A restrição explícita restringe a contribuição total de cada utilizador a um intervalo especificado. Os limites explícitos são aplicados uniformemente a todas as linhas e têm de ser valores literais. Mesmo que algumas linhas tenham um intervalo maior de contribuições por utilizador do que outras, os mesmos limites aplicam-se a todas elas. Isto facilita a comparação dos resultados de linhas diferentes, embora algumas recebam mais ruído do que receberiam com a restrição implícita.

A restrição explícita usa metade do ruído relativamente à restrição implícita para um determinado conjunto de limites de restrição. Assim sendo, se for possível estimar limites razoáveis, os resultados serão melhores quando os definir de forma explícita.

Para usar a restrição explícita, defina os limites para cada função de agregação suportada através da adição de números inteiros que representem o limite inferior e o superior. Por exemplo:

SELECT
campaign_name,
-- Set lower and upper bounds to 0 and 1, respectively
ADH.ANON_COUNT(*, contribution_bounds_per_group => (0,1))
FROM data
GROUP BY 1

Execute uma consulta através da injeção de ruído

1. Escreva uma consulta ou abra uma que já exista. Para ver que funções agregadas pode usar, consulte a secção Funções suportadas.
2. No editor de consultas, clique em Executar e introduza os detalhes para uma nova tarefa.
3. Clique no botão Definições de privacidade para ativar a opção Usar ruído.
4. Execute a consulta.
5. Reveja o ruído adicionado.
6. Opcional: adapte a consulta para reduzir o impacto do ruído.

Reveja o impacto do ruído

Assim que a consulta for concluída com êxito, o Ads Data Hub apresenta a fiabilidade do resultado com base no número de células no resultado que têm a quantidade esperada de ruído. Na tabela de resultados, considera-se que um valor é altamente afetado se a escala de ruído adicionado for superior a 5% do resultado na célula. Consulte os intervalos de impacto na seguinte tabela.

No caso dos conjuntos de dados de resultado afetados, o separador de detalhes apresenta as 10 colunas com mais ruído, do maior impacto para o menor e a correspondente contribuição para o ruído. Segue-se a discriminação da quantidade esperada de ruído.

Dados com a quantidade de ruído esperada	Cor do indicador	Impacto
> 95%	Verde	Impacto reduzido
85%-95%	Amarelo	Impacto médio
75%-85%	Laranja	Impacto elevado
< 75%	Vermelho	Impacto muito elevado

Para consultar informações detalhadas sobre o impacto do ruído:

1. Clique em Relatórios.
2. Selecione um relatório na lista. A sugestão do resumo de privacidade indica a percentagem de resultados que têm a quantidade de ruído esperada, correspondente à quantidade de ruído adicionado que é superior a 5% do resultado.
3. Para ver mais informações, clique em Tarefas > Detalhes
4. Consulte Mensagens de privacidade nos detalhes da tarefa. Os resultados inserem-se numa das categorias apresentadas.
5. Se necessário, ajuste a consulta para melhorar o resultado.

Adapte as consultas

A probabilidade de os resultados agregados terem uma quantidade de ruído inesperada é maior quando há poucos utilizadores a contribuírem para esses resultados. Isto pode acontecer quando as linhas têm poucos utilizadores ou quando alguns utilizadores não afetam os resultados (por exemplo, quando a função COUNTIF é usada). Com base nos detalhes do ruído, é recomendável ajustar a consulta para aumentar a percentagem de dados com a quantidade de ruído esperada.

Seguem-se as diretrizes gerais:

• Expanda o intervalo de datas.
• Reescreva a consulta para reduzir o nível de detalhe dos dados. Por exemplo, pode agrupá-los por um menor número de parâmetros ou substituir COUNTIF por COUNT.
• Remova as colunas com ruído.
• Use a restrição explícita.

---

Funções de agregação suportadas

As seguintes funções de agregação são suportadas com ruído:

• SUM(...)
• COUNT(*)
• COUNT(...)
• COUNTIF(...)
• COUNT(DISTINCT user_id)
• APPROX_COUNT_DISTINCT(user_id)
• AVG(...)

A palavra-chave DISTINCT só é suportada com a função COUNT e apenas quando usada com referência direta à coluna user_id de uma tabela do Ads Data Hub ou uma expressão que devolva user_id ou NULL, como COUNT(DISTINCT IF(..., user_id, NULL)).

As seguintes funções não são suportadas diretamente, mas podem ser substituídas por outras funções de agregação com ruído para receber resultados estatísticos. Tenha em atenção que os valores numéricos são apenas exemplos:

• LOGICAL_OR(...). Substituição sugerida: COUNT(DISTINCT IF(..., user_id, NULL)) > 0
• LOGICAL_AND(...). Substituição sugerida: COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

Acerca dos resultados dos números inteiros

Embora o Ads Data Hub injete automaticamente o ruído para estas funções de agregação, as assinaturas de funções não se alteram. Dado que as funções como COUNT ou SUM de INT64 devolvem INT64, qualquer parte decimal do resultado com ruído é arredondada. Normalmente, isto não é significativo em relação ao tamanho do resultado e do ruído.

Se precisar do nível de detalhe da casa decimal no resultado, evite escrever funções que devolvam INT64 (por exemplo, usando SUM com entrada convertida para FLOAT64).

---

Padrões de consulta suportados

Importante: a maioria das práticas recomendadas padrão do Ads Data Hub continuam a aplicar-se às consultas que usam a injeção de ruído. Em particular, recomendamos que reveja as orientações sobre a consulta de forma repetida dos mesmos dados.

Esta secção descreve os padrões de consulta suportados quando se executam consultas através da injeção de ruído.

Dados agregados ao nível do utilizador

Os dados agregados ao nível do utilizador não restritos são suportados da mesma forma que no modo de verificação de diferenças. O ruído só é injetado em agregações que combinam dados de vários utilizadores. As agregações que agrupam os dados explicitamente por user_id ou as funções analíticas que fazem a partição dos mesmos por user_id, não recebem nenhum ruído, sendo permitida qualquer função. As agregações ao nível do utilizador que não agrupam os dados explicitamente por user_id, por exemplo, GROUP BY impression_id, são tratadas como agregações de vários utilizadores, pelo que se adiciona ruído.

Agrupar por external_cookie não é suficiente. Enquanto external_cookie pode ser usado para juntar tabelas *_match a tabelas detidas por clientes, as agregações de utilizador único devem ser agrupadas de forma explícita por coluna user_id e não apenas por coluna external_cookie.

Exemplo de função de agregação:

WITH user_paths AS (
  # Grouping by user_id, no noise needed, all functions allowed
  SELECT user_id, STRING_AGG(campaign_id, ">" ORDER BY query_id.time_usec) AS path
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to num_users
SELECT path, COUNT(*) AS num_users
FROM user_paths
GROUP BY 1;

Exemplo de função analítica:

WITH events AS (
  # Partitioning by user_id, no noise needed, all functions allowed
  SELECT
    campaign_id,
    ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY query_id.time_usec) AS index
  FROM adh.google_ads_impressions
)
# Noise applied here to first_impressions
SELECT campaign_id, COUNT(*) AS first_impressions
FROM events
WHERE index = 1
GROUP BY 1;

Dados agregados paralelos

Cada agregação de vários utilizadores recebe ruído de forma independente. Pode executar várias agregações desse tipo numa única declaração, combinando resultados numa tabela usando JOIN ou UNION.

Exemplo:

WITH result_1 AS (
  # Noise applied here to num_impressions
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
  GROUP BY 1
), result_2 AS (
  # Noise applied here to num_clicks
  SELECT campaign_id, COUNT(*) AS num_clicks
  FROM adh.google_ads_clicks
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

Tenha em atenção que isto é suportado, mas deve evitar-se no modo de verificação de diferenças. Esta prática não apresenta problemas com o ruído, pois cada dado agregado paralelo recebe ruído e é filtrado de forma independente.

Dados agregados combinados com dados não agregados

Nota: cada agregação recebe ruído de forma independente, pelo que os valores totais podem não corresponder. Neste caso, os valores somados de imps para um determinado campaign_id podem não corresponder ao valor correspondente de campaign_imps.

Como o Ads Data Hub só suporta janelas analíticas que fazem a partição por user_id, uma solução comum é agregar estes resultados separadamente e fazer a autojunção dos mesmos antes de os agregar de novo. Estas consultas são suportadas no modo de ruído e, muitas vezes, têm um desempenho melhor do que no modo de verificação de diferenças, pois os requisitos de privacidade são resolvidos antes.

Exemplo:

WITH campaign_totals AS (
  # Noise applied here to campaign_imps
  SELECT campaign_id, COUNT(*) AS campaign_imps
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to imps
SELECT campaign_id, demographics, campaign_imps, COUNT(*) AS imps
FROM adh.google_ads_impressions JOIN campaign_totals USING(campaign_id)
GROUP BY 1,2,3

O modo de ruído proíbe a agregação repetida de resultados agregados, como AVG(campaign_imps).

---

Padrões de consulta não suportados

Esta secção descreve os padrões de consulta não suportados quando se executam consultas usando a injeção de ruído.

Consultas que incluem a data atual

As consultas do modo de ruído não suportam a consulta dos dados do dia atual. (Isto é desaconselhado no modo de verificação de diferenças.) Não é possível selecionar a data atual para consultas que usam a injeção de ruído.

Resultados repetidos

No modo de ruído, o Ads Data Hub limita a frequência com que pode repetir a mesma agregação. Se alcançar estes limites, as suas consultas do modo de ruído vão perder o acesso a datas consultadas frequentemente no conjunto de dados. Seguem-se exemplos de como isto pode ocorrer.

A repetição de consultas acontece quando a mesma consulta é executada várias vezes com os mesmos parâmetros ou parâmetros altamente semelhantes, como intervalos de datas que se sobrepõem. Para evitar esta situação, use dados já exportados para o seu projeto do BigQuery.

Tenha em atenção que se houver duas tarefas a consultar intervalos de datas sobrepostos, podem gerar repetições, se executarem o mesmo cálculo nos mesmos utilizadores. Por exemplo, a seguinte consulta executada em intervalos de datas sobrepostos cria uma repetição, pois está a fazer a partição por data:

SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1

Neste caso, deve executar a consulta em segmentos de datas separados.

Outro exemplo de uma repetição acontece quando os dados são de alguma forma independentes da data. A seguinte consulta gera repetições quando executada em datas sobrepostas, em que ambas as tarefas abrangem a duração total de uma campanha:

SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1

Neste caso, deve executar esta consulta apenas uma vez, pois o resultado não se altera.

A repetição de agregações acontece quando a mesma agregação se repete várias vezes numa consulta:

SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table

Neste caso, deve remover uma das repetições.

Tenha em atenção que mesmo que as agregações sejam sintaticamente diferentes, mas calculem o mesmo valor, isso conta como uma repetição. Por outras palavras, se os valores de condition1 e condition2 forem os mesmos para todos os utilizadores com algum valor de key, a seguinte consulta vai gerar uma repetição:

SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key

Se tem condições muito semelhantes para alguns grupos de utilizadores, pode ponderar reescrever a consulta de modo a ter apenas um valor COUNT.

A duplicação de linhas acontece quando uma tabela do Ads Data Hub é juntada a uma tabela do BigQuery de uma forma que cada linha da tabela do Ads Data Hub corresponda a várias linhas na tabela do BigQuery. Por exemplo, a seguinte consulta gera uma repetição se houver várias linhas com o mesmo ID da campanha em bq_table:

SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id

Neste caso, deve reestruturar a consulta para que bq_table tenha apenas uma linha por chave-valor de junção (campaign_id, concretamente).

Tenha em atenção que desaninhar uma matriz da tabela do Ads Data Hub pode produzir o mesmo efeito se a maioria dos utilizadores tiverem as mesmas matrizes de valores:

SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1

Saiba mais acerca de outras práticas recomendadas para consultas.

Agregação repetida direta

O ruído é aplicado à primeira camada de agregação de vários utilizadores na consulta. As consultas com várias camadas de agregação são bloqueadas:

WITH layer_1 AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
)
# Reaggregation of partial_result with no user-level data, will be rejected
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

Para receber os melhores resultados do ruído, calcule todas as operações de vários utilizadores numa única agregação. Por exemplo, use uma SUM de eventos em vez de uma SUM de contagens intermédias. É possível reescrever uma consulta para fazer a agregação repetida de agregados com ruído, mas os agregados finais podem ter ruído muito mais elevado.

Se isto for inevitável, pode reescrever a sua consulta para exportar resultados diretamente a partir da primeira camada. Para fazer isto numa única tarefa sem alterar os resultados do script, crie uma tabela temporária (ou uma tabela exportada para o seu projeto do BigQuery) com a sintaxe OPTIONS(privacy_checked_export=true). Por exemplo:

CREATE TEMP TABLE layer_1 OPTIONS(privacy_checked_export=true) AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
);
# Reaggregation of privacy checked data, no noise needed
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

Saiba mais acerca das tabelas temporárias.

Se a primeira camada de agregação for demasiado detalhada para verificações de privacidade, considere reescrever a consulta com dados agregados ao nível do utilizador. Se isto não for possível, então a consulta não é suportada no modo de ruído.

IDs do utilizador não combinados

As consultas no modo de ruído não podem combinar dados de utilizadores separados numa única linha, exceto quando executam uma agregação com ruído. Como resultado, as junções de dados do Ads Data Hub não agregados têm de ser juntadas explicitamente na colunauser_id.

Esta consulta não é juntada explicitamente na coluna user_id, o que resulta num erro de validação:

SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_clicks USING(impression_id)

Isto pode ser corrigido ajustando a cláusula USING para incluir explicitamente user_id, por exemplo, USING(impression_id, user_id).

Tenha em atenção que esta limitação só se aplica a junções entre tabelas do Ads Data Hub (com exceção das tabelas de dimensões). Não se aplica a tabelas detidas pela organização. Por exemplo, é permitido o seguinte:

SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)

Junções entre o Ads Data Hub e o BigQuery

Nas agregações com ruído, é necessário que os identificadores de utilizador funcionem corretamente. Os dados detidos pela organização no BigQuery não tem identificadores de utilizador e, por isso, não podem ser unidos numa agregação com ruído sem serem juntados a uma tabela do Ads Data Hub.

Esta consulta resulta num erro de validação:

SELECT COUNT(*) FROM (
  SELECT 1 FROM adh.google_ads_impressions
  UNION ALL
  SELECT 1 FROM bigquery_project.dataset.table
)

Para corrigir isto, deve juntar a tabela do BigQuery para aumentar os dados do Ads Data Hub em vez de unir ou separar os dados para agregar cada origem separadamente.

Tenha em atenção que pode unir várias tabelas do Ads Data Hub com dados do utilizador, ou várias tabelas do BigQuery detidas pela organização, mas não pode misturar as duas.

Junções à direita entre o Ads Data Hub e o BigQuery

As junções externas com dados detidos pela organização podem gerar linhas com identificadores de utilizador em falta, o que impede o correto funcionamento do ruído.

As duas consultas a seguir geram erros de validação porque permitem linhas sem correspondência com identificadores de utilizador em falta no lado do Ads Data Hub:

SELECT …
FROM adh.google_ads_impressions
RIGHT JOIN bigquery_project.dataset.table USING(column)

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions USING(column)

Tenha em atenção que qualquer destas junções funcionaria se a ordem das tabelas fosse invertida.

Resumo das linhas filtradas

A especificação do resumo das linhas filtradas não é suportada no modo de ruído. Esta funcionalidade costuma ser desnecessária com o ruído devido às baixas taxas de filtragem e à falta de filtragem das verificações de diferenças.

Se observar uma filtragem de dados significativa num resultado com ruído, aumente os dados agregados. Pode executar uma agregação paralela no conjunto de dados completo para comparar uma estimativa do total, por exemplo:

SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1

Tenha em atenção que a contagem total recebe ruído de forma independente e que os valores totais podem não corresponder, mas a contagem total costuma ser mais precisa do que a soma das linhas com ruído.

Tabelas criadas com vários modos

As tabelas não exportadas no Ads Data Hub só podem ser usadas com o mesmo modo de privacidade em que foram criadas. Não pode criar uma tabela no modo de agregação normal e usá-la no modo de ruído ou vice-versa (a menos que essa tabela seja exportada primeiro para o BigQuery).