Daily report automatici su Slack. BigQuery, n8n e zero intervento manuale.
Ogni giorno, tra le 14 e le 15, un messaggio arriva su Slack. Sessioni, pageview, transazioni, revenue di ogni cliente. Se qualcosa crolla o il tracking si rompe, lo sappiamo prima del cliente.
Il problema iniziale
Quando gestisci 8 ecommerce o siti web contemporaneamente, avere una visione panoramica della salute del tracking e delle performance è impossibile a mano. Ogni mattina dovrei aprire Google Analytics per ogni cliente, controllare sessioni, transazioni, revenue, e annotarmi le anomalie. Un lavoro meccanico, ma che richiedeva tempo e attenzione.
Il vero dramma però è un altro. Quando un pixel di tracking si rompe, quando il codice esce di sync, quando ci sono null nei dati delle transazioni, io lo scopro dopo giorni. Il cliente lo scopre prima di me. E allora parte la telefonata di panico.
Avevo bisogno di un sistema che mi desse una visione costante, automatica, di cosa stava succedendo nei dati di tutti i miei clienti. Un sistema che urlasse se qualcosa andava male, non che aspettasse che me lo dicesse qualcun altro.
La soluzione inizia con una domanda
Mi sono chiesto: quanti check posso automatizzare? Quali sono le metriche che vanno monitorate ogni giorno?
La risposta è venuta da una lista semplice
- Sessioni di oggi vs ieri
- Pageview di oggi vs ieri
- Transazioni di oggi vs ieri
- Revenue di oggi vs ieri
- Alert rossi quando i dati sono null, quando il tracking è chiaramente rotto
- Alert gialli quando scende più del 15% rispetto al giorno prima
Poi, una volta a settimana, uno sguardo più profondo su uno specifico cliente con analisi su 7 giorni.
Architettura del sistema
Il flusso è in tre step.
Step uno è BigQuery. Tutti i dati di tracking di tutti i clienti sono già in BigQuery. Ho scritto delle query SQL che estraggono, per ogni cliente, le quattro metriche di base. Sessioni, pageview, transazioni, revenue di ieri. E le metto a confronto con il giorno precedente.
Step due è n8n. Ho configurato due workflow.
- Il primo gira ogni giorno tra le 14 e le 15. Chiama BigQuery, estrae i dati di tutti gli 8 clienti, formatta il messaggio per Slack.
- Il secondo gira ogni mercoledì alle 10 del mattino. Fa un'analisi su 7 giorni per uno specifico cliente, sempre su BigQuery, e posta il report dettagliato.
Step tre è Slack. I messaggi arrivano nel canale #all-clients. Formattati, leggibili, con i colori giusti per gli alert.
Come leggere il report giornaliero
Un report giornaliero per ogni cliente è così fatto
Transactions: 3 (+200.0% vs 1) - Revenue: $160.00 (+175.9% vs $58.00)
Questo significa: oggi 3 transazioni (200% di aumento rispetto a ieri che erano 1). Revenue di $160 (175.9% di aumento vs i $58 di ieri).
Se invece il tracking è rotto, vedi questo
Transactions: 0 / Null warning broken tracking
Questo significa che le transazioni sono null. Il codice di tracking non sta passando i dati. Red alert.
Se un numero crolla di più del 15%, il workflow aggiunge una flag
Sessions: 1200 (-18.5%) 🚨
Le sessioni sono scese del 18.5%. Qualcosa è cambiato.
Un caso reale
Una settimana dopo aver messo online il sistema, il report di un cliente nel settore luxury arriva come al solito. Ma c'è un warning
Transactions: 0 / Null broken tracking
Io leggo il messaggio alle 14.45. Il cliente ancora non lo sa. Mi lancio subito in un'indagine di 10 minuti. Il pixel del loro e-commerce non stava più tracciando le transazioni. Il loro developer aveva pushato una versione di codice tre ore prima, e il deployment era andato a fuoco senza che nessuno se ne accorgesse.
Quello stesso pomeriggio ho fatto il fix e il pixel è tornato attivo. Il cliente ha una conversione alle 15.30. Quando apre Google Analytics il giorno dopo, non vede niente di strano. Il tracking è ok. Zero danno.
Questo è il valore del sistema. Non è una dashboard fancy. Non è un alerting AI-powered. È un semplice, brutale check. Ogni giorno. Stesso orario. Stesso canale. E quando qualcosa va male, io lo so prima di chiunque altro.
Gli strumenti dietro il sipario
Il sistema gira su un VPS. BigQuery è il cuore dei dati. n8n è l'orchestrator che chiama BigQuery, processa i risultati, e posta su Slack.
Non c'è intervento manuale. Non c'è click. Non c'è controllo che mi dimentico di fare. Alle 14.15 di ogni giorno, il workflow parte. Alle 14.30, il messaggio è su Slack. È matematico.
Cosa ho imparato
La cosa più importante è questa: il monitoring non deve essere complicato. Non deve avere machine learning. Non deve predire il futuro. Deve semplicemente farti sapere quando le cose vanno male, oggi, rispetto a ieri. E farlo ogni giorno, allo stesso orario, senza che tu debba pensarci.
Ho iniziato con la visione di quattro metriche semplici. E ho scoperto che quelle quattro metriche risolvono il 90% dei miei problemi di anomalia tracking. Il resto sono outlier, è il noise.
Quando il tracking funziona, il report è verde. Quando qualcosa crolla, il report ti urla addosso. E io agisco in minutes, non in days.