Colmare il divario tra l'UI di Google Analytics e BigQuery Export

Minhaz Kazi, Developer Advocate, Google Analytics – Aprile 2023

"Ma perché i numeri non corrispondono a quelli dell'UI?"

Se hai lavorato con i dati di esportazione degli eventi BigQuery per la tua proprietà GA4, a un certo punto hai posto questa domanda. O peggio ancora: te l'ha chiesto qualcun altro. E mentre cercavi di rispondere, probabilmente ti è stata posta la terribile domanda di follow-up:

"E dove si dice che?"

Con questo articolo cercheremo di far luce su entrambi.

Prima di addentrarci nei dettagli di come variano le cifre, è importante capire lo scopo previsto dei dati di esportazione degli eventi BigQuery. Gli utenti di Google Analytics inviano i dati raccolti a GA tramite uno dei metodi di raccolta: Tag Google, Google Tag Manager, Measurement Protocol, SDK e Importazione dati. In base alle impostazioni della proprietà GA, Google Analytics aggiunge un valore significativo ai dati raccolti prima di raggiungere le piattaforme di generazione di report standard tra cui i report standard, le Esplorazioni e l'API di dati. Queste aggiunte di valore possono includere l'inclusione di Google Signals, la creazione di modelli, l'attribuzione del traffico, la previsione e così via.

Le piattaforme di generazione di report standard mirano a fornire il valore massimo agli utenti GA con il minore attrito. Tuttavia, siamo consapevoli che, per un ampio spettro di utenti, qualcuno potrebbe voler integrare il valore aggiunto di Google Analytics o persino creare qualcosa di completamente personalizzato. Per questi utenti, l'esportazione di eventi BigQuery è il punto di partenza previsto. L'esportazione di eventi BigQuery includerà dati raccolti, che vengono inviati dal client o dall'app a Google Analytics. L'esportazione di eventi BigQuery non conterrà dati granulari sulla maggior parte dei valori aggiunti sopra menzionata.

Pertanto, per un numero elevato di casi d'uso, i report standard vengono visualizzati e i dati di esportazione di BigQuery non sono riconciliabili quando si tratta di queste parti valore aggiunto. Se c'è coerenza interna in entrambi i prodotti e se corrispondono a ciò che stai raccogliendo, non devi fare altro.

Esaminiamo ora alcuni dei motivi specifici delle differenze e vediamo come mitigarli, se possibile. Questo articolo riguarda solo l'esportazione di eventi giornalieri di BigQuery e non l'esportazione streaming.

Campionamento

Per un confronto accurato dei dati di BigQuery Export con i report standard, API di dati o Esplorazioni, verifica che non siano basati su dati campionati. Il campionamento dei dati in GA4 fornisce ulteriori dettagli e modi per gestire il campionamento.

Utenti attivi

Se conti tutti gli utenti che hanno registrato almeno un evento nella proprietà GA4, visualizzerai la metrica Utenti totali. Sebbene la metrica Utenti totali sia disponibile nell'interfaccia utente di Esplorazioni nell'interfaccia utente di GA4, la metrica utente principale utilizzata per i report in GA4 è Utenti attivi. Nell'interfaccia utente di GA4 e nei report, se viene menzionato solo Utenti, ciò in genere si riferisce agli Utenti attivi. Quindi, quando calcoli il numero di utenti dai dati di BigQuery, dovrai filtrare e mantenere solo gli utenti attivi per rendere i numeri paragonabili a quelli dell'interfaccia utente GA. Il metodo di calcolo varierà anche in base all'identità report selezionata.

Implementazione tecnica

Nei dati di esportazione di eventi BigQuery, se conti il numero di ID utente distinti, ottieni il conteggio Utenti totali. Ecco una query di esempio che mostra sia utenti totali sia 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 gli 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 le metriche comuni, tra cui Utenti attivi e Sessioni. Ciò significa che quando visualizzi il conteggio unico di queste metriche nell'interfaccia utente o tramite l'API, si tratta di un'approssimazione con una certa precisione. Poiché hai accesso ai dati granulari, in BigQuery puoi calcolare la cardinalità esatta di queste metriche. Pertanto, le metriche possono variare con una piccola percentuale. Con un intervallo di confidenza del 95%, la precisione potrebbe essere ±1,63% per il numero di sessioni. I livelli di precisione variano in base alle diverse metriche e cambiano in base agli intervalli di confidenza. Consulta Sket HLL++ per i livelli di precisione a intervalli di confidenza diversi per i diversi parametri di precisione di HLL++.

Implementazione tecnica

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

Ritardo nella raccolta dei dati

Le tabelle di esportazione giornaliera vengono create dopo che GA ha raccolto tutti gli eventi della giornata. Le tabelle giornaliere possono essere aggiornate fino a 72 ore dopo la data della tabella con gli eventi che presentano il timestamp con la data della tabella. Leggi i dettagli a proposito ed esempi. Questo è più un problema se l'implementazione dell'SDK Firebase o di Measurement Protocol invia eventi offline o in ritardo. A seconda di quando la piattaforma di report standard e BigQuery vengono aggiornati entro queste 72 ore, potresti notare differenze tra loro. Per questo tipo di implementazione, è consigliabile effettuare confronti con dati risalenti a più di 72 ore fa.

Report ad alta cardinalità

Supponiamo che tu stia visualizzando un report tramite i report standard o l'API di dati. Il report mostra una grande quantità di dati e presenta dimensioni con un'alta cardinalità. Le dimensioni ad alta cardinalità potrebbero causare il superamento del limite di cardinalità per la tabella sottostante nel report. In questo caso, Google Analytics raggruppa i valori meno frequenti e li etichetta come (other).

Utilizzando un esempio semplificato e su scala ridotta, se il limite di cardinalità per la tabella sottostante è 10 righe, questo è ciò che può accadere:

