Introduzione: la dimensione temporale nel customer journey come chiave decisiva per il churn prediction

Nel panorama digitale italiano, dove il customer journey si evolve rapidamente e l’esperienza utente è il fattore differenziante, la segmentazione basata esclusivamente su fasi statiche risulta insufficiente per identificare tempestivamente il rischio di churn. La dimensione temporale – ovvero il “quando” degli eventi nel percorso utente – emerge come un indicatore critico, capace di rivelare pattern comportamentali invisibili con approcci tradizionali. Questo approfondimento, sviluppatosi a partire dalle fondamenta della segmentazione temporale distinti nel Tier 1, esplora metodologie avanzate per identificare “momenti critici” nel ciclo utente, costruire segmenti dinamici e integrare analisi temporali nelle pipeline di predizione, con particolare riferimento al settore dei servizi digitali italiani, tra streaming, telemedicina e piattaforme di e-commerce.

1. Fondamenti della segmentazione temporale nel Customer Journey

La segmentazione temporale nel customer journey non si limita a taggare “login”, “pagina vista”, “acquisto” con timestamp UTC. Deve essere precisa, contestualizzata e sensibile al comportamento sequenziale. Ogni fase – dalla prima interazione fino alla disconnessione – deve essere arricchita con metadati temporali dettagliati, tra cui: intervallo tra eventi consecutivi, durata sessioni, caduta percentuale di attività settimanale e ritmo di interazione.

> “Un evento non è solo un click: è il momento in cui l’utente si ferma, ripensa o si disconnette. Il tempo tra azioni è spesso più rivelatore del singolo clic.”
> — Analisi interna piattaforme italiane, Q2 2024

Per mappare con accuratezza il percorso temporale, è essenziale implementare un sistema di event tracking con timestamp in UTC, convertiti localmente in CET/CEST per garantire coerenza in un contesto geograficamente frammentato come l’Italia. Gli eventi devono essere arricchiti con meta-dati temporali espliciti:
– `evento`: nome semantico (es. “sessione_iniziale”, “pagina_contatto”, “acquisto_confermato”)
– `timestamp_utc`: preciso al millisecondo
– `durata_sessione`: tempo tra eventi consecutivi (es. login → pagina vista)
– `intervallo_ultimo_evento`: tempo trascorso dall’ultimo evento positivo (es. acquisto)

Questi dati, raccolti da web, app mobile e API di backend, alimentano sistemi CRM come Segment e piattaforme di analytics come Tealium, garantendo una visione unificata e temporally sound del comportamento utente.

2. Tier 2: Segmentazione temporale avanzata nel journey analytics

Il Tier 2 introduce una segmentazione dinamica e contestualizzata, che va oltre i cluster statici per considerare il ritmo e la sequenza temporale degli eventi. La chiave sta nel definire intervalli temporali variabili – non solo 7, 14, 30 giorni, ma finestre calcolate in base alla frequenza d’uso del servizio – e applicare tecniche di decomposizione della serie temporale per isolare trend, stagionalità e rumore.

Fase 1: Estrarre e pulire i dati temporali
– Normalizzare tutti i timestamp in UTC con offset CET/CEST
– Eliminare duplicati e correggere anomalie (es. sessioni >24h senza azione)
– Imputare dati mancanti con interpolazione lineare o modelli predittivi basati su comportamento storico

Fase 2: Generare feature temporali avanzate
– `timeSinceLastLogin`: tempo ★ tra login consecutivi (in ore/minuti)
– `session_interval_avg`: intervallo medio tra eventi di sessione
– `decay_rate_sessione`: % calo sessioni settimanali rispetto alla settimana precedente
– `tempo_caduta_engagement`: % assenza di interazione in 7 giorni consecutivi

