Weekly MarTech Signals That Matter to Me: Parte 24, Settimana 42
🇬🇧 Read in English

8 min di lettura

Questo articolo è una traduzione assistita dall’AI dell’originale in inglese, revisionata dall’autore.

L’uscita merita la stessa progettazione dell’ingresso

Quando rivedo il design di un journey, i criteri di ingresso occupano di solito una pagina e l’uscita una riga. Lo stesso vale per segmenti, sync di audience e integrazioni: si pensa molto a come una cosa parte e pochissimo a come si ferma. I rilasci registrati nella MarTech Watch della settimana 42 sono insoliti proprio perché diversi riguardano il fermarsi, e messi insieme dicono che l’uscita è ormai un oggetto di design a sé.

TL;DR

  • Uscire da un’offerta non significa più uscire dal journey. La nuova Stop action di Adobe Journey Optimizer toglie un profilo da un massimo di cinque attività o esperienze inbound mentre il journey continua.
  • L’uscita da un segmento ha un percorso e un ritardo. Nella sync di Insider verso ChatGPT Ads e nei segmenti esterni di Bloomreach 1.320 la rimozione arriva dopo un push e l’elaborazione della destinazione.
  • Le integrazioni invecchiano e scadono. Salesforce revocherà i refresh token inattivi da più di trenta giorni, e Hightouch ha comprato Strata.
  • Revocare deve essere facile quanto dire sì. Il termine del Garante del 29 ottobre chiede una revoca semplice e anche selettiva.




Un’uscita che non chiude il journey

Adobe Journey Optimizer ha aggiunto al canvas del journey l’attività Stop action. La descrizione di Adobe è precisa: permette di “remove a profile from up to five inbound activities or experiences directly from a journey, decoupling inbound disqualification from journey exit for more advanced cross-channel orchestration”.

La parola interessante è proprio separare, perché nei progetti su cui ho lavorato le due cose erano legate. I posizionamenti inbound, un messaggio in-app, una content card, una code-based experience, restavano visibili finché il profilo stava nel journey che li aveva messi lì. Se un cliente converte il secondo giorno di un journey di onboarding di cinque giorni, la card promozionale pensata per spingere la conversione continua a comparire, perché l’unico modo pulito per toglierla era togliere la persona dal journey. E così si toglieva anche tutto quello che il journey doveva fare dopo, la sequenza di benvenuto, i promemoria di configurazione, i consigli per il primo utilizzo, di cui il cliente ha ancora bisogno.

I team aggirano il problema da anni. Alcuni spezzano un journey in due, così che l’uscita dal primo chiuda l’offerta mentre il secondo prosegue. Altri aggiungono a ogni posizionamento inbound condizioni che leggono un attributo di profilo aggiornato da un altro processo. Funzionano entrambi, ed entrambi distribuiscono una sola decisione in punti che col tempo si allontanano. Con la Stop action la decisione sta dove deve stare: nel punto del journey in cui il motivo per fermarsi diventa vero, con il journey che intanto continua.

Per come la leggo, questo cambia l’aspetto del documento di design. Per ogni posizionamento inbound le domande diventano due: quale evento deve spegnere questo posizionamento? E quale evento deve chiudere il journey? Spesso sono diversi, e scriverli separatamente è il primo passo per farli giusti entrambi. Lo stesso rilascio ha aggiunto un pulsante Validate on demand, che esegue i controlli di configurazione e sui messaggi quando chi progetta è pronto a testare o pubblicare. Su un canvas che ora contiene la propria logica di uscita, è un buon punto per verificare che ogni posizionamento abbia la sua.

Diagramma della Stop action in Adobe Journey Optimizer. Prima: un'uscita sola per tutto, perché lasciare un'offerta significava lasciare il journey, quindi si fermavano anche i passi di onboarding e offerta e journey finivano insieme. Ora, con la Stop action: due uscite separate, che tolgono un profilo da un massimo di cinque attività inbound mentre il journey continua, quindi l'offerta finisce e il journey prosegue. Una fascia in basso dice: per ogni posizionamento inbound, scrivi due eventi, uno lo spegne e uno chiude il journey.

