Journey Builder è la parte di Salesforce Marketing Cloud (SFMC) dove le buone intenzioni diventano spaghetti. È abbastanza accessibile perché chiunque possa costruire un journey, e abbastanza potente perché uno costruito male possa danneggiare in silenzio la tua reputazione di invio e i tuoi dati. Dopo aver revisionato molte implementazioni, gli stessi errori di architettura tornano di continuo. Eccone sette, e come progetto per evitarli.
1. Un unico journey gigante per tutto
L’istinto è modellare l’intero lifecycle del cliente in un’unica canvas enorme. Diventa impossibile da modificare, testare o comprendere. Soluzione: scomponi in journey più piccoli e a scopo unico (welcome, nurture, win-back, transazionali) che condividono i dati tramite Data Extension. I journey piccoli sono journey testabili.
2. Injection sull’entry source sbagliata
Far entrare i contatti via API o via una Data Extension che si aggiorna in place, senza controllare il re-entry, porta a ingressi duplicati e a persone che ricevono la stessa email due volte. Soluzione: progetta l’entry source deliberatamente, imposta la modalità di re-entry con consapevolezza e usa una Data Extension di “injection” pulita il cui unico compito è alimentare il journey.
3. Nessuna policy di re-entry (o quella sbagliata)
“Re-entry consentito” vs “no re-entry” vs “re-entry dopo l’uscita” non è una casella da spuntare distrattamente — è una regola di business. Sbagliarla significa o persone bloccate fuori da un journey in cui dovrebbero rientrare, o spammate. Soluzione: decidi la regola di re-entry a partire dal requisito di marketing, poi configura di conseguenza e documenta il perché.
4. Cablare nella logica ciò che appartiene ai dati
Decision split impilati dieci livelli in profondità, con valori letterali incastonati nel journey, significano che ogni cambio di regola è un redeploy del journey. Soluzione: sposta la logica nei dati. Pre-calcola un segmento, un flag o uno score in una SQL Query o in un sistema a monte, e lascia che il journey legga un campo semplice. I journey dovrebbero instradare in base ai dati, non calcolarli.
5. Ignorare il comportamento di wait/send-time su scala
Le attività di wait, le finestre di invio e i fusi orari si comportano diversamente sui volumi rispetto a un test con tre contatti. Journey che “funzionavano in QA” si accumulano o partono alle 3 di notte per metà del pubblico. Soluzione: ragiona esplicitamente su fusi orari e throughput, e testa con volumi realistici prima del go-live.
6. Nessun criterio di uscita
I contatti che dovrebbero uscire da un journey quando convertono, si disiscrivono o fanno bounce — ma non lo fanno — continuano a ricevere messaggi irrilevanti (o non conformi). Soluzione: definisci i criteri di uscita per ogni journey. “Cosa fa sì che una persona non appartenga più qui?” è una domanda di design obbligatoria, non un ripensamento.
7. Costruire senza monitoraggio né documentazione
Un journey senza convenzioni di naming, senza nota di versione e senza nessuno che ne guardi le statistiche è una bomba a orologeria. Sei mesi dopo nessuno sa cosa fa o se è ancora attivo. Soluzione: adotta convenzioni di naming, tieni un semplice inventario dei journey e monitora conteggi di ingresso/uscita e salute degli invii. Tratta i journey come sistemi di produzione, perché lo sono.
Il pattern dietro tutti e sette
Ognuno di questi errori ha la stessa radice: trattare Journey Builder come uno strumento di disegno invece che come un’architettura. Un journey è un sistema distribuito, stateful e basato sul tempo che tocca dati cliente live e la tua reputazione di mittente. Progettalo come tale — piccolo, data-driven, con regole di ingresso/uscita esplicite e monitoraggio — e resta manutenibile. Disegnalo come un diagramma di flusso e prima o poi ti sorprenderà, di solito in produzione.
Se stai ereditando una org SFMC piena di journey aggrovigliati, parti dagli errori 6 e 1: aggiungi i criteri di uscita e spezza i monoliti. Solo questo ti restituisce gran parte del controllo.