Best practice

Le best practice riportate di seguito ti illustreranno tecniche per sviluppare query ad alte prestazioni e incentrate sul rispetto della privacy.

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, a causa della mancanza di 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)