Come puoi vedere, il numero totale di eventi rimane invariato. Tuttavia, i valori meno frequenti vengono raggruppati e non è possibile riaggregare la tabella in base a qualsiasi dimensione (ad es. non è possibile utilizzare la tabella aggregata per calcolare con precisione il conteggio totale degli eventi per una città specifica. L'esempio diventa più approfondito se filtri i dati aggregati in base a una qualsiasi dimensione.

Questo raggruppamento della riga (other) si verifica solo nel modulo dei report e nell'API di dati quando il report supera il limite di cardinalità. Se esegui i calcoli da BigQuery, otterrai sempre dati empirici reali, ovvero le righe più granulari. Scopri di più sulla riga (other) e sulle best practice su come evitarla.

Google Signals

L'attivazione di Google Signals nella proprietà GA4 offre diversi vantaggi, tra cui la deduplicazione degli utenti su più piattaforme e dispositivi. Supponendo che lo User-ID e gli indicatori Google non siano implementati, se una persona visualizza il tuo sito web su tre browser web diversi, Google Analytics lo conteggerà come tre utenti diversi e l'esportazione BigQuery avrà tre user_pseudo_id distinti. Tuttavia, se gli indicatori di Google sono attivati e la persona ha eseguito l'accesso al proprio Account Google in tutti e tre i browser, Google Analytics duplica un utente e mostra questo conteggio nelle piattaforme di generazione di report standard. Tuttavia, BigQuery continuerà a mostrare tre user_pseudo_id separati. Non sono disponibili informazioni di Google Signals nell'esportazione in BigQuery. Pertanto, i report con dati di Google Signals avranno probabilmente un numero di utenti inferiore rispetto a BigQuery Export.

Il modo migliore per ridurre questo effetto è implementare gli User-ID nella proprietà GA4 e attivare Google Signals. Ciò garantirà che la deduplicazione venga eseguita prima in base a user_id. Per gli utenti che hanno eseguito l'accesso, il campo user_id verrà completato in BigQuery e potrà essere utilizzato per il calcolo. Tuttavia, per gli utenti che non hanno eseguito l'accesso (ad es. sessioni senza user_id), Google Signals verrà comunque utilizzato per la deduplicazione.

Inoltre, tieni presente che ad alcuni report nelle piattaforme di generazione di report standard potrebbe essere stata applicata una soglia e potrebbero non restituire determinati dati. La maggior parte delle informazioni che possono essere soggette a soglie di solito non sono disponibili nell'esportazione BigQuery.

Modalità di consenso e dati modellati

La modalità di consenso su siti web e app mobile ti consente di comunicare a Google lo stato del consenso all'uso dei cookie o degli identificatori di app concesso o meno dagli utenti. Quando i visitatori negano il consenso, GA4 colma le lacune della raccolta dei dati con la definizione del modello di conversione e la modellazione del comportamento. Nessuno dei dati modellati è disponibile nell'esportazione degli 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 della modellazione, 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, potresti notare un numero inferiore di utenti attivi rispetto all'esportazione di BigQuery, in quanto la definizione di modelli potrebbe cercare di prevedere le sessioni multiple di singoli utenti senza consenso.

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

Dati sull'attribuzione del traffico

In BigQuery, i dati di attribuzione del traffico sono disponibili a livello di utente (prima visita) e di evento. Questi sono i dati raccolti. Tuttavia, poiché Google Analytics implementa il proprio modello di attribuzione a livello di sessione, queste informazioni non sono direttamente disponibili in BigQuery Export né possono essere calcolate con la massima precisione con i dati disponibili. A seconda del tuo caso d'uso, puoi valutare di unire il set di dati BigQuery con i dati proprietari pertinenti e creare un tuo modello di attribuzione. In futuro, ulteriori dati raccolti per l'attribuzione del traffico potrebbero essere disponibili tramite l'esportazione di eventi BigQuery.

Errori di calcolo comuni

• Metodo di calcolo: quando calcoli diverse metriche in BigQuery, assicurati di utilizzare la metodologia corretta. Ad esempio:
  • Il metodo standard di conteggio delle sessioni per le proprietà Google Analytics 4 conteggia le combinazioni uniche di user_pseudo_id/user_id e ga_session_id indipendentemente dal periodo di tempo. In Universal Analytics, le sessioni venivano reimpostate a mezzanotte. Se segui il modello UA, calcoli le sessioni per ogni giorno e le aggiungi per ottenere un conteggio totale delle sessioni, il conteggio delle sessioni su più giorni viene raddoppiato.
  • A seconda dell'identità report selezionata, il metodo di calcolo del conteggio degli utenti dovrà essere aggiornato.
• Ambito di dimensioni e metriche: assicurati che i calcoli utilizzino l'ambito corretto a livello di utente, sessione, articolo o evento.
• Fuso orario: nell'esportazione BigQuery, event_date è per il fuso orario dei report, mentre event_timestamp è un timestamp UTC in microsecondi. Pertanto, idealmente, se si utilizza event_timestamp in una query, questo deve essere regolato in base al fuso orario dei report corretto durante il confronto con i numeri dell'interfaccia utente.
• Filtro dei dati e limiti di esportazione: se hai configurato il filtro dati per l'esportazione degli eventi BigQuery o se il volume di esportazione degli eventi giornaliero ha superato il limite, i dati di esportazione degli eventi BigQuery non corrisponderanno alle piattaforme di generazione di report standard.

CON tutto questo, c'è qualcosa di UNNEST in questo post. Spero che tu possa SELEZIONARE le soluzioni giuste per il tuo progetto DISTINCT DALLE linee guida riportate qui. In caso di domande, unisciti al server Discord di GA DOVE le query sono più gradite.