GA4 e CRM danno numeri diversi: come riconciliare visite e richieste

GA4 e CRM possono dare numeri diversi anche quando funzionano correttamente. GA4 descrive interazioni osservate sul sito o nell’app. Il CRM registra contatti e passaggi commerciali. Una persona può visitare più volte il sito, inviare due richieste e aprire una sola trattativa.

Una sessione è un periodo di interazione, non una persona unica né un appuntamento. Google descrive la generazione di sessioni e identificatori nella documentazione sulle sessioni GA4. La prima riconciliazione si fa sulle definizioni, non forzando i totali a coincidere.

Fai una prova tecnica in un ambiente di test, senza inviare dati a persone o campagne reali. Il clic sul pulsante deve restare distinto dalla ricezione del modulo. Se il server rifiuta l’invio e il tag conta comunque una conversione, stai misurando un tentativo.

Usa un identificatore tecnico della richiesta per controllare i passaggi nei sistemi autorizzati. Non mandare email, nomi o altri dati personali a GA4 come parametri per facilitare il confronto. Chi progetta la misura deve documentare quali identificatori sono ammessi e come vengono trattati.

Ecco un esempio inventato per capire il metodo. In un periodo il server registra cento richieste web accettate. Il CRM riconosce dieci richieste aggiuntive provenienti da persone già conteggiate e conserva quindi novanta contatti distinti. Nello stesso periodo vengono inseriti venti contatti telefonici. Il totale del CRM può essere centodieci senza che il sito abbia perso o generato contatti in modo anomalo.

Se GA4 mostra settantacinque eventi di richiesta, la differenza con i cento invii accettati va esaminata, non distribuita subito fra i canali pubblicitari. Una parte può dipendere dalla copertura della misurazione, una da blocchi tecnici, una da eventi duplicati o mancanti. Le categorie devono essere costruite su verifiche: non puoi attribuire a “consenso negato” tutto ciò che non riesci a spiegare.

Conserva il numero di richieste distinto dal numero di persone. Una persona può avere due esigenze commerciali legittime; unirne l’anagrafica non significa cancellare la seconda richiesta. Il prospetto dovrebbe permettere di passare dall’evento al contatto e poi all’opportunità, usando soltanto gli identificatori autorizzati per ciascun sistema. È diverso dal copiare dati personali negli strumenti di analisi.

Per gli invii server-side con Measurement Protocol, Google precisa che un errore nel contenuto della richiesta non produce necessariamente un errore HTTP. La procedura ufficiale di validazione degli eventi GA4 consente controlli dedicati; gli eventi inviati al server di validazione non compaiono nei report.

Per questo il collaudo ha più passaggi. Verifica che il modulo sia accettato, che venga creato il record previsto e che il payload di analisi abbia il formato corretto. Poi controlla nell’ambiente appropriato se l’evento risulta osservabile. Un solo indicatore verde nel pannello del sito non dimostra che tutti i sistemi abbiano ricevuto e interpretato la stessa cosa.

Ripeti la prova dopo una modifica del modulo, della pagina di conferma o delle impostazioni di consenso. Annota la data del cambiamento nel report: una variazione improvvisa può dipendere dalla misura prima ancora che dalle campagne. Se nessuno conserva questa cronologia, il confronto commerciale parte da numeri di cui non è chiaro quando sia cambiato il significato.

Supponiamo che una richiesta ricevuta a marzo diventi cliente ad aprile. Attribuire il ricavo soltanto alle richieste entrate ad aprile rende poco leggibile il rapporto fra acquisizione e vendita. Affianca al report del mese un gruppo di richieste per data di ingresso, seguendo nel tempo qualificazione, appuntamenti e chiusure. Non aspettarti che tutti i gruppi siano già maturi allo stesso modo.

Decidi inoltre come trattare i contatti già presenti che tornano con una nuova esigenza. Il costo della campagna, la riattivazione del rapporto e la nuova opportunità sono fatti distinti. Documentare la regola evita che marketing e commerciale discutano usando la stessa parola per oggetti diversi. Il primo accordo da raggiungere non è sul totale finale, ma sul significato di ciascuna riga.

Una richiesta arrivata via telefono può entrare nel CRM senza produrre un evento web. Un visitatore che rifiuta i cookie può completare un modulo necessario al servizio, mentre la misurazione pubblicitaria segue impostazioni differenti. La copertura dei due sistemi può quindi essere diversa.

Consent Mode non significa che ogni rifiuto produca lo stesso comportamento tecnico. Google distingue una modalità di base, che blocca i tag fino all’interazione autorizzante, da una avanzata che può inviare segnali senza cookie con consenso negato. Non è una certificazione di conformità legale. Riferimento tecnico: modalità di consenso Google.

Allinea fuso orario e intervallo, poi distingui la data di arrivo dalla data di qualificazione. Una richiesta di fine mese può diventare opportunità il mese dopo. Controlla infine ricaricamenti della pagina di conferma, eventi inviati sia dal browser sia dal server e contatti uniti dal CRM.

Un buon prospetto mostra richieste ricevute, duplicati identificati, contatti qualificati e casi ancora da chiarire, ciascuno con la propria definizione. Non distribuire la quota sconosciuta fra i canali in modo arbitrario. Mantienila visibile.

Se manca l’accordo su cosa sia un contatto utile, parti dalla definizione di lead qualificato. Se il dubbio riguarda le risposte AI, tieni separate anche citazioni e visite. Il lavoro di web analytics deve rendere le differenze interpretabili, non nasconderle in un unico numero.