Colma il divario tra l'interfaccia utente di Google Analytics e BigQuery Export

Minhaz Kazi, Developer Advocate, Google Analytics – Aprile 2023


"Ma perché i numeri non corrispondono all'UI?"

Se hai utilizzato i dati dell'esportazione degli eventi BigQuery per la tua proprietà GA4, sicuramente hai fatto questa domanda a un certo punto. O, peggio ancora, qualcun altro te lo ha chiesto. Nel tentativo di rispondere, probabilmente ti è stato chiesto temuta domanda:

"E dove si dice?"

Con questo post cercheremo di far luce su entrambi.

Prima di entrare nel dettaglio di come variano i numeri, è importante capire lo scopo previsto dei dati di esportazione degli eventi BigQuery. Utenti di Google Analytics inviare i dati raccolti a Google Analytics tramite uno dei metodi di raccolta disponibili: Google Tag, Google Tag Manager, Measurement Protocol, SDK e Importazione dati. In base alle impostazioni della proprietà GA, Google Analytics genera un valore significativo oltre ai dati raccolti prima che raggiungano le piattaforme di generazione di report standard inclusi i report standard, le Esplorazioni e l'API di dati. Questi valori le aggiunte possono includere l'inclusione di Google Signals, la definizione del modello, il traffico attribuzione, previsione e così via

Le piattaforme di generazione di report standard mirano a fornire il valore massimo agli utenti GA a il minimo sforzo. Tuttavia, siamo consapevoli che nell'ampio spettro di utenti, alcuni potrebbero voler integrare il valore aggiunto di Google Analytics o persino qualcosa di completamente personalizzato. Per questi utenti, l'esportazione di eventi BigQuery il punto di partenza previsto. L'esportazione di eventi BigQuery avrà dati raccolti, che viene inviato dal client o dall'app a Google Analytics. Esportazione eventi BigQuery non conterrà dati granulari sulla maggior parte dei valori aggiunti sopra.

Di conseguenza, per un gran numero di casi d'uso, i report standard emettono Per quanto riguarda questi dati, non è previsto che i dati di BigQuery Export siano riconciliabili a valore aggiunto. Se c'è coerenza interna in entrambi e corrispondono con i contenuti che stai raccogliendo, dovresti essere pronto.

Ora analizziamo alcuni dei motivi specifici delle differenze ed esploriamo modi per ridurle, quando possibile. Questo post è incentrato sugli Solo l'esportazione degli eventi giornalieri e non l'esportazione streaming.

Campionamento

Per un confronto accurato dei dati di BigQuery Export con i report standard, I report dell'API o i report di esplorazione confermano che non sono basati su dati campionati. Il campionamento dei dati in GA4 fornisce ulteriori dettagli e modalità per gestire il campionamento.

Utenti attivi

Se conteggi tutti gli utenti che hanno registrato almeno un evento in GA4 otterrai la metrica Utenti totali. Anche se il valore di Utenti totali è disponibile in Esplorazioni della UI di GA4, la metrica utente principale utilizzata per il report di GA4 è Utenti attivi. Nell'interfaccia utente di GA4 e nei report, se solo Utenti , che in genere si riferisce agli Utenti attivi. Quindi, quando calcoli il numero dai dati BigQuery, dovrai filtrare e mantenere solo gli utenti attivi per rendere i numeri paragonabili a quelli di GA. Il metodo di calcolo variano in base all'identità report selezionata.

Implementazione tecnica

Nei dati di esportazione degli eventi BigQuery, se calcoli il numero di ID utente distinti, ottiene il valore Utenti totali. Ecco un esempio di query che mostra i valori Totali Utenti e Nuovi utenti in base a user_pseudo_id:

-- Example: Get 'Total User' count and 'New User' count.

WITH
  UserInfo AS (
    SELECT
      user_pseudo_id,
      MAX(IF(event_name IN ('first_visit', 'first_open'), 1, 0)) AS is_new_user
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
    GROUP BY 1
  )
SELECT
  COUNT(*) AS user_count,
  SUM(is_new_user) AS new_user_count
FROM UserInfo;

Per selezionare solo utenti attivi, limita la query agli eventi in cui is_active_user è true:

-- Example: Get exact and approximate Active User count.

WITH
  ActiveUsers AS (
    SELECT
      user_pseudo_id
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
      AND is_active_user
    GROUP BY 1
  )
SELECT
  COUNT(DISTINCT user_pseudo_id) AS exact_active_user_count,
  APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_active_user_count
FROM ActiveUsers;

HyperLogLog++

Google Analytics utilizza l'algoritmo HyperLogLog++ (HLL++) per stimare la cardinalità per metriche comuni come Utenti attivi e Sessioni. Ciò significa che quando visualizzi il conteggio unico di queste metriche nell'interfaccia utente o tramite l'API, con una certa precisione. In BigQuery, poiché hai accesso i dati granulari, puoi calcolare la cardinalità esatta per queste metriche. Quindi... le metriche possono variare di una piccola percentuale. Con un intervallo di confidenza del 95%, la precisione potrebbe essere ±1,63% per il conteggio delle sessioni. I livelli di precisione variano diverse metriche e cambieranno in base agli intervalli di confidenza. Consulta schizzi HLL++ per i livelli di precisione a diversi intervalli di confidenza per diversi parametri di precisione di HLL++.

Implementazione tecnica

Consulta Approssimazione del conteggio univoco in Google Analytics per comprendere in che modo HLL++ implementato in Google Analytics e come replicare la funzionalità utilizzando le query di BigQuery.

Ritardo nella raccolta dei dati

Le tabelle di esportazione giornaliere vengono create dopo che GA ha raccolto tutti gli eventi del giorno. Le tabelle giornaliere possono essere aggiornate fino a 72 ore dopo la data della tabella con eventi con timestamp con la data della tabella. Leggi i dettagli informazioni sull'argomento e vedere alcuni esempi. Questo è più un problema se l'implementazione dell'SDK Firebase o di Measurement Protocol viene inviata offline o in ritardo. A seconda di quando la piattaforma di generazione dei report standard e BigQuery vengono aggiornati entro queste 72 ore, potresti notare differenze tra di loro. Per tale implementazione, è necessario confrontare i dati precedenti per più di 72 ore.

Report ad alta cardinalità

Supponi di visualizzare un report tramite report standard o l'API di dati. Il report mostra una grande quantità di dati e ha dimensioni con cardinalità. Le dimensioni ad alta cardinalità potrebbero causare il superamento della soglia limite di cardinalità per la tabella sottostante. In questi casi, Google Analytics raggrupperà i valori meno frequenti e li etichetterà come (other).

Utilizzando un esempio semplificato e su piccola scala, se il limite di cardinalità per tabella sottostante è composta da 10 righe, ecco cosa può succedere:

Esempio semplificato di dati di fatto rispetto a una tabella aggregata con altri riga

Come puoi vedere, il numero totale di eventi rimane invariato. Tuttavia, meno spesso i valori frequenti vengono raggruppati e non puoi riaggregare la tabella in base su qualsiasi dimensione (ad es. non puoi prendere la tabella aggregata per ricavare il totale conteggio eventi di una città specifica con una precisione elevata). L'esempio mostra più profondo se filtri i dati aggregati in base a una qualsiasi delle dimensioni.

Questo raggruppamento della riga (other) avviene solo nel modulo dei report e nella API di dati quando il report supera il limite di cardinalità. Se esegui le tue da BigQuery, rifinirai sempre con dati empirici reali, le righe più granulari. Scopri di più sulla riga (other) e sulle best practice relative a come evitarlo.

Google Signals

L'attivazione di Google Signals nella proprietà GA4 offre diversi vantaggi, tra cui deduplicando gli utenti su piattaforme e dispositivi diversi. Se non raccogli i dati sull'utente ID o attiva Google Signals e una persona visualizza il tuo sito web su tre browser web diversi, Google Analytics attribuisce tale attività a tre utenti diversi e BigQuery Export avrà tre user_pseudo_id separati. Al contrario, quando Google Signals è attivato e la persona ha eseguito l'accesso al suo un unico Account Google in tutti e tre i browser, gli attributi di Google Analytics attività per un utente e viene indicata nel conteggio nelle piattaforme di generazione di report standard. Tuttavia, BigQuery mostrerà comunque tre user_pseudo_id separati perché Le informazioni di Google Signals non sono disponibili nell'esportazione BigQuery. Pertanto, i report con dati di Google Signals avranno molto probabilmente un numero inferiore di utenti rispetto a in BigQuery Export.

