La Superficie di Tracciamento SFMC

Ai fini del consenso è utile trattare SFMC non come un singolo prodotto ma come quattro superfici di tracciamento sovrapposte, ciascuna con il proprio schema di integrazione.

Web Analytics Connector e Codice di Tracciamento Collect

Il codice di tracciamento Collect (spesso chiamato collect.js o referenziato tramite cdn.evgnet.com) è il tracker comportamentale di SFMC. Imposta i cookie _etmc e correlati, identifica i visitatori tra le sessioni e invia eventi di visualizzazione pagina, clic e conversione a SFMC per l'uso nei trigger Journey Builder e nel retargeting via email. Dal punto di vista normativo è chiaramente un tracker di marketing — anche se gli eventi sembrano analitici, i dati alimentano l'automazione del marketing diretto.

Script Marketing Cloud Personalization

Lo script Personalization (ex Interaction Studio) è più pesante di Collect. Carica un SDK che monitora l'intero DOM, cattura i dati di click-stream e di interazione con i moduli, e li invia a un motore decisionale di personalizzazione che può riscrivere il contenuto della pagina in tempo reale. I cookie impostati includono gli identificatori _ev_* e un token di sessione. Si tratta di elaborazione a scopo di marketing inequivocabile e richiede il consenso opt-in in qualsiasi giurisdizione EU o UK.

Moduli CloudPages e link tracciati

Le landing page ospitate da CloudPages e i link email tracciati che transitano attraverso SFMC portano i propri parametri identificativi (subscriberkey, jb, parametri mid negli URL). Quando un visitatore arriva tramite un link tracciato, SFMC può correlare la sessione con il loro record di iscritto anche prima che si attivi il tracciamento nella pagina. Questa è una posizione legale significativamente diversa dal tracciamento anonimo — l'identità dell'iscritto è nota al primo contatto — e il consenso per le comunicazioni di marketing deve essere già presente.

Connettori Data Cloud

L'integrazione Data Cloud di SFMC (il livello della piattaforma dati cliente) raccoglie identificatori dal tracciamento web, dagli SDK mobili, dai record CRM e dai dati offline in un profilo unificato. Lo stato del consenso deve propagarsi nel Data Cloud, non solo nel pixel di tracciamento a livello superficiale, affinché le attivazioni downstream verso le reti pubblicitarie rispettino le preferenze registrate del visitatore.

Controlli sulla Privacy SFMC Nativi

SFMC espone diversi controlli nativi ma, come per la maggior parte delle piattaforme di marketing enterprise, assumono che una decisione sul consenso sia stata raccolta a monte e venga trasmessa. I controlli nativi non raccolgono il consenso autonomamente.

Opt-out del tracciamento per Web Analytics Connector

Lo script Collect legge un flag do_not_track e una funzione di opt-out configurabile. Impostarli impedisce a Collect di inviare dati ma non impedisce allo script stesso di caricarsi. Per le giurisdizioni con consenso preventivo è necessario bloccare il caricamento dello script, non solo attivare/disattivare il flag.

Preferenze di consenso nei record degli iscritti

Il profilo dell'iscritto in SFMC ha campi per il consenso alle comunicazioni, il consenso ai dati del profilo e la base giuridica. Questi sono i primitivi giusti per tracciare la base giuridica con cui un contatto noto viene commercializzato, e il CMP dovrebbe riscrivere in questi campi quando un visitatore accetta o revoca.

Consenso Marketing Cloud Personalization

L'SDK Personalization accetta un flag di consenso durante l'inizializzazione. Impostarlo su false finché l'utente non ha accettato la categoria marketing nel banner CMP, poi reinizializzare l'SDK quando il consenso viene concesso.

Integrazione CMP Passo-Passo

L'architettura affidabile consiste nel bloccare tutte e quattro le superfici di tracciamento dietro il CMP e usare i flag nativi di SFMC per perfezionare il comportamento downstream una volta concesso il consenso.

1. Impedire allo script Collect di caricarsi per impostazione predefinita

Rimuovere lo script Collect dall'intestazione del documento e sostituirlo con un segnaposto che il CMP può attivare. Quando il visitatore accetta la categoria marketing, il CMP riscrive il segnaposto per caricare collect.js. Tutti gli eventi in coda vengono svuotati al caricamento.

2. Differire l'inizializzazione di Marketing Cloud Personalization

Lo script Personalization non deve inizializzarsi prima del consenso. La maggior parte dei CMP gestisce questo con un pattern di caricamento differito: l'elemento script è presente nel DOM ma il suo attributo type è text/plain, e il CMP lo riscrive in text/javascript all'accettazione del consenso.