Fase 3: Clusterizzare con approcci temporali
– Applicare **K-means su vettori temporali**, usando feature come media mobile di sessioni, varianza inter-sessione e decay rate
– Validare cluster con analisi di coorte temporale: confrontare tassi di churn tra gruppi definiti per periodo di acquisizione (Q1 vs Q2 2024)
– Adottare soglie dinamiche per il “momento critico” di disconnessione

Fase 4: Implementazione tecnica con BigQuery
— Materialized view: aggregazione sessioni per utente con finestre temporali scorrevoli
WITH windowed_sessions AS (
SELECT
user_id,
event_timestamp_utc,
CASE WHEN event = ‘login’ THEN ‘session_start’ ELSE event END AS event_type,
CASE WHEN event = ‘logout’ THEN TIMESTAMPDIFF(MINUTE, session_start, event) ELSE 1000 END AS session_duration
FROM
user_events
WHERE
event_timestamp_utc >= ‘2024-01-01T00:00:00Z’
ORDER BY
user_id, event_timestamp_utc
),
feature_engine AS (
SELECT
user_id,
time_since_last_login,
avg_inter_session_interval,
decay_rate_sessione,
caduta_engagement_7d
FROM (
SELECT
user_id,
event_timestamp_utc,
CASE WHEN event = ‘login’ THEN
NTILE(7) OVER (ORDER BY event_timestamp_utc ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS login_bucket
END AS login_bucket,
session_interval_avg,
AVG(session_duration) OVER (PARTITION BY user_id ORDER BY event_timestamp_utc ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS avg_session_interval,
EXP(0.1 * (CASE WHEN session_duration < 60 THEN 2 ELSE 0 END)) AS decay_rate_sessione,
SUM(CASE WHEN decay_rate_sessione < 0 THEN 1 ELSE 0 END) OVER (PARTITION BY user_id ORDER BY event_timestamp_utc ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) / COUNT(*) OVER (PARTITION BY user_id) AS caduta_engagement_7d
FROM windowed_sessions
)
WHERE session_duration < 1000 AND interval_between_events > 15 — filtro per eventi significativi
),
clusterized_users AS (
SELECT
user_id,
login_bucket,
avg_session_interval,
decay_rate_sessione,
caduta_engagement_7d,
KMEANS(
CASE WHEN decay_rate_sessione < 0 THEN 1 ELSE 0 END,
avg_session_interval,
caduta_engagement_7d
) OVER () AS segment_id
FROM feature_engine
)
SELECT * FROM clusterized_users
ORDER BY segment_id, caduta_engagement_7d DESC;

3. Analisi temporale delle fasi di rischio churn: mappare il “momento critico” con precisione

Il churn non è un evento istantaneo, ma un processo cumulativo che si manifesta attraverso un progressivo calo di engagement. Identificare il “momento critico” richiede mappare il tempo trascorso senza evento positivo rispetto all’ultimo’interazione significativa, integrando decay rate e caduta sessioni.

Il “momento di rischio” è definito come:
> interruzione > X giorni senza evento positivo, accompagnata da decay rate elevato (>0.15) e caduta sessioni >20% settimana per settimana.

Per questo, si calcola il tempo medio tra evento attuale e ultimo positivo (**TMEP**), e si aggrega per cohort temporali (es. utenti acquisiti nel Q1 2024 vs Q2 2024) per rivelare pattern stagionali e comportamenti ciclici legati a festività o eventi locali (es. Natale, Pasqua).

> “Un utente può non disconnettersi mai, ma se l’engagement cala del 30% in 14 giorni, è già in fase avanzata di rischio.”
> — Analisi survival model, telemedicina italiana, 2024

Fase 1: Definire il momento di rischio
WITH risk_windows AS (
SELECT
user_id,
event_timestamp_utc,
CASE WHEN event = ‘acquisto’ THEN 1 ELSE 0 END AS tipo_evento,
TIMESTAMPDIFF(DAY, event_timestamp_utc, MAX(event_timestamp_utc)) AS giorni_senza_evento
FROM user_events
WHERE TIMESTAM