GA4 e BigQuery non coincidono: trova la differenza giusta

Stesso nome non significa stesso numero

Il report GA4 mostra un ricavo, la query BigQuery un altro. La tentazione è correggere il codice finché i numeri coincidono. Prima serve capire cosa stai confrontando. Parti da una scheda della metrica: evento, campo economico, identità, data, valuta, filtri, livello di aggregazione e momento dell'estrazione.

Johan van de Werken, su GA4BigQuery, separa tre cause spesso confuse: definizioni, scope e logica della query. Ricorda che BigQuery accetta anche una query che restituisce un risultato concettualmente sbagliato. Tradotto nel lavoro sull'account: il fatto che il codice termini senza errori non dimostra che il ricavo sia attribuito al livello giusto.

Se la domanda riguarda gli acquisti, inizia dagli acquisti. Rimanda la ripartizione per canale: aggiungere subito l'attribuzione significa confrontare contemporaneamente raccolta, trasformazione e assegnazione del merito.

Allinea le date e scegli la valuta

Nello schema GA4, event_timestamp è espresso in microsecondi UTC, mentre event_date segue il fuso configurato. La conversione del timestamp senza un fuso esplicito può spostare gli eventi vicino alla mezzanotte. Per il controllo giornaliero scegli una regola unica e riportala nel risultato, soprattutto quando account pubblicitario, proprietà Analytics e gestionale usano impostazioni diverse.

I campi economici distinguono valori in valuta locale e valori in dollari. Sommare importi locali di valute diverse produce un totale senza significato. Nel primo controllo separa currency; per una vista consolidata applica poi un criterio di cambio documentato. Verifica anche se il confronto comprende spedizioni, imposte e rimborsi: chiamare tutto ‘ricavi’ nasconde decisioni contabili diverse.

Le tabelle giornaliere possono essere aggiornate per eventi tardivi entro tre giorni dalla data dell'evento. Per il collaudo iniziale scegliamo un intervallo più vecchio e salviamo l'ora di estrazione. Questo riduce una causa di instabilità senza promettere che ogni altra differenza scompaia.

L'errore che moltiplica il fatturato

Katie Kaczmarek, su Measurelab, mostra due modi diversi di estrarre un array: aprirlo in righe oppure recuperare un parametro con una sottoquery correlata. Avverte anche che un cross join può eliminare gli eventi con array vuoti. La scelta cambia quindi sia il numero di righe sia quali eventi sopravvivono alla trasformazione.

Esempio didattico: un acquisto da 120 euro contiene tre prodotti. Dopo UNNEST(items) ottieni tre righe. Se sommi purchase_revenue trovi 360 euro. Se apri anche un secondo array indipendente di quattro elementi nella stessa clausola FROM, potresti arrivare a dodici combinazioni. Il totale sbagliato può sembrare credibile su migliaia di transazioni.

Mantieni una tabella eventi per le misure a livello ordine e una tabella articoli per le misure a livello prodotto. Per estrarre la valuta, seleziona la chiave currency, non l'elemento in posizione zero: la prima posizione dell'array non garantisce il significato del parametro. Se la stessa chiave compare più volte, fai emergere l'anomalia invece di scegliere un valore arbitrario.

Parti da una query che puoi spiegare riga per riga

La query seguente è un controllo del dato raccolto. Non replica l'interfaccia GA4 e non applica una deduplicazione degli ordini. Usa soltanto tabelle giornaliere, conserva la valuta e lascia intatto il livello evento. Sostituisci progetto, dataset e intervallo; la sottoquery sulla valuta presuppone una sola occorrenza della chiave per evento.

Confronta purchaseEvents e transactionIds. Una differenza può indicare transaction_id mancanti o ripetuti: va indagata sui record, non eliminata scegliendo automaticamente il primo acquisto. Lo stesso identificatore potrebbe anche essere riutilizzato erroneamente tra negozi. Costruisci una regola di deduplicazione solo dopo aver verificato come il CMS genera e invia gli eventi.

Aggiungi tre casi al collaudo: un acquisto con un solo prodotto, uno con più prodotti e uno privo di valuta. Per ciascuno conserva conteggio delle righe e valore prima e dopo le trasformazioni. Sono controlli piccoli, ma intercettano errori che il totale mensile può nascondere.

WITH purchaseEvents AS (
  SELECT
    event_date AS reportDate,
    ecommerce.transaction_id AS transactionId,
    ecommerce.purchase_revenue AS purchaseRevenue,
    (SELECT p.value.string_value
     FROM UNNEST(event_params) AS p
     WHERE p.key = 'currency') AS currencyCode
  FROM `your-project.analytics_123.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'
    AND event_name = 'purchase'
)
SELECT
  reportDate,
  currencyCode,
  COUNT(*) AS purchaseEvents,
  COUNT(DISTINCT NULLIF(transactionId, '')) AS transactionIds,
  SUM(purchaseRevenue) AS collectedRevenue
FROM purchaseEvents
GROUP BY reportDate, currencyCode

L'attribuzione viene dopo la raccolta

Quando i totali del dato raccolto sono stabili, aggiungi una dimensione alla volta. GA4BigQuery insiste sulla distinzione fra scope utente, sessione, evento e articolo. Se assegni tutti gli acquisti alla sorgente iniziale dell'utente, non stai riproducendo un report di acquisizione delle sessioni: stai rispondendo a una domanda diversa.

Dichiara il perimetro del tuo modello: per esempio, ‘ricavi purchase associati alla sessione osservata’. Non presentarlo come replica dell'attribuzione basata sui dati della piattaforma. A ogni passaggio controlla che il ricavo totale resti coerente e misura la quota senza una sorgente utilizzabile. Quel residuo è un'informazione del sistema di misurazione, non uno spazio da riempire a intuito.

Consegna una spiegazione utilizzabile

Nel suo metodo di debug, Kaczmarek propone di seguire un singolo identificatore attraverso le CTE, restringendo prima date e volume elaborato. Applichiamolo a un ordine problematico: controlla che esista nell'estrazione iniziale, poi dopo i filtri, dopo l'apertura degli articoli e dopo il join con le campagne. Il primo passaggio in cui scompare o si duplica indica dove intervenire.

Per ogni differenza conserva valore assoluto, percentuale, periodo, definizione e causa verificata. Distingui una causa confermata da una ancora da verificare. ‘Probabile attribuzione’ non chiude un controllo sui ricavi duplicati; servono campioni di transazioni e conteggi intermedi.

Una revisione utile termina con una scelta: quale fonte useremo per leggere l'andamento commerciale, quale per ottimizzare le campagne e quale per verificare il tracciamento. Possono essere fonti diverse, purché il marketing manager capisca perché. Il risultato è una dashboard con numeri interpretabili e una traccia per correggere ciò che non torna.