import pandas as pd

HADI cycles: practical application

Il growth team accumula idee, ma poche diventano esperimenti con ipotesi chiare, metriche definite prima del lancio e una decisione presa dopo il risultato. Il ciclo HADI, da Hypothesis, Action, Data, Insight, dà a questo ritmo una struttura: non uno slogan, ma un ciclo di apprendimento misurabile. La lezione è tecnica, quindi conta capire cosa credi, cosa fai, quale dato osservi e quale decisione cambia dopo l’insight.

La logica controintuitiva del ciclo HADI

Il mondo del data science è pieno di progetti tecnicamente brillanti ma commercialmente irrilevanti: modelli predittivi con AUC del 95% che non vanno mai in produzione, dashboard complesse che nessuno consulta. Il ciclo HADI nasce come antidoto, spostando il focus dalla perfezione algoritmica all’impatto misurabile sul business. La sua logica è opposta a quella accademica tradizionale, che prevede una lunga fase di ricerca e sviluppo seguita da un “big bang” di rilascio. HADI si fonda sulla falsificabilità popperiana: il progresso non viene dalla conferma di ciò che sappiamo, ma dalla rapida invalidazione di ciò che crediamo di sapere.

Il ciclo si articola in quattro fasi sequenziali ma concettualmente interconnesse.

La prima è l’Hypothesis, la più critica e spesso la più trascurata. Un’ipotesi non è un’idea vaga, ma un’affermazione precisa, misurabile e falsificabile che lega una causa a un effetto. Una cattiva ipotesi è “miglioriamo le nostre email promozionali”. Un’ipotesi HADI-compatibile è: “Se modifichiamo l’oggetto delle email promozionali settimanali da un formato generico a uno personalizzato che include il nome del prodotto più visualizzato dall’utente negli ultimi 7 giorni, l’Open Rate aumenterà di 5 punti percentuali (dal 18% al 23%) e il Click-Through Rate di 2 punti percentuali (dal 3% al 5%) entro 14 giorni, senza impattare negativamente sull’Unsubscribe Rate (metrica di controllo)”. La formulazione contiene una leva, un risultato atteso quantificato, un vincolo e un orizzonte temporale.

La seconda è l’Action, cioè l’implementazione del minimo indispensabile per testare l’ipotesi. Non costruisci un motore di personalizzazione email completo. Scrivi uno script Python di 50 righe che estrae i dati di navigazione da un data warehouse come BigQuery, genera una lista di utenti e oggetti personalizzati, e la carica su una piattaforma di marketing automation come Braze o Customer.io per una singola campagna. L’obiettivo qui non è la scalabilità ma la velocità di apprendimento: l’azione deve essere robusta abbastanza da generare dati puliti e snella abbastanza da girare in giorni, non in mesi.

La terza è la fase Data, e la raccolta dati va progettata prima dell’azione. Questo implica definire un gruppo di controllo, che riceve l’email generica, e un gruppo di trattamento, che riceve quella personalizzata. La dimensione dei campioni si calcola a priori con la power analysis, per assicurarsi che l’esperimento abbia una probabilità sufficiente di rilevare l’effetto atteso, se esiste. Si definiscono le metriche primarie come Open Rate e CTR e quelle di controllo come Unsubscribe Rate, Conversion Rate e Average Order Value, per monitorare effetti collaterali imprevisti.

La quarta è la fase Insights, quella di sintesi, perché i dati non parlano da soli. L’analisi statistica, per esempio un test t di Student o un test Z per le proporzioni, dice se la differenza osservata tra i due gruppi è statisticamente significativa (p-value <0.05). L’insight però va oltre il numero. Se l’ipotesi è confermata, l’insight è “la personalizzazione a livello di prodotto nell’oggetto è una leva efficace per l’engagement”. Se è falsificata, potrebbe essere “la personalizzazione dell’oggetto non basta a muovere l’engagement, forse va personalizzato il corpo dell’email”. Un’ipotesi falsificata non è un fallimento, è un apprendimento a basso costo che previene un investimento sbagliato su larga scala.

Caso di studio 1: Netflix e l’artwork personalizzato

Netflix è forse l’organizzazione più emblematica costruita attorno alla sperimentazione continua. Ogni modifica all’interfaccia, all’algoritmo di raccomandazione o alla strategia di contenuto passa per un rigoroso A/B testing, che è l’incarnazione operativa del ciclo HADI. Un caso celebre e didattico è l’ottimizzazione delle immagini di anteprima dei contenuti.

