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 che fanno guadagnare — una vendita, un lead, una registrazione — sono gli unici in questa pagina che nulla invia automaticamente. GA4 ne definisce nomi e forma; il tuo sito deve inviare ciascuno al dataLayer, esattamente con quel nome, nel momento in cui avviene.

Ogni container SignalHost ha, per sedici di essi, un attivatore e un tag evento GA4 già pronti:

• Nove per il funnel di un negozio: view_item_list, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info e purchase, ciascuno con un oggetto ecommerce allegato.
• Cinque per i lead: generate_lead, contact, schedule, submit_application e subscribe.
• Due per le registrazioni: sign_up e start_trial.

Un tema Shopify standard non ne invia nessuno, e nemmeno il core di WooCommerce: 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. Nel momento in cui il tuo sito ne invia uno, il tag è lì per inoltrarlo — l’invio devi organizzarlo tu, e l’articolo su Shopify e WooCommerce spiega esattamente cosa installare.

Il pulsante «Eventi supportati» nel riquadro «Eventi» del tuo container li elenca tutti, con il significato di ciascuno e cosa inviare. Se il tuo container invia già uno di essi a GA4 con un tuo tag, SignalHost lascia quell’evento al tuo tag invece di contarlo due volte.

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 cose impediranno sempre alle due liste di coincidere esattamente. Un visitatore che non ha risposto al tuo banner invia comunque ogni evento, come ping senza cookie, e il container lo conta mentre Analytics lo scarta — la pagina mostra entrambi i numeri perché tu veda quale è quale. E session_start e first_visit non compaiono mai nella pagina del container: il browser non li invia come eventi, imposta due flag sul primo page_view, e Analytics fabbrica gli eventi dalla sua parte.

Sopra l’elenco, il riquadro conta quanti di quei sedici eventi sono arrivati negli ultimi 30 giorni, così quello che il tuo sito ha dimenticato di inviare salta all’occhio.

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 uno dei sedici, 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.

Parti da zero? Come configurare Google Tag Manager lato server, passo passo.