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

12 min di lettura

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

La decisione passa alla persona, lo storico rimane a noi

Ogni audit sul consenso a cui ho partecipato si chiude sulla stessa domanda, e non è mai quella per cui il team si era preparato. Nessuno chiede se il banner dei cookie fosse conforme o se il preference center funzionasse. Si chiede che cosa sapevamo esattamente di questa persona nel momento in cui le abbiamo inviato questo messaggio, e se siamo in grado di dimostrarlo. Due fra le piattaforme che uso in produzione hanno rilasciato modifiche che rendono più facile rispondere a quella domanda nel momento dell’azione e, per come la leggo, più difficile rispondere dopo.

TL;DR

  • Anche Iterable ha trasformato il pixel di open tracking in un valore di consenso per singolo destinatario. Con la nuova impostazione attiva, l’email marketing porta il pixel solo se emailTrackingPixelConsent è esattamente il booleano true, e un valore mancante vale come rifiuto.
  • Il server MCP remoto di Braze è disponibile, e l’agente si autentica come te. OAuth al posto della API key, con accesso limitato ai permessi dell’utente della dashboard.
  • Entrambe le modifiche spostano un controllo condiviso sulla singola persona, e in entrambi i casi lo storico resta a te.
  • Ottobre è un calendario. L’errore 1003 di Marketo dal 30 settembre, il guardrail TTL di Journey Optimizer dal 1° ottobre, il blocco su Audience Composition a fine mese e il termine del Garante del 29 ottobre.




Il pixel di tracciamento diventa un campo del profilo

Il 21 settembre Iterable, come gìà fatto da InsiderOne, ha documentato il consenso al pixel di tracciamento a livello di utente, disponibile da inizio ottobre. Il meccanismo è semplice, e il valore sta nei dettagli. Un’impostazione di progetto chiamata Use consent-based open tracking cambia il modo in cui Iterable decide se inserire il pixel di open tracking in un’email. Quando è attiva, un’email marketing porta il pixel solo se un booleano di sistema sul profilo del destinatario, emailTrackingPixelConsent, vale true. La documentazione è precisa su cosa significhi true: “Iterable treats only an exact boolean true as consent”, quindi la stringa “true” non conta, e un valore mancante viene trattato esattamente come un rifiuto.

Quest’ultima proprietà è la scelta di design che sottolineerei a chiunque stia pianificando il rollout. Se il campo manca, manca anche il pixel: il sistema, in caso di dubbio, sceglie di non tracciare. Iterable lo dice nel suo stesso avviso agli amministratori: se si attiva l’impostazione prima di aver caricato i valori di consenso, le email marketing ometteranno il pixel per tutti gli utenti il cui campo è false o assente. L’ordine delle operazioni conta più dell’interruttore.

Altri tre dettagli decidono come si comporta la funzione su uno stack reale. L’email transazionale non viene mai verificata e porta sempre il pixel, e Iterable classifica un invio come marketing o transazionale in base al canale del messaggio, non al nome della campagna o al template. Un team che fa passare contenuti promozionali da un canale transazionale per ragioni di deliverability avrà il pixel su quegli invii qualunque sia il valore del destinatario, e la documentazione di Iterable ricorda esplicitamente che la normativa può comunque applicarsi. Iterable poi non raccoglie il consenso e non fa backfill: il valore arriva attraverso gli stessi percorsi di aggiornamento del profilo di qualsiasi altro attributo. E Iterable conserva solo il valore corrente, con un’indicazione diretta per chi ha bisogno di più: “maintain a timestamped consent log in your own systems.”

