Il contesto storico risale all'evoluzione dei modelli freemium da limiti statici (fissi 5GB nel cloud) a restrizioni dinamiche, adattative basate su Machine Learning. I classici approcci per valutare l'efficacia di tali interventi si scontrano con una fondamentale endogeneità: il sistema limita intenzionalmente gli utenti con alta propensione prevista alla conversione, creando un forte spostamento selettivo. I metodi iniziali di analisi correlazionale fornivano stime distorte, poiché ignoravano il confounding by indication, portando a una sovrastima dell'effetto del 200-300%.
La formulazione del problema richiede la misurazione del Local Average Treatment Effect (LATE) in situazioni in cui l'assegnazione del limite è correlata alla motivazione latente dell'utente. Il modello prevede la probabilità di conversione $P(conv|X)$ e assegna un limite quando $P > \tau$, rendendo i gruppi non comparabili per caratteristiche osservabili e non osservabili. Un confronto diretto tra utenti con limite e senza porta a overestimation, poiché il gruppo trattato è intrinsecamente "caldo" e pronto a pagare.
La soluzione dettagliata si basa sul Regression Discontinuity Design (RDD) sulla soglia $\tau$ del modello di punteggio. Nelle vicinanze della soglia (bandwidth $h$), l'assegnazione del limite è quasi casuale, poiché gli utenti con $P = \tau - \epsilon$ e $P = \tau + \epsilon$ sono statisticamente indistinguibili. Viene costruita una regressione continua dell'outcome sul punteggio di punteggio con la stima del salto (jump) nel punto $\tau$. Per aumentare la precisione, si applica il Causal Forest per stimare l'eterogeneità dell'effetto, mentre l'implementazione graduale utilizza Difference-in-Discontinuities per controllare le tendenze temporali. Alternativamente, è possibile applicare il Inverse Propensity Weighting (IPW) con stima del propensity score attraverso Random Forest, ma questo richiede la condizione di unconfoundedness, che raramente viene completamente soddisfatta.
Problema
In un prodotto B2B SaaS per la gestione delle attività è stato implementato un limite dinamico sul numero di progetti attivi per account gratuiti. Un modello ML ha analizzato oltre 50 caratteristiche comportamentali e ha bloccato la creazione di nuovi progetti, prevedendo una probabilità di conversione superiore a 0.75. Il team di prodotto ha osservato un aumento della conversione del 40% tra gli utenti "limitati", ma non è stato in grado di separare l'effetto del limite dall'auto-selezione degli utenti motivati. Inoltre, il divieto totale sui limiti per il test era impossibile, poiché ciò avrebbe comportato una perdita di $200K MRR al mese di esperimento.
Opzione 1: Confronto ingenuo con dati storici
Confrontare la conversione degli attuali utenti con limite contro una coorte risalente a due mesi prima dell'implementazione della funzionalità. Vantaggi: richiede minimi costi infrastrutturali, valutazione rapida senza modifiche tecniche. Svantaggi: ignora completamente la stagionalità (la diminuzione delle interazioni post-natalizie), la tendenza generale alla crescita della conversione (il prodotto stava diventando più maturo) e l'effetto novità; fornisce una stima distorta verso l'alto del 35-40% a causa del selection bias.
Opzione 2: Classico A/B test con disattivazione del modello ML
Disattivare casualmente l'assegnazione di limiti per il 15% degli utenti, consentendo loro di utilizzare il prodotto senza limiti indipendentemente dal punteggio. Vantaggi: standard d'oro della causalità, misurazione diretta del Average Treatment Effect (ATE). Svantaggi: categoricamente respinto dal C-level a causa del rischio di perdita di utenti "caldi", che nel gruppo di controllo non riceveranno il trigger per la conversione; crea un significativo costo opportunità e conflitti etici (perché ad alcuni consentiamo tutto e ad altri no).
Opzione 3: Regression Discontinuity Design con approccio ibrido
Utilizzare la soglia naturale del punteggio (0.75) come punto di discontinuità, confrontando gli utenti con probabilità di conversione 0.74 e 0.76 come gruppi randomizzati localmente (~5000 utenti nella finestra di ±0.05). Aggiungere il Synthetic Control Method per le regioni in cui l'implementazione è stata posticipata di un mese. Vantaggi: conserva la logica di business per il 95% degli utenti; fornisce una stima non distorta dell'effetto locale (LATE) per gli utenti "borderline"; consente di utilizzare la variazione naturale senza compromettere i ricavi. Svantaggi: richiede un campione ampio vicino alla soglia (>2000 osservazioni); la stima è applicabile solo a un sottogruppo con $P(conv) \approx 0.75$, invece che all'intera popolazione; sensibile alle manipolazioni della soglia (richiede il McCrary test sulla densità della distribuzione).
Soluzione scelta e risultato
È stata scelta la RDD con larghezza ottimale della finestra secondo il metodo Calonico-Cattaneo-Titiunik (CCT bandwidth), integrata con Causal Forest per identificare le sub-populazioni con effetti negativi. L'analisi ha rivelato che un limite rigido conferisce +12% di conversione per gli utenti "medi" (intorno alla soglia), ma -8% di retention per power users (alto engagement, ma punteggio leggermente sotto la soglia). Sulla base di questo è stato implementato un modalità ibrida: limiti soft (solo avviso) per power users, limiti rigidi per gli utenti medi. Il risultato finale: aumento della conversione dell'8% mantenendo la retention a 30 giorni al 96% del valore di base, portando ulteriori $450K ARR trimestrali senza abbandono degli utenti chiave.
Come distinguere l'effetto del limite stesso dall'effetto di "promemoria" (reminder effect) sulla versione a pagamento?
I candidati spesso interpretano l'aumento della conversione come risultato solo della restrizione finanziaria, ignorando che la notifica stessa del limite agisce come un punto di contatto di marketing. Per isolare è necessario un gruppo di controllo aggiuntivo con "morbido" avviso (solo informazioni sul premium senza bloccare la funzione) o analizzare il tempo trascorso tra la visualizzazione del limite e la conversione. Se la conversione avviene istantaneamente (entro un'ora) è probabile che si tratti di un reminder effect, se avviene dopo 3-7 giorni dopo diversi tentativi di superare il limite, questo è l'effetto reale della restrizione. È possibile utilizzare anche una variabile strumentale sotto forma di latenza tecnica nella visualizzazione della notifica come variazione casuale nell'intensità del promemoria, applicando una regressione 2SLS.
Come considerare gli effetti di rete nei prodotti di squadra (Notion, Figma), dove la restrizione di un utente influisce sulla collaborazione dei colleghi?
In B2B SaaS una restrizione per un membro del team crea spillover effects: i colleghi possono aggregare le risorse in un solo account o migrare a un concorrente. Il classico RDD ignora questi effetti esterni, violando la SUTVA (Stable Unit Treatment Value Assumption). La soluzione è un cluster-RDD a livello di team/workspace, dove il trattamento è definito dalla proporzione di utenti "limitati" nel team, o l'uso di two-stage least squares (2SLS) con il numero di vicini limitati nel grafo di rete come strumento. È importante misurare la violazione attraverso l'analisi dell'attività di rete (network adjacency matrix) tra utenti con diversi status di limite, testando l'ipotesi di homophily nei team.
Come separare l'effetto reale della restrizione di una funzione specifica dal cambiamento dell'utilizzo verso funzioni meno preziose (substitution bias)?
Gli utenti, di fronte a un limite sulla funzione A, possono migrare a funzione B (ad esempio da tabelle a documenti di testo), creando l'illusione di un'alta retention, ma degradando effettivamente la product stickiness e la depth of feature adoption. Per la misurazione è necessaria un'analisi della Shannon entropy dell'uso delle funzioni (misurazione della diversità d'uso) o dell'analisi dei dati composizionali (CODA). Se l'entropia diminuisce dopo la restrizione, significa che si è verificata la cannibalizzazione all'interno del prodotto. La politica ottimale dovrebbe massimizzare non solo la conversione, ma il LTV atteso, tenendo conto dei cambiamenti nei modelli di utilizzo, il che richiede una modellazione attraverso il Markov Decision Process (MDP) o contextual bandit con una funzione di ricompensa che tiene conto della profondità di adozione delle funzionalità e della velocità di engagement, e non solo del fatto della conversione.