Anche l’uscita da un segmento deve viaggiare

I segmenti hanno lo stesso squilibrio. Le regole di ingresso ricevono attenzione, e la rimozione si dà per scontata. Un presupposto che si indebolisce ogni volta che un segmento esce dalla piattaforma in cui è stato costruito.

Insider ha documentato un ChatGPT Ads Remarketing Segment che invia un Dynamic Segment a ChatGPT Ads come custom audience e lo tiene sincronizzato: “Users who entered the segment are added, and users who left the segment are removed.” Vengono inviati solo indirizzo email e numero di telefono, normalizzati e cifrati con hash SHA-256, e Insider precisa che “No other identifiers or attributes are sent.” Nota anche che ChatGPT Ads elabora ogni aggiornamento prima che l’audience cambi, quindi l’effetto di una sync non è immediato. Dell’assistente come canale pubblicitario ho scritto nel ventesimo articolo della serie; qui il punto è la rimozione.

Bloomreach ha affrontato la stessa meccanica dall’altro lato. La Release 1.320 introduce gli external segment: segmenti definiti in un sistema sorgente come un data warehouse vengono registrati in Bloomreach, gli aggiornamenti di appartenenza arrivano con un push da quella sorgente e i segmenti si usano poi come proprietà del cliente. Dove debba vivere quello stato è una domanda che ho trattato nel quindicesimo articolo.

Entrambi i rilasci rendono visibile che una rimozione ha un percorso e un ritardo. Un cliente che si disiscrive, si lamenta o converte esce dal segmento sorgente in un momento, ed esce dall’audience a pagamento o dalla piattaforma di engagement in un momento successivo, dopo un push programmato e l’elaborazione della destinazione. Per i casi di soppressione quel ritardo è tutta la questione, e merita un numero nel design, non un’ipotesi.

Diagramma del percorso di un'uscita da un segmento. Passo uno, sorgente: il cliente esce, perché si disiscrive, si lamenta o converte nella piattaforma o nel warehouse. Passo due, push: la modifica aspetta la prossima sync programmata, come in Insider e Bloomreach. Passo tre, destinazione: il sistema ricevente elabora l'aggiornamento prima che l'audience cambi. Una fascia in basso dice che per la soppressione il ritardo tra il passo uno e il passo tre è il numero su cui progettare.

Anche le integrazioni hanno un ciclo di vita

Le integrazioni sono la parte meno visibile di uno stack di marketing, e se ne vanno in silenzio anche loro. Salesforce ha comunicato agli amministratori che i refresh token non usati da più di trenta giorni verranno revocati per le connected app e le external client app, prima nelle sandbox e poi in produzione, con le date riportate nella Watch di questa settimana. La comunicazione stessa elenca i casi probabili: job batch, integrazioni stagionali, client usati di rado.

Negli stack di marketing quell’elenco descrive un tipo preciso di connettore: quello che si sveglia per una campagna natalizia, una ricarica annuale del programma fedeltà o una sync trimestrale, e nel frattempo dorme. Se il token dietro di lui è stato revocato, il connettore fallisce proprio il giorno in cui serve, e qualcuno deve rifare il login o autorizzarlo di nuovo. La soluzione è organizzativa: un responsabile e una voce in calendario per ogni connettore che non gira tutti i mesi.

Hightouch, un vendor che seguo nella mia watchlist ma non uso in produzione, ha acquisito Strata, che descrive come “an agent-driven platform for building and maintaining custom API integrations without code”. L’agente mappa campi ed eventi, genera l’integrazione e, nelle parole di Hightouch, “keeps it running as systems change”. I fondatori di Strata si sono conosciuti come primi dipendenti di Iterable, buon segno che il problema che risolvono viene dalla pratica.

Letti insieme, i due fatti descrivono la stessa realtà dai due capi opposti. Le integrazioni richiedono cura molto dopo essere state costruite: invecchiano, le credenziali scadono e i sistemi alle due estremità cambiano, e che la manutenzione la faccia una persona o un agente, qualcuno deve sapere quali integrazioni esistono e quando ognuna ha funzionato l’ultima volta.

