Dal click alla vendita: come tracciamo tutto

Panoramica dell'architettura

Il sistema è organizzato su tre livelli. Il browser raccoglie UTM, click ID e stato del consenso e invia gli eventi a un container su un tuo sottodominio. Il server container deduplica, arricchisce con i dati del CRM, filtra il traffico non valido e inoltra. Le destinazioni (Meta, Google Ads, GA4, BigQuery, CRM) ricevono eventi completi e coerenti. Nessun dato personale viaggia in chiaro e nessun passaggio dipende da cookie di terze parti.

1 · Struttura UTM e link tracking

L'attribuzione comincia dall'URL. Ogni link verso il sito, a pagamento o no, porta parametri UTM coerenti con una convenzione unica (foglio master versionato). Meta e Google li compilano con variabili dinamiche; i link in email, SMS, WhatsApp e bio passano da un redirect server che registra click, IP, dispositivo e orario prima di reindirizzare.

Esempi di tagging

# Meta Ads · parametri URL dinamici a livello di annuncio
utm_source=facebook&utm_medium=paid_social
&utm_campaign={{campaign.name}}&utm_content={{ad.name}}&utm_term={{adset.name}}

# Google Ads · template di tracciamento con ValueTrack
utm_source=google&utm_medium=cpc
&utm_campaign={campaign}&utm_term={keyword}&utm_content={creative}&device={device}

# Link tracciati · redirect server (email, SMS, WhatsApp, bio)
https://trk.tuodominio.it/l/?src=email_wuc_mar26&uid={{contact_id}}&seq=followup_3

Cookie first-party e click ID

fbclid, gclid, gbraid/wbraid e msclkid vengono catturati al primo accesso e salvati in tre posti: localStorage, un cookie first-party di 180 giorni impostato dal server e il campo del contatto nel CRM al primo form. Così una conversione tardiva, anche dopo settimane o da un altro dispositivo, può essere ricondotta al click di origine.

// Sulla landing page, al primo accesso
fbclid  → localStorage → cookie first-party (180 gg, HTTP) → campo CRM "fbclid"
gclid   → stessa pipeline → campo CRM "gclid"
utm_*   → stessa pipeline → campi CRM "sorgente", "campagna", "contenuto"

2 · Eventi tracciati

Ogni evento ha un nome standard per Meta e per GA4, scatta in un punto preciso del funnel e porta parametri obbligatori: valore, valuta, identificativo univoco e dati di matching. Gli eventi web vengono inviati sia dal browser sia dal server con lo stesso event_id; quelli offline partono solo dal server.

3 · Deduplicazione con event_id

Browser e server inviano la stessa conversione. Per contarla una volta sola, entrambi portano lo stesso event_name e lo stesso event_id, generato una sola volta nel dataLayer (per gli acquisti coincide con l'ID ordine). Meta e Google riconoscono la coppia entro la finestra di deduplicazione e scartano il doppione.

4 · Consent Mode v2

Il consenso dell'utente governa tutto il flusso. Consent Mode v2 definisce quattro segnali che i tag Google leggono prima di scrivere cookie o inviare dati; il server container riceve lo stesso stato e lo applica anche agli eventi verso Meta. Di default tutto è denied; il banner (CMP) aggiorna i valori appena l'utente sceglie.

// Prima di qualsiasi tag: default negato, in attesa del banner
gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});
// La CMP aggiorna i segnali con la scelta dell'utente
gtag('consent', 'update', { ad_storage: 'granted', analytics_storage: 'granted',
  ad_user_data: 'granted', ad_personalization: 'granted' });

Il server container legge lo stato di consenso dall'evento in arrivo: se ad_user_data è negato, i tag Meta CAPI e Google Ads non includono email, telefono né click ID. Gli eventi aggregati restano disponibili per il reporting interno in forma anonima.

5 · GTM server container

Il cuore dell'architettura è un container Google Tag Manager lato server, pubblicato su un sottodominio first-party come trk.tuodominio.it, ospitato su Stape o Google Cloud Run. Il container web del sito invia tutti gli eventi lì, invece che direttamente a Meta e Google.

• Cookie HTTP di lunga durata: i cookie _ga, _fbp e _fbc vengono riscritti dal server con scadenza fino a 2 anni, aggirando il limite di 7 giorni che Safari e iOS impongono ai cookie scritti da JavaScript.
• Resistenza agli adblocker: le richieste vanno al tuo dominio, non a facebook.com o google-analytics.com, quindi non vengono bloccate dalle liste dei filtri.
• Un evento, molte destinazioni: il client GA4 riceve l'evento dal browser e lo passa ai tag Meta CAPI, Google Ads, GA4 e BigQuery, ciascuno con il proprio formato.
• Arricchimento: una variabile Firestore o un lookup sul CRM aggiunge email e telefono hashati, external_id e valore LTV all'evento prima dell'inoltro.
• Filtri: IP interni, user agent di bot e richieste malformate vengono scartati o marcati come test prima di arrivare alle piattaforme.
• Ingresso webhook: il CRM e il sistema di pagamento inviano al container gli eventi offline (contratto firmato, pagamento ricevuto) che il browser non può vedere.

6 · Meta Conversions API

La Conversions API (CAPI) è il canale server-to-server verso Meta. Ogni evento porta i dati di matching hashati, il click ID, IP e user agent dell'utente, l'event_id per la deduplicazione con il Pixel e l'action_source che distingue web da offline. L'obiettivo è un Event Match Quality alto, condizione per cui Meta attribuisca correttamente la conversione e ottimizzi la consegna.

POST https://graph.facebook.com/v21.0/{PIXEL_ID}/events
{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1760000000,
    "event_id": "ORD-1042",
    "action_source": "website",
    "event_source_url": "https://tuodominio.it/grazie",
    "user_data": {
      "em": ["<sha256 email>"], "ph": ["<sha256 telefono>"],
      "external_id": ["<sha256 crm_id>"],
      "fbc": "fb.1.1759000000.AbCdEf", "fbp": "fb.1.1758000000.123456",
      "client_ip_address": "203.0.113.4", "client_user_agent": "Mozilla/5.0 ..."
    },
    "custom_data": { "currency": "EUR", "value": 1990, "order_id": "ORD-1042" }
  }]
}

Eventi inviati: PageView, ViewContent, Lead (email hashata + fbclid + IP per attribuzione certa), CompleteRegistration (iscrizione evento confermata dal CRM), Purchase con valore reale, order_id e currency, Purchase offline per il coaching inviato entro 24 ore dalla firma con LTV stimato. Target di Event Match Quality: oltre 7/10; match rate su email hashata oltre il 70%.

7 · GA4 Measurement Protocol

Il Measurement Protocol è l'API con cui il server invia eventi a GA4. Serve per registrare in analytics ciò che accade fuori dal browser (contratto firmato, pagamento ricevuto, rimborso) e per completare gli eventi web con dati che il client non ha. Ogni chiamata richiede measurement_id, api_secret e un client_id esistente (dal cookie _ga) oppure uno user_id, altrimenti l'evento non viene associato a nessun utente.

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXX&api_secret=***
{
  "client_id": "1234567890.1759000000",
  "user_id": "crm_8812",
  "timestamp_micros": 1760000000000000,
  "consent": { "ad_user_data": "GRANTED", "ad_personalization": "GRANTED" },
  "events": [{
    "name": "purchase",
    "params": {
      "transaction_id": "ORD-1042", "value": 1990, "currency": "EUR",
      "items": [{ "item_id": "corso-marketing", "item_name": "Corso Marketing", "price": 1990, "quantity": 1 }],
      "session_id": "1759000000", "engagement_time_msec": 100
    }
  }]
}

• Il client_id viene salvato sul contatto CRM al primo form, così gli eventi offline tornano nella stessa sessione utente di GA4.
• Il Measurement Protocol non crea nuovi utenti né sessioni complete: va usato per integrare, non per sostituire il tag web.
• I dati arrivano in BigQuery con l'export giornaliero o in streaming, dove vengono uniti a costi e CRM per la dashboard.

8 · Google Enhanced Conversions e offline conversions

Lato Google Ads lavoriamo su tre livelli: le Enhanced Conversions for web arricchiscono le conversioni del sito con email e telefono hashati; le Enhanced Conversions for leads e l'Offline Conversion Import portano in Google Ads le vendite chiuse fuori dal sito; Customer Match carica liste hashate per audience, lookalike ed esclusioni.

// Pipeline offline → Google Ads
CRM: il lead firma il contratto
  → webhook al server container
  → estrae gclid (o gbraid/wbraid), data di conversione, valore reale
  → Offline Conversion Import via Google Ads API (entro 90 gg dal click)
  → Google ottimizza le aste su chi compra davvero, non su chi compila un form

9 · Pipeline nurturing: dal lead alla vendita tracciata

Ogni tappa del funnel invia un evento server-side. Le piattaforme imparano da tutto il percorso, non solo dal primo click, e il CRM mantiene punteggio, sorgente e click ID aggiornati. Volumi di esempio, struttura reale.

10 · Pulizia e qualità del dato

Deduplicazione eventi Critico

• event_id univoco su ogni evento: Pixel e CAPI mandano lo stesso ID, Meta e Google deduplicano.
• Finestra di dedup configurata fino a 7 giorni per eventi lenti come il coaching.
• Log degli eventi duplicati per l'audit mensile.
• Test Event Code attivo in staging, mai in produzione.

Normalizzazione contatti Critico

• Email sempre lowercase, trim e validazione regex prima dell'hashing.
• Telefono normalizzato in formato E.164 (+39…).
• Merge automatico dei duplicati nel CRM su email e telefono.
• Flag "test interno" sui contatti del team per escluderli dalle metriche.

Filtro del traffico non valido Importante

• IP interni e del team in blacklist su GA4, Meta e Google Ads.
• Filtro bot attivo su GA4 e Cloudflare Turnstile sui form.
• Monitoraggio anomalie: picchi improvvisi di CTR o click generano un alert.
• Esclusione dal remarketing dei clienti già attivi.

Stitching cross-device Importante

• Email come chiave univoca che unifica sessioni mobile e desktop.
• fbclid e gclid collegati al contact_id del CRM dal primo click.
• Continuità di sessione: lo stesso utente che torna dopo 30 giorni viene riconosciuto dal CRM.
• Finestra di attribuzione configurata: 7 giorni click / 1 giorno view per Meta.

Validazione UTM e tagging Importante

• Foglio master UTM: ogni campagna ha un codice unico e versionato.
• Alert automatico se arrivano sessioni senza UTM da canali a pagamento.
• Regex per rilevare UTM malformati o duplicati nel naming.
• Revisione mensile degli UTM orfani (click senza conversioni).

Data quality score Avanzato

• Score mensile automatico per ogni fonte: percentuale di eventi con email matchata.
• Match rate CAPI target oltre il 70%; sotto il 60% è un problema di qualità dei dati.
• Dashboard separata di data health, visibile solo internamente.
• Alert su Slack quando il match rate scende sotto la soglia critica.

11 · Obiettivi di qualità del dato

I target mensili che monitoriamo e riportiamo nel report di data health.

12 · Funzionalità avanzate

Quello che si costruisce sopra un dato affidabile. Per il dettaglio orientato al business vedi la fase 05 del framework.

13 · Stack tecnologico tipico

Gli strumenti cambiano in base a quello che usi già; l'architettura resta la stessa.