Un sito riceve visite, ma i contatti sembrano pochi. Guardi Analytics e trovi un numero che conferma la sensazione. A quel punto viene abbastanza naturale cercare cosa cambiare nella pagina.
Francesca Antichi ha scritto le sette cose che guarda per prime in un’analisi CRO: cosa si capisce del sito, dove porta, quali ostacoli incontra una persona. Nell’ultimo punto arriva alla misurazione. È il passaggio da cui vorrei prendere il filo, perché quel numero dipende anche da come abbiamo costruito il sistema che lo raccoglie.
Per dire: quando diciamo «contatti», che cosa c’è dentro?
Seguire il numero all’indietro
Facciamo un esempio ipotetico. Nel report un evento si chiama richiesta_contatto. Il nome è chiaro, quindi lo leggiamo come una richiesta ricevuta.
Poi andiamo a vedere quando parte. Potrebbe essere collegato al clic su un pulsante, oppure alla conferma dell’invio. Nel primo caso conta anche i tentativi che si fermano su un errore; nel secondo bisogna verificare che il segnale arrivi tutte le volte previste e una volta sola.
Il nome nel report era lo stesso. La cosa contata cambia parecchio.
Nel lavoro sui tracciamenti mi serve ricostruire proprio questo collegamento: l’azione nell’applicazione, il segnale prodotto, il codice che lo raccoglie e quello che arriva agli strumenti. Ho raccontato alcuni di questi passaggi in Dai tracciamenti a un sistema con cui analizzarli.
Qui c’è un pezzo successivo. Se usiamo quel numero per decidere cosa modificare nel sito, un errore nel collegamento può diventare una spiegazione sbagliata del comportamento delle persone.
Un controllo oggi non ricostruisce ieri
Supponiamo, sempre come esempio, che le conversioni registrate scendano dopo un intervento sul sito. Potrebbe essere cambiata l’esperienza: un percorso meno chiaro, una pagina più lenta, un passaggio che non funziona. Potrebbe essere cambiata la rilevazione. Le due cose potrebbero anche essere successe insieme.
La prova nel browser serve a capire cosa accade adesso. Per spiegare il calo mi serve anche ricostruire da quando: quali eventi c’erano prima, quali modifiche sono state pubblicate, quali altri segnali si muovono nello stesso periodo.
Se oggi trovo un tag che non parte, ho trovato un difetto. Per dire che quel difetto spiega il calo di due mesi fa manca ancora un collegamento.
È una distinzione un po’ scomoda, perché una causa l’avevamo appena trovata e sembrava pure convincente.
Guardare anche da un’altra parte
La verifica può richiedere una fonte diversa. Un gestionale o un registro degli invii, quando sono disponibili, possono aiutare a confrontare le richieste ricevute con quelle misurate. Anche quel confronto va capito: periodi, definizioni, duplicati, richieste che arrivano da altri canali.
Per il traffico da Google, invece, posso affiancare Search Console ad Analytics. Omar Attia spiega nella sua guida a Search Console la differenza fra ciò che avviene nella ricerca e ciò che misuriamo sul sito.
Clic e sessioni non devono coincidere. Però, se cambiano in modi molto diversi, quella differenza può suggerire una verifica: quali pagine, quale periodo, quale sorgente, quali cambiamenti nella raccolta o nell’attribuzione? Da sola non identifica la causa.
Tre cose da separare prima di decidere
- Che cosa è successo nel sito: apertura del form, invio, risposta ricevuta.
- Che cosa è stato contato: evento, momento di attivazione, eventuali duplicati.
- Che cosa è arrivato davvero: richiesta nel sistema che la riceve e possibilità di ricostruirne il percorso.
Un evento di invio dimostra che è arrivato un contatto? Dipende da dove viene generato. Un click o un tentativo possono precedere una risposta fallita. Bisogna seguire il passaggio fino al sistema che riceve la richiesta.
Se il debugger funziona oggi, posso spiegare il calo di ieri? Il controllo descrive la configurazione osservata adesso. Per ricostruire un periodo precedente servono altre evidenze: cambiamenti, date, dati e condizioni di allora.
Dare un posto alle verifiche
Nel repository con cui lavoro sui dati insieme a un agente IA ho messo strumenti per interrogare le fonti, conservare i risultati e collegare le osservazioni alle evidenze.
Questa struttura serve anche a tenere separate frasi che nella conversazione rischiano di diventare equivalenti: «gli eventi registrati sono diminuiti», «arrivano meno richieste», «la pagina convince meno». La prima può essere un dato osservato; le altre richiedono altri controlli.
L’agente può aiutarmi a eseguire le interrogazioni e seguire i percorsi di verifica. Io porto il contesto tecnico e controllo le interpretazioni. Il sistema ha già prodotto un’analisi; questo esempio non descrive un nuovo caso eseguito.
Il lavoro può tornare alla pagina, al tracciamento o a entrambi. A volte resta una domanda aperta perché manca lo storico o una fonte con cui confrontare il dato. Almeno, a quel punto, so quale pezzo manca prima di cambiare qualcosa.