Revocare deve essere facile quanto dire sì

La versione normativa della stessa idea arriva in Italia il 29 ottobre. Il Garante ha ribadito che entro quella data aziende, piattaforme e newsletter devono allineare informative, consensi e revoca per i tracking pixel nelle email alle sue linee guida di aprile, e ha inserito la verifica tra le attività ispettive del secondo semestre 2026. La nota del Garante dice che gli utenti devono poter revocare il consenso in modo semplice, “anche selettivamente”. Non sono un avvocato, e il riferimento è la pagina dell’autorità; la meccanica del consenso come campo di profilo è nel ventunesimo articolo.

Quello che mi colpisce è dove finisce di solito lo sforzo. Klaviyo, anche lui nella mia watchlist, ha aggiunto il consenso al tracciamento email ai moduli di iscrizione, e la raccolta è appunto la parte che quasi tutti gli stack progettano con cura. L’interruttore di spegnimento, e dove si propaga, riceve meno attenzione. Una revoca che aggiorna il profilo ma non l’export verso la piattaforma pubblicitaria, o non il campo letto dalla piattaforma di invio, è una revoca che nessuno può dimostrare.

Un inventario delle uscite

Ciascuno di questi rilasci dà ai team uno strumento migliore per uscire, e nessuno decide quando uscire o con che velocità. Stando alla documentazione pubblica al momento della pubblicazione, quella decisione resta al team che gestisce lo stack. Aggiungerei una pagina a ogni design di una CEP: per ogni punto di ingresso, un journey, un posizionamento inbound, un segmento, una sync di audience, una credenziale di integrazione, un consenso, l’evento che toglie qualcuno, ogni sistema che la rimozione deve raggiungere e quanto tempo ci mette ad arrivarci.

Diagramma di un inventario delle uscite, una pagina per ogni design di CEP. Punto di ingresso: cosa lo avvia, che sia un journey, un posizionamento inbound, un segmento, una sync di audience, una credenziale o un consenso, una riga ciascuno. Rimozione: l'evento che toglie qualcuno e ogni sistema che deve raggiungere. Latenza: il tempo prima che l'ultimo sistema rifletta la rimozione, come numero misurato. Una fascia in basso dice: progetta l'uscita, e misura quanto tempo richiede.

L’uscita da un journey, da un segmento o da un’integrazione oggi si può progettare: progettala, e misura quanto tempo richiede.

Fonti

Adobe Journey Optimizer

  • Release notes. Fonte per la descrizione della Stop action, il limite di cinque attività inbound e il pulsante Validate on demand.



Insider

  • ChatGPT Ads Remarketing Segment. Fonte per il comportamento della sync, gli identificativi inviati e cifrati con hash e il ritardo di elaborazione in ChatGPT Ads.



Bloomreach

  • Release 1.320. Fonte per gli external segment, gli aggiornamenti di appartenenza inviati dal sistema sorgente e il targeting come proprietà del cliente.



Salesforce

  • MarTech Watch, Settimana 42. Fonte per il limite di inattività dei refresh token, le date di applicazione e i casi indicati da Salesforce, dalla comunicazione agli amministratori.



Hightouch



Regolazione



Klaviyo

  • What’s New. Fonte per il consenso al tracciamento email nei moduli di iscrizione.



Il record



Il digest alla base di ogni articolo settimanale è prodotto attraverso una scansione strutturata, assistita dall’AI, di release note ufficiali e fonti di product update. Io rivedo l’output, verifico i segnali rilevanti e scrivo l’interpretazione architetturale.

Questo articolo si basa sulle scansioni del Martech Weekly Digest eseguite il 15 ottobre 2026, che coprivano il periodo dal 9 al 15 ottobre su diverse piattaforme CEP e vendor. Il record datato che ne sta alla base è in MarTech Watch, Settimana 42.

Se trovate errori o lacune nella copertura, voglio saperlo. Il processo migliora quando l’output viene messo in discussione.

Apri a dimensione piena