Troppi dati, zero risposte: Quando l'Analisi Diventa Bias di Conferma

Una scena che ho visto decine di volte. Una call di allineamento con il team marketing di un eCommerce. Si apre Google Analytics. Poi Klaviyo. Poi la dashboard di Shopify. Poi Hotjar. Quattro schermate, centinaia di metriche, grafici che salgono e scendono. E qualcuno che dice: "I dati ci dicono che..."

Ecco, quella frase. Quel momento esatto. È il punto in cui, nella mia esperienza, le cose iniziano ad andare storte. Non perché i dati siano sbagliati. Ma perché nella maggior parte dei casi quei dati non stanno "dicendo" niente. Siamo noi che stiamo dicendo qualcosa a noi stessi, e stiamo usando i numeri per darci ragione.

È un meccanismo subdolo, perché ha l'aspetto della razionalità. Ha l'aspetto dell'analisi rigorosa. Ma sotto la superficie è qualcosa di molto diverso: è bias di conferma travestito da processo data-driven.

Meglio averli che non averli. Ma il problema non è averli.

Partiamo da un punto fermo: avere dati è sempre meglio che non averne. Dati profilanti, comportamentali, transazionali, qualitativi. Più ne hai, più hai materiale per capire chi sono i tuoi clienti, cosa fanno, dove si perdono. Questo non è in discussione.

Il problema nasce nel momento in cui passi dall'avere i dati al guardarli. Perché guardare i dati non è un atto neutro. Ogni volta che apri una dashboard, hai già in testa un'ipotesi, un sospetto, una narrativa. Magari non la formuli esplicitamente, magari non te ne accorgi nemmeno. Ma è lì. E orienta tutto quello che vedi.

"La homepage non converte." Lo pensi da settimane. Apri Analytics. Cerchi un dato che lo confermi. E lo trovi, perché in un dataset con centinaia di metriche c'è sempre qualcosa che cala, un segmento che sottoperforma, un giorno della settimana che sembra anomalo. Lo presenti al team come un'evidenza. In realtà è una conferma che sei andato a cercare.

Non è analisi. È un interrogatorio in cui il verdetto era già scritto.

La tortura dei dati: un vizio con un nome preciso

Quello che ho appena descritto ha un nome in statistica: data dredging, a volte chiamato anche p-hacking. È il processo per cui setacci un dataset abbastanza grande, per un tempo abbastanza lungo, guardandolo da un numero sufficiente di angolazioni, finché non trovi un pattern che sembra significativo. Non perché il pattern esista davvero, ma perché i numeri, se li torturi abbastanza, confessano qualsiasi cosa.

La frase è attribuita a Ronald Coase, premio Nobel per l'economia:

"If you torture the data long enough, it will confess to anything."

Nassim Nicholas Taleb, in "Fooled by Randomness", dedica pagine e pagine a questo meccanismo. La sua tesi centrale è che siamo biologicamente predisposti a trovare pattern nel rumore. È un tratto evolutivo: vedere una tigre dove c'è solo un'ombra è meno pericoloso che non vedere una tigre dove c'è davvero. Ma nel contesto delle decisioni basate su dati, questa predisposizione diventa una trappola. Ci fa vedere segnali dove c'è solo rumore statistico, e ci fa costruire narrative causa-effetto su correlazioni che non significano nulla.

Daniel Kahneman, in "Thinking, Fast and Slow", fornisce il framework cognitivo che spiega perché questo succede. Il nostro Sistema 1, il pensiero rapido e intuitivo, cerca costantemente conferme a quello che già crede. Non lo fa per malafede. Lo fa perché è progettato per essere efficiente, non accurato. E quando hai davanti 40 metriche, il Sistema 1 fa quello che sa fare meglio: ignora le 37 che contraddicono la tua ipotesi e si aggrappa alle 3 che la confermano. In un istante, hai la tua "evidenza".

Nate Silver, in "The Signal and the Noise", sposta il discorso sul piano pratico: il problema non è la quantità di dati disponibili, ma la nostra incapacità di distinguere il segnale dal rumore quando il volume dei dati cresce. Più metriche hai, più rumore hai. E più rumore hai, più è facile trovarci dentro quello che cerchi.

Il tiratore texano: la fallacia che governa il marketing

C'è una metafora che sintetizza perfettamente questo meccanismo. Si chiama Texas Sharpshooter Fallacy, la fallacia del tiratore texano. Funziona così: un uomo spara una raffica di colpi contro il muro di un fienile. Poi prende un pennarello e disegna il bersaglio intorno al gruppo di fori più concentrato. A quel punto si gira e dice: "Guarda che precisione."

