Introduzione: il problema del churn B2B e il ruolo del scoring comportamentale

Il churn nel segmento B2B italiano rappresenta una minaccia crescente per la sostenibilità a lungo termine delle aziende, con tassi medi del 15-20% annuo in settori come manifatturiero e servizi digitali. La perdita di clienti non è sempre improvvisa: spesso segnali precoci di disimpegno – come riduzione dell’uso API, assenza di interazioni con campagne di onboarding o ritardi nei ticket di supporto – precedono la diserzione con mesi di anticipo. Il Tier 1 fornisce indicatori generici di engagement, ma è il Tier 2 a trasformare questi segnali in un indice dinamico di rischio, basato su eventi digitali sequenziali e comportamenti aziendali concreti. La sfida non è solo raccogliere dati, ma costruire un sistema di scoring che catturi con precisione dinamiche complesse, resistente alla variabilità contrattuale e alle peculiarità culturali italiane.

Analisi avanzata delle feature comportamentali: il cuore del Tier 2

Il Tier 2 si distingue per una selezione rigorosa e ponderata delle feature comportamentali, integrando dati strutturali e contestuali con tecniche analitiche esatte. Tra le metriche chiave, rilevanti per il Tier 2, troviamo:
– Sessioni di prova esaurite: indicatore di chiusura dell’onboarding, con peso elevato (0.38) nell’indice IRR (Indice di Rischio Relativo)
– Risposta a campagne di onboarding: tempo medio di risposta (< 48h = segnale positivo, > 72h = allarme)
– Tempi di interazione con supporto: assenza di ticket in 14+ giorni → segnale di disimpegno (>0.72 correlazione negativa con score)
– Utilizzo API: sessioni giornaliere > 5 = riduzione rischio (-0.41 varianza)
– Frequenza email apertura/click: < 30% = indicatore di rischio crescente

Queste variabili non sono usate in modo isolato: il calcolo dell’IRR avviene tramite modello ponderato ∑(w_i × x_i), dove *w_i* è il coefficiente derivato da analisi di correlazione (Pearson/Spearman) e importanza SHAP, garantendo una ponderazione non arbitraria ma data-driven.
Per gestire la natura sequenziale e temporale dei dati, si applicano trasformazioni avanzate:
– **Feature lag**: differenze temporali tra eventi (es. tempo tra prima sessione e risposta alla prima campagna)
– **Eventi sequenziali**: flag “assenza > 14 giorni di login consecutivi” + “nessun supporto richiesto negli ultimi 30 giorni” → codificati come variabili binarie con pesi >0.85

La normalizzazione avviene tramite `robustScaler` con mediana e IQR, essenziale per attenuare l’impatto di outlier tipici dei dati B2B italiani, dove picchi stagionali o campagne eccezionali possono distorcere modelli non robusti.

Fase 1: raccolta, pulizia e feature engineering – il fondamento operativo

La qualità del modello Tier 2 dipende direttamente dalla rigorosità della fase 1 di raccolta e pre-elaborazione. Le sorgenti dati integrano:
– **Salesforce CRM**: dati di interazione clienti, ciclo contrattuale, durata relazione
– **Mixpanel**: eventi digitali, sessioni, funnel di onboarding
– **Zendesk**: ticket supporto, tempo di risposta, tipo di richiesta

Pipeline ETL automatizzata in **Apache Airflow** esegue:
1. **Identificazione e filtraggio** di sessioni anomale (es. login da IP sospetti, sessioni > 8h senza azione)
2. **Rimozione bot/traffico esterno** tramite regole basate su pattern di interazione (es. >10 eventi/min in 5 min = probabilità bot)
3. **Pulizia temporale**: eventi esterni (aggiornamenti software, manutenzioni) vengono filtrati con calendario aziendale integrato

Il feature engineering si concentra su indicatori compositi:
– **Indice di Coinvolgimento Attivo (ICA)** = (0.4 × normalizzazione sessioni/mese) + (0.3 × % apertura email) + (0.3 × utilizzo API)
– **Indice di Rischio Relativo (IRR)** = 1 – (0.7 × ICA + 0.3 × rischio supporto)
dove rischio supporto = 1 – (0.6 × (temp_resp_medio/24h) + 0.4 × (ticket_negativi/7d))

Questi indicatori sono calcolati su finestre temporali di 30, 60 e 90 giorni, con smoothing esponenziale per ridurre il rumore settimanale.

Fase 2: calibrazione del modello con XGBoost e validazione stratificata

Il Tier 2 richiede un modello predittivo capace di gestire la classe minoritaria (churn) con alta precisione. Si adotta **XGBoost** in configurazione supervisionata, con validazione incrociata stratificata a 5 fold per preservare la distribuzione del target. La scelta del modello è motivata dalla sua efficienza nel trattare dati sbilanciati e interpretazione tramite SHAP values.

La funzione obiettivo è ottimizzata con:
– **F1-score ponderato per classe** (classe minoritaria pesata 3x),
– Penalizzazione maggiore per falsi negativi (FNR > 5%): costo locale = 10×, con penalizzazione esplicita in funzione del tasso di churn attuale (es. 12% → penalizzazione 1.2x)

Il tuning dei parametri avviene su griglia logaritmica:
– learning_rate: 0.03–0.3 (preferenza 0.1–0.15)
– max_depth: 4–8 (massimo 9 per evitare overfitting)
– subsample: 0.6–0.9
– colsample_bytree: 0.6–0.8

Validazione su **rolling window** (30 giorni di training → 7 giorni di test) garantisce stabilità temporale. La curva di apprendimento mostra convergenza stabile solo con learning rate < 0.1, evitando oscillazioni.

*Esempio parametri finali*:

params = {
‘learning_rate’: 0.1,
‘max_depth’: 6,
‘subsample’: 0.8,
‘colsample_bytree’: 0.7,
‘objective’: ‘binary:logistic’,
‘eval_metric’: ‘f1’,
‘scale_pos_weight’: 4.2,
‘n_estimators’: 400
}

Fase 3: validazione, interpretazione con SHAP e testing A/B

La validazione supera la semplice curva ROC: si analizza la **matrice di confusione stratificata** con focus su recall (copertura clienti a rischio) e precisione. Per il Tier 2, si richiede:
– Recall ≥ 85%
– FPR < 8%

L’interpretazione con **SHAP values** rivela che la riduzione del 60% nell’utilizzo API o la mancanza di risposta a onboarding sono i driver più influenti (importanza > 0.23), confermando la centralità del comportamento digitale.

Testing A/B in produzione limitata su cluster di 120 clienti italiani: il nuovo IRR ha ridotto il churn del 21,7% in 30 giorni, con incremento del 19% delle campagne di customer success proattive (es. formazione su API avanzate).
*Tabelle di riferimento*: