Inserimento del rumore

L'inserimento del rumore è una tecnica utilizzata per proteggere la privacy degli utenti quando viene eseguita una query in un database. Funziona aggiungendo un rumore inusuale a una clausola SELECT di aggregazione di una query. Questo rumore protegge la privacy degli utenti e, nel contempo, fornisce risultati ragionevolmente precisi, il che elimina la necessità di controllare le differenze e riduce la soglia di aggregazione richiesta per l'output. La maggior parte delle query esistenti può essere eseguita in modalità rumore, con alcune limitazioni.

Vantaggi dell'utilizzo dell'inserimento del rumore

Il controllo delle differenze non viene usato: quando esegui query con l'inserimento del rumore Ads Data Hub non filtra le righe per via della similarità con set di risultati precedenti. Ciò significa che puoi ancora avere una vista olistica dei dati e continuare a proteggere la privacy degli utenti.

La risoluzione dei problemi è più semplice: le righe vengono omesse solo a causa di requisiti di aggregazione, il che rende più semplice risolvere i problemi e adattare le query.

Non devi imparare una nuova sintassi: non devi imparare una sintassi diversa per le query né nuovi concetti sulla privacy per utilizzare il rumore anziché il controllo delle differenze.

La precisione dei risultati è evidente: un job eseguito correttamente mostra la percentuale totale dei dati con il rumore previsto.

In che modo il rumore influisce sui requisiti di privacy

Controllo delle differenze: l'inserimento del rumore non si basa su controlli delle differenze esistenti in Ads Data Hub. Quando inserisci il rumore, i controlli delle differenze vengono disattivati.

Requisito di aggregazione: l'inserimento del rumore restituisce i dati sulle impressioni di circa 20 o più utenti unici e dati su clic o conversioni relativi a 10 o più utenti unici.

Controlli statici: nessun impatto.

Budget e limiti di query: le query eseguite utilizzando il rumore condividono il budget di accesso ai dati usato con i controlli delle differenze. Come con i controlli delle differenze, se esegui la stessa query sullo stesso set di dati più volte, potresti perdere l'accesso a date sottoposte di frequente a query nel set di dati. Ciò può verificarsi se esegui query su finestre scorrevoli o se invii la stessa richiesta più volte.

La modalità rumore impone ulteriori limiti rigidi sul riconteggio degli stessi risultati aggregati tra le varie query o al loro interno. Come con il budget di accesso ai dati, puoi perdere l'accesso a date sottoposte di frequente a query nel set di dati; tuttavia, le limitazioni dovute al riconteggio degli stessi risultati aggregati limiteranno solo le query nella modalità rumore, non quelle nella modalità di controllo delle differenze. Per saperne di più, consulta l'argomento Risultati ripetuti.

Scopri di più sui controlli per la privacy.

In che modo l'inserimento del rumore incide sui risultati

Ads Data Hub inserisce il rumore per mitigare i rischi di divulgazione, ossia il rischio che qualcuno possa ottenere informazioni su un singolo utente. Bilancia la privacy e l'utilità.

L'inserimento del rumore in Ads Data Hub trasforma i risultati delle query in questo modo:

Limita i contributi degli utenti anomali nei risultati aggregati. Somma tutti i contributi dell'utente in ogni aggregazione e fissa ogni contributo con limiti minimi e massimi di blocco.
Aggrega i contributi bloccati per utente.
Aggiunge rumore a tutti i risultati aggregati: il risultato di ogni chiamata di funzione dell'aggregazione in ogni riga. La portata di questo rumore inusuale è proporzionale ai limiti fissati.
Viene conteggiato il numero di utenti che usano il rumore per ogni riga, mentre vengono eliminate le righe con un numero troppo basso di utenti. Questo approccio è simile alla k-anonymity nella modalità di controllo delle differenze; tuttavia, a causa del rumore, i job eseguiti sullo stesso set di dati possono ignorare diverse righe. Inoltre, la modalità rumore ignora meno righe perché il requisito di aggregazione è inferiore (circa 20 rispetto a esattamente 50).