Per anni ogni film o serie su Netflix aveva una singola immagine di copertina scelta dal marketing. Il team di prodotto ipotizzò invece che la preferenza per un’immagine fosse soggettiva e dipendesse dal background di visione dell’utente.

L’ipotesi: “Se personalizziamo l’artwork di un titolo mostrando un’immagine che riflette i gusti pregressi dell’utente, il tasso di interazione click-to-play per quel titolo aumenterà in modo statisticamente significativo per il segmento esposto all’artwork personalizzato”. Per il film “Good Will Hunting”, per esempio, a un utente che ha visto molte commedie romantiche si poteva mostrare l’artwork con Matt Damon e Minnie Driver, mentre a uno appassionato di drammi si mostrava quello con Robin Williams. L’obiettivo quantificato era un aumento del 5% del play rate sul titolo.

L’azione fu circoscritta. Il team di design creò da 3 a 5 artwork alternativi per una decina di titoli ad alto traffico, ciascuno taggato con metadati come attori, genere e tono emotivo. Un algoritmo semplice, dentro la piattaforma di A/B testing, associava i cluster di utenti (fan di commedie, amanti del thriller) all’artwork più pertinente e lo serviva casualmente a un sottogruppo, mentre il gruppo di controllo continuava a vedere l’immagine di default.

I dati raccolti per due settimane furono a livello di singola impressione, su quattro metriche chiave: il Take Rate, cioè la percentuale di volte in cui un utente riproduce il titolo dopo aver visto l’artwork; l’Aggregate View Time, il tempo di visione totale per variante; l’Impression-to-Play Conversion, il tasso di conversione dall’anteprima alla riproduzione; e una metrica di controllo, l’abbandono della sessione, per verificare che un artwork sbagliato non spingesse l’utente a chiudere l’app per frustrazione.

Gli insight superarono le aspettative. L’artwork personalizzato aumentava il tempo di visione di un titolo fino al 20-30% in alcuni casi. L’ipotesi fu confermata e l’impatto si rivelò più grande del previsto: l’immagine è una leva di engagement potente quanto il titolo o la sinossi. Questa serie di cicli HADI portò alla decisione strategica di investire in un sistema scalabile, oggi noto come Dynamic Creative Optimization, che personalizza in tempo reale milioni di artwork per oltre 200 milioni di utenti. L’effetto composto di migliaia di piccoli esperimenti ha consolidato il dominio di Netflix, riducendo il choice fatigue e aumentando la retention degli abbonati di svariati punti percentuali l’anno.

L’anatomia di un log HADI

Un singolo ciclo HADI è un esperimento. Una successione di cicli documentati è un motore di apprendimento istituzionale. Senza un sistema centralizzato per tracciare ipotesi, azioni, dati e insight, un’organizzazione ripete gli stessi errori e perde il valore cumulativo della sperimentazione. Il log HADI, gestito su Notion, Confluence o anche un Google Sheet strutturato, diventa la memoria storica del team di prodotto e data science.

Un log efficace non è un diario ma un documento che forza il rigore analitico. Ogni entry dovrebbe contenere campi standardizzati: un ID univoco del ciclo (per esempio MKTG-2024-013); l’owner o lo squad responsabile (Anna Rossi / Growth Team); le date di inizio e fine; l’ipotesi SMART nella sua formulazione completa; la metrica primaria che determina successo o fallimento (per esempio il Conversion Rate); le metriche guardrail per gli effetti collaterali negativi (latenza pagina, tasso di disiscrizione); il design dell’esperimento con gruppi, dimensione del campione, durata prevista, livello di significatività α e potenza statistica 1-β; il link all’azione, cioè al ticket Jira, al codice GitHub o alla configurazione su Optimizely; i risultati quantitativi grezzi, con uplift osservato (per esempio +7.2%), intervallo di confidenza ([4.1%, 10.3%]) e p-value (0.001); i risultati qualitativi, come feedback degli utenti; l’insight appreso in linguaggio naturale; e infine la decisione di prodotto.

La decisione conseguente ha tre esiti tipici. Il roll-out si applica quando l’ipotesi è confermata con impatto significativo e la modifica va al 100% degli utenti. L’iterate si sceglie quando i risultati sono inconcludenti o l’impatto è modesto, e si formula una nuova ipotesi per un ciclo successivo. Il kill arriva quando l’ipotesi è chiaramente falsificata, l’idea viene abbandonata e le risorse liberate per altre scommesse.

Per passare dalla raccolta dati all’analisi serve padroneggiare gli strumenti statistici di base. Questo è un esempio di script Python che un data scientist userebbe per analizzare un A/B test su un tasso di conversione, con pandas per i dati e scipy for statistical calculation.

