Un'automazione non è finita quando funziona

Capita spessissimo. Apri un flusso che gira da settimane, guardi i numeri, e sono tutti a zero. E arriva la domanda, sacrosanta: “siamo sicuri che stia funzionando?”.

La risposta onesta, il più delle volte, è un’alzata di spalle. Non perché non sai rispondere, ma perché il flusso è stato costruito in un modo che non ti permette di farlo.

Quello zero può voler dire diverse cose diverse: c'è poco traffico in generale sul sito, poco movimento sull'evento scatenante del flusso, oppure un filtro che ha tagliato fuori più gente del previsto.

Per le prime due alternative, la soluzione è piuttosto ovvia: andare a controllare gli eventi. Ma per la terza, vale la pena fare un approfondimento.

Parliamo oggi di metodo progettuale… o, almeno, di quello che io credo sia più giusto fare in questi casi. Potrebbe sembrare una sottigliezza tecnica, ma l'esperienza mi dice il contrario.

Scatola nera o scatola di vetro?

Quando metti una condizione all’ingresso di un flusso - il classico “entra solo chi è di questo Paese, parla questa lingua, ha questa property” - chi non la soddisfa semplicemente sparisce. Non entra, non lo conti, non lo vedi. È una scatola nera: dentro succede qualcosa, ma da fuori leggi solo il risultato finale. Se il risultato è zero, non sai se è zero perché non è entrato nessuno o perché chi è entrato non ha convertito. Le due cose, dall’esterno, sono identiche.

Quando invece fai entrare tutti e metti la stessa condizione come uno split dentro al flusso, la scatola diventa di vetro. Vedi quante persone sono passate, quante hai instradato verso le eMail e quante verso l’uscita. Lo zero smette di essere un mistero: o sono entrate in pochi (e allora il problema è a monte, nel volume), o sono entrate in tanti ma la condizione li ha buttati fuori.

A questo punto ci si può chiaramente chiedere: il mio filtro è troppo restrittivo o sta facendo ciò che mi aspettavo facesse?

La differenza non è “funziona meglio”. Funzionano identici, mandano le stesse eMail alle stesse persone. La differenza è che una versione te la sai spiegare e l’altra no.

Non tutte le condizioni vanno trattate uguali

Qui però si annida la trappola, perché la conclusione facile sarebbe “allora sposta tutti i filtri dentro al flusso”. E sarebbe una regola stupida quanto quella che vuole sostituire.

Le condizioni non sono tutte uguali. Alcune sono guardie di cui ti fidi: “non scrivere a chi ha già comprato” è una di quelle. Non la stai testando, non hai dubbi, non c’è niente da ispezionare. Quella può stare benissimo all’ingresso, e anzi è giusto che stia lì a fare da buttafuori.

Altre sono condizioni sperimentali. Le stai provando, non sei sicuro che facciano davvero quello che pensi, o sono il tipo di cosa che si rompe in silenzio senza dirtelo. Quelle vanno rese osservabili, perché sono esattamente quelle su cui un giorno qualcuno ti chiederà conto. Tipicamente è il campo nuovo che hai introdotto la settimana scorsa per testare se segmenta meglio del precedente: è la cosa di cui dubiti, ed è l’unica che hai messo proprio dove non puoi guardarla.

La regola vera quindi non è “tutto dentro al flusso”. È: le condizioni di cui sei sicuro stanno all’ingresso, quelle che stai testando o che potrebbero rompersi vanno rese ispezionabili. È una decisione che prendi condizione per condizione, non flusso per flusso.

“Funziona” non è una proprietà stabile

Il motivo per cui insisto su questo è che è il punto in cui cambia il modo di lavorare, non la singola impostazione.

La maggior parte delle automazioni viene progettata per far funzionare qualcosa. Obiettivo ragionevole, e di solito lo raggiunge. Ma “funziona” è una proprietà che esiste solo finché nessuno fa domande. Regge fino al primo “come fai a saperlo?”, e a quel punto un’automazione costruita solo per funzionare non ha risposta: ha un numero che non sa raccontare.

Io provo a progettare per un obiettivo diverso, e un po’ più scomodo da costruire: che il flusso sia verificabile. Che quando arriva il dubbio - e arriva sempre, prima o poi qualcuno apre quel report e chiede - ci sia un fatto al posto dell’alzata di spalle. Non è una rifinitura estetica. È la differenza tra un sistema di cui ti puoi fidare e uno che speri stia andando bene.

È anche, banalmente, il motivo per cui non faccio una cosa “perché tanto si fa così”. “Si fa così” costruisce automazioni che funzionano. Costruisce raramente automazioni che puoi interrogare.

La domanda da farsi prima di costruire

Il caso da cui parte tutto questo, alla fine, è un filtro Paese su un flusso di checkout. Roba minima. Ma la tattica - lo split piazzato nel punto giusto, l’osservabilità - la conoscono in tanti, e non è quella il punto. Il punto è la domanda che viene prima di aprire l’editor…

!uesto flusso, il giorno in cui qualcuno mi chiede se sta funzionando, mi permette di rispondere con un fatto o con un’alzata di spalle?

Se la risposta è “alzata di spalle”, il flusso non è finito. Anche se funziona.