Tracciamento lato server di GA4 tramite il livello di redirect

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. Entrambi si incollano nelle impostazioni del workspace di Elido in meno di due minuti.
• Il client_id è ciò che collega un evento lato server a una sessione GA4; Elido imposta un cookie UUID first-party sul redirect del link breve e lo include in ogni inoltro di conversione, così non devi leggere il cookie _ga dal browser.
• 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. Una volta salvati, Elido convalida la coppia rispetto all'endpoint di debug di GA4 e conferma la connettività. La validazione è immediata; un 4xx in questo passaggio significa che il Measurement ID o il segreto API è sbagliato.

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 (coperto nella sezione di validazione) per individuare i superamenti durante lo sviluppo.

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.

Connessione del client_id: perché è importante e come Elido la gestisce#

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 risolve questo problema al livello di redirect. Quando un utente fa clic su un link breve, il gestore dell'edge di Elido genera un UUID e lo imposta come cookie first-party _elido_cid nella risposta del redirect - prima che l'utente raggiunga il tuo sito. L'UUID viene anche aggiunto all'URL di destinazione come ?elido_click=<uuid> (configurabile per workspace). Il flusso:

La tua landing page o tag manager legge elido_click dall'URL e lo scrive negli attributi personalizzati dell'ordine. Al momento della conversione, il tuo webhook dell'ordine porta l'UUID. Elido lo cerca, costruisce il payload del Measurement Protocol con client_id impostato su quell'UUID e lo inoltra a GA4.

Questo è più affidabile che leggere _ga dal browser perché l'UUID viene catturato al momento del clic, prima che la sessione del browser dell'utente determini se i cookie vengono accettati. Anche se ITP cancella il cookie _ga entro 24 ore, il cookie _elido_cid di Elido persiste come cookie first-party sotto il dominio del tuo link breve - e l'attributo dell'ordine persiste nel tuo database indipendentemente.

La guida all'invio di eventi di GA4 (acceduta il 2026-05-12) descrive come funziona client_id tra percorsi client e server.

Inoltro di Elido: il curl effettivo#

Quando arriva POST /v1/conversions con un click_id, Elido assembla il payload del Measurement Protocol e lo inoltra. Per chiamare l'endpoint direttamente - bypassando Elido e testando il lato GA4 MP del cablaggio - il curl è:

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 vedere se l'evento è davvero arrivato, 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.

Quando si usa Elido, la stessa visibilità di validazione è disponibile tramite GET /v1/conversions/{id} - il record di conversione mostra lo stato dell'inoltro GA4 e qualsiasi risposta di errore dall'endpoint di debug durante la modalità test.

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, non Purchase o ecommerce_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, non eur, non Euro).

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 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. Il click ID funziona qui: imposta event_id sull'UUID elido_click. Sia il pixel lato browser che l'inoltro lato server fanno riferimento allo stesso valore. Questa è la stessa disciplina descritta nel tutorial di tracciamento UTM end-to-end, che copre la configurazione del tagging della campagna più ampia che rende questo ID disponibile in 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 del prodotto per questa configurazione: conversion tracking features documenta l'API /v1/conversions completa, incluso il fan-out su più piattaforme, gli eventi di rimborso e la semantica retry. Solutions for marketers mostra come la pipeline di conversione si inserisce in un flusso di lavoro di campagna insieme ai template UTM e al routing degli smart link.

La configurazione stessa - credenziali nelle impostazioni del workspace, passaggio del tag manager per elido_click 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)