Best practice

Le best practice riportate di seguito ti illustreranno tecniche per sviluppare query ad alte prestazioni e incentrate sul rispetto della privacy. Per le best practice specifiche per eseguire query in modalità rumore, consulta le sezioni sui pattern di query supportati e non supportati in Inserimento del rumore.

Privacy e accuratezza dei dati

Sviluppare query sui dati sandbox

Best practice: esegui le query sui dati di produzione solo in ambienti di produzione.

Utilizza il più possibile i dati sandbox durante lo sviluppo delle query. I job che utilizzano i dati sandbox non introducono ulteriori opportunità di eseguire controlli delle differenze per filtrare i risultati delle query. Inoltre, per via della mancanza dei controlli per la privacy, le query sandbox vengono eseguite più velocemente, consentendo un'iterazione più rapida durante il loro sviluppo.

Se devi sviluppare query sui tuoi dati effettivi (ad esempio quando utilizzi le tabelle delle corrispondenze), per ridurre le probabilità di sovrapposizione di righe, scegli intervalli di date e altri parametri che difficilmente si sovrappongono per ogni iterazione della query. Infine, esegui la query sull'intervallo di dati che ti interessa.

Valutare attentamente i risultati storici

Best practice: riduci la probabilità di sovrapposizione del set di risultati tra le query eseguite di recente.

Tieni presente che la frequenza di modifica dei risultati di una query influisce sulla probabilità che i risultati vengano omessi in un secondo momento a causa dei controlli per la privacy. È probabile che venga eliminato un secondo set di risultati molto simile a uno restituito di recente.

Piuttosto, modifica i parametri chiave della query, ad esempio intervalli di date o ID campagna, per ridurre le probabilità di una sovrapposizione significativa.

Non eseguire query sui dati del giorno corrente

Best practice: non eseguire più query la cui data di fine è il giorno corrente.

L'esecuzione di più query con date di fine corrispondenti al giorno corrente spesso causa il filtraggio delle righe. Queste indicazioni valgono anche per le query eseguite poco dopo la mezzanotte sui dati del giorno precedente.

Non eseguire query sugli stessi dati più del necessario

Best practice:

  • seleziona date di inizio e fine strettamente legate.
  • Anziché eseguire query su finestre sovrapposte, eseguile su set di dati distinti, quindi aggrega i risultati in BigQuery.
  • Utilizza i risultati salvati anziché eseguire di nuovo la query.
  • Crea tabelle temporanee per ogni intervallo di date per il quale stai eseguendo la query.

Ads Data Hub limita il numero totale di volte in cui puoi eseguire query sugli stessi dati. Di conseguenza, devi cercare di limitare il numero di accessi a un determinato dato.

Non utilizzare più aggregazioni del necessario nella stessa query

Best practice:

  • Riduci al minimo il numero di aggregazioni in una query
  • Se possibile, riscrivi le query per combinare le aggregazioni

Ads Data Hub limita a 100 le aggregazioni tra utenti che è possibile utilizzare in una sottoquery. In generale, consigliamo di scrivere query che generino più righe con chiavi di raggruppamento specifiche e semplici aggregazioni, anziché più colonne con chiavi di raggruppamento generiche e aggregazioni complesse. Evita quanto segue:

SELECT
  COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
  COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
  table

Le query che conteggiano gli eventi in base allo stesso insieme di campi devono essere riscritte utilizzando l'istruzione GROUP BY.

SELECT
  field_1,
  field_2,
  COUNT(1) AS cnt
FROM
  table
GROUP BY
  1, 2

Il risultato può essere aggregato nello stesso modo in BigQuery.

Le query che creano colonne da un array e le aggregano dopo devono essere riscritte per unire questi passaggi. 

SELECT
  COUNTIF(a_1) AS cnt_1,
  COUNTIF(a_2) AS cnt_2
FROM
  (SELECT
     1 IN UNNEST(field) AS a_1,
     2 IN UNNEST(field) AS a_2,
   FROM
     table)

La query precedente può essere riscritta come:

SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1

Le query che utilizzano combinazioni diverse di campi in aggregazioni diverse possono essere riscritte in più query mirate.

SELECT
  COUNTIF(field_1 = a_1) AS cnt_a_1,
  COUNTIF(field_1 = b_1) AS cnt_b_1,
  COUNTIF(field_2 = a_2) AS cnt_a_2,
  COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table

La query precedente può essere suddivisa:

SELECT
  field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1

e

SELECT
  field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1

Puoi suddividere questi risultati in query separate, creare e unire le tabelle in una singola query o combinarle con un'istruzione UNION se gli schemi sono compatibili.

Ottimizzare e comprendere i join

Best practice: utilizza un LEFT JOIN anziché un INNER JOIN per unire i clic o le conversioni alle impressioni.

