Nel libro Growth Engineering la crescita viene trattata come un sistema integrato, dove prodotto, dati, codice, esperimenti e responsabilità operativa fanno parte dello stesso disegno. Qui prendo quella prospettiva e la porto sul terreno pratico. Un test vale qualcosa solo se misura le persone che hanno davvero avuto la possibilità di cambiare comportamento.
Se includi anche utenti che la variante non l’hanno mai vista, l’effetto si diluisce. Il risultato sembra neutro anche quando l’intervento funziona benissimo per chi lo incontra.
Problema reale
Misurare tutti gli utenti in un test sul checkout è come valutare un cartello stradale interrogando pure chi da quella strada non è mai passato. Il punto è che si confonde l’assegnazione alla variante con l’esposizione vera.
Modello concettuale
Un buon sistema di growth non promette certezze. Riduce il costo dell’incertezza, e basta. Quello che serve è un meccanismo che acceleri il passaggio dal segnale alla decisione: ogni modifica va legata a un’ipotesi che si possa osservare e poi trasformare in una scelta, cioè rilasciare, iterare, fermare o approfondire.
Formalizzazione rigorosa
Lo schema operativo di base è questo:
- popolazione eleggibile
- evento di trigger
- assegnazione variante
- esposizione registrata
- analisi sulla popolazione corretta
Tenerlo semplice conta. Se il flusso non sta in cinque o sei passaggi leggibili, il rischio è automatizzare un processo che non hai ancora capito fino in fondo.
Esempio o caso studio
Un test sul messaggio di errore nel form di pagamento deve scattare solo per chi arriva a quel form, non per tutti i visitatori del sito. È l’unico modo per non diluire l’effetto e per imparare qualcosa che vale davvero.
Lab / esercizio
Livello base: Identifica in un esperimento esistente quale evento rappresenta il trigger effettivo e verifica se tutti gli utenti analizzati sono stati esposti.
Livello intermedio: Progetta un sistema di raccolta dati che separi chiaramente l’assegnazione dall’esposizione, aggiungendo un evento “experiment_exposed”.
Livello research-grade: Analizza un esperimento complesso con più segmenti e canali, assicurandoti che l’analisi consideri solo la popolazione realmente esposta e valutando l’impatto di eventuali diluizioni.
Dataset e materiali consigliati: Dataset di esperimenti A/B con log di eventi dettagliati, documentazione su metriche di exposure e trigger rate.
Errore tipico da evitare
Confondere assegnazione ed esposizione. Stare nel gruppo B non vuol dire aver visto B. Da questo errore nascono attività e grafici, ma il ciclo di apprendimento non ne guadagna nulla.
Quiz o checkpoint
- Perché è importante distinguere tra assegnazione e esposizione in un test?
- Quali sono i passaggi chiave per garantire che un esperimento misuri solo chi poteva essere influenzato?
- Quali metriche aiutano a monitorare la qualità dell’esposizione in un test?
Il punto
Con l’AI di mezzo, il growth fatto male diventerà solo più rumoroso. Generare idee e automazioni sarà banale; costruire sistemi che separano il segnale dal rumore resterà raro. Il growth engineer che conta non sarà quello più tecnico, ma quello che sa progettare le prove, i limiti, i feedback e la memoria operativa del processo. E la velocità vera non è partire subito: è non dover rifare tutto perché le ipotesi o i dati erano confusi. Registrare sempre un evento “experiment_exposed” separato dall’assegnazione è un dettaglio piccolo, ma è da lì che un sistema comincia a imparare sul serio.