Il risultato finale è un set di dati in cui ogni riga dispone di risultati aggregati sul rumore, mentre i gruppi piccoli vengono eliminati. Ciò maschera l'effetto di un singolo utente sui risultati visualizzati.

Informazioni sul blocco dell'aggregazione

L'inserimento del rumore in Ads Data Hub utilizza un blocco per l'aggregazione implicito o esplicito per limitare il contributo di valori o utenti anomali. Puoi scegliere il tipo di blocco da utilizzare, a seconda del caso d'uso.

Blocco implicito

Nel blocco implicito, i limiti vengono stabiliti automaticamente. Non è necessaria una sintassi SQL particolare per usare un blocco implicito. Se una riga ha un intervallo di valori più ampio di un'altra, il blocco implicito individua limiti diversi per queste righe. In questo modo, il margine di errore è generalmente inferiore per ogni risultato. D'altra parte, ogni aggregazione ha limiti di blocco e livelli di rumore diversi, il che rende difficile il confronto.

Il blocco implicito potrebbe non funzionare quando un'aggregazione riceve i dati da un numero ridotto di utenti, ad esempio una chiamata COUNTIF() con una condizione rara. In questi casi vengono visualizzati risultati NULL. Inoltre, tieni presente che COUNT(DISTINCT user_id) utilizza automaticamente il blocco esplicito con limiti di 0 e 1.

Blocco esplicito

Il blocco esplicito limita il contributo totale di ogni utente a un intervallo specificato. I limiti espliciti vengono applicati uniformemente a tutte le righe e devono essere valori letterali. Anche se alcune righe presentano una gamma più vasta di contributi per utente rispetto ad altre, vengono applicati gli stessi limiti a tutte le righe. Ciò rende i risultati di diverse righe più paragonabili, anche se alcune righe avranno più rumore di quanto potrebbero ottenere con il blocco implicito.

Il blocco esplicito utilizza la metà del rumore rispetto al blocco implicito per un determinato insieme di limiti di blocco. Pertanto, se puoi stimare limiti ragionevoli, otterrai risultati migliori impostandoli esplicitamente.

Per utilizzare il blocco esplicito, imposta i limiti per ogni funzione aggregata supportata aggiungendo numeri interi che indichino il valore minimo e massimo dei limiti. Ad esempio:

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

Eseguire una query utilizzando l'inserimento del rumore

Crea una query o aprine una esistente. Per capire quali funzioni aggregate utilizzare, consulta l'argomento Funzioni supportate.
Nell'editor query, fai clic su Esegui per inserire i dettagli relativi a un nuovo job.
Fai clic sull'opzione Impostazioni della privacy per attivare o disattivare Usa il rumore.
Esegui la query.
Rivedi il rumore aggiunto.
Facoltativo: adatta la query per ridurre l'impatto del rumore.

Rivedere l'impatto del rumore

Una volta completata una query, Ads Data Hub indica l'affidabilità del risultato in base al numero di celle nell'output che mostra la quantità di rumore prevista. Un valore nella tabella dei risultati viene considerato altamente influenzato se la scala del rumore aggiunto supera il 5% del risultato nella cella. Visualizza gli intervalli dell'impatto nella seguente tabella.

Per i set di dati dell'output interessati, la scheda Dettagli indica le 10 colonne con maggior rumore dall'impatto maggiore a quello minore e relativi contributi al rumore. Questa è la suddivisione della quantità prevista di rumore.

Dati con una quantità prevista di rumore	Colore dell'indicatore	Impatto
>95%	Verde	Impatto ridotto
85% - 95%	Giallo	Impatto medio
75% - 85%	Arancione	Impatto elevato
<75%	Rosso	Impatto molto elevato

Per visualizzare informazioni dettagliate sull'impatto del rumore:

Fai clic su Report.
Seleziona un report dall'elenco. La descrizione comando del riepilogo sulla privacy indica la percentuale di risultati che presentano la quantità di rumore prevista, corrispondente alla quantità di rumore aggiunta maggiore del 5% rispetto al risultato.
Per scoprire di più, fai clic su Job > Dettagli
Visualizza Messaggi sulla privacy nei dettagli del job. I risultati rientrano in una delle categorie elencate.
Se necessario, modifica la query per migliorare il risultato.

Adattare le query

È più probabile che i risultati aggregati contengano una quantità di rumore inaspettata quando pochi utenti contribuiscono a questi risultati. Ciò può verificarsi quando le righe hanno pochi utenti o quando alcuni utenti non influiscono sui risultati, ad esempio quando usano la funzione COUNTIF. In base ai dettagli del rumore, potresti voler modificare la query per aumentare la percentuale di dati con la quantità di rumore previsto.

Ecco alcune linee guida generali:

Espandi l'intervallo di date.
Riscrivi la query per ridurre la granularità dei dati, ad esempio raggruppandoli in base a meno parametri o sostituendo COUNTIF con COUNT.
Rimuovi le colonne con rumore.
Utilizza il blocco esplicito.

Funzioni aggregate supportate

Le funzioni aggregate riportate di seguito sono supportate con il rumore:

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

La parola chiave DISTINCT è supportata solo con la funzione COUNT e solo quando utilizzata con un riferimento diretto alla colonna user_id da una tabella di Ads Data Hub o un'espressione che restituisce i valori user_id o NULL, ad esempio COUNT(DISTINCT IF(..., user_id, NULL)).

Le seguenti funzioni non sono supportate direttamente, ma possono essere sostituite da altre funzioni aggregate con rumore per ottenere risultati statistici. Tieni presente che i valori numerici sono solo esempi:

LOGICAL_OR(...). Alternativa consigliata: COUNT(DISTINCT IF(..., user_id, NULL)) > 0
LOGICAL_AND(...). Alternativa consigliata: COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

Informazioni sui risultati interi

Sebbene Ads Data Hub inserisca il rumore automaticamente per queste funzioni di aggregazione, le firme delle funzioni non cambiano. Poiché le funzioni come COUNT o SUM di INT64 restituiscono INT64, tutti i numeri con parte decimale dei risultati con rumore verranno arrotondati. Solitamente, si tratta di un valore trascurabile rispetto alla dimensione del risultato e del rumore.

Se hai bisogno della granularità del valore decimale nei risultati, non scrivere funzioni che restituiscano INT64, ad esempio utilizzando SUM con l'input trasmesso a FLOAT64.

Pattern di query supportati

Importante: la maggior parte delle best practice standard di Ads Data Hub continua a essere applicata alle query che usano l'inserimento del rumore. In particolare, ti consigliamo di rivedere le istruzioni su come eseguire query ripetute sugli stessi dati.

In questa sezione vengono descritti i pattern di query supportati quando si eseguono query con l'inserimento del rumore.

Dati aggregati a livello di utente

I dati aggregati a livello di utente senza limitazioni sono supportati come nella modalità di controllo delle differenze. Il rumore viene inserito solo nelle aggregazioni che combinano dati di più utenti. Le aggregazioni che eseguono raggruppamenti espliciti in base a user_id o le funzioni di analisi che eseguono partizioni in base a user_id, non ricevono rumore e possono usare qualsiasi funzione. Le aggregazioni a livello di utente che non eseguono raggruppamenti espliciti in base a user_id, ad esempio GROUP BY impression_id, vengono trattate come aggregazioni per più utenti e, di conseguenza, viene aggiunto il rumore.

Il raggruppamento per external_cookie non è sufficiente. Sebbene external_cookie possa essere usato per unire le tabelle *_match con quelle di proprietà del cliente, tutte le aggregazioni per singolo utente devono effettuare un raggruppamento esplicito in base alla colonna user_id, non solo alla colonna external_cookie.

Esempio di funzione aggregata:

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;

Esempio di funzione di analisi:

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;

Dati aggregati paralleli

Ogni aggregazione per più utenti riceve il rumore in modo indipendente. Puoi utilizzare più aggregazioni in una singola istruzione e combinare i risultati in un'unica tabella utilizzando un'istruzione JOIN o UNION.