Non tutte le impressioni sono associate a clic o conversioni. Di conseguenza, se utilizzi un INNER JOIN per unire i clic o le conversioni alle impressioni, le impressioni che non sono legate a clic o conversioni verranno filtrate dai risultati.

Immagine che mostra più tipi di join tramite diagrammi di Venn

Unire alcuni risultati finali in BigQuery

Best practice: evita le query di Ads Data Hub che uniscono i risultati aggregati. Scrivi invece due query distinte e unisci i risultati in BigQuery.

Le righe che non soddisfano i requisiti di aggregazione vengono filtrate dai risultati. Di conseguenza, se la tua query unisce una riga non sufficientemente aggregata a un'altra che lo è a sufficienza, la riga risultante verrà filtrata. Inoltre, le query con più aggregazioni hanno prestazioni inferiori in Ads Data Hub.

Puoi unire i risultati (in BigQuery) di più query di aggregazione (da Ads Data Hub). I risultati calcolati utilizzando le query comuni condivideranno gli schemi finali.

La query seguente prende i singoli risultati di Ads Data Hub (campaign_data_123 e campaign_data_456) e li unisce in BigQuery:

SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)

Utilizzare riepiloghi delle righe filtrate

Best practice: aggiungi riepiloghi delle righe filtrate alle query.

I riepiloghi delle righe filtrate contengono i dati filtrati a causa dei controlli per la privacy. I dati delle righe filtrate vengono sommati e aggiunti a una riga catch-all. Sebbene non possano essere ulteriormente analizzati, i dati filtrati forniscono un riepilogo del volume dei dati esclusi dai risultati.

Considerare gli ID utente uguali a zero

Best practice: prendi in considerazione gli ID utente uguali a zero nei risultati.

L'ID di un utente finale può essere impostato su 0 per una serie di motivi, ad esempio la disattivazione della personalizzazione degli annunci, ragioni di natura normativa e così via. Pertanto, i dati provenienti da più utenti verranno associati a uno user_id uguale a 0.

Per comprendere i totali dei dati, come le impressioni o i clic totali, devi includere questi eventi. Tuttavia, questi dati non sono utili per ricavare informazioni sui clienti e devono essere filtrati se esegui questo tipo di analisi.

Puoi escludere questi dati dai risultati aggiungendo WHERE user_id != "0" alle query.

Prestazioni

Evitare la riaggregazione

Best practice: evita più livelli di aggregazione tra gli utenti.

L'elaborazione di query che combinano risultati già aggregati, come una query con più GROUP BY o un'aggregazione nidificata, richiede più risorse.

Spesso le query con più livelli di aggregazione possono essere suddivise, migliorando le prestazioni. Durante l'elaborazione, devi cercare di mantenere le righe a livello di evento o utente per poi combinarle con una singola aggregazione.

I seguenti formati devono essere evitati:

SELECT SUM(count)
FROM
  (SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)

Le query che utilizzano più livelli di aggregazione devono essere riscritte in modo da utilizzare un singolo livello di aggregazione.

(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )

Le query facilmente suddivisibili devono essere suddivise. Puoi unire i risultati in BigQuery.

Ottimizzare per BigQuery

In genere le query meno complesse hanno prestazioni migliori. Quando valuti le prestazioni delle query, la quantità di lavoro richiesta dipende dai seguenti fattori:

Se l'esecuzione delle query non rispetta i tuoi accordi sul livello del servizio o se riscontri errori dovuti a timeout o esaurimento di risorse, considera i seguenti suggerimenti:

  • Utilizza i risultati delle query precedenti anziché ripetere i calcoli. Ad esempio, il totale settimanale potrebbe essere la somma calcolata in BigQuery di sette query aggregate di un solo giorno.
  • Scomponi le query in sottoquery logiche (ad esempio suddividendo più join in più query) o limita il set di dati elaborati. Puoi combinare i risultati dei singoli job in un unico set di dati in BigQuery. Anche se ciò può essere utile in caso di esaurimento delle risorse, la query ne potrebbe risultare rallentata.
  • Se stai riscontrando errori di superamento di risorse in BigQuery, prova a utilizzare le tabelle temporanee per suddividere la query in più query BigQuery.
  • Fai riferimento a un numero inferiore di tabelle in una singola query, poiché questa operazione utilizza grandi quantità di memoria e può causare la mancata riuscita della query.
  • Riscrivi le query in modo che uniscano meno tabelle utente.
  • Riscrivi le query per evitare che una tabella venga unita a se stessa.

Consulente per query

Se l'SQL è valido, ma potrebbe attivare un filtraggio eccessivo, il consulente per query mostra delle azioni consigliate durante la procedura di sviluppo della query per aiutarti a evitare risultati indesiderati.

Gli attivatori includono i seguenti pattern:

Per utilizzare il consulente per query: