Come riconciliare conversioni e lead del CRM

Come riconciliare le conversioni delle analisi del sito web con i record del CRM

Le analisi del sito web e un CRM conteggiano cose diverse. Le analisi possono registrare un evento di invio di un modulo, mentre il CRM registra un lead solo dopo la convalida, la deduplicazione o il completamento corretto del trasferimento. Una differenza tra i due totali non significa automaticamente che il monitoraggio non funzioni. Significa però che serve un metodo coerente per confrontarli e capire perché i lead CRM non corrispondono alle conversioni del sito.

L’obiettivo è capire che cosa è successo a ogni conversione pertinente, non costringere i due sistemi a mostrare lo stesso numero. Una riconciliazione pratica parte da un evento, segue un insieme di regole ben definito e registra le ragioni di eventuali differenze.

1. Definisci la conversione e il lead da riconciliare

Scegli una conversione registrata nelle analisi e il risultato corrispondente nel CRM. Per esempio, confronta l’evento del sito web demo_request_submit con i record CRM creati come nuovi lead per richieste di demo. Non sommare a quell’evento le iscrizioni alla newsletter o le richieste telefoniche: sono azioni diverse dei clienti e possono seguire percorsi distinti.

Annota che cosa viene conteggiato in ciascun sistema. Una conversione nelle analisi potrebbe corrispondere a un evento di invio riuscito, attivato dopo che il server ha confermato la ricezione. Un lead nel CRM potrebbe invece indicare un nuovo record con un indirizzo e-mail valido, non un contatto esistente di cui sono stati aggiornati i dati. Questa distinzione determina che cosa può dirti il confronto.

Stabilisci il periodo di riferimento e gli stati da includere. Se stai esaminando la prima settimana del mese, indica gli orari esatti di inizio e fine e decidi se includere i lead aperti, qualificati, non qualificati o eliminati. Mantieni l’ambito abbastanza circoscritto da poter spiegare i risultati. «Tutte le conversioni e tutte le attività del CRM» è di solito un perimetro troppo ampio per individuare il problema.

Prima di estrarre i dati, annota la definizione in un documento condiviso. Questo semplice passaggio evita che un analista conteggi tutti gli invii dei moduli mentre un altro consideri solo i lead accettati dal team vendite. Se ti serve un metodo più ampio per pianificare i flussi di dati, tratta questa riconciliazione come un’attività di misurazione separata, senza riaprire la progettazione dell’intera integrazione del CRM.

2. Stabilisci le regole di confronto prima di estrarre i dati

Per prima cosa, concordate il fuso orario. Le analisi e il CRM potrebbero memorizzare gli orari in fusi diversi o mostrarli in base a impostazioni differenti dell’account. Prima di confrontare i totali giornalieri, convertite entrambi i set di dati nello stesso fuso concordato, ad esempio UTC; altrimenti, un invio avvenuto a ridosso della mezzanotte potrebbe risultare in date diverse.

Usa lo stesso intervallo di date, ma chiarisci quale timestamp determina l’inclusione. Le analisi potrebbero basarsi sull’ora dell’evento, mentre il report del CRM potrebbe filtrare in base alla data di creazione del lead. Se il lead viene creato in ritardo, le due date possono ricadere in periodi di rendicontazione diversi. Per la riconciliazione, spesso conviene partire dall’ora dell’evento e conservare quella di creazione nel CRM per spiegare eventuali ritardi.

Se la domanda riguarda l’attribuzione delle campagne, documenta anche la finestra e il modello di attribuzione. Una conversione può essere presente in entrambi i sistemi, ma avere una fonte diversa, perché le analisi e il CRM potrebbero assegnare il merito secondo regole differenti. Confronta separatamente il numero di record e l’attribuzione ai canali: mescolare le due questioni rende più difficile interpretare i risultati.

Decidi in anticipo come gestire test, spam, duplicati e record non qualificati. Per esempio, escludi gli invii di test interni usando un indirizzo noto, ma non rimuovere un lead solo perché il team vendite lo ha successivamente contrassegnato come non qualificato. Quel cambiamento di stato può spiegare un esito commerciale, ma non cancella l’invio originale.

3. Confronta le conversioni delle analisi con i lead del CRM