Il contesto spiega perché arriva adesso. La sezione di compliance di Iterable cita le indicazioni della CNIL in Francia e del Garante in Italia, che separano il consenso a ricevere email marketing dal consenso a essere tracciati tramite pixel, e il termine del Garante per adeguare le pratiche di open tracking esistenti cade il 29 ottobre. Il record ha registrato una serie di controlli dei vendor su questo tema, dal toggle di open tracking nella Web UI di Adobe Campaign alla gestione del click tracking di Klaviyo, fino agli interruttori per business unit in Account Engagement di Salesforce, tutti elencati con le loro date nella MarTech Watch della settimana 39. Sono interruttori a livello di workspace, di account o di business unit. Iterable però non è la prima fra quelle che controllo ad andare oltre. Insider One documenta già lo stesso design nella sua academy, in una pagina aggiornata il 3 settembre: un’impostazione Pixel Tracking Opt-in a livello di account, nelle Email Settings, attiva il controllo al momento dell’invio, ogni email promozionale, standalone o Architect, legge l’attributo email_pixel_tracking_optin del destinatario, e un valore null vale come rifiuto. Sono quindi due delle nove a legare il pixel a un valore sul profilo di ciascun destinatario, con lo stesso default quando il valore manca, e per come la leggo questa convergenza dice più sulla direzione del consenso di quanto dica ciascun rilascio da solo.

Diagramma di come Iterable decide se un'email marketing porta il pixel di open tracking quando il consent-based open tracking è attivo, documentato il 21 settembre 2026. In verde smeraldo, un campo che vale esattamente il booleano true: pixel incluso. In ambra, un campo false o mancante, dove nemmeno la stringa "true" conta: nessun pixel. In indaco, l'email transazionale: pixel sempre incluso, mai verificato, classificato in base al canale del messaggio. Una fascia in basso ricorda che Iterable conserva solo il valore corrente e che il log del consenso con timestamp spetta a te.

L’agente si autentica come te

Il rilascio di Braze del 17 settembre, pubblicato dopo la chiusura dell’edizione della settimana scorsa, ha reso disponibile il server MCP ospitato da remoto. La release note lo descrive in una frase che contiene tutto il design: l’accesso “is limited by the signed-in user’s permissions and OAuth scopes”, senza pacchetto locale, senza file di configurazione e senza API key.

La documentazione MCP spiega che cosa significa sul piano operativo. Si collega un client supportato con un URL e ci si autentica con il proprio account Braze, e “If a dashboard user loses access in Braze, the client loses access too.” Il server ospitato in locale, rilasciato ad agosto 2025, è deprecato. I tool che espongono PII a livello di utente non sono disponibili, quindi l’agente lavora su aggregati, configurazione e contenuti. La superficie dei tool non è cambiata rispetto alla tabella registrata nella settimana 37: la colonna Access di Braze marca 34 dei suoi 71 tool come create, update, delete o write, e un sottoinsieme, che comprende l’avvio e l’arresto delle campagne, è disponibile solo ai clienti nei programmi beta.

Due righe della documentazione contano per la pianificazione del rollout più dell’annuncio stesso. I clienti che usano l’IP allowlisting non possono ancora usare il server remoto, il che lo esclude per alcuni stack enterprise finché la cosa non cambia. E il disclaimer legale di Braze dice che la piattaforma “does not see your original natural-language prompt”, riceve la chiamata al tool esattamente come l’ha formulata il modello del client, e sconsiglia di usare l’auto-mode del client per le azioni. La piattaforma verifica chi sei e cosa puoi fare; è il client a decidere se una persona rivede ogni azione prima che venga eseguita.

Braze affianca a tutto questo una voce più discreta nello stesso rilascio: il provisioning SCIM che sincronizza i gruppi da Okta e Microsoft Entra ID sui custom role di Braze. Letti insieme, l’identità che un agente eredita diventa quella gestita dal tuo identity provider, che è poi, nella mia esperienza, l’assetto che i team di sicurezza chiedono per primo.

Una sola scelta di design, e i compiti che lascia

In superficie le due modifiche non hanno niente in comune. Una riguarda il cliente, l’altra l’operatore. Una vive nella pipeline di rendering delle email, l’altra in un flusso di autenticazione. Eppure prendono la stessa decisione, e vale la pena darle un nome perché tornerà nel resto dello stack.