Il modo migliore per ridurre questo effetto è implementare gli User-ID in GA4 insieme all'attivazione di Google Signals. Questo assicura che la deduplicazione avviene per prima in base a user_id. Per gli utenti che hanno eseguito l'accesso, user_id verrà compilato in BigQuery e potrà essere utilizzato a scopo di calcolo. Tuttavia, per gli utenti che non hanno eseguito l'accesso (ovvero sessioni senza user_id), Google Signals continuerà a essere utilizzato per la deduplicazione.

Tieni inoltre presente che alcuni report nelle piattaforme standard potrebbero avere soglia applicata e non restituisce determinati dati. La maggior parte delle informazioni che possono essere soggetti a soglie non sono generalmente disponibili in BigQuery Export.

La modalità di consenso su siti web e app mobile ti consente di informare gli utenti stato del consenso all'uso dei cookie o degli identificatori di app per Google. Quando i visitatori negano il consenso, GA4 colma le lacune nella raccolta dei dati con la creazione di modelli di eventi chiave e il comportamento del linguaggio naturale. Nessuno dei dati modellati è disponibile nell'esportazione di eventi BigQuery. Quando viene implementata la modalità di consenso, il set di dati BigQuery conterrà ping senza cookie raccolti da GA e ogni sessione avrà un valore user_pseudo_id diverso. A causa di ci saranno differenze tra le piattaforme di generazione di report standard e i dati granulari in BigQuery. Ad esempio, a causa della creazione di modelli di comportamento, potrebbe notare un numero inferiore di utenti attivi rispetto a BigQuery Export la modellazione potrebbe tentare di prevedere le diverse sessioni di singoli utenti senza consenso utenti.

Anche in questo caso, per ridurre l'effetto di questa operazione, devi implementare gli User-ID in GA4 proprietà. user_id e le dimensioni personalizzate vengono esportate in BigQuery indipendentemente da lo stato del consenso degli utenti.

Dati di attribuzione del traffico

In BigQuery i dati di attribuzione del traffico sono disponibili a livello di utente (prima visita) e a livello di evento. Questi sono i dati raccolti. Tuttavia, poiché Google Analytics implementa il proprio modello di attribuzione a livello di sessione, tali informazioni vengono né disponibile direttamente in BigQuery Export, né calcolabile con la precisione con i dati disponibili. In base al tuo caso d'uso, puoi prendere in considerazione unendo il set di dati BigQuery con tutti i dati proprietari pertinenti il tuo modello di attribuzione. In futuro, sono stati raccolti dati aggiuntivi relativi al traffico potrebbe essere disponibile tramite l'esportazione di eventi BigQuery.

Errori di calcolo comuni

  • Metodo di calcolo:quando calcoli metriche diverse in BigQuery, di utilizzare la metodologia corretta. Ad esempio:
    • Il metodo standard di conteggio delle sessioni per Google Analytics 4 proprietà è il conteggio delle combinazioni univoche user_pseudo_id/user_id e ga_session_id a prescindere dal un periodo di tempo. In Universal Analytics, le sessioni vengono reimpostate a mezzanotte. Se segui il modello UA, calcoli le sessioni per ogni giorno e le aggiungi per ottenere il conteggio totale delle sessioni, conteresti due volte su più giorni.
    • In base all'identità report selezionata, gli utenti vengono conteggiati metodo di calcolo dovrà essere aggiornato.
  • Ambito di dimensioni e metriche: assicurati che i calcoli utilizzino la proprietà l'ambito corretto a livello di utente, sessione, articolo o evento.
  • Fuso orario: in BigQuery Export, event_date è per il momento del report mentre event_timestamp è un timestamp UTC in microsecondi. Quindi... idealmente, se si utilizza event_timestamp in una query, deve essere modificato il fuso orario dei report corretto quando esegui il confronto con i numeri dell'interfaccia utente.
  • Filtro dei dati e limiti di esportazione: se hai configurato il filtro dei dati per l'esportazione di eventi BigQuery o il volume giornaliero di esportazione degli eventi sia stato superato una volta superato il limite, i dati di esportazione degli eventi BigQuery non corrisponderanno ai piattaforme di generazione dei report.

Con tutto questo, c'è un po' di UNNEST in questo post. Speriamo che tu possa SELEZIONARE le soluzioni giuste per il tuo progetto DISTINCT DALLE linee guida riportate qui. Se se hai domande, UNISCITI al server Discord di GA DOVE sono le query più adatte.

Indietro
Soluzioni aziendali
Avanti
Approssimazione del conteggio univoco con HLL++