È esattamente quello che succede quando un team marketing guarda i dati a posteriori senza una domanda formulata prima. Si accumulano numeri, si osservano i pattern che emergono, e si costruisce la narrativa intorno ai dati che confermano un'intuizione preesistente. Il bersaglio viene disegnato dopo lo sparo.

L'ho visto fare con Analytics: "Il bounce rate della pagina X è aumentato del 15% in questa settimana, quindi la modifica che abbiamo fatto non funziona." Peccato che nessuno avesse stabilito prima quale fosse la soglia di significatività, che il campione fosse di 200 visite, e che nessuno avesse controllato se il traffico di quella settimana era anomalo per altre ragioni.

L'ho visto fare con Klaviyo: "L'open rate di questo segmento è più alto del 3%, quindi dobbiamo mandare più email a questo cluster." Senza chiedersi se quel 3% fosse statisticamente significativo, se il segmento fosse abbastanza grande, o se l'open rate da solo, senza guardare click-through e conversioni, significasse qualcosa di utile per il business.

L'ho visto fare con Shopify: "Le vendite sono calate dopo che abbiamo cambiato il tema, quindi il tema vecchio era meglio." Ignorando che il cambio tema è coinciso con la fine di una campagna ads, un calo stagionale, e una modifica alla policy di spedizione.

In tutti questi casi, la struttura è identica. Prima la conclusione, poi la ricerca delle prove. Il contrario esatto del metodo scientifico.

Il paradosso dell'abbondanza: più dati hai, più disciplina ti serve

Ecco il punto centrale, e quello che trovo più controintuitivo: avere pochi dati ti costringe ad essere onesto sui limiti di quello che sai. Se hai solo il conversion rate complessivo e il fatturato mensile, non puoi costruirci sopra una narrativa sofisticata. Sai poco, e sai di sapere poco. E questa consapevolezza ti protegge.

Avere molti dati ti dà l'illusione di sapere tutto. Hai le coorti, i segmenti, i funnel, le heatmap, le session recording, i flussi con le metriche per step. Hai così tanto materiale che puoi costruire qualsiasi narrativa, e sarà sempre plausibile. E quella plausibilità è più pericolosa dell'ignoranza, perché ti toglie il dubbio. Ti fa sentire sicuro. E le decisioni peggiori sono quelle prese con una sicurezza infondata.

Questo non è un argomento contro la raccolta di dati. È un argomento a favore della disciplina nell'interpretarli. La differenza tra un professionista che usa i dati bene e uno che li usa male non è la quantità di dati a cui ha accesso. È il momento in cui formula la domanda.

Prima la domanda, poi i dati. Mai il contrario.

Il principio che ho fatto mio da anni, e che applico in ogni progetto di automazione e analisi che gestisco, è semplice nella formulazione e difficilissimo nella pratica: prima chiediti perché.

Prima di aprire una dashboard. Prima di lanciare un report. Prima di guardare qualsiasi numero. Formulare la domanda in modo esplicito. Scriverla. Condividerla con il team. E poi, solo poi, andare a cercare i dati che possono rispondere a quella domanda specifica.

Non "apriamo Analytics e vediamo come sta andando". Ma "la nostra ipotesi è che la nuova sezione di social proof nella pagina prodotto sta aumentando il tasso di aggiunta al carrello per i nuovi visitatori. Andiamo a verificare questo dato specifico, su questo segmento specifico, in questo arco temporale, e stabiliamo prima quale risultato considereremmo significativo."

La prima versione è un invito al bias di conferma. La seconda è un'analisi. La differenza sta tutta nel "prima".

Questo vale per l'analisi delle performance di un eCommerce, vale per l'interpretazione dei risultati di un flusso email in Klaviyo, e vale anche per l'A/B testing. Anzi, è esattamente il punto in cui il discorso sul testing come tic compulsivo e il discorso sul bias di conferma si incontrano: un A/B test senza un'ipotesi formulata prima non è un test. È una pesca a strascico nei dati, dove qualcosa abboccherà sempre.

Un caso concreto: il report settimanale che conferma tutto e non insegna niente

Faccio un esempio che vedo ripetersi continuamente. Un brand eCommerce ha un reporting settimanale. Ogni lunedì il team riceve un documento con decine di metriche: sessioni, conversion rate, AOV, revenue per canale, open rate email, click rate, unsubscribe rate, flussi attivi, campagne inviate, ROAS delle ads.

Tutti guardano i numeri. Qualcuno nota che l'open rate del flusso welcome è sceso dal 52% al 48%. Si accende una discussione. Si propone di cambiare l'oggetto. Qualcun altro nota che il conversion rate da mobile è più basso del 2% rispetto a desktop. Si propone di rivedere il layout mobile. Un terzo nota che le vendite del martedì sono più alte del venerdì. Si propone di spostare la campagna settimanale al martedì.

