Il tagging lato client di GA4 tramite gtag.js o GTM è la baseline di attribuzione su cui la maggior parte dei team si basa per default. Funziona bene in condizioni ideali: un utente Chrome desktop su una connessione veloce, nessun ad-blocker, una sessione Safari che non ha attivato il limite di cookie del script impostato a 24 ore di ITP. Le condizioni ideali coprono forse il 65-75% del traffico UE nel 2026.
Il resto - utenti di uBlock Origin, il blocking integrato di Brave, l'Intelligent Tracking Prevention di Safari su iOS, la crescente coorte di blocchi a livello di rete come NextDNS e Pi-hole - invia eventi che o vengono eliminati prima di raggiungere www.google-analytics.com o arrivano senza un identificatore client utilizzabile perché il cookie _ga è stato cancellato. Il divario tipico sui pubblici con forte presenza UE è il 25-35% degli eventi di conversione. Per alcuni settori - fintech, strumenti privacy, strumenti per sviluppatori - è più alto perché il segmento demografico degli utenti è correlato con l'adozione degli ad-blocker.
Il Measurement Protocol di GA4 è il percorso lato server che bypassa tutto questo. Il tuo server parla direttamente con l'endpoint di raccolta di Google. Lo stato del browser è irrilevante. Questo post copre la configurazione esatta: credenziali, forma del payload, connessione del client_id, validazione e il pattern di deduplicazione per i team che eseguono gtag insieme al percorso lato server.
L'architettura di inoltro delle conversioni sottostante - perché il lato server vince e come funziona il fan-out verso più piattaforme - è coperta nella panoramica del tracciamento delle conversioni lato server. La versione Meta CAPI di questo tutorial è su inoltro delle conversioni a Meta CAPI; il pattern di configurazione ha la stessa forma, con parametri specifici per GA4 qui.
TL;DR
- GA4 gtag.js perde il 25-35% degli eventi di conversione sul traffico UE tipico verso gli ad-blocker (uBlock, Brave) e ITP (limiti di durata dei cookie Safari); il Measurement Protocol bypassa tutto questo perché la richiesta proviene dal tuo server.
- Hai bisogno di due credenziali: il Measurement ID (
G-XXXXXXXX) dal tuo data stream e un segreto API generato in Admin → Data Streams → Measurement Protocol API secrets. Sono anche ciò che chiede l'integrazione GA4 di Elido, che inoltra i click (non gli acquisti) e richiede circa due minuti di configurazione. - Il
client_idè ciò che collega un evento lato server a una sessione GA4. Elido non imprime un click ID né imposta un cookie sul redirect e non inoltra ancora gli acquisti a GA4, quindi catturi ilclient_idsul tuo sito e invii l'evento Measurement Protocol dal tuo server. - La validazione richiede circa dieci minuti: GA4 DebugView mostra gli eventi del Measurement Protocol che arrivano entro circa dieci secondi; i report standard si popolano nell'arco di 24-48 ore.
Le due credenziali di cui hai bisogno
GA4 Measurement Protocol richiede due informazioni, entrambe dalla console di amministrazione GA4.
Measurement ID. L'identificatore del data stream, formattato come G-XXXXXXXX. Trovalo in Admin → Data Streams → il tuo web stream → il pannello dei dettagli dello stream. È lo stesso ID che passi a gtag('config', 'G-XXXXXXXX') nella tua configurazione lato client - non è un segreto; appare nel codice sorgente della tua pagina.
Segreto API. Questa è la credenziale che autorizza le scritture lato server all'endpoint di raccolta. Vai su Admin → Data Streams → il tuo web stream → Measurement Protocol API secrets → Create. Il segreto è una stringa alfanumerica breve. Trattalo come una chiave di account di servizio: conservalo come segreto del workspace, ruotalo con le altre credenziali del servizio, non eseguirne il commit nel codice sorgente.
In Elido, questi si incollano in Impostazioni Workspace sotto Integrations → GA4. Test connection invia quindi un evento di test al server di convalida di GA4 e, se il payload supera i controlli, lo invia effettivamente con debug_mode impostato. Questo controllo riguarda il payload, non le credenziali: il server di convalida accetta qualsiasi segreto API e persino un Measurement ID che non appartiene ad alcuna proprietà, quindi un esito positivo non dimostra che la coppia sia corretta. Conferma l'evento di test in DebugView o Realtime prima di farvi affidamento.
La forma dell'evento
Il riferimento al Measurement Protocol di GA4 (acceduto il 2026-05-12) specifica il formato della richiesta. L'endpoint è:
POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=<secret>
Il corpo porta un client_id, un user_id opzionale e un array events. Ecco il payload per un evento di acquisto:
{
"client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"user_id": "user-shop-12847",
"events": [
{
"name": "purchase",
"params": {
"transaction_id": "ord_98231",
"value": 89.5,
"currency": "EUR",
"engagement_time_msec": 1,
"items": [
{
"item_id": "sku-spring-jeans-32-blue",
"item_name": "Spring Jeans 32 Blue",
"quantity": 1,
"price": 89.5
}
]
}
}
]
}
Alcune cose in questo payload che è facile sbagliare:
event_name deve essere in snake_case minuscolo. Il riferimento agli eventi di GA4 (acceduto il 2026-05-12) elenca i nomi di evento raccomandati: purchase, sign_up, generate_lead, add_to_cart. Inviare Purchase (con la P maiuscola) produrrà un evento separato nei report di GA4 invece di unirsi ai tuoi eventi purchase attivati da gtag. La piattaforma non ti avvisa; l'evento arriva semplicemente come un evento personalizzato con un nome strano.
engagement_time_msec deve essere presente e impostato su un numero intero positivo. Senza di esso, GA4 conta l'evento ma non accredita l'engagement della sessione, e alcuni modelli di attribuzione escludono gli eventi senza tempo di engagement. Impostare 1 è sufficiente per soddisfare il requisito.
event_params è limitato a 25 parametri per evento. Il Measurement Protocol rifiuterà i payload che superano questo limite. Il rifiuto è silenzioso per default - la richiesta restituisce 204 senza corpo indipendentemente dal fatto che l'evento sia stato accettato. Usa l'endpoint di debug con validation_behavior impostato su ENFORCE_RECOMMENDATIONS (coperto nella sezione di validazione) per individuare i superamenti durante lo sviluppo; la modalità predefinita lascia passare un 26° parametro.
user_id è opzionale ma prezioso. Se hai un identificatore utente persistente lato server - un ID cliente nella tua tabella degli ordini, un ID sottoscrittore nel tuo CRM - invialo. GA4 lo usa per l'attribuzione cross-device e migliora la corrispondenza tra gli eventi lato server e lato client.
Collegare il client_id: perché è importante e come lo gestisce Elido
Il client_id è il campo che GA4 usa per collegare un evento lato server a una sessione del browser. Quando gtag.js viene eseguito su una pagina, legge il cookie _ga e usa il suo UUID come client_id per tutti gli eventi che attiva. Se il tuo evento lato server porta lo stesso client_id, GA4 può connettere quegli eventi nello stesso percorso utente e sessione.
La sfida è portare quell'UUID lato server. Il cookie _ga è un cookie first-party sul tuo dominio, quindi il tuo server può leggerlo al momento del checkout e includerlo nel payload della conversione. Ma questo funziona solo se il browser dell'utente ha _ga impostato, che è esattamente la popolazione che perdi a causa di ITP e degli ad-blocker.
Elido non risolve ancora questo problema al livello di redirect: non imposta un cookie né aggiunge un click ID all'URL di destinazione, e non inoltra le conversioni a GA4. Un click ID sul redirect è nel nostro backlog, non rilasciato. Fino ad allora costruisci tu l'abbinamento, sul tuo sito. Il flusso:
La tua landing page o tag manager legge il valore _ga dove esiste, oppure genera un tuo UUID first-party dove non esiste, e lo scrive negli attributi personalizzati dell'ordine. Al momento della conversione, il tuo webhook dell'ordine porta quel valore. Il tuo server costruisce il payload Measurement Protocol con client_id impostato su di esso e lo invia a GA4.
Scrivere l'identificatore sull'ordine al momento della visita è più affidabile che leggere _ga al checkout, perché anche se ITP cancella il cookie entro 24 ore, l'attributo dell'ordine persiste comunque nel tuo database.
La guida all'invio di eventi di GA4 (acceduta il 2026-05-12) descrive come funziona client_id tra percorsi client e server.
Inoltro: il curl effettivo
Elido non assembla né inoltra questo payload per gli acquisti; lo fa il tuo server, quando arriva il webhook d'ordine. La chiamata che esegue, che puoi lanciare anche a mano per testare il lato GA4 del cablaggio, è:
curl -X POST \
"https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET" \
-H "Content-Type: application/json" \
-d '{
"client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"user_id": "user-shop-12847",
"events": [
{
"name": "purchase",
"params": {
"transaction_id": "ord_98231",
"value": 89.50,
"currency": "EUR",
"engagement_time_msec": 1
}
}
]
}'
GA4 restituisce 204 sia per gli eventi validi che per quelli non validi. Non puoi distinguere un evento malformato da un'acquisizione riuscita solo tramite il codice di stato HTTP. Per verificare che l'evento sia ben formato, usa l'endpoint di debug durante lo sviluppo:
POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET
L'endpoint di debug restituisce un corpo JSON che elenca gli errori di validazione per ogni evento. Un evento con un nome di parametro sbagliato, un payload che supera i 25 parametri o un client_id malformato emergerà qui. Alcuni di questi problemi emergono solo quando il corpo di debug imposta validation_behavior su ENFORCE_RECOMMENDATIONS, e l'API secret non viene mai verificato; la guida al debug del Measurement Protocol illustra cosa il validatore rileva e cosa non rileva.
Quando si usa Elido, Test connection nell'integrazione GA4 esegue questo controllo al posto tuo e mostra eventuali validationMessages come errore. Un risultato pulito continua a non dire nulla sull'API secret. Per questo il passaggio successivo è DebugView.
Validazione: DebugView
DebugView di GA4 è il ciclo di feedback più rapido durante la configurazione. Per attivarlo per gli eventi lato server, aggiungi "debug_mode": 1 all'oggetto params dell'evento. Gli eventi con questo flag appaiono in DebugView entro circa dieci secondi; non contano verso i dati dei report di produzione.
In DebugView (GA4 Admin → DebugView), ogni evento mostra il suo nome, i parametri che ha portato e se qualche parametro è stato rifiutato. La visualizzazione raggruppa gli eventi per client_id, così puoi tracciare l'intera sessione dal clic alla conversione.
Cosa verificare prima di rimuovere debug_mode:
- Il nome dell'evento appare esattamente come previsto nel flusso di eventi di DebugView (
purchase, nonPurchaseoecommerce_purchase). - Il parametro
transaction_idè visibile e corrisponde al formato del tuo ID ordine. - Il
client_idè una stringa in formato UUID - non vuoto, non una stringa"unknown"di fallback. - La
currencyè il codice ISO 4217 corretto (EUR, noneur, nonEuro).
I report standard di GA4 impiegano 24-48 ore per riflettere i dati di conversione lato server. Non valutare l'accuratezza del report il primo giorno. DebugView conferma la forma dell'evento; i report confermano l'attribuzione e i totali.
Errori comuni
client_id mancante. Gli eventi senza un client_id vengono eliminati silenziosamente dal Measurement Protocol. Questa è la modalità di errore singola più comune. L'eliminazione è invisibile - la richiesta restituisce 204, DebugView non mostra nulla, la conversione non appare mai. Verifica che il campo client_id sia sempre popolato prima che la richiesta si attivi. Nella configurazione di Elido, un client_id mancante significa che il parametro elido_click non è stato scritto nell'ordine al momento della conversione - controlla il tag della landing page o il gestore del webhook.
Formato del nome dell'evento sbagliato. Purchase crea un evento personalizzato chiamato Purchase insieme a qualsiasi evento purchase esistente da gtag. Il tuo conteggio totale degli acquisti nei report di GA4 si divide tra due nomi di evento. La correzione consiste nell'applicare lo snake_case minuscolo a tutti i nomi degli eventi inviati all'endpoint del Measurement Protocol. Il riferimento agli eventi di GA4 (linkato sopra) elenca i nomi canonici per gli eventi e-commerce.
Superamento dei 25 event_params. Il Measurement Protocol rifiuta silenziosamente i payload con più di 25 parametri per evento. I team che inoltrano i metadati completi degli ordini (tutte le voci, tutti gli attributi personalizzati) spesso raggiungono questo limite senza rendersene conto. Usa l'endpoint di debug in modalità ENFORCE_RECOMMENDATIONS per individuare i superamenti durante lo sviluppo. In produzione, elimina i parametri non essenziali e mantieni i payload degli eventi snelli.
Valuta proveniente dalla configurazione della pagina, non dall'ordine. Se la tua configurazione gtag usa come default USD ma i tuoi ordini sono in EUR, l'evento lato server e l'evento lato client portano valori di valuta diversi. GA4 li registra sotto lo stesso nome di evento ma non può aggregare i valori. Sorgente la valuta dal record dell'ordine nel tuo backend, non da una configurazione gtag a livello di pagina.
Deduplicazione con gtag lato client
Se esegui gtag.js lato client e il Measurement Protocol lato server simultaneamente, hai bisogno della deduplicazione. GA4 deduplica gli eventi usando client_id combinato con una finestra temporale. Il meccanismo è meno esplicito del campo event_id di Meta CAPI ma l'approccio pratico è lo stesso: porta un transaction_id coerente sugli eventi di acquisto tra entrambi i percorsi.
Per gli eventi di acquisto, imposta transaction_id sull'ID del tuo ordine. Il tuo gtag lato browser attiva purchase con transaction_id: "ord_98231" quando si carica la pagina di conferma; il tuo evento del Measurement Protocol lato server porta lo stesso transaction_id: "ord_98231". GA4 deduplica all'interno della stessa finestra di sessione. Se la stessa combinazione client_id + transaction_id arriva due volte entro la finestra di deduplicazione, la seconda viene ignorata.
Per gli eventi upstream - generate_lead, sign_up, add_to_cart - non c'è un ID ordine da usare. Qui funziona un identificatore del visitatore che hai generato tu: imposta event_id sull'UUID che hai memorizzato sul tuo sito. Sia il pixel lato browser che la chiamata lato server fanno riferimento allo stesso valore. È la stessa disciplina descritta nel tutorial end-to-end sul tracciamento UTM, che copre la configurazione più ampia dei tag di campagna che porta gli identificatori lungo tutto il funnel.
La finestra di deduplicazione in GA4 non è documentata pubblicamente con la precisione con cui Meta pubblica per CAPI. In pratica, gli eventi con client_id + transaction_id corrispondenti che arrivano entro la stessa finestra di sessione vengono deduplicati. Eseguire entrambi i percorsi simultaneamente è la configurazione più sicura - fornisce copertura di fallback per il pubblico con molti ad-blocker pur dando all'algoritmo un segnale più pulito dal percorso server.
Dove si inserisce nella pipeline di attribuzione
Il Measurement Protocol chiude il divario del segnale GA4 nello stesso modo in cui CAPI chiude il divario del segnale Meta. I meccanismi sono diversi - GA4 usa client_id e transaction_id dove Meta usa event_id e le chiavi di corrispondenza - ma l'architettura è identica: un evento lato server che non dipende dallo stato del browser.
Per il quadro completo di quali piattaforme inoltrare e come funziona il fan-out su scala, la panoramica del tracciamento delle conversioni lato server copre GA4, Meta CAPI e TikTok Events affiancati. Per le campagne in cui il tagging UTM è il passaggio upstream, il tracciamento delle campagne UTM end-to-end è la lettura prerequisita.
La superficie di prodotto per questa configurazione: le funzionalità di tracciamento delle conversioni documentano ciò che esiste oggi: gli acquisti Stripe e Shopify collegati al link tramite elido_link_id. L'inoltro degli acquisti a GA4, Meta o TikTok non è ancora disponibile. Soluzioni per i marketer mostra come la pipeline delle conversioni si inserisce in un flusso di campagna insieme ai template UTM e al routing degli smart link.
La configurazione stessa - credenziali nella configurazione del tuo server, un passaggio del tag manager che memorizza l'identificatore sulla landing page, cablaggio del webhook dell'ordine - richiede metà giornata per la maggior parte dei team. Il passaggio di validazione DebugView aggiunge altri trenta minuti. Il risultato è dati di conversione GA4 che riflettono ciò che le tue campagne stanno effettivamente generando, non il 65-75% di esse che sopravvive al percorso lato browser.
Fonti
- Google Analytics 4: Measurement Protocol overview. developers.google.com/analytics/devguides/collection/protocol/ga4 (acceduto il 2026-05-12)
- GA4 Measurement Protocol: Event reference. developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events (acceduto il 2026-05-12)
- GA4 Measurement Protocol: Sending events. developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events (acceduto il 2026-05-12)
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Senza registrazione. Crea un account gratuito per 50 link al mese.