Negli ultimi anni il tracciamento è diventato una sorta di requisito implicito. Se il tracciamento di un sito invia eventi, registra conversioni e popola una dashboard, viene considerato correttamente misurato. In realtà, nella maggior parte dei casi, sta solo accumulando segnali.
Il punto non è se il tracking funziona, ma se permette di capire qualcosa. Molti sistemi registrano eventi formalmente corretti, ma privi delle informazioni necessarie per rispondere alle domande che contano davvero: quale form funziona, quale posizione converte meglio, quale percorso genera valore reale. I dati ci sono, ma non spiegano nulla.
Questo accade perché il tracciamento viene spesso progettato come una somma di eventi, non come un modello di lettura del comportamento. Si misura l’effetto finale (una thank you page, un caricamento, un click) invece della causa reale. Si usano nomi generici, si omettono parametri chiave, si rinuncia al contesto. Il risultato è un sistema che sembra ricco, ma è analiticamente povero.
Un esempio tipico è il form_submit senza form_id. L’evento esiste, le conversioni aumentano, ma tutte le compilazioni appaiono identiche. Non si distingue quale form è stato compilato, dove era posizionato, né quale porta lead di qualità. In assenza di queste informazioni, non si sta misurando un comportamento, si sta solo contando un’azione.
Questo articolo nasce proprio da qui. Analizzando configurazioni di tracking apparentemente corrette, emergono errori e leggerezze ricorrenti che trasformano il dato in rumore. Non si tratta di problemi tecnici, ma di scelte concettuali che rendono impossibile qualsiasi analisi seria, anche quando gli eventi arrivano regolarmente.
Eventi presenti, informazione assente
Uno degli errori più comuni nei sistemi di tracciamento è confondere l’esistenza di un evento con la presenza di una informazione. Un evento che arriva correttamente non è automaticamente utile. È utile solo se porta con sé abbastanza contesto da poter essere interpretato.
Molti tracciamenti si fermano al livello più superficiale: qualcosa è successo. Un form è stato inviato, un pulsante è stato cliccato, un acquisto è stato registrato. Ma manca sempre la stessa cosa: l’identità dell’azione. Chi, cosa, dove, in quale contesto.
Quando un evento non è accompagnato da parametri che lo descrivono, tutte le occorrenze diventano indistinguibili. Un form_submit vale l’altro, un click è uguale a qualsiasi altro click, una conversione non racconta nulla sul percorso che l’ha generata. Il dato esiste, ma non consente alcuna lettura.
Il problema non è la quantità di eventi, ma la loro ambiguità. Un sistema di misurazione efficace non si limita a dire che qualcosa è avvenuto, ma rende possibile capire che cosa è avvenuto esattamente e perché. Senza questa distinzione, qualsiasi analisi successiva diventa un esercizio di interpretazione arbitraria.
È in questo spazio che nascono molti dei problemi più gravi: dashboard apparentemente complete, report dettagliati, numeri coerenti nel tempo, ma impossibilità totale di collegare quei numeri a decisioni concrete. Quando gli eventi non hanno identità, i dati non possono guidare nessuna scelta.
Tracciare la conseguenza invece della causa
Un altro errore strutturale molto diffuso è tracciare ciò che avviene dopo un’azione, invece dell’azione stessa. È una scorciatoia comoda, ma concettualmente sbagliata.
Il caso più classico è la conversione registrata al caricamento di una pagina di conferma. Il sistema non intercetta l’evento reale (la submit di un form, la conferma di un ordine, l’esito di una chiamata API), ma una sua rappresentazione grafica. In quel momento, però, gran parte dell’informazione utile è già persa.
Quando si traccia la conseguenza:
non si hanno più i dati disponibili al momento dell’azione
non si può distinguere tra successo reale e semplice caricamento di una pagina
si espongono le conversioni a duplicazioni e falsi positivi
si perde qualsiasi possibilità di validazione o deduplicazione seria
Il problema è che la conseguenza non è un segnale affidabile, in particolare quando stiamo parlando di un evento di conversione: una thank you page può essere ricaricata dall’utente, salvata nei preferiti, aperta direttamente, o caricata più volte per motivi tecnici. In tutti questi casi il sistema registra una conversione che non corrisponde a nessuna azione reale.
Lo stesso schema si ripete negli ecommerce, quando l’evento di acquisto viene agganciato al caricamento della pagina di conferma invece che all’evento transazionale effettivo. Il dato sembra coerente finché non lo si confronta con il backend, momento in cui emergono discrepanze difficili da spiegare a posteriori.
Tracciare la causa significa intercettare l’azione nel punto in cui avviene, quando il contesto è ancora disponibile e l’evento è univoco.
Tracciare la conseguenza significa accettare un’approssimazione che, nel tempo, degrada la qualità dell’intero sistema di misurazione.
Ed è proprio questa differenza che separa un tracking pensato per funzionare da un tracking pensato per misurare.
Eventi tutti uguali, comportamenti diversi
Uno degli effetti più subdoli di un tracciamento povero di contesto è l’appiattimento dei comportamenti. Azioni diverse, compiute in momenti, luoghi e condizioni differenti, finiscono per essere registrate come se fossero la stessa cosa.
È il caso tipico degli eventi generici. Un form_submit senza form_id, un click senza posizione, una conversione senza origine. Dal punto di vista del sistema tutto è corretto, ma dal punto di vista dell’analisi tutto è indistinguibile.
Il problema non è solo non sapere quale evento performa meglio. È non poter nemmeno formulare la domanda. Se tutte le azioni sono registrate allo stesso modo, il sistema impedisce qualsiasi confronto, qualsiasi priorità, qualsiasi scelta informata.
Questo tipo di tracciamento produce report apparentemente ordinati, con numeri puliti e stabili nel tempo, ma completamente scollegati dalla realtà del sito. Non si vede quale elemento funziona, quale posizione converte, quale percorso accompagna l’utente verso un’azione significativa.
La conseguenza è che le decisioni vengono prese altrove. Non sui dati, ma sulle percezioni, sulle preferenze personali o su ipotesi non verificabili. Il tracciamento continua a funzionare, ma smette di essere uno strumento di supporto alle decisioni.
Quando eventi diversi vengono trattati come identici, il dato perde la sua funzione principale: distinguere. E senza distinzione non c’è analisi, solo accumulo.
Parametri mancanti e contesto perso
Un evento, da solo, dice pochissimo.
È il contesto che lo rende interpretabile.
Molti sistemi di tracciamento si limitano a registrare che qualcosa è accaduto, ma rinunciano a descrivere le condizioni in cui è avvenuto. Mancano parametri che permettano di capire dove si trovava l’utente, quale elemento ha attivato l’evento, in quale punto del percorso e con quale intento.
Il risultato è un dato che non può essere messo in relazione con nulla. Un evento senza posizione, senza tipo di elemento, senza relazione con la pagina o con il layout non consente di confrontare alternative né di individuare pattern. Tutte le interazioni vengono lette come se avvenissero in un vuoto.
Questo è particolarmente evidente quando lo stesso elemento viene riutilizzato in più contesti. Lo stesso form inserito in una landing, nel footer o in un popup produce comportamenti diversi, ma senza parametri che identifichino il contesto quei comportamenti vengono compressi in un unico numero.
Il problema non è non sapere quale contesto funziona meglio. È non poterlo sapere nemmeno in teoria, perché l’informazione necessaria non è mai stata raccolta. In questo scenario il dato non è incompleto, è strutturalmente cieco.
Un tracciamento che perde il contesto non è neutro. Influenza direttamente le decisioni, perché costringe a ottimizzare su segnali aggregati che nascondono le differenze invece di renderle visibili.
In molti casi questa perdita di contesto non è una scelta, ma una conseguenza. Chi si occupa del tracciamento spesso non ha una reale conoscenza di come funzionano HTML e JavaScript, e quindi non dispone degli strumenti concettuali per dialogare con gli sviluppatori per far adattare il sito alle proprie esigenze di tracking. Senza questa base diventa difficile anche solo immaginare quali informazioni potrebbero essere esposte, normalizzate o rese disponibili come parametri. Il tracciamento finisce così per adattarsi ai limiti percepiti del sito, invece di guidarne l’evoluzione in funzione delle decisioni che dovrebbe supportare.
Duplicazioni, ambiguità e falsi positivi
Anche quando un evento è ben definito e corredato da parametri, resta un problema spesso sottovalutato: capire se quell’evento rappresenta davvero un’azione unica e reale. In molti sistemi di tracciamento questa distinzione non esiste.
Eventi che dovrebbero verificarsi una sola volta vengono registrati più volte per motivi diversi. Un form può generare un evento al click del pulsante e uno alla submit, un acquisto può essere tracciato sia alla risposta di un’API sia al caricamento della pagina di conferma, una stessa azione può essere replicata a ogni refresh. Dal punto di vista tecnico tutto sembra funzionare, ma il dato perde affidabilità.
Il problema non è solo quantitativo. Una duplicazione introduce ambiguità. Se non è chiaro quando un evento rappresenta una nuova azione e quando è solo una ripetizione, diventa impossibile distinguere il comportamento reale dell’utente dal rumore generato dal sistema.
Questo porta a uno degli effetti più pericolosi del tracciamento mal progettato: i falsi positivi. Conversioni che non corrispondono a nessuna azione concreta, acquisti che non esistono, lead che non sono mai stati inviati. Il dato cresce, ma non perché il business stia andando meglio.
In assenza di meccanismi di controllo dello stato, deduplicazione o verifica della sequenza degli eventi, il sistema di misurazione smette di essere una fonte affidabile. E quando il dato non è affidabile, qualsiasi analisi successiva è solo un esercizio teorico.
Quando il tracciamento non supporta le decisioni
Tutti gli errori descritti finora hanno un tratto comune: producono dati che non possono essere usati per decidere. Gli eventi esistono, i numeri sono coerenti, i report si popolano, ma manca sempre il passaggio fondamentale tra informazione e azione.
Un sistema di tracciamento dovrebbe permettere di confrontare alternative, individuare pattern, verificare ipotesi. Quando questo non accade, il problema non è l’assenza di dati, ma la loro struttura. Eventi anonimi, contesto mancante, duplicazioni e ambiguità rendono impossibile capire cosa funziona davvero e cosa no.
In questi casi il tracciamento diventa decorativo. Serve a dimostrare che qualcosa è stato misurato, non a orientare una scelta. Le decisioni vengono prese altrove, spesso sulla base di percezioni, urgenze o abitudini, mentre i dati restano sullo sfondo come elemento di conferma a posteriori.
Il paradosso è che sistemi molto ricchi dal punto di vista tecnico finiscono per essere inutilizzabili sul piano strategico. Più eventi vengono raccolti, più diventa difficile distinguere i segnali che contano da quelli irrilevanti. Senza una progettazione che parta dalle decisioni da supportare, il tracciamento perde la sua funzione principale.
Misurare non significa registrare tutto.
Significa costruire un sistema che renda visibili le differenze rilevanti, nel momento in cui servono, per guidare scelte concrete. Quando questo non accade, il problema non è nel dato, ma nel modo in cui è stato pensato.
Conclusioni
Un sistema di tracciamento non va valutato in base al numero di eventi che raccoglie, ma alle domande a cui permette di rispondere. Quando eventi, parametri e contesto non sono progettati insieme, il risultato è un accumulo di dati che non guida nessuna decisione.
Gli errori descritti in questo articolo non sono eccezioni. Sono il risultato di un approccio che tratta il tracciamento come un adempimento tecnico invece che come un modello di lettura del comportamento. Si misura ciò che è facile intercettare, non ciò che è utile capire.
Il caso del form_submit senza form_id lo mostra in modo evidente. Il tracciamento esiste, le conversioni vengono registrate, ma il sistema non permette di distinguere quale form funziona, dove converte meglio e quale genera valore reale. Senza queste informazioni, ogni ottimizzazione diventa una supposizione.
Misurare significa scegliere: cosa tracciare, come descriverlo, quale contesto rendere visibile e quali eventi devono essere univoci. Significa progettare il dato prima di raccoglierlo, partendo dalle decisioni che dovrà supportare.
Quando questo lavoro viene fatto, il tracciamento smette di essere un insieme di segnali e diventa uno strumento di comprensione. Quando non viene fatto, anche il sistema più sofisticato resta solo una collezione di numeri.
FAQ rapide
Sì, è una situazione molto comune.
Molti sistemi di tracciamento sono tecnicamente corretti ma progettati per registrare eventi, non per supportare decisioni. Quando mancano contesto, parametri distintivi o controllo delle duplicazioni, i dati esistono ma non spiegano nulla di utile.
No.
Una misurazione efficace non dipende dalla quantità di eventi raccolti, ma dalla loro capacità di distinguere comportamenti rilevanti. Pochi eventi ben progettati sono molto più utili di decine di eventi generici.
Perché una thank you page rappresenta una conseguenza visiva, non l’azione reale.
Può essere ricaricata, aperta direttamente o generare duplicazioni. In questi casi il sistema registra conversioni che non corrispondono a nessuna azione effettiva, compromettendo l’affidabilità dei dati.
Sì, perché permettono di distinguere comportamenti diversi.
Senza parametri che identificano cosa è stato utilizzato e in quale contesto, tutte le azioni risultano identiche. In questo scenario non si misura il comportamento, si contano solo eventi.