Ognuna di queste osservazioni sembra ragionevole. Ognuna è supportata da un dato reale. E ognuna, molto probabilmente, è rumore.

Lo è perché nessuna di queste osservazioni era una domanda formulata prima di guardare i dati. Sono tutte anomalie notate a posteriori in un dataset vasto, dove le anomalie sono la norma, non l'eccezione. Un open rate che fluttua di 4 punti da una settimana all'altra è fisiologico. Un delta del 2% tra mobile e desktop può dipendere da mille fattori. E le vendite del martedì vs. venerdì possono riflettere il calendario delle campagne ads, non un comportamento reale del cliente.

Ma il team agisce su questi dati. Cambia l'oggetto dell'email. Rivede il layout. Sposta la campagna. E la settimana dopo guarda i nuovi numeri per vedere se "ha funzionato". E il ciclo ricomincia. Più dati, più rumore, più decisioni basate su rumore, più dati nuovi da interpretare nel contesto di decisioni precedenti prese su dati che erano rumore.

È un loop che si autoalimenta. E non è data-driven. È data-addicted.

L'onestà estrema come antidoto

C'è un valore che considero non negoziabile nel mio lavoro: l'onestà. Non quella di facciata, non quella diplomatica. Quella scomoda. Quella che in una call ti fa dire "non lo sappiamo" quando tutti vorrebbero sentirsi dire "i dati confermano che".

Dire "non lo sappiamo" è l'atto più data-driven che esista. Perché riconosce i limiti del campione, la complessità del sistema, e la differenza tra correlazione e causalità. È il contrario del bias di conferma: è ammettere che i dati, in questo momento, con questo volume, con queste variabili confondenti, non ti stanno dando una risposta chiara. E che agire come se lo facessero è peggio che non agire.

Kahneman lo chiama "WYSIATI" - What You See Is All There Is: la tendenza a prendere decisioni basandosi solo sulle informazioni immediatamente disponibili, ignorando tutto ciò che non vediamo. Nel contesto di un eCommerce con 15 dashboard aperte, il paradosso è che WYSIATI colpisce ancora più forte: vedi talmente tanti dati che ti sembra di vedere tutto. E proprio quella sensazione di completezza è l'inganno.

Cosa fare, in concreto

Non sto proponendo di smettere di guardare i dati. Sto proponendo di cambiare l'ordine delle operazioni.

Primo: formula la domanda prima di aprire qualsiasi dashboard. Scrivila. Letteralmente. Se non riesci a scrivere in una frase cosa stai cercando di capire, non sei pronto per guardare i numeri.

Secondo: stabilisci prima cosa considereresti una risposta significativa. Non dopo aver visto i dati. Prima. Se stai verificando se una modifica ha impattato il conversion rate, decidi prima quale delta consideri rilevante e quale campione ti serve per fidarti del risultato.

Terzo: limita le metriche. Non guardare tutto. Guarda solo quello che è direttamente collegato alla tua domanda. Ogni metrica in più è un'opportunità in più per il tuo Sistema 1 di trovare un pattern dove non c'è.

Quarto: aspetta. Il buon lavoro richiede tempo. Due settimane di dati spesso non bastano. Un campione di 300 persone quasi mai basta. La fretta di trovare una risposta è il terreno più fertile per il bias di conferma.

Quinto: cerca di smentire la tua ipotesi, non di confermarla. Questo è il punto più difficile e più importante. Quando hai un'intuizione, non cercare i dati che la supportano. Cerca quelli che la contraddicono. Se non li trovi, forse la tua ipotesi regge. Se li trovi e li ignori, stai facendo il tiratore texano.

I dati non parlano. Noi parliamo per loro.

La prossima volta che qualcuno in una call dice "i dati ci dicono che...", prova a riformulare mentalmente la frase: "Noi stiamo dicendo che, e stiamo usando i dati per sostenerlo." Non è la stessa cosa. E riconoscere la differenza è il primo passo per fare analisi che servano davvero a qualcosa.

Avere tanti dati è un vantaggio enorme. Ma quel vantaggio si trasforma in un rischio nel momento in cui perdi la disciplina di formularti la domanda prima di andare a cercare la risposta. Perché se cerchi abbastanza a lungo, in un dataset abbastanza grande, troverai sempre qualcosa che ti dà ragione. E quel qualcosa, molto probabilmente, non significherà niente.

Prima chiediti perché. Poi guarda i numeri. Mai il contrario.

Vuoi un approccio strutturato all'analisi dei tuoi dati eCommerce e dei tuoi flussi Klaviyo, dove le domande vengono prima delle dashboard? Parliamone.