Per come confrontare conversioni web e lead CRM, crea una riga per ogni conversione del periodo scelto e cerca il record CRM corrispondente. Se entrambi i sistemi conservano un ID di invio o di evento condiviso, questo è il metodo di abbinamento più affidabile. Trasmetti l’identificativo lungo il flusso del modulo e salvalo in un campo del CRM, così da poterlo verificare in seguito.

Se non esiste un ID condiviso, usa una combinazione di campi definita in modo preciso, ad esempio l’ora di invio, il tipo di modulo e un identificativo rispettoso della privacy a cui il tuo team può accedere. Il solo timestamp è una prova debole: due persone possono inviare lo stesso modulo a pochi secondi di distanza e la stessa persona potrebbe inviarlo due volte. Se le prove sono incomplete, non considerare certo un abbinamento approssimativo.

Classifica ogni confronto come corrispondente, senza corrispondenza o ambiguo. Una riga corrispondente ha un record chiaramente associabile. Un evento delle analisi senza corrispondenza non ha un record CRM secondo le regole concordate. Una riga ambigua potrebbe corrispondere a più record candidati oppure contenere dati insufficienti per decidere. Mantieni separate queste categorie invece di forzare ogni riga in una risposta sì o no.

Una tabella di lavoro di base potrebbe includere l’ID dell’evento nelle analisi, il timestamp dell’evento, il nome del modulo, l’ID del record CRM, l’ora di creazione nel CRM, lo stato attuale e l’esito dell’abbinamento. Limita l’accesso ai dati personali e usa solo i campi necessari per l’attività. Se il modulo non dispone di un identificativo di invio stabile, annotalo come limite del monitoraggio invece di fingere che un abbinamento basato sul timestamp sia definitivo.

4. Individua le cause di una discrepanza tra le analisi del sito web e i dati del CRM

Una discrepanza tra le analisi del sito web e i dati del CRM può verificarsi in diversi punti tra l’azione di un visitatore e la generazione di un report. Per riconciliare conversioni analytics e CRM, considera ogni possibile causa un’ipotesi da verificare, non una spiegazione da dare per scontata. Parti dai record senza corrispondenza e osserva se la discrepanza si concentra su un modulo, un browser, una campagna o un periodo specifico.

• Consenso o blocco degli annunci: Un visitatore potrebbe inviare un modulo mentre la raccolta dei dati delle analisi è limitata o bloccata. Verifica che l’invio raggiunga comunque il server e che l’evento debba attivarsi in base alle impostazioni di consenso applicabili.

• Attivazione dei tag: Il tag delle analisi potrebbe non attivarsi dopo l’invio oppure attivarsi prima che l’invio vada a buon fine. Prova il modulo in una sessione controllata e verifica che l’evento compaia solo nel punto previsto del flusso.

• Recapito del modulo: Una pagina di conferma nel browser non dimostra che i dati del modulo siano arrivati al CRM. Controlla l’endpoint del modulo o il registro dell’integrazione per verificare la risposta di recapito e gli eventuali errori associati allo stesso invio.

• Convalida del CRM: Una regola del CRM potrebbe rifiutare un record perché manca un campo obbligatorio o un valore non supera la convalida. Esamina i registri dei rifiuti e, quando possibile, collega l’invio rifiutato al relativo ID evento.

• Deduplicazione: Il CRM potrebbe aggiornare un contatto esistente invece di creare un nuovo lead. Cerca l’identificativo nei record esistenti e controlla se il sistema ha registrato un aggiornamento o un’unione.

• Creazione ritardata: Una coda, un processo pianificato o una verifica manuale potrebbero ritardare la creazione del record CRM. Prima di considerarlo mancante, confronta l’ora dell’evento con quella di creazione del record.

Verifica una causa alla volta. Se tutti i record senza corrispondenza provengono da un modulo specifico, esamina la sequenza di invio e monitoraggio di quel modulo prima di modificare i report delle campagne. Registra la data di attivazione di ogni modifica ai tag o alla gestione dei moduli, così che nei confronti successivi sia possibile distinguere un problema passato da uno attuale.

5. Riconcilia duplicati, ritardi e cambiamenti di stato

