Questo articolo è una traduzione assistita dall’AI dell’originale in inglese, revisionata dall’autore.
C’è una versione della scansione settimanale MarTech che copre generatori di contenuti AI e nuovi widget di dashboard. Non è questo il caso. Qui il punto è l’infrastruttura che determinerà se la tua CEP riesce davvero a scalare.
Il rilascio AJO di maggio 2026 è uscito questa settimana, ed è uno dei rilasci architetturalmente più significativi della prima metà del 2026. Non per una singola feature, ma per ciò che la combinazione di feature rivela su cosa Adobe pensa debba diventare una piattaforma di customer engagement. Il pattern è coerente con i segnali di Bloomreach e Klaviyo questa settimana.
Quando le feature smettono di essere feature
Guardiamo le release note di maggio:
- Chained orchestrated campaigns: la possibilità di collegare l’attività End di una campagna a una campagna downstream, passando il contesto runtime (generally available dal 20 maggio).
- Journey Fragments: set riutilizzabili di nodi di journey memorizzati in un inventory dedicato e inseribili in qualsiasi journey (disponibili dal 13 maggio, attualmente in Limited Availability).
- Completamento automatico per i journey Read Audience non ricorrenti, così i journey si fermano davvero quando l’ultimo profilo esce invece di restare “Live” per 91 giorni per via tecnica, come avviene oggi quando c’è una coda lunga di profili inattivi ancora tecnicamente eligible (in rollout dal 22 maggio).
- Certificate-Based Custom Authentication nelle custom action (in rollout dal 22 maggio).
- Cartelle per journey e campagne, annunciate per il 2 giugno.
Nessuna di queste è una feature marketing. Non puoi usarne nessuna per inviare un’email migliore. Sono infrastruttura operativa: gli strumenti necessari per gestire un grande quantità di journey senza che diventi ingestibile. Qualsiasi team che gestisce 50 o più journey attivi in AJO sa esattamente perché ognuna di queste conta. Journey Fragments significa scrivere il controllo di eligibility una volta e riusarlo ovunque invece di copiare la stessa sequenza di tre nodi su venti journey e fare debug indipendentemente quando i requisiti cambiano. Il completamento automatico dei journey significa che l’inventory dei journey riflette effettivamente cosa sta girando, il che conta quando si governa la compliance sul consenso, il performance reporting, o si cerca semplicemente di capire cosa è live. Lo stato è di Limited Availability per i Journey Fragments e vale la pena monitorare: i team che ne hanno bisogno adesso dovrebbero coinvolgere il loro account team Adobe invece di aspettare la GA.
L’argomento implicito di questo rilascio è che la CEP ha superato una soglia di complessità. Su scala, gestire i journey richiede la stessa disciplina di gestire il codice: modularità, riusabilità, controllo di versione, gate di governance. Adobe sta costruendo queste primitive nella piattaforma, in altre parole, sta trasformando un CEP in un sistema di programme management per le campagne.
L’RCS diventa infrastruttura di primo livello
L’altro titolo del rilascio AJO di maggio è il consolidamento di SMS, MMS e RCS sotto un’unica azione Mobile Message, con authoring RCS nativo (caroselli, azioni suggerite, rich media) costruito direttamente in Journey Optimizer.
Il problema della frammentazione dei canali nella messaggistica mobile non era che le piattaforme mancassero di connettività RCS. Molti stack di messaggistica enterprise hanno già trovato il modo di instradare RCS attraverso partner o integrazioni di canale. Il problema era raramente la pura raggiungibilità. Il problema era la frammentazione operativa. RCS richiedeva un’interfaccia di authoring separata, gestione dei template separata, logica di suppression separata e un data stream separato, tutto da integrare con l’infrastruttura SMS già esistente. Il risultato era un overhead operativo che rendeva RCS un’eccezione costosa piuttosto che un canale predefinito. I team aggiungevano RCS a casi d’uso premium specifici e continuavano a instradare tutto il resto su SMS perché la complessità di gestione cross-channel non valeva il marginal uplift.
Ciò che AJO ha rilasciato non è la connettività RCS. È l’integrazione RCS nel modello di governance dei canali esistente: una superficie di configurazione, una lista di suppression, un frequency cap, una vista di reporting. La complessità del canale scompare perché il modello operativo diventa uniforme. Per i brand che gestivano una strategia ibrida SMS/RCS con overhead di gestione separato, questo cambia la base di costo del mantenimento di RCS come canale predefinito piuttosto che eccezione.
Prima, RCS viveva in uno stack parallelo: strumenti separati, regole separate, reporting separato. Dopo questo rilascio, SMS, MMS e RCS condividono un’unica superficie operativa: configurazione, suppression, frequenza, reporting.
Questo conta di più per i brand che gestiscono già programmi ibridi SMS/RCS su scala; per tutti gli altri, abbassa silenziosamente il costo futuro di attivare RCS come default.
Bloomreach colma il gap di governance
Bloomreach ha rilasciato due release questa settimana: la 1.308, in rollout dal 4 maggio, con un pattern aggiornato di link shortener per SMS/MMS e miglioramenti alle Performance Dashboard, e la 1.309, in rollout dal 18 maggio, con il workflow di approvazione per gli scenari.
Lo scenario è sempre lo stesso: un brand nel financial services o nel settore assicurativo, o un retailer con un ampio team di agenzia che apporta modifiche all’automazione, ha bisogno di un processo di revisione strutturato prima che un journey vada live. Senza di esso, la governance del change control che il business richiede deve essere costruita fuori dalla piattaforma: processi di approvazione manuali, tracciamento su fogli di calcolo, workaround documentali. Niente di tutto questo è affidabile su scala.
La 1.309 aggiunge il passaggio di revisione nativamente. Il meccanismo di gating esiste nella piattaforma. Per le decisioni di procurement dove questo era un blocker ora non lo è più.
L’aggiornamento alle Performance Dashboard nella 1.308 affronta un tipo diverso di attrito operativo: non il setup, ma l’usabilità del monitoraggio. Ricaricamenti più veloci, caching a breve termine e meno interruzioni per limiti di richieste possono sembrare dettagli, ma contano quando i team di campagna stanno monitorando attivamente le performance durante i lanci o i periodi ad alto volume.
Insieme, la 1.308 e la 1.309 rappresentano Bloomreach che chiude sistematicamente alcuni gap di maturità operativa quando ci sono requisiti di governance. La mia lettura è che non sono miglioramenti isolati. Sembrano feedback di prospect enterprise convertiti in impegni di roadmap.
La composability come filosofia di design
C’è qualcosa che vale la pena osservare nell’insieme del rilascio AJO. Chained orchestrated campaigns. Journey Fragments. Personalizzazione loop-based per dati relazionali: un nuovo blocco che itera su ordini, account o prenotazioni e genera un blocco di contenuto per record in una singola email (annunciato per il 1 giugno). AEM Content Fragments nel Decisioning. File-based targeting per le orchestrated campaigns (annunciato per il 1 giugno). E su AEP, chained activation nell’Audience Composition, in rilascio nello stesso ciclo.
Questa è una filosofia di design coerente, non un elenco di feature. Adobe sta costruendo la composability nell’intero livello di esecuzione: costruisci una volta, riusa su journey, campagne, canali, logica delle offerte. Journey Fragments stanno al journey design come i moduli di codice stanno all’ingegneria del software. Le chained campaigns decompongono l’orchestrazione complessa in flussi riutilizzabili. La personalizzazione loop-based genera dati relazionali senza richiedere varianti di template separate. AEM Content Fragments nel Decisioning permette allo stesso contenuto di servire sia l’authoring delle campagne che la selezione delle offerte senza duplicazione.
Il prerequisito, e questo è importante per chiunque stia pianificando implementazioni AEP/AJO, è un’architettura dei contenuti e un modello di dati abbastanza disciplinati da poter sfruttare la composability. In concreto, questo significa una tassonomia AEM coerente, content fragment che mappano a concetti di business piuttosto che a campagne, e schemi relazionali per ordini, account o prenotazioni coerenti tra i mercati. Un brand con tassonomia degli asset incoerente, content fragment non strutturati e modelli relazionali ad hoc non beneficerà di queste capacità finché quelle fondamenta non saranno al loro posto.
La piattaforma è già più avanti della maggior parte delle implementazioni attuali. Ed è proprio quel divario a rappresentare il vero rischio di delivery nelle conversazioni di scoping.
Il segnale AWS Marketplace di Klaviyo
Klaviyo è approdata su AWS Marketplace il 19 maggio. I brand enterprise possono ora usare la spesa impegnata AWS EDP per acquistare Klaviyo, semplificando i contratti e accelerando il procurement dei vendor attraverso i framework di spesa cloud esistenti.
Questa non è una feature di prodotto. Ma il segnale di categoria vale la pena notare.
AWS Marketplace è dove va il procurement tecnologico enterprise. I brand che valutano Klaviyo tramite AWS Marketplace hanno un profilo acquirente diverso rispetto ai brand mid-market e SME dove Klaviyo ha costruito la sua installed base. Hanno cicli di vendita più lunghi, governance di procurement più complessa e relazioni esistenti con i team account AWS che possono fare co-sell. Sono anche i brand che svolgono le stesse valutazioni CEP dove Braze, Bloomreach, Insider e occasionalmente AJO sono nella shortlist.
Ciò che cambia con il listing AWS non è cosa Klaviyo può fare: è come i team di procurement enterprise possono acquistarla. È la stessa modalità in cui operano già Braze e Bloomreach. Rimuove un ostacolo strutturale di procurement che in precedenza poteva rendere Klaviyo più difficile da valutare nelle dinamiche di acquisto enterprise.
Proprio come Adobe e Bloomreach stanno costruendo infrastruttura operativa nel prodotto, Klaviyo sta costruendo infrastruttura di procurement attorno ad esso. Tutti e tre i segnali indicano CEP che maturano in sistemi adatti al programme management enterprise, non solo all’esecuzione di campagne.
La profondità di prodotto Spring 2026 di Klaviyo la posiziona per quelle valutazioni in termini di prodotto: Customer Agent su email, WhatsApp e live chat; RCS GA; Composer AI per la generazione di campagne; multi-email profile; ottimizzazione del send time a livello individuale. Il listing AWS Marketplace è l’infrastruttura GTM a corrispondere. Da tenere d’occhio: gli annunci sui tier di packaging e contratto enterprise che seguiranno.
Cosa significa per i practitioner
Se stai gestendo una selezione o rivalutazione CEP nel 2026, i criteri di valutazione devono includere l’infrastruttura operativa, non solo la capability di canale.
La domanda “la piattaforma supporta RCS?” è meno interessante di “come appare il modello operativo per gestire RCS insieme a SMS, e chi si fa carico dell’overhead di governance?” La domanda “la piattaforma ha la personalizzazione AI?” è meno interessante di “quale architettura dati è necessaria perché l’AI funzioni alla risoluzione di cui ho bisogno, e ce l’ho?”
In termini pratici, la prossima valutazione CEP dovrebbe includere domande come queste:
- Come gestisce la piattaforma la governance dei canali su SMS, MMS e RCS come un unico sistema operativo?
- Quali primitive di governance esistono per journey e campagne: approvazioni, cartelle, fragment riutilizzabili o controlli di versioning?
- Quale disciplina nel contenuto e nel modello di dati è necessaria prima che le feature di composability e AI diventino utilizzabili su scala?
- Dove si posiziona la complessità operativa una volta che la piattaforma è live: all’interno dei controlli nativi o in workaround di processo esterni?
Il rilascio di maggio di Adobe è notevole non perché ha aggiunto feature, ma perché ha aggiunto infrastruttura. Il CEP non sta diventando un software di project management. Sta diventando, però, il livello di controllo operativo dei programmi di customer engagement su larga scala. Le piattaforme che stanno facendo bene questa transizione sono quelle che costruiscono primitive di governance, pattern di riusabilità e controlli operativi insieme alle headline AI capabilities.
Fonti
Adobe Journey Optimizer
Adobe Experience Platform
Bloomreach Engagement
Klaviyo
Il digest alla base di ogni articolo settimanale è prodotto attraverso una scansione strutturata assistita dall’AI delle release note ufficiali e delle fonti di aggiornamento prodotto. Revisiono l’output, verifico i segnali rilevanti e scrivo l’interpretazione architetturale.
Questo articolo si basa sulle scansioni del Martech Weekly Digest del 21 maggio 2026, che coprono release note e aggiornamenti prodotto di 11 piattaforme CEP e 10 vendor.
Se trovi errori o lacune nella copertura, voglio saperlo. Il processo migliora quando l’output viene messo in discussione.