HADI cycles: applicazione pratica

La tesi del ciclo HADI è semplice: la crescita non si pianifica, si sperimenta. Le ipotesi si testano su tabelle di dati, con test statistici classici e senza reti neurali, e ogni ciclo trasforma un’idea in ipotesi falsificabile, azione minima, dati con controllo e insight che decide roll-out, iterazione o stop. Il progresso non viene dalla conferma di ciò che sappiamo, ma dalla rapida invalidazione di ciò che crediamo di sapere.

Che cos’è il ciclo HADI

Il ciclo HADI trasforma un’idea di crescita in ipotesi falsificabile, azione minima, dati con controllo e insight che decide roll-out, iterazione o stop.

La procedura in cinque passaggi

Ecco la sequenza che seguiamo per ogni ciclo, dal primo esperimento al centesimo.

1. Scrivi ipotesi con leva, effetto quantificato, vincolo e orizzonte temporale.
2. Lancia l’azione minima che genera dati puliti in giorni, non mesi.
3. Raccogli dati con controllo, potenza statistica e metriche di guardrail.
4. Calcola significatività, intervallo di confidenza ed effetti collaterali.
5. Decidi tra roll-out, iterazione e stop con soglie scritte prima del test.

La logica del ciclo HADI

Il mondo del data science è pieno di progetti tecnicamente brillanti ma commercialmente irrilevanti: modelli predittivi con AUC del 95 per cento che non vanno mai in produzione, dashboard complesse che nessuno consulta. Il ciclo HADI nasce come antidoto e sposta 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 rilascio unico. HADI si fonda sulla falsificabilità: 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 è migliorare le email promozionali. Un’ipotesi HADI-compatibile è: se modifichiamo l’oggetto delle email settimanali da formato generico a personalizzato con il prodotto più visto negli ultimi 7 giorni, l’Open Rate sale di 5 punti dal 18 al 23 per cento e il CTR di 2 punti dal 3 al 5 per cento entro 14 giorni, senza peggiorare l’Unsubscribe Rate come metrica di controllo. La formulazione contiene leva, risultato atteso quantificato, vincolo e orizzonte temporale.

La seconda è l’Action, cioè l’implementazione del minimo indispensabile per testare l’ipotesi. Non costruisci un motore di personalizzazione completo. Scrivi uno script di 50 righe che estrae i dati di navigazione da un warehouse come BigQuery, genera lista utenti e oggetti personalizzati, e la carica su Braze o Customer.io per una singola campagna. L’obiettivo 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 o un test Z per proporzioni, dice se la differenza osservata tra i due gruppi è statisticamente significativa con valore p minore di 0.05. L’insight però va oltre il numero. Se l’ipotesi è confermata, l’insight è che la personalizzazione a livello di prodotto nell’oggetto è una leva efficace per l’engagement. Se è falsificata, potrebbe essere che la personalizzazione dell’oggetto non basta e 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 è l’organizzazione più emblematica costruita attorno alla sperimentazione continua. Ogni modifica all’interfaccia, all’algoritmo di raccomandazione o alla strategia di contenuto passa per A/B testing, che è l’incarnazione operativa del ciclo HADI. Un caso celebre è l’ottimizzazione delle immagini di anteprima dei contenuti.

Per anni ogni film o serie 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 fu: se personalizziamo l’artwork mostrando un’immagine che riflette i gusti pregressi, il tasso click-to-play aumenta in modo significativo per il segmento esposto. Per il film Good Will Hunting, a un utente con molte commedie romantiche si mostrava l’artwork con Matt Damon e Minnie Driver, mentre a un appassionato di drammi quello con Robin Williams. L’obiettivo quantificato era un aumento del 5 per cento del play rate.

L’azione fu circoscritta. Il team creò da 3 a 5 artwork alternativi per una decina di titoli ad alto traffico, ciascuno taggato con attori, genere e tono emotivo. Un algoritmo semplice associava i cluster di utenti all’artwork più pertinente e lo serviva a un sottogruppo, mentre il controllo vedeva l’immagine di default.

