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.

Importante: l'accreditamento MRC di Ads Data Hub non si estende alle query eseguite in modalità rumore.

Scopri i vantaggi 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 viene segnalata: un job eseguito correttamente mostra la percentuale totale dei dati che potrebbero essere stati interessati dal rumore.

Scopri 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

Non è necessaria una sintassi SQL particolare per usare un blocco implicito, che viene applicato per impostazione predefinita. I limiti impliciti vengono derivati dai dati stessi e vengono determinati per ogni aggregazione. Se alcune aggregazioni hanno un intervallo di valori più ampio di altre, il blocco implicito può dedurre limiti diversi per aggregazioni diverse, a seconda dei casi. In genere, questo comporta un numero inferiore di errori. Tieni presente che COUNT(DISTINCT user_id) utilizza automaticamente il blocco esplicito con il limite superiore di 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 aggregazioni e devono essere valori letterali. Il bloccaggio esplicito può fornire risultati migliori quando i limiti sono generalmente noti. Ad esempio, limitare le età tra 0 e 100 riflette le informazioni pubbliche perché l'età della maggior parte delle persone rientra generalmente in questo intervallo.

Ads Data Hub fornisce funzioni di aggregazione ADH.ANON supplementari per il blocco esplicito. 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

1. Apri un report.
2. Fai clic sull'opzione Impostazioni del rumore per la privacy per attivare o disattivare Usa il rumore.
3. Esegui la query.
4. Rivedi l'impatto del rumore aggiunto.
5. Facoltativo: adatta la query per ridurre l'impatto del rumore.

Rivedere l'impatto del rumore

Una volta completato un job, Ads Data Hub indica l'affidabilità del risultato nel riepilogo della privacy. L'affidabilità si basa sulla percentuale di celle nell'output che potrebbero essere fortemente influenzate dal rumore. Un valore nella tabella dei risultati viene considerato influenzato se la scala del rumore aggiunto supera il 5% del risultato nella cella.

Per i set di dati dell'output interessati, il riepilogo della privacy elenca le dieci colonne con maggior rumore dall'impatto maggiore a quello minore e relativi contributi al rumore. Questa è la suddivisione delle etichette di impatto del rumore.

% dei risultati interessati	Colore dell'indicatore	Impatto
<5%	Verde	Impatto ridotto
5%-15%	Giallo	Impatto medio
15%-25%	Orange	Impatto elevato
>25%	Rosso	Impatto molto elevato

Puoi anche visualizzare l'anteprima del riepilogo della privacy per i job di report recenti nella pagina Home. Per visualizzare l'anteprima della privacy per un determinato lavoro, tieni il puntatore sopra l'icona del suggerimento sulla privacy privacy_tip nella scheda del lavoro in Attività recente.

Adattare le query

È più probabile che le aggregazioni siano influenzate dal rumore quando pochi utenti contribuiscono al risultato. Ciò può verificarsi quando le aggregazioni vengono calcolate a partire da piccoli gruppi di utenti o quando alcuni utenti non influiscono sui risultati, ad esempio con la funzione COUNTIF. In base al report sul rumore, potresti voler modificare la query per ridurre la percentuale di risultati interessati.

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.
• Prova il bloccaggio esplicito quando è possibile scegliere limiti ragionevoli.

---

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)).

Tieni presente che queste limitazioni si applicano solo alle aggregazioni con rumore, che è il primo livello di aggregazione per più utenti. I dati aggregati a livello di utente e i dati aggregati dopo l'inserimento di rumore non sono soggetti a limitazioni.

Funzioni aggregate supplementari

Oltre a supportare gli aggregatori regolari, Ads Data Hub introduce funzioni di aggregazione ADH.ANON supplementari che supportano il blocco esplicito. Questi aggregatori condividono la sintassi con le funzioni di aggregazione con privacy differenziale di BigQuery, ma non richiedono la clausola WITH DIFFERENTIAL_PRIVACY:

• ADH.ANON_SUM( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_COUNT( *, [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_COUNT( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_AVG( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_PERCENTILE_CONT( ..., percentile, contribution_bounds_per_row => (lower_bound, upper_bound) )

Parametri ADH.ANON_SUM, ADH.ANON_COUNT e ADH.ANON_AVG:

• contribution_bounds_per_group: i contributi per utente vengono limitati per ogni partizione definita dalle chiavi GROUP BY. I limiti superiore e inferiore vengono applicati ai valori per gruppo dopo che i valori sono stati aggregati per utente.
• lower_bound: valore letterale numerico che rappresenta il valore più piccolo da includere in un'aggregazione.
• upper_bound: valore letterale numerico che rappresenta il valore più grande da includere in un'aggregazione.

Parametri ADH.ANON_PERCENTILE_CONT:

• percentile: il percentile da calcolare, un valore letterale nell'intervallo [0, 1].
• contribution_bounds_per_row: i contributi per utente vengono bloccati in base a ogni riga (ogni record). Tieni presente che per il percentile sono necessari limiti di bloccaggio espliciti, pertanto è supportato solo come funzione supplementare.
• lower_bound: valore letterale numerico che rappresenta il valore più piccolo da includere in un'aggregazione.
• upper_bound: valore letterale numerico che rappresenta il valore più grande da includere in un'aggregazione.

Calcola MIN e MAX

Le funzioni MIN e MAX non sono supportate direttamente nelle aggregazioni con rumore, ma spesso esistono metodi alternativi per calcolare questi risultati.

Se hai un MIN o un MAX di valori che possono essere utilizzati come chiavi di raggruppamento, ad esempio la data dell'evento, puoi prima RAGGRUPPARE PER quel valore, quindi calcolare MIN/MAX in un secondo momento. Restituisce il valore minimo o massimo che supera la soglia di aggregazione.

Esempio:

WITH campaign_date_ranges AS (
  SELECT campaign_id, MIN(event_date) AS min_date, MAX(event_date) AS max_date
  FROM (
    # Aggregation thresholding will be applied here
    SELECT DISTINCT
      campaign_id,
      DATE(query_id.time_usec, @time_zone) AS event_date
    FROM adh.google_ads_impressions
  )
)
SELECT campaign_id, num_impressions, min_date, max_date
FROM (
  # Noise and aggregation thresholding will be applied here
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
)
JOIN campaign_date_ranges USING(campaign_id)

In alternativa, se hai un MIN o un MAX di valori granulari con limiti noti, puoi utilizzare PERCENTILE_CONT con limiti espliciti per un risultato approssimativo.

Esempio:

SELECT
  campaign_id,
  COUNT(*) AS num_impressions,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 0,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS min_timestamp,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 1,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS max_timestamp
FROM adh.google_ads_impressions

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.

Informazioni sui risultati negativi

In linea di principio, il rumore con valori molto piccoli può generare numeri negativi, anche quando ciò dovrebbe essere semanticamente impossibile per la query. Per mantenere il comportamento previsto, tutte le forme di COUNT e COUNTIF vengono automaticamente bloccate a zero, in modo da non dare mai risultati negativi. Se vuoi lo stesso comportamento con un'altra funzione, ad esempio SUM, puoi bloccare i risultati manualmente utilizzando GREATEST(0, SUM(...)).

Questa modifica è generalmente trascurabile, ma introduce un piccolo bias positivo nei risultati complessivi.

---

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_creative_conversions
  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

Nota: ciascuna aggregazione riceve rumore in modo indipendente, quindi i valori totali potrebbero non corrispondere. In questo caso, i valori sommati di imps per un particolare campaign_id potrebbero non corrispondere al valore corrispondente di campaign_imps.

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 sconsiglia 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.

Informazioni sulle finestre temporali

Alcuni pattern di query generano report su un periodo di tempo ampio, rigenerandosi periodicamente per includere nuovi risultati. Queste query potrebbero richiedere modifiche per funzionare in modalità rumore perché, se ricalcolano i risultati precedenti, verranno bloccate. Ogni job deve invece generare solo nuovi risultati, che possono poi essere combinati con quelli dei job precedenti per ottenere un report completo.

Ad esempio, se stai creando un report sulle metriche per data, aggiornato quotidianamente:

SELECT
  campaign_id,
  DATE(TIMESTAMP_MICROS(query_id.time_usec), @time_zone) AS event_date,
  COUNT(*) AS impressions
FROM adh.google_ads_impressions
GROUP BY 1,2

Non devi eseguire questa operazione con un intervallo di date ampio, in quanto ricalcolerà i risultati dei giorni precedenti. Invece, devi eseguire ogni job solo nell'ultimo giorno, che contiene nuovi dati, e poi combinarlo con i risultati dei job precedenti.

Se devi aggiornare un risultato precedente (ad esempio per tenere conto dei dati arrivati in ritardo), evita di ricalcolare un singolo risultato più di 1 o 2 volte. In caso contrario, potresti ricevere errori dovuti a tentativi di query ripetuti.

Riaggregazione diretta

Il rumore viene applicato al primo livello di aggregazione per più utenti nella query. Le query con più livelli di aggregazione combinano i risultati con rumore, quindi i dati aggregati finali possono avere molto più rumore. Queste query ricevono un avviso durante la convalida:

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.

Se l'aggregazione multilivello è inevitabile, puoi risolvere l'avviso esportando 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 avviso di convalida:

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

I join di questo tipo potrebbero non funzionare come previsto perché verranno abbinate solo le righe con lo stesso valore di user_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)

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 avvisi 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. Esiste anche un'eccezione per le tabelle RDID che vengono unite direttamente su device_id_md5. Ad esempio, la seguente query funzionerà senza avvisi:

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions_rdid USING(device_id_md5)

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.