Tutti gli eventi GA4 che il tuo container server vede, e da dove arriva ciascuno

Nel momento in cui il tag Google si carica con il tuo ID misurazione, quattro eventi fluiscono senza alcuna impostazione dietro. Nulla in Analytics li disattiva, e nulla nel tuo container deve richiederli.

• page_view: uno per caricamento di pagina, o per cambio di route in una single-page app quando l’opzione «modifiche alla pagina» dello stream è attiva.
• session_start: il primo hit di una nuova sessione. Una sessione termina dopo trenta minuti di inattività, quindi un visitatore che torna due ore dopo ne inizia un’altra.
• first_visit: una volta per browser, nella prima sessione in assoluto che GA4 ha visto da quel browser. Cancellare i cookie ne produce un altro.
• user_engagement: inviato quando la pagina è rimasta in primo piano per dieci secondi, o quando il visitatore se ne va dopo aver interagito. Da qui nasce il tempo di coinvolgimento di GA4.

Se vedi page_view e nient’altro, il tag funziona. Non è un guasto: è un sito in cui nessuno è ancora arrivato in fondo alla pagina.

La misurazione avanzata di GA4 raccoglie altri nove eventi nel browser, senza un tag per nessuno di essi. Si configurano sullo stream di dati, non in Tag Manager, ed è per questo che un container server li inoltra senza sapere che esistono.

Ciascuno ha una condizione più stretta di quanto il nome lasci intendere.

• scroll: una volta per pagina, e solo quando il 90 % dell’altezza della pagina è stato visibile. Non a qualsiasi scorrimento: al raggiungimento del fondo. Una pagina più corta della finestra non lo attiva mai.
• click: un clic in uscita, verso un dominio diverso da quello corrente. I link interni non contano. L’evento si chiama click, con un parametro outbound; non esiste outbound_click.
• view_search_results: un caricamento di pagina il cui URL contiene un parametro di ricerca (q, s, search, query o keyword per impostazione predefinita).
• file_download: un clic su un link che termina con un’estensione di documento, archivio, audio, video o foglio di calcolo.
• form_start e form_submit: la prima interazione con un modulo nella pagina, e il suo invio.
• video_start, video_progress e video_complete: solo per player YouTube incorporati, e solo se l’incorporamento ha l’API JS abilitata.

Ed ecco la parte che costa settimane. Ognuno di quei nove dipende dall’interruttore principale della misurazione avanzata dello stream, e uno stream creato tramite l’API di amministrazione di Analytics — anziché nell’interfaccia di Analytics — ha quell’interruttore SPENTO. Leggi le impostazioni via API e ogni singola opzione risponde true; l’interruttore principale è semplicemente assente dalla risposta, perché è false e l’API omette i booleani falsi. La configurazione sembra quindi interamente attiva e consegna solo page_view.

L’abbiamo scoperto sulla nostra stessa proprietà. SignalHost accende l’interruttore principale quando crea una proprietà per te; se la tua è stata creata in altro modo e scroll non arriva mai, apri lo stream di dati in Analytics e controlla «Misurazione avanzata» in sé, non le opzioni sotto di essa.

Gli eventi commerce — view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info e purchase — sono quelli che a un negozio interessano davvero, e gli unici in questa pagina che nulla invia automaticamente. GA4 definisce nomi e forma; il tuo sito deve inviare ciascuno al dataLayer, esattamente con quel nome, con un oggetto ecommerce allegato.

Un tema Shopify standard non lo fa. Il core di WooCommerce non lo fa. Lo fa un’app o un plugin per il dataLayer, e su Shopify gli eventi del checkout richiedono un Custom Pixel, perché il container del tema non si carica mai sulle pagine di pagamento. Quando scegli una piattaforma per negozi nella procedura guidata di SignalHost, installiamo un attivatore e un tag evento GA4 per ciascuno dei sette, così nel momento in cui il tuo sito invia purchase l’evento viene inoltrato — ma l’invio devi organizzarlo tu. L’articolo successivo spiega esattamente cosa installare.

Ogni richiesta di misurazione che passa dal tuo container viene contata per nome di evento, per giorno, per 400 giorni. Si conserva solo il nome — non l’URL, non l’ID cliente, non un solo parametro — ed è ciò che rende sicuro conservarlo così a lungo. L’elenco è ciò che è arrivato al tuo nome host, quindi risponde a una domanda a cui Analytics da solo non può rispondere: il browser lo ha inviato davvero?

Aspettati conteggi disomogenei. Ogni caricamento di pagina è un page_view; solo i caricamenti che raggiungono il fondo sono uno scroll; solo le sessioni che superano i dieci secondi sono un user_engagement. Un sito con dieci visualizzazioni di pagina e due scroll è un sito normale.

Due casi, e la pagina del container li distingue.

Se l’evento non è nell’elenco del container, il tuo sito non lo ha mai inviato. Il container non può inoltrare ciò che non è arrivato. Per un evento standard, controlla l’interruttore della misurazione avanzata dello stream; per un evento commerce, verifica che l’invio al dataLayer avvenga, con il nome giusto, nella pagina in cui dovrebbe.

Se l’evento è nell’elenco del container ma non in Analytics, è arrivato ed è stato inoltrato, e il problema sta dal lato Google della linea: l’ID misurazione sbagliato, un filtro dati, una proprietà in un account diverso da quello che stai guardando, o semplicemente il ritardo dei report — il tempo reale lo mostra in pochi secondi, i report standard possono richiedere un giorno.