I dati raccolti per due settimane furono a livello di singola impressione, su Take Rate, tempo di visione totale, conversione da anteprima a riproduzione e abbandono sessione come metrica di controllo. Gli insight superarono le aspettative. L’artwork personalizzato aumentava il tempo di visione fino al 20-30 per cento in alcuni casi. L’ipotesi fu confermata e portò alla Dynamic Creative Optimization, che personalizza milioni di artwork per oltre 200 milioni di utenti.

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 un foglio 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 contiene ID univoco come MKTG-2024-013, owner e squad, date di inizio e fine, ipotesi SMART completa, metrica primaria, metriche guardrail, design con gruppi, campione, durata, significatività e potenza, link a ticket e codice, risultati con uplift osservato come 7.2 per cento, intervallo di confidenza e p-value, feedback qualitativi, insight in linguaggio naturale e 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 per cento 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.

Verdetto: roll-out sopra soglia con guardrail stabili, iterazione su segnale debole, stop netto su falsificazione senza appelli.

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 per il calcolo statistico.

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

Intorno al 2009 Airbnb era una startup promettente ma con crescita anemica. I fondatori notarono che gli annunci a New York performavano male per foto scadenti, scattate con cellulari e luce povera. Da lì nacque uno dei cicli HADI più celebri.

L’ipotesi fu: se sostituiamo le foto amatoriali con fotografie professionali, la fiducia aumenta e le notti prenotate raddoppiano entro 30 giorni. Audace, ma specifica e misurabile.

L’azione fu l’epitome del fare cose che non scalano. I fondatori affittarono una macchina da 5000 dollari e andarono porta a porta in una ventina di appartamenti a New York, offrendo un servizio fotografico gratuito. Niente sistema di prenotazione, niente team: solo i fondatori con una macchina fotografica. L’azione era insostenibile su larga scala, ma era il modo più veloce per raccogliere dati validi.

Il team definì un gruppo di trattamento, i circa 20 annunci con nuove foto, e un controllo di annunci simili con foto amatoriali. La metrica primaria era il revenue settimanale per annuncio nelle quattro settimane successive.

Gli insight furono immediati. Gli annunci con foto professionali raddoppiarono, in alcuni casi triplicarono, le prenotazioni. Il revenue medio passò da circa 200 a 400 dollari a settimana. L’ipotesi fu confermata e nacque l’Airbnb Photography Program, con fotografi freelance in tutto il mondo.

Costruire un motore di sperimentazione

Un’organizzazione matura non esegue cicli HADI in modo sporadico: costruisce un motore 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. Gli esperimenti si classificano per costo e impatto atteso, bilanciando poche scommesse grandi con molti test piccoli e veloci.

Errori frequenti e come evitarli

Il primo errore è confondere correlazione e causalità: due metriche che si muovono insieme non implicano che una causi l’altra. Solo un test con controllo stabilisce causalità. Il secondo è ignorare la stagionalità: confrontare novembre con dicembre senza correggere l’effetto festività produce insight fuorvianti. Usa quindi un confronto anno su anno o una media destagionalizzata. Il terzo è non validare il grain della query, la causa più comune di risultati errati. Un JOIN che duplica righe, un filtro tardivo o una finestra sul dataset sbagliato invalidano ogni metrica a valle.

Un caso che fa riflettere: Airbnb

Nel 2009 i fondatori di Airbnb notarono che gli annunci di New York con foto amatoriali frenavano le prenotazioni. Con una macchina fotografica da 5000 dollari fotografarono di persona circa 20 appartamenti come gruppo di trattamento. Nelle quattro settimane successive quegli annunci raddoppiarono le prenotazioni, in alcuni casi triplicandole, con revenue medio passato da circa 200 a 400 dollari a settimana. Il test validò il Photography Program globale contro concorrenti come Craigslist.

Domande per l’autoverifica

1. Quale ipotesi lega leva, effetto quantificato e orizzonte temporale?
2. Quale azione minima genera dati puliti in giorni senza scalare?
3. Quale metrica di guardrail blocca un roll-out con effetti collaterali?
4. Quale soglia separa roll-out, iterazione e stop dopo il test?