Anomalie nei dati analytics: sistema di sorveglianza automatico per 100+ proprietà GA4

1. Come è iniziato

Ho scoperto il calo tre settimane dopo che era iniziato. Il sito era sceso del 35% nel traffico organico. Il cliente non lo sapeva. Io non lo sapevo. Tre settimane di traffico perso, tre settimane in cui qualunque intervento tempestivo sarebbe stato più efficace — tre settimane che non si recuperano.

Quel giorno ho aperto GA4 per caso, mentre controllavo un'altra cosa. Il grafico era evidente. Ho controllato le date, ho fatto i calcoli, ho riletto la storia. Il problema era iniziato ventuno giorni prima. Non avevo ricevuto nessuna notifica perché non avevo nessun sistema che monitorasse quella proprietà. E in quel momento gestivo già decine di siti.

Il problema non è la mancanza di dati. GA4 ne produce in quantità industriale — sessioni, utenti, eventi, canali, conversioni, per ogni giorno di ogni proprietà. Il problema è che nessuno può aprire 100 proprietà ogni mattina, confrontare i numeri di ieri con quelli della settimana precedente, valutare se un calo è fisiologico o allarmante, capire se dipende dal calendario, da un problema tecnico, o da un deterioramento reale del traffico organico. Non è una questione di disciplina o pigrizia. È aritmetica: il tempo necessario supera quello disponibile di un ordine di grandezza. Ho scelto di automatizzare invece di ignorare.

2. La domanda giusta

Ho iniziato costruendo qualcosa di semplice: una notifica ogni volta che una proprietà variava di più del 20% rispetto al giorno precedente. Semplice da implementare, intuitivo come concetto. In tre giorni avevo ricevuto abbastanza messaggi Telegram da disattivare le notifiche.

Il problema non era tecnico. Era concettuale. Avevo formulato la domanda sbagliata. Mi ero chiesto "come rilevo i cambiamenti?" quando avrei dovuto chiedermi "come distinguo i cambiamenti significativi da quelli attesi?".

Un lunedì ha strutturalmente meno traffico di un venerdì. Agosto ha meno traffico di ottobre. Il 15 agosto non è paragonabile a un martedì di marzo. Un e-commerce registra picchi nel weekend che un sito B2B non vede mai. Una campagna paid iniziata il giorno prima gonfia i numeri in un modo che non c'entra niente con la salute organica del sito. Una soglia fissa applicata a questi dati produce rumore continuo. E un sistema che genera rumore continuo diventa invisibile — peggio di non avere nessun sistema, perché crea l'abitudine di ignorare.

3. Rilevamento a tre segnali

La soluzione non era una soglia più raffinata. Era un approccio radicalmente diverso: invece di confrontare oggi con ieri, incrociare tre segnali indipendenti che catturano dimensioni diverse dell'anomalia. Solo quando più segnali convergono nella stessa direzione, con sufficiente intensità, il sistema classifica un'anomalia.

3.1 Confronto same-day-of-week

Il traffico di oggi viene comparato con il traffico degli stessi giorni della settimana nelle settimane precedenti. Un lunedì viene confrontato con i lunedì storici, non con la domenica adiacente o il venerdì. Questo elimina la varianza strutturale tra giorni della settimana, che per molte proprietà è la principale fonte di rumore in un sistema a soglia fissa.

Il confronto non usa una media semplice. Applica uno z-score che tiene conto della deviazione standard intrinseca di quel giorno per quella specifica proprietà. Una proprietà naturalmente volatile il giovedì — magari per una newsletter settimanale che porta picchi di traffico diretto — ha una baseline di riferimento che incorpora quella volatilità. Il sistema non allerta per variazioni che rientrano nel suo normale range di oscillazione. Se invece una proprietà storicamente stabile subisce un calo anomalo rispetto ai propri storici, il segnale emerge con precisione.

3.2 Trend settimana su settimana

Il primo segnale risponde alla domanda "questo lunedì è normale rispetto agli altri lunedì?". Il secondo risponde a una domanda diversa: "ma quegli altri lunedì stavano già calando?".

Una proprietà potrebbe superare il test del same-day-of-week — il calo rispetto ai lunedì precedenti è nella norma — ma se quei lunedì erano già in declino rispetto ai lunedì di prima, il segnale aggregato racconta una storia diversa. Il sistema calcola il trend week-over-week su fino a tre settimane precedenti applicando una ponderazione temporale decrescente: la settimana più recente pesa il 50% del segnale, quella di due settimane fa il 30%, quella di tre settimane fa il 20%. I dati più recenti contano di più perché riflettono meglio la situazione attuale.