from scipy.stats import norm

def analyze_ab_test_proportions(control_users, control_conversions, treatment_users, treatment_conversions, confidence_level=0.95):
    """
    Analizza i risultati di un A/B test per due proporzioni.
    Calcola il p-value usando un test Z e l'intervallo di confidenza per la differenza.
    """
    # Calcolo dei tassi di conversione
    p_control = control_conversions / control_users
    p_treatment = treatment_conversions / treatment_users

    # Calcolo della statistica Z
    p_pooled = (control_conversions + treatment_conversions) / (control_users + treatment_users)
    se_pooled = (p_pooled * (1 - p_pooled) * (1/control_users + 1/treatment_users))**0.5
    z_score = (p_treatment - p_control) / se_pooled

    # Calcolo del p-value (test a due code)
    p_value = 2 * (1 - norm.cdf(abs(z_score)))

    # Calcolo dell'intervallo di confidenza per la differenza
    diff = p_treatment - p_control
    se_diff = ((p_control * (1 - p_control) / control_users) + (p_treatment * (1 - p_treatment) / treatment_users))**0.5
    z_critical = norm.ppf(1 - (1 - confidence_level) / 2)
    ci_lower = diff - z_critical * se_diff
    ci_upper = diff + z_critical * se_diff
    
    # Stampa dei risultati
    print(f"--- Risultati A/B Test ---")
    print(f"Tasso Conversione Controllo: {p_control:.4f}")
    print(f"Tasso Conversione Trattamento: {p_treatment:.4f}")
    print(f"Uplift Assoluto: {diff:.4f}")
    print(f"Uplift Relativo: {(diff / p_control):.2%}")
    print(f"P-value: {p_value:.5f}")
    print(f"Intervallo di Confidenza al {confidence_level*100}% per la differenza: [{ci_lower:.4f}, {ci_upper:.4f}]")

    if p_value < (1 - confidence_level):
        print("\nRisultato STATISTICAMENTE SIGNIFICATIVO.")
    else:
        print("\nRisultato NON statisticamente significativo.")

# Esempio di utilizzo
# Dati da un ipotetico esperimento
control_users = 10150
control_conversions = 325
treatment_users = 10210
treatment_conversions = 388

analyze_ab_test_proportions(control_users, control_conversions, treatment_users, treatment_conversions)

Lo script è il motore della fase Insights: trasforma i dati grezzi in una chiara indicazione per la decisione finale.

Caso di studio 2: il growth hacking di Airbnb

Agli albori della sua storia, intorno al 2009, Airbnb era una startup promettente ma con una crescita anemica. Analizzando i dati, i fondatori notarono che gli annunci a New York performavano male. La qualità delle inserzioni era bassa, soprattutto a causa delle foto, spesso scattate con cellulari scadenti e in condizioni di luce povera. Da lì nacque uno dei cicli HADI più celebri della Silicon Valley.

L’ipotesi: “Se sostituiamo le foto amatoriali dei proprietari con fotografie professionali di alta qualità, la fiducia dei potenziali ospiti aumenterà, portando a un raddoppio delle notti prenotate per quegli annunci entro 30 giorni”. Audace, ma specifica e misurabile.

L’azione fu l’epitome del “fare cose che non scalano”. Invece di lanciare un programma complesso, i fondatori Brian Chesky e Joe Gebbia affittarono una macchina fotografica di alta gamma da 5000 dollari e andarono di persona, porta a porta, in una ventina di appartamenti a New York, offrendo un servizio fotografico professionale gratuito. Niente sistema di prenotazione, niente team di fotografi: solo i fondatori con una macchina fotografica. L’azione era insostenibile su larga scala, ma era il modo più veloce ed economico per raccogliere dati validi e testare l’ipotesi.

Il team definì un gruppo di trattamento, i circa 20 annunci con le nuove foto, e un gruppo di controllo, annunci simili nella stessa area con foto amatoriali. La metrica primaria era diretta: il revenue settimanale di ciascun annuncio, tracciato dalla loro piattaforma per le quattro settimane successive all’aggiornamento.