Entrambe sostituiscono un controllo condiviso e a grana grossa con un valore che appartiene a una sola persona e viene valutato nel momento dell’azione. Il pixel dipende ora dal campo di questo destinatario, letto quando questa email viene renderizzata, e l’impostazione di progetto fa solo da interruttore generale. L’agente dipende dai permessi di questo operatore nella dashboard, verificati su questa richiesta, dove prima dipendeva da una API key con scope fissi. E in entrambi i casi, quando il valore manca, vince l’esito sicuro: niente campo di consenso, niente pixel; niente accesso alla dashboard, niente agente.

È la direzione giusta, e non contesterei nessuna delle due implementazioni. Quello che cambia, per come la leggo, è dove vive la prova. Quando il controllo era a grana grossa, anche la prova lo era, ma era stabile: un’impostazione di progetto ha un change log, una API key ha una data di creazione e uno scope. Quando il controllo è per persona e valutato al rendering o alla richiesta, la domanda di un auditor diventa “che cosa diceva il valore di questa persona in quel momento?”, e la piattaforma non è necessariamente il sistema in grado di rispondere. Iterable lo dice esplicitamente per il consenso. Per l’accesso degli agenti, sapere quali permessi aveva un utente nella dashboard il giorno in cui è partita una chiamata a un tool dipende da come vengono registrate le modifiche ai permessi, cosa che ogni vendor gestisce a modo suo e che la documentazione del server MCP non affronta.

I compiti quindi sono gli stessi per entrambi. Conserva il tuo storico del valore per persona, con i timestamp, in un sistema che controlli: un registro del consenso per il pixel e, per l’accesso degli agenti, una traccia nel tempo di ruoli e appartenenza ai gruppi, che il tuo identity provider potrebbe già tenere se glielo chiedi. Le piattaforme hanno spostato la decisione sul singolo. La traccia di quella decisione tocca ancora a noi.

Diagramma della scelta di design condivisa da due modifiche della settimana 39. A sinistra, Iterable e il cliente: il campo di questo destinatario, letto al rendering dell'email, dove un valore mancante significa nessun pixel. A destra, il server MCP di Braze e l'operatore: i permessi di questo utente, verificati a ogni richiesta, dove nessun accesso alla dashboard significa nessun agente. Una fascia in basso indica i compiti: conservare il proprio storico con timestamp di ogni valore per persona.

Due modi nuovi in cui una journey sbaglia in silenzio

L’ondata di settembre di Adobe per Journey Optimizer, pubblicata nelle release note, contiene una funzione che aspettavo da anni e due comportamenti che aggiungerei a ogni runbook operativo.

La funzione è Compare journey versions in CX Enterprise Coworker, che restituisce quello che Adobe chiama “a full-fidelity, structured diff” fra due versioni qualsiasi di una journey: nodi aggiunti, rimossi, modificati o spostati, dettaglio a livello di campo, connessioni cambiate e proprietà della journey, senza aprire il canvas. Il release management delle journey complesse si è sempre basato su screenshot e memoria. Un diff strutturato è qualcosa che un approvatore può firmare.

Il primo comportamento è il nuovo trigger dopo la valutazione batch dell’audience. Una journey ricorrente su un’audience batch ora può attendere fino a sei ore una valutazione aggiornata e, se non arriva, quell’occorrenza viene saltata. Inviare all’audience di ieri era il vecchio errore. Un’esecuzione saltata è quello nuovo, e non sembra un errore se non lo stai cercando.

Il secondo è ancora nella sezione Coming soon, quindi può cambiare: un timeout di recupero automatico degli eventi che, per impostazione predefinita, riproduce gli eventi delle journey coinvolte fino a 72 ore dopo un’interruzione del servizio, con un’impostazione per accorciare la finestra nelle journey sensibili al tempo. Il replay è il default giusto per la resilienza. Significa però anche che una journey può agire su un evento vecchio di quasi tre giorni, a meno che qualcuno non abbia deciso diversamente per quella journey. Per un avviso di prezzo o un messaggio di carrello abbandonato, quella decisione va messa nel runbook prima del prossimo incidente.

Il calendario di ottobre