Questo secondo segnale cattura i cali graduali che il primo non vede: una proprietà in declino lento ma costante che rimane "nella norma" rispetto ai propri storici immediati, ma accumula un deterioramento che diventa visibile solo guardando il trend complessivo delle ultime settimane.

3.3 Consapevolezza del calendario italiano

Il terzo segnale nasce da una constatazione pratica: molti dei falsi positivi del sistema iniziale coincidevano con festività. Ferragosto. Pasqua. I ponti di novembre. Il sistema interpretava come anomalia quello che era semplicemente un calo fisiologico legato al calendario italiano.

Ho implementato una consapevolezza completa del calendario. Non solo le festività fisse — Capodanno, Epifania, Festa della Liberazione, Ferragosto, Immacolata, Natale — ma anche la Pasqua calcolata dinamicamente anno per anno usando l'algoritmo di Meeus/Jones/Butcher (valido per qualsiasi anno del calendario gregoriano), i ponti che si formano automaticamente quando una festività cade di martedì o giovedì, e il periodo natalizio esteso dal 24 dicembre al 3 gennaio.

Quando un calo coincide con una festività o un ponte, il peso del segnale negativo viene ridotto significativamente. Quando il giorno precedente era festivo, un picco di traffico — recovery dopo l'inattività del giorno prima — viene smorzato per non generare un falso positivo di segno opposto. Il sistema sa che il 26 dicembre non è un mercoledì qualsiasi. Sa che il lunedì dopo Pasqua non è un lunedì qualsiasi. Sa che il 2 novembre, se cade di lunedì dopo il giorno dei Santi, è quasi certamente un ponte.

3.4 Punteggio composito e livelli di severità

I tre segnali vengono combinati in un punteggio composito su scala -3/+3. Positivo indica crescita anomala, negativo indica calo anomalo. Solo quando il punteggio supera una soglia configurabile e contemporaneamente la variazione percentuale supera un minimo configurabile, il sistema classifica un'anomalia. Al di sotto di quella soglia, non notifica.

Il sistema distingue due livelli: warning (variazione moderata, da tenere sotto controllo) e anomalia (variazione significativa, da investigare). C'è anche uno stato "vuota" per le proprietà storicamente senza traffico o con traffico trascurabile: non vengono trattate come siti rotti, ma come siti semplicemente inattivi. In un portafoglio di 100+ proprietà questa distinzione è essenziale per non annegare in notifiche irrilevanti — ci sono sempre proprietà in pausa, in costruzione, o dormienti.

4. Il layer AI: i pattern che i segnali statistici non vedono

La detection statistica a tre segnali è ottima per rilevare scossoni giornalieri. Ma esiste un'intera categoria di problemi che si manifesta gradualmente, sotto la soglia di qualunque varianza giornaliera.

A un certo punto mi sono accorto che il sistema vedeva i terremoti ma non le faglie che si spostavano lentamente. Un sito che perde il 4% di traffico organico ogni settimana per tre mesi consecutivi non fa mai scattare un'allerta giornaliera — ogni singolo giorno il calo rientra nella varianza normale. Eppure, a fine trimestre, quel sito ha perso oltre il 40% del suo traffico organico. Un'altra proprietà potrebbe aver avuto un'anomalia grave sei settimane fa, essersi parzialmente ripresa, ma non aver mai recuperato il livello baseline precedente — una regressione invisibile alle metriche di varianza giornaliera.

Ho provato a codificare questi pattern in regole deterministiche. Ho fallito. Erano troppo contestuali, troppo dipendenti dalla storia specifica di ogni proprietà, troppo sensibili a combinazioni di fattori che cambiano da sito a sito. Ogni volta che pensavo di aver catturato un pattern, trovavo un caso che lo contraddiceva. Alla fine ho smesso di cercare la regola e ho passato la domanda direttamente a un modello di linguaggio, alimentandolo con 90 giorni di dati storici per ogni proprietà.