Gli insight furono immediati e dirompenti. Gli annunci con foto professionali raddoppiarono, in alcuni casi triplicarono, le prenotazioni settimanali, come ipotizzato. Il revenue medio passò da circa 200 a 400 dollari a settimana. L’ipotesi fu confermata in modo inequivocabile, e l’insight fu profondo: nel mercato della fiducia, la qualità della presentazione visiva non è un dettaglio ma un fattore critico di conversione. Quel ciclo, condotto con mezzi quasi artigianali, portò alla creazione dell’Airbnb Photography Program. L’azienda iniziò a reclutare fotografi freelance in tutto il mondo, differenziandosi da concorrenti come Craigslist e alimentando un ciclo virtuoso di crescita.

Costruire un motore di sperimentazione

Un’organizzazione matura non esegue cicli HADI in modo sporadico: costruisce un motore di sperimentazione sistematico. Questo significa passare dalla gestione del singolo ciclo alla gestione di un portfolio di esperimenti, e misurare le performance del motore stesso. Il successo non è più la vittoria di un singolo test, ma la velocità e l’impatto cumulativo dell’intero programma.

La gestione del portfolio di cicli HADI assomiglia a quella di un portafoglio di investimenti: non tutte le scommesse hanno lo stesso potenziale o lo stesso costo. Gli esperimenti possono essere classificati per costo e per impatto atteso, così da bilanciare poche scommesse grandi e rischiose con molti test piccoli e veloci che alimentano l’apprendimento continuo.

Workshop and Exercises

Lavora su un dataset reale. Se non hai accesso al data warehouse aziendale, usa dataset pubblici come Google Analytics Sample su BigQuery o il dataset E-Commerce di Kaggle.

Nel primo esercizio riproduci la query o il modello descritto, adattandolo al tuo dataset, e verifica che i risultati siano coerenti con le metriche attese: se il totale non quadra con una query di controllo, c’è un problema di grain. Nel secondo esercizio aggiungi una dimensione di analisi non coperta nella lezione, segmentando per paese, device, fascia oraria o coorte, e chiediti dove emergono pattern inattesi e cosa implicano per le decisioni. Nel terzo esercizio trasforma la query in una vista o in un modello dbt con test di integrità (unique, not_null), documenta le colonne e, se lo stack lo permette, configura un alert che notifichi quando la metrica esce da 2 deviazioni standard dalla media mobile.

Common Mistakes and How to Avoid Them

Anche gli analisti esperti cadono in trappole prevedibili. Conoscerle in anticipo riduce il tempo di debugging e aumenta la fiducia nei risultati.

Il primo errore è confondere correlazione e causalità: due metriche che si muovono insieme non implicano che una causi l’altra. Solo un A/B test o un’analisi controfattuale stabilisce causalità, e ogni dashboard di correlazione va presentata con un disclaimer esplicito. Il secondo è ignorare la stagionalità: confrontare novembre con dicembre senza correggere l’effetto festività produce insight fuorvianti, quindi usa un confronto anno su anno o una media mobile destagionalizzata quando la metrica ha componenti stagionali note. Il terzo è non validare il grain della query, la causa più comune di risultati errati: un JOIN che duplica righe, un filtro applicato troppo tardi, una finestra definita sul dataset sbagliato. Prima di interpretare qualsiasi numero, verifica il conteggio delle righe a ogni step.

Esempio operativo e checkpoint

Per consolidare il ciclo HADI, trattalo come una piccola prova di lavoro. Il team ipotizza che una sequenza di onboarding con prova sociale aumenti il primo acquisto. Con HADI la discussione diventa testabile: quale azione lanci, quale dato osservi, quale soglia decide se iterare e quale insight resta valido anche se il test non vince.

Observed evidence	Cautious interpretation	Recommended action
The number improves	Could be a real effect or normal variation	Look for comparison and segment
One segment changes more than others	The aggregated average hides a difference	Separate cohorts or use cases
Cost grows along with the result	Impact must be read on the margin	Estimate trade-offs and sustainability

Prima di presentare un risultato, prova a rispondere: quale decisione concreta dovrebbe migliorare, quale unità di analisi rende il problema misurabile, quale baseline eviti una lettura ingenua, quale errore tipico potrebbe cambiare la conclusione, e quale output consegneresti a uno stakeholder non tecnico. L’errore più comune resta usare HADI come etichetta invece che come processo: un grafico senza decisione, una metrica senza baseline, una conclusione senza l’assunzione che potrebbe invalidarla.

Operational Summary

Il ciclo HADI diventa utile quando produce una decisione più chiara, non quando aggiunge terminologia. Un’ipotesi precisa, un’azione minima, dati progettati prima e un insight onesto valgono più di un modello perfetto che nessuno usa. La forma corretta della lezione collega decisione, segnale, baseline, rischio e azione, e tutto il resto serve solo se rende più affidabile uno di questi passaggi.