Quello che rende insolito questo autunno è il numero di modifiche datate in arrivo prima di novembre per i team che usano queste piattaforme in Europa. Il limite sulle liste statiche degli endpoint Get Lead Activities e Get Lead Changes di Marketo comincia a restituire l’errore 1003 a 10.000 lead dal 30 settembre. Journey Optimizer applica il guardrail sul time-to-live dei dataset alle sandbox esistenti dal 1° ottobre. Il consenso al pixel di Iterable diventa disponibile a inizio ottobre. Adobe dichiara che con il rilascio di ottobre, a fine mese, Journey Optimizer fermerà le journey e le campagne che usano un’audience di Audience Composition il cui dataset di origine non ha un primary identity descriptor: è la voce di questa lista che controllerei per prima, perché l’effetto è una journey ferma e non un avviso. E il termine del Garante per l’open tracking delle email cade il 29 ottobre.

Più in là, Marketo ha fissato una fine per la sua interfaccia Classic: la New UI raggiunge la general availability entro la fine di settembre e la possibilità di scegliere la Classic UI resta fino al rilascio di gennaio 2027. Niente di tutto questo è drammatico. Messo insieme, però, è un calendario, e i calendari sono proprio ciò che potrebbe slittare quando ogni team pensa che sia un altro a tenerlo d’occhio.

Linea del tempo di cinque modifiche datate prima di novembre 2026: Marketo restituisce l'errore 1003 sulle liste da 10.000 lead dal 30 settembre, il guardrail TTL dei dataset di Journey Optimizer sulle sandbox esistenti dal 1° ottobre, il consenso al pixel per destinatario di Iterable a inizio ottobre, il termine di adeguamento del Garante sull'open tracking il 29 ottobre, e il blocco di Journey Optimizer sulle audience di Audience Composition senza primary identity descriptor a fine ottobre. Una fascia in basso invita a controllare per primo quest'ultimo, perché l'effetto è una journey ferma e non un avviso.

Cosa valuta oggi il Magic Quadrant

Il Gartner Magic Quadrant 2026 per i Multichannel Marketing Hubs è uscito con data del report 22 settembre, e Braze ha annunciato di essere Leader per il quarto anno consecutivo, posizionata più in alto per Ability to Execute e più avanti per Completeness of Vision. Non ho ancora verificato le posizioni degli altri vendor e non le commenterò qui.

Leggo questi report più per i criteri che per i puntini, e il companion Critical Capabilities è di solito il documento più utile in un processo di selezione, perché valuta i vendor su casi d’uso specifici. La mia aspettativa, dato che il report non l’ho letto per intero, è che la governance dell’accesso degli agenti stia più al centro della valutazione di quest’anno rispetto a due anni fa. Se è così, le domande di questo articolo sono quelle che un buyer dovrebbe portare a ogni vendor della shortlist: quando il controllo passa al singolo, dove vive lo storico del suo valore, e chi è in grado di produrlo il giorno in cui viene richiesto?

Le piattaforme hanno spostato la decisione sulla persona. Conservare la traccia di quella decisione resta compito nostro.

Fonti

Iterable



Insider One

  • Email Open Tracking Consent. Fonte per l’impostazione Pixel Tracking Opt-in a livello di account, l’attributo email_pixel_tracking_optin, il valore null trattato come rifiuto, il perimetro delle email promozionali e Architect e le scadenze di CNIL e Garante.



Braze



Adobe

  • Journey Optimizer release notes. Fonte per Compare journey versions, il trigger dopo la valutazione batch dell’audience, il timeout di recupero degli eventi in Coming soon, il blocco su Audience Composition e il guardrail TTL dei dataset.
  • Marketo Engage current release notes. Fonte per le date della New UI e della Classic UI e per il limite sulle liste statiche.



Il record

  • MarTech Watch, Week 39. Ogni data, stato e controllo dei vendor citato in questo articolo, compresi gli interruttori di tracciamento precedenti di Adobe Campaign, Klaviyo e Salesforce Account Engagement.
  • MarTech Watch, Week 37. Il primo conteggio della tabella dei tool MCP di Braze.


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 24 settembre 2026, che coprivano il periodo dal 18 al 24 settembre su diverse piattaforme CEP e vendor. Il record datato che ne sta alla base è in MarTech Watch, Settimana 39.

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

Apri a dimensione piena