Il CRM ha la vendita ma non il GCLID: posso ancora inviarla a Google Ads?

Il commerciale chiude una vendita e il CRM registra cliente, data e valore. Quando parte il flusso verso Google Ads, però, il campo gclid è vuoto. La conversione è persa oppure può essere inviata comunque?

Può ancora essere inviata, ma non basta sostituire il GCLID con una UTM. La strada dipende da ciò che hai raccolto sul sito e conservato nel CRM: dati proprietari dell’utente, altri identificatori pubblicitari o attributi della sessione. Se non hai nessuno di questi elementi, Google non può collegare in modo affidabile la vendita a un’interazione pubblicitaria.

Prima domanda: perché manca il GCLID?

Il GCLID è il Google Click ID aggiunto all’URL quando l’auto-tagging è attivo e il clic è idoneo. Può mancare perché il parametro non è stato salvato, perché il modulo è su un altro dominio, perché un passaggio lo ha rimosso oppure perché il percorso usa identificatori diversi, come wbraid o gbraid.

La prima azione non è “recuperarlo” a posteriori: è verificare landing, redirect, modulo e mapping CRM. Un valore inventato o ricostruito da campagna e keyword non è un click ID. Nell’articolo sul modulo ospitato su un altro dominio trovi i controlli per evitare che questi identificatori si perdano nel percorso.

Google accetta anche dati proprietari, se il flusso è configurato correttamente

Le enhanced conversions for leads collegano l’esito offline ai dati proprietari raccolti sul sito, per esempio email o telefono, e poi inviati dal CRM in forma normalizzata e sottoposta a hash SHA-256. Google raccomanda comunque di includere il GCLID quando disponibile, insieme ai dati dell’utente: non sono alternative da scegliere per comodità, ma segnali complementari. Fonte: Google Ads, upgrade degli import offline.

La documentazione della Data Manager API richiede almeno una famiglia di identificatori per gli eventi Google Ads: click ID, attributi di sessione, dati dell’utente oppure, nei casi previsti, informazioni del dispositivo. Quindi un evento con soli dati proprietari può essere tecnicamente valido; questo non garantisce che venga attribuito. Il dato deve trovare una corrispondenza e rispettare configurazione, consenso e policy applicabili. Fonte: Google Data Manager API, requisiti per l’invio degli eventi.

Nel 2026 il riferimento è la Data Manager API

Per le nuove integrazioni userei la Data Manager API, che Google presenta come endpoint per conversioni offline ed enhanced conversions for leads. Il flusso prevede destinazione, evento, identificatori, invio e controllo asincrono di stato e diagnostica; permette inoltre di validare il payload prima della trasmissione effettiva. Fonte: Google Data Manager API, conversioni offline di Google Ads.

Dal 15 giugno 2026 l’accesso alle vecchie richieste di upload della Google Ads API è limitato per i developer token che non avevano già inviato conversioni nel periodo indicato da Google. Per un progetto nuovo non imposterei quindi l’architettura su un percorso legacy che potrebbe essere bloccato. Fonte: Google Ads API, gestione delle conversioni offline.

Che cosa deve contenere il record del CRM

• email e telefono raccolti direttamente, con origine e stato del consenso documentati;
• gclid, wbraid e gbraid quando presenti, senza sovrascriverli con le UTM;
• eventuali attributi di sessione previsti dalla configurazione;
• nome dell’azione di conversione, data e ora reale con fuso;
• valore, valuta e un ID univoco dell’evento;
• stato dell’invio, risposta e diagnostica della piattaforma.

Le regole di normalizzazione vengono prima dell’hash: applicarle male produce stringhe formalmente cifrate ma inutili per il matching. Ho separato i passaggi nell’articolo su email, telefono e SHA-256. Il CRM dovrebbe inoltre conservare il dato sorgente secondo le regole aziendali; non affiderei a un webhook l’unica copia dell’identificatore.

Un esempio ipotetico

Esempio ipotetico, non riferito a un cliente: il lead compila un modulo con email e telefono. Il sito invia i dati proprietari tramite la configurazione per enhanced conversions, ma un errore di mapping impedisce al GCLID di arrivare nel CRM. Dopo dieci giorni il commerciale registra il contratto.

Il flusso non crea un GCLID fittizio. Prepara l’evento di vendita con data reale, ID univoco e dati proprietari normalizzati e sottoposti a hash, quindi lo invia tramite Data Manager API. La richiesta viene controllata nelle diagnostiche. In parallelo si corregge il mapping, perché i prossimi record conservino anche gli identificatori di clic disponibili.

Se invece l’email della vendita è diversa da quella raccolta sul modulo, il telefono è assente e non esistono click ID o attributi di sessione, il postback può non trovare corrispondenza. La risposta corretta è segnare l’evento come non attribuibile, non forzare la campagna più plausibile.

Tre controlli prima di usare il segnale per le offerte

1. Completezza: misura quanti lead conservano almeno un identificatore utile e quanti record arrivano senza dati collegabili.
2. Accettazione: distingui evento inviato, accettato, elaborato e attribuito. Una risposta HTTP positiva non dimostra da sola che la conversione sia finita nei report.
3. Coerenza: confronta ID, timestamp, valore e definizione della conversione tra CRM e Google Ads; testa anche retry e duplicati.

Prima di rendere primaria la nuova azione, eseguirei un test controllato come quello descritto nella guida su verifica dei segnali di vendita. Un’integrazione può aumentare la copertura osservabile, ma non ricrea informazioni mai raccolte e non garantisce risultati pubblicitari.

La regola operativa è questa: conserva tutti gli identificatori disponibili, usa i dati proprietari soltanto con una configurazione corretta e tratta l’assenza di matching come un dato di qualità del processo. Il GCLID mancante non rende automaticamente inutile la vendita; rende più importante tutto ciò che hai progettato prima che la vendita arrivasse nel CRM.

Fonti ufficiali consultate il 4 novembre 2026. L’esempio è ipotetico. Requisiti tecnici, accesso alle API e trattamento dei dati dipendono dalla configurazione dell’account, dalle policy della piattaforma e dalle regole applicabili.