Esempio:

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)

Tieni presente che questo è supportato ma dovrebbe essere evitato quando si usa la modalità di controllo delle differenze. Questa procedura non presenta problemi con il rumore, poiché ogni dato aggregato parallelo riceve il rumore e usa i filtri in modo indipendente.

Dati aggregati uniti a dati non aggregati

Poiché Ads Data Hub supporta solo le finestre di analisi che eseguono le partizioni in base a user_id, puoi aggregare i risultati separatamente ed eseguire un self-join prima di riaggregarli. Queste query sono supportate in modalità rumore e spesso hanno un rendimento migliore di quello che avrebbero se fossero in modalità di controllo delle differenze, a causa dei requisiti di privacy risolti precedentemente.

Esempio:

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

La modalità rumore vieta di riaggregare i risultati aggregati, come AVG(campaign_imps).

Pattern di query non supportati

In questa sezione vengono descritti i pattern di query non supportati quando si eseguono query con l'inserimento del rumore.

Query inclusive dei dati del giorno corrente

Le query in modalità rumore non supportano l'esecuzione di query dei dati del giorno corrente. (Questo approccio è sconsigliato nella modalità di controllo delle differenze.) Non è possibile selezionare la data corrente per le query che usano l'inserimento del rumore.

Risultati ripetuti

In modalità rumore, Ads Data Hub limita la frequenza con cui puoi ripetere la stessa aggregazione. Se raggiungi questi limiti, le query in modalità rumore perderanno l'accesso alle date sottoposte di frequente a query nel set di dati. Ecco alcuni esempi di come ciò può accadere.

Una query viene ripetuta quando viene eseguita più volte con gli stessi parametri o parametri molto simili, inclusa la sovrapposizione degli intervalli di date. Puoi evitare che ciò accada usando i dati già esportati nel tuo progetto BigQuery.

Tieni presente che se due job eseguono query con una sovrapposizione degli intervalli di date, potrebbero verificarsi delle ripetizioni, se si eseguono i medesimi calcoli sugli stessi utenti. Ad esempio, la seguente query, eseguita con una sovrapposizione di intervalli di date, crea ripetizioni poiché c'è una partizione in base alla data:

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

In questo caso, dovresti eseguire la query su segmenti di dati separati.

Un altro esempio di ripetizione si verifica quando i dati sono in qualche modo indipendenti dalla data. La seguente query genera ripetizioni se eseguita con date in sovrapposizione, in cui entrambi i job coprono l'intera durata di una campagna:

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

In questo caso, dovresti eseguire questa query una sola volta visto che il risultato non cambia.

Un'aggregazione viene ripetuta quando la stessa aggregazione viene eseguita più volte in una query:

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

In questo caso, devi rimuovere una delle ripetizioni.

Tieni presente che anche se le aggregazioni sono sintatticamente diverse ma calcolano lo stesso valore, viene conteggiata una ripetizione. In altre parole, se il valore di condition1 e condition2 è uguale per tutti gli utenti con un valore key, la seguente query viene conteggiata come ripetizione:

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

Se ci sono condizioni molto simili per alcuni gruppi di utenti, potresti valutare la possibilità di riscrivere la query per avere un solo valore COUNT.

Una riga viene duplicata quando una tabella di Ads Data Hub viene unita a una tabella BigQuery in modo che ogni riga della tabella di Ads Data Hub corrisponda a più righe della tabella BigQuery. Ad esempio, la seguente query genera una ripetizione se esistono più righe con lo stesso ID campagna in bq_table:

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

Dovresti quindi modificare la query in modo che bq_table abbia una sola riga per la coppia chiave-valore (in questo caso campaign_id).

Tieni presente che separare un array dalla tabella di Ads Data Hub potrebbe produrre lo stesso effetto se la maggior parte degli utenti ha gli stessi array di valori:

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

Scopri di più su altre best practice relative alle query.

Riaggregazione diretta