Ogni proprietà viene analizzata con 90 giorni di sessioni giornaliere più il mix di canali degli ultimi 30 giorni confrontato con i 60 precedenti — organico, diretto, paid, social, referral, ciascuno come quota percentuale e come valore assoluto. Il modello riceve istruzioni precise su categorie di pattern da cercare: declini graduali week-over-week che non raggiungono mai la soglia di anomalia giornaliera; mancati recovery dopo anomalie passate (il sito si è "ripreso" nei numeri ma non ha recuperato il baseline); correlazioni tra proprietà dello stesso account che potrebbero indicare un problema di configurazione del tracciamento; shift nel mix di canali — in particolare un calo organico mascherato da un aumento della quota paid; sorgenti di traffico che erano attive nei 60 giorni precedenti e sono scomparse negli ultimi 30; dipendenza eccessiva da un singolo canale che costituisce un rischio strutturale.

Il report segue una struttura fissa: situazioni critiche (richiedono azione immediata), elementi da monitorare (segnali deboli che potrebbero evolvere), tendenze positive (crescite che meritano di essere notate), e cinque raccomandazioni prioritizzate con numeri reali. Non "il traffico organico è calato" ma "il traffico organico è passato dal 65% al 40% del totale negli ultimi 30 giorni, con una perdita di 340 sessioni organiche settimanali rispetto al periodo precedente". Il report può essere generato dalla dashboard per qualsiasi proprietà, o inviato direttamente via Telegram con un click.

5. Il funzionamento quotidiano

Ogni giorno, automaticamente, senza che io apra nessun tool, il sistema esegue tre operazioni in sequenza.

1. Recupero dati: per ogni proprietà nel database viene interrogata la GA4 Data API per ottenere il dato di sessioni del giorno precedente, suddiviso per canale di traffico. I tre segnali vengono calcolati, il punteggio composito aggiornato, lo stato della proprietà classificato, e il dato archiviato nella serie storica.
2. Notifiche anomalie: tutte le proprietà in stato warning o anomalia vengono raggruppate per account e inviate via Telegram in un messaggio strutturato. Ogni riga riporta nome della proprietà, sessioni del giorno, variazione percentuale, e direzione del trend. Le proprietà normali non generano nessuna notifica.
3. Aggiornamento canali: il breakdown del traffico per canale viene aggiornato per alimentare l'analisi longitudinale del layer AI.

Adesso arrivo al computer la mattina e so già se c'è qualcosa che richiede attenzione. Se il telefono non ha notificato nulla durante la notte, i 100 siti stanno bene. Se c'è una notifica, so già quale proprietà, quale account, quale entità del problema, e ho già abbastanza contesto per decidere se intervenire subito o monitorare. Il tempo tra il verificarsi di un'anomalia e la mia consapevolezza è passato da settimane a ore.

6. La dashboard

Le notifiche Telegram gestiscono le situazioni urgenti. La dashboard gestisce tutto il resto: la visione d'insieme del portafoglio, l'analisi di una singola proprietà, la generazione del report AI, la configurazione delle soglie.

La schermata principale mostra tutte le proprietà raggruppate per account con il loro stato corrente — un colpo d'occhio sull'intero portafoglio. Le proprietà in anomalia vengono messe in evidenza. Cliccando su una proprietà si accede al dettaglio: il valore dei tre segnali, la variazione percentuale, la storia delle ultime due settimane, e — quando presente — il motivo specifico dell'anomalia. Non solo "questo sito è in anomalia", ma "calo del 28% rispetto ai lunedì precedenti, trend settimana su settimana negativo per tre settimane consecutive, nessuna festività rilevante nel periodo".

Da qui è possibile generare il report AI su 90 giorni per qualsiasi proprietà, o inviarlo direttamente via Telegram. La dashboard mostra anche lo storico delle anomalie passate per ogni sito, utile per identificare pattern ricorrenti e verificare se un recovery è stato completo o solo parziale.

7. Architettura e costi

L'intera logica di rilevamento gira su edge functions serverless. Non c'è nessun server persistente da mantenere, nessun processo da gestire, nessun costo fisso di infrastruttura. Le funzioni vengono invocate dal cron job una volta al giorno, eseguono il loro lavoro in pochi minuti, e tornano inattive per le successive 23+ ore. Il costo è proporzionale all'utilizzo effettivo, e l'utilizzo effettivo è minimo.

Aggiungere una nuova proprietà richiede meno di un minuto. Si inserisce il service account, si avvia la funzione di inizializzazione che raccoglie autonomamente i 30 giorni di storico precedente e calibra i parametri di baseline su quel sito specifico, e la proprietà viene monitorata dal giorno successivo. Non c'è configurazione manuale delle soglie — il sistema si calibra da solo sulla variabilità storica di ogni proprietà.

8. Il modello dati

Il database è strutturato su sei tabelle principali, ciascuna con una responsabilità precisa.