Non tutte le conversioni registrate nelle analisi devono generare un nuovo lead nel CRM. Una persona potrebbe inviare il modulo più volte oppure il CRM potrebbe accorpare il secondo invio a un contatto esistente. Conteggia gli eventi di conversione secondo la definizione delle analisi e i record CRM univoci secondo quella del CRM. I totali possono differire legittimamente, ma la regola per i duplicati deve essere esplicita.

Prima di contrassegnare una conversione come priva di corrispondenza, considera un possibile ritardo nell’arrivo dei dati. Se il record CRM compare alcune ore dopo, l’invio non è andato perso: è semplicemente arrivato in ritardo. Conserva entrambi i timestamp e stabilisci un periodo di attesa uniforme per i report periodici. Il periodo appropriato dipende dal processo di elaborazione, quindi concordalo con il team responsabile dell’integrazione.

Separa la creazione dai cambiamenti di stato successivi. Un lead contrassegnato come non qualificato dopo una verifica esiste comunque come record nel CRM, anche se non rientra più in un report vendite. Un record eliminato richiede una spiegazione diversa: controlla se è stato rimosso da un utente, da un processo di conservazione dei dati o in seguito a un’unione. Riporta ciò che risulta dalla cronologia di controllo del CRM, senza dedurre la causa dalla sola vista attuale.

Per ogni eccezione, annota una breve motivazione, come «duplicato accorpato», «creato il giorno successivo» o «rifiutato per un campo obbligatorio». Così la riconciliazione sarà utile al team responsabile del passaggio successivo. Se durante la verifica emerge una questione di privacy o di accesso, consulta le linee guida approvate dalla tua organizzazione sulla sicurezza dei siti web e sulla gestione dei dati.

6. Correggi la riconciliazione senza riscrivere la cronologia

Una volta raccolte prove sufficienti, correggi la causa del problema. Se il tag si attiva prima di una risposta positiva, modifica il trigger e verifica un invio confermato. Se la convalida del CRM rifiuta un valore valido del modulo, correggi la mappatura dei campi o la regola di convalida seguendo la normale procedura di modifica. La correzione deve risolvere un problema dimostrato, non limitarsi a far coincidere i due totali.

Conserva l’ora originale dell’evento nelle analisi e quella di creazione nel CRM. Se inserisci retroattivamente record o eventi, contrassegnali come dati aggiunti a posteriori e conserva la data della correzione. Altrimenti, un analista potrebbe scambiare in futuro i dati ricostruiti per un evento acquisito in tempo reale.

Annota ogni modifica alle definizioni, ai filtri o alle regole di attribuzione. Per esempio, se dal primo giorno di un trimestre un report inizia a escludere i test interni, segnala il cambiamento e non confrontare il nuovo totale con uno precedente come se le regole fossero rimaste invariate. Anche quando la misurazione migliora, i dati storici devono restare interpretabili.

7. Monitora la riconciliazione nel tempo

Ripeti lo stesso confronto con una cadenza prestabilita, ad esempio al termine di ogni periodo di rendicontazione o dopo una modifica significativa a un modulo. Ogni volta usa lo stesso evento, le stesse regole sugli stati, lo stesso fuso orario e lo stesso metodo di abbinamento. Se il processo cambia, documenta la nuova regola e la data in cui è entrata in vigore.

Classifica le differenze irrisolte in base alla causa, invece di riassumerle in una sola percentuale o in un unico totale. Un piccolo gruppo di errori di convalida del CRM potrebbe richiedere l’intervento di un referente diverso rispetto a un gruppo di conversioni mancanti perché le impostazioni del consenso impediscono la raccolta dei dati delle analisi. Assegna ogni categoria al team che può esaminarla e, quando possibile, includi alcuni ID di esempio senza dati personali.

Concorda una soglia di tolleranza per l’escalation con i responsabili delle analisi e del CRM; la soglia dovrebbe basarsi sulle normali variazioni operative, quindi definite prima di usarla negli avvisi. Quando la discrepanza osservata supera il limite, avvisa il team responsabile indicando il periodo, il modulo interessato, il numero di record senza corrispondenza e le prime verifiche già eseguite. Un avviso specifico permette di intervenire; «i numeri sembrano sbagliati» no.