Il rumore viene applicato al primo livello di aggregazione per più utenti nella query. Le query con più livelli di aggregazione vengono bloccate:

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

Per ottenere i migliori risultati dal rumore, calcola tutte le operazioni per più utenti di una singola aggregazione. Ad esempio, prendi in considerazione un valore SUM per gli eventi anziché un valore SUM per i conteggi intermedi. Puoi anche riscrivere una query per riaggregare i dati aggregati con rumore, ma i dati aggregati finali possono avere molto più rumore.

Se questo è inevitabile, allora puoi riscrivere la query per esportare i risultati direttamente dal primo livello. Per farlo in un singolo job senza modificare i risultati dello script, crea una tabella temporanea (o una tabella esportata nel tuo progetto BigQuery) con la sintassi OPTIONS(privacy_checked_export=true). Ad esempio:

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

Scopri di più sulle tabelle temporanee.

Se il primo livello di aggregazione è troppo granulare per i controlli per la privacy, valuta la possibilità di riscrivere la query con i dati aggregati a livello di utente. Se questo non è possibile, allora la query in questione non è supportata in modalità rumore.

ID utente non uniti

Le query in modalità rumore non devono combinare dati di utenti separati in un'unica riga, tranne quando si esegue un'aggregazione con rumore. Di conseguenza, i join di dati Ads Data Hub non aggregati devono essere uniti esplicitamente nella colonna user_id.

Questa query non viene unita esplicitamente nella colonna user_id, il che genera un errore di convalida:

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

Puoi risolvere questo problema modificando la clausola USING in modo che includa in modo esplicito user_id, ad esempio USING(impression_id, user_id).

Tieni presente che questa limitazione si applica solo ai join tra tabelle di Ads Data Hub (ad eccezione delle tabelle delle dimensioni). Non si applica alle tabelle di proprietà del cliente. Ad esempio, quanto segue è consentito:

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

Unioni di Ads Data Hub-e BigQuery

Per le aggregazioni con rumore è necessario che gli identificatori utente funzionino correttamente. I dati di proprietà dei clienti in BigQuery non hanno identificatori utente e non possono essere uniti in un'aggregazione con rumore senza che venga effettuata l'unione di una tabella di Ads Data Hub.

Questa query genera un errore di convalida:

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

Per risolvere questo problema, devi unire la tabella BigQuery per aumentare i dati di Ads Data Hub anziché unirli oppure separare i dati per aggregare ciascuna origine separatamente.

Tieni presente che puoi unire più tabelle Ads Data Hub con i dati utente o più tabelle BigQuery di proprietà del cliente, ma non puoi combinare le due cose.

Right join di Ads Data Hub-e BigQuery

Gli outer join con i dati di proprietà del cliente possono generare righe in cui mancano gli identificatori utente, il che impedisce il corretto funzionamento del rumore.

Entrambe queste query generano errori di convalida perché consentono righe senza corrispondenza con identificatori utente mancanti sul lato 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)

Tieni presente che entrambi i join funzionerebbero se l'ordine delle tabelle fosse invertito.

Riepilogo delle righe filtrate

La specifica di riepilogo delle righe filtrate non è supportata in modalità rumore. Questa funzionalità molto spesso non è necessaria con il rumore a causa di velocità di filtro inferiori e della mancanza di filtri dai controlli delle differenze.

Se noti che i dati vengono filtrati in modo eccessivo in un risultato con rumore, aumenta il volume di dati aggregati. Puoi eseguire un'aggregazione parallela sull'intero set di dati per confrontare una stima del totale, ad esempio:

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

Tieni presente che il conteggio totale utilizza il rumore in modo indipendente e che i valori totali potrebbero non sommarsi, ma il conteggio totale è spesso più accurato rispetto alla somma delle righe con rumore.

Tabelle create in più modalità

Le tabelle non esportate in Ads Data Hub possono essere usate solo con la stessa modalità privacy in cui sono state create. Non puoi creare una tabella in modalità aggregazione standard e utilizzarla in modalità rumore o viceversa, a meno che la tabella non venga prima esportata in BigQuery.