• ga4_credentials — il service account JSON di ogni proprietà, cifrato a riposo.
• ga4_properties — lo stato corrente di ogni proprietà: status, sessioni del giorno, variazione percentuale, e un campo JSONB anomaly_details con il dettaglio completo dell'anomalia quando presente.
• historical_sessions — la serie storica giornaliera per ogni proprietà, usata per calcolare i tre segnali. Ogni record archivia data, sessioni, e i valori intermedi dei segnali per il debugging.
• telegram_settings — configurazione del bot Telegram per gli account: token, chat ID, e preferenze di notifica.
• anomaly_settings — soglie configurabili per account o per singola proprietà: threshold, min_sessions (sotto cui non notificare), min_percentage_change, e finestre temporali.
• traffic_sources_history — breakdown giornaliero per canale (organic, direct, paid, social, referral), alimenta il layer AI longitudinale.

Il campo anomaly_details nel JSONB di ga4_properties è il componente che rende la dashboard utile anziché un semplice semaforo. Archivia il livello di anomalia, i valori dei tre segnali con il loro contributo relativo al punteggio composito, il contesto storico delle ultime due settimane, e il timestamp di rilevamento. Questo permette di rispondere alla domanda "perché questo sito è in anomalia?" senza dover ricalcolare nulla — tutto il contesto è già lì.

9. Cosa non ha funzionato prima

Il sistema attuale è la terza architettura. Le prime due hanno fallito per ragioni diverse, e da ogni fallimento ho ricavato qualcosa che ha informato la versione successiva.

La prima soluzione era un foglio di calcolo con formule condizionali che confrontavano ogni giorno con la media mobile degli ultimi sette giorni e coloravano le celle in rosso se la variazione superava il 15%. Richiedeva aggiornamento manuale ogni mattina — importare i dati da GA4, incollare, aspettare che le formule ricalcolassero. L'ho abbandonato dopo due settimane. Non per pigrizia, ma perché richiedeva esattamente l'attenzione quotidiana che stavo cercando di eliminare. Era un'automazione parziale, e le automazioni parziali tendono a fallire nella parte manuale.

La seconda soluzione era uno script Google Apps Script che automatizzava l'importazione e mandava un'email ogni mattina con il report. Ha funzionato per qualche settimana, poi GA4 ha cambiato qualcosa nell'API di reporting e lo script ha smesso di funzionare silenziosamente. Non mandava più email, non dava errori visibili. Ho scoperto che era rotto quando ho aperto GA4 per controllare manualmente dopo qualche giorno di silenzio sospetto. Il problema non era il codice — era che nessuno controllava che il sistema stesso stesse funzionando.

La terza soluzione — quella attuale — è nata dall'analisi di questi due fallimenti. Dall'esperienza del foglio di calcolo: l'automazione deve essere completa, non parziale, altrimenti il punto di rottura è sempre nella parte umana. Dall'esperienza di Apps Script: il sistema deve essere osservabile — se smette di funzionare devo saperlo subito, non tre settimane dopo. Dalla prima versione con soglie fisse: il segnale deve essere contestuale, non assoluto, perché il contesto — giorno della settimana, stagione, calendario — è metà dell'informazione.

10. Uno strumento che uso ogni giorno

Non è uno strumento elegante nel senso estetico del termine. L'interfaccia è funzionale, non bella. L'architettura è pragmatica, non ottimizzata per sembrare impressionante in una presentazione tecnica. È uno strumento che funziona, che uso ogni giorno, e che ha già evitato almeno una dozzina di conversazioni imbarazzanti con clienti.

Il tipo di conversazione che evita è specifico: quella in cui il cliente mi chiede "hai visto che il traffico è calato del 30% la settimana scorsa?" e io devo rispondere di no. Quella conversazione costa in termini di fiducia molto più di quanto costi costruire un sistema di monitoring automatico. Da quando questo sistema è attivo, non ho più avuto quella conversazione.

Quello che mi ha sorpreso di più, guardando indietro, è quanto il costo sia vicino a zero. Non in senso figurato: in senso letterale. Le API serverless, il costo marginale delle edge functions, i modelli AI economici per l'analisi longitudinale — la combinazione rende accessibile oggi qualcosa che due anni fa avrebbe richiesto un'infrastruttura con costi fissi mensili significativi. Il timing ha contato.

Se gestisci molti siti e ti riconosci in questo problema, scrivimi — sono disponibile a parlarne.