3. Bloccare i parametri di tracciamento di CloudPages

Se un visitatore arriva tramite un link tracciato e non ha ancora dato il consenso, il parametro subscriberkey in ingresso dovrebbe essere acquisito ma non utilizzato per guidare la personalizzazione immediata. Il pattern corretto è memorizzarlo nello stato di sessione e attivarlo solo (correlando con i dati del profilo, attivando gli eventi Journey Builder) una volta registrato il consenso.

4. Propagare lo stato del consenso al Data Cloud

L'integrazione Data Cloud deve conoscere lo stato del consenso di ogni visitatore affinché le attivazioni downstream lo rispettino. SFMC supporta un'estensione del consenso che consente al CMP di scrivere un record di consenso nel Data Cloud tramite API. Configurarla in modo che la decisione sul consenso del CMP diventi la fonte di verità nell'intero livello SFMC, non solo per gli script nella pagina.

5. Mappare ai campi di consenso dell'iscritto SFMC

Quando un iscritto noto aggiorna il proprio consenso in un centro preferenze CloudPages, il CMP e il record dell'iscritto SFMC devono rimanere sincronizzati. Configurare un write-back dal CMP nei campi di consenso dell'iscritto SFMC, e configurare un read-back in modo che il banner nella pagina rispetti le preferenze email impostate dall'iscritto.

Insidie Comuni

Tre errori di integrazione sono responsabili della maggior parte dei risultati degli audit enterprise su SFMC.

Trattare Collect come analisi

Poiché lo script Collect segnala visualizzazioni di pagina ed eventi clic che sembrano analitici, i team a volte lo bloccano nella categoria di consenso analisi. SFMC utilizza quei dati per guidare l'automazione del marketing Journey Builder, che è elaborazione a scopo di marketing inequivocabile. Bloccare Collect sotto marketing.

Permettere a Personalization di funzionare prima del consenso

Personalization è la più pesante delle superfici di tracciamento SFMC e la più visibile ai regolatori perché modifica attivamente la pagina. Permetterle di inizializzarsi prima del consenso è, in termini di audit, il singolo schema più esposto nello stack SFMC.

Non sincronizzare il consenso nell'intero stack

Se il banner nella pagina registra una decisione sul consenso ma il profilo Data Cloud conserva uno stato più vecchio, le attivazioni downstream verso le reti pubblicitarie continueranno ad attivarsi in base a un consenso obsoleto. Il CMP deve possedere la fonte di verità e propagarla ovunque lo stack SFMC possa raggiungere.

Checklist di Audit

Cinque domande concrete a cui rispondere per qualsiasi implementazione SFMC che tocca traffico EU, UK o californiano.

• Collect attende il consenso? Confermare che nessuna richiesta collect.js o evgnet.com si attiva prima dell'accettazione del banner.
• Personalization è differita? Confermare che l'SDK Personalization non si inizializza fino a quando la categoria marketing non viene concessa.
• I parametri dei link tracciati in ingresso vengono trattenuti fino al consenso? Confermare che la personalizzazione guidata da subscriberkey attende un segnale di consenso esplicito.
• Data Cloud vede lo stato del consenso? Confermare che l'estensione del consenso è configurata e che il CMP scrive le decisioni nel Data Cloud in tempo reale.
• I campi di consenso dell'iscritto sono sincronizzati? Confermare che le modifiche al centro preferenze si propagano al banner nella pagina e viceversa.

Dove si Inserisce SFMC in uno Stack Consent-First

SFMC è una delle piattaforme di marketing più potenti — e una delle più esposte — che un'impresa possa implementare. Il pattern di installazione predefinito semplicemente non soddisfa le aspettative europee o californiane attuali, e i controlli nativi della piattaforma sono primitivi utili ma non un sostituto per un livello upstream di gestione del consenso. L'architettura corretta tratta il CMP come unica fonte di verità, blocca ogni modulo di tracciamento dietro di esso e usa le estensioni del consenso di SFMC per fare in modo che Data Cloud e i record degli iscritti propaghino quella verità in tutto il resto dello stack. Se eseguito correttamente, SFMC continua a fare ciò per cui i marketer lo hanno acquistato — trigger Journey Builder, decisioni Personalization, attivazione Data Cloud — mentre la postura di conformità sottostante corrisponde a ciò che i regolatori si aspettano ora da qualsiasi marketer enterprise.