Cosa sono i journey in Customer Insights - Journeys

In Dynamics 365 Customer Insights - Journeys (l’evoluzione di quello che si chiamava Dynamics 365 Marketing), un journey è l’orchestrazione automatizzata di una serie di interazioni con il cliente lungo il tempo. Il modello real-time ha di fatto sostituito il vecchio motore outbound: mentre l’outbound si basava su segmenti statici ricalcolati in batch e su un canvas “marketing pipeline”, il real-time reagisce agli eventi nel momento in cui accadono e attinge a dati unificati provenienti da Customer Insights - Data (profili + segmenti + measures).

La scelta architetturale fondamentale, e quella più testata all’esame, riguarda il punto di ingresso (entry point) del journey.

Trigger-based vs segment-based

Quando crei un journey scegli come i contatti vi entrano:

  • Trigger-based journey: parte quando si verifica un event trigger (es. “abandoned cart”, “form submitted”, “product viewed”). È il pattern giusto per scenari reattivi e transazionali: onboarding, conferme, recupero carrello, comportamenti in tempo reale. Ogni occorrenza dell’evento fa entrare l’individuo nel journey con il payload dell’evento a disposizione per personalizzazione e condizioni.
  • Segment-based journey: parte da un segment di Customer Insights. È il pattern giusto per iniziative pianificate e batch: newsletter, nurture ricorrenti, campagne verso una lista definita. Il journey valuta l’appartenenza al segmento e fa entrare/uscire i membri quando cambiano.

Regola pratica: evento che richiede reazione immediata → trigger-based; audience nota che vuoi coltivare → segment-based.

Gli step del journey

Il canvas real-time si costruisce con blocchi collegati in sequenza e ramificazioni:

  • Send an email / channel step: invio su un canale. Oltre a email, i canali includono SMS, push notification e Microsoft Teams / custom channel; la disponibilità dipende dalle licenze e dagli outbound number/sender configurati.
  • Wait / attesa: pausa per una durata fissa, fino a una data, o fino a un trigger (es. “aspetta max 3 giorni che l’utente clicchi”).
  • Attribute branch / condizione (if-then): ramifica in base ad attributi del profilo o al payload dell’evento.
  • Trigger branch / activity-based branch: ramifica in base a ciò che il contatto fa dopo uno step (ha aperto? ha cliccato? ha acquistato?), usando i trigger generati dalle interazioni.

Personalizzazione dei contenuti tramite dynamic content che legge attributi del profilo, dati correlati (related tables) e valori del trigger.

Stati di go-live

Un journey non è attivo finché non lo pubblichi:

  • Draft: in costruzione/modifica, non elabora nessuno.
  • Live: pubblicato e in esecuzione; i nuovi ingressi vengono elaborati.
  • Stop / Edit: mettendolo in modifica lo fermi; le modifiche strutturali richiedono spesso di ripubblicare. I contatti già in transito seguono regole specifiche a seconda del tipo di modifica.

Prima del go-live viene eseguito un error check che blocca la pubblicazione se mancano contenuti pubblicati, sender verificati o configurazioni obbligatorie.

Il real-time applica il consent in modo nativo tramite i compliance profiles e i purposes (finalità: commercial, transactional). Ogni contact point (email, telefono) ha uno stato di consenso valutato al momento dell’invio: se il contatto non ha dato consenso per quella finalità su quel canale, lo step di invio viene saltato senza fermare il journey. Questo è il meccanismo con cui GDPR/preferenze vengono rispettate.

Trappole tipiche d’esame

  • Scenario: “Vuoi inviare un messaggio non appena un cliente abbandona il carrello.” → Journey trigger-based con event trigger, non segment-based: il segment-based non reagisce all’evento in tempo reale.
  • Scenario: “Newsletter mensile a tutti i clienti di una regione.” → Segment-based journey su un segment di Customer Insights - Data; usare un trigger qui è la scelta sbagliata.
  • Scenario: “Un contatto nel journey non riceve l’email pur essendo nel percorso.” → Verificare il consent/compliance profile per quella finalità e canale: senza consenso lo step di invio viene saltato, non è un errore di configurazione del canvas.
  • Scenario: “Devi migrare campagne dal vecchio motore.” → Ricordare che outbound marketing è deprecato; le nuove iniziative vanno costruite in real-time journeys, non nel canvas outbound.
  • Scenario: “Il journey è costruito ma nessuno lo riceve.” → Controllare lo stato: deve essere Live, non Draft, e deve aver superato l’error check (contenuti pubblicati e sender verificati).