La surface de suivi SFMC

Pour les besoins du consentement, il est utile de ne pas considérer SFMC comme un produit unique, mais comme quatre surfaces de suivi qui se chevauchent, chacune avec son propre schéma d'intégration.

Web Analytics Connector et code de suivi Collect

Le code de suivi Collect (souvent appelé collect.js ou référencé via cdn.evgnet.com) est le traceur comportemental de SFMC. Il définit les cookies _etmc et associés, identifie les visiteurs d'une session à l'autre, et transmet les événements de consultation de page, de clic et de conversion à SFMC pour une utilisation dans les déclencheurs Journey Builder et le reciblage par e-mail. D'un point de vue réglementaire, il s'agit clairement d'un traceur marketing — même si les événements ressemblent à de l'analyse, les données alimentent l'automatisation du marketing direct.

Script Marketing Cloud Personalization

Le script Personalization (l'ancien Interaction Studio) est plus lourd que Collect. Il charge un SDK qui surveille l'ensemble du DOM, capture les données de flux de clics et d'interactions avec les formulaires, et les transmet à un moteur de décision de personnalisation capable de réécrire le contenu des pages en temps réel. Les cookies définis comprennent les identifiants _ev_* et un jeton de session. Il s'agit sans ambiguïté d'un traitement à des fins marketing qui nécessite un consentement opt-in dans toute juridiction de l'UE ou du Royaume-Uni.

Formulaires CloudPages et liens trackés

Les pages d'atterrissage hébergées par CloudPages et les liens e-mail trackés qui transitent par SFMC portent leurs propres paramètres d'identification (subscriberkey, jb, paramètres mid dans les URL). Lorsqu'un visiteur arrive via un lien tracké, SFMC peut corréler la session avec son enregistrement d'abonné avant même qu'un suivi in-page ne se déclenche. Il s'agit d'une posture juridique sensiblement différente du suivi anonyme — l'identité de l'abonné est connue dès le premier contact — et le consentement aux communications marketing doit déjà exister.

Connecteurs Data Cloud

L'intégration Data Cloud de SFMC (la couche plateforme de données client) extrait les identifiants du suivi web, des SDK mobiles, des enregistrements CRM et des données hors ligne dans un profil unifié. L'état du consentement doit se propager dans Data Cloud, pas seulement dans le pixel de suivi de surface, afin que les activations en aval vers les réseaux publicitaires respectent les préférences enregistrées du visiteur.

Contrôles de confidentialité natifs de SFMC

SFMC expose plusieurs contrôles natifs, mais comme pour la plupart des plateformes marketing d'entreprise, ils supposent qu'une décision de consentement a été collectée en amont et est transmise. Les contrôles natifs ne collectent pas eux-mêmes le consentement.

Désinscription du suivi pour Web Analytics Connector

Le script Collect lit un indicateur do_not_track et une fonction de désinscription configurable. Les définir empêche Collect d'envoyer des données, mais n'empêche pas le script lui-même de se charger. Pour les juridictions à consentement préalable, vous devez bloquer le chargement du script, pas seulement basculer l'indicateur.

Préférences de consentement dans les enregistrements d'abonnés

Le profil d'abonné dans SFMC possède des champs pour le consentement à la communication, le consentement aux données de profil et la base légale. Ce sont les bons primitifs pour suivre la base juridique sur laquelle un contact connu est prospecté, et le CMP doit réécrire dans ces champs lorsqu'un visiteur accepte ou révoque.

Consentement Marketing Cloud Personalization

Le SDK Personalization accepte un indicateur de consentement lors de l'initialisation. Définissez-le sur false jusqu'à ce que l'utilisateur ait accepté la catégorie marketing dans la bannière CMP, puis réinitialisez le SDK lorsque le consentement est accordé.

Intégration CMP étape par étape

L'architecture fiable consiste à placer les quatre surfaces de suivi derrière le CMP et à utiliser les indicateurs natifs de SFMC pour affiner le comportement en aval une fois le consentement accordé.

1. Empêcher le chargement par défaut du script Collect

Supprimez le script Collect de l'en-tête du document et remplacez-le par un espace réservé que le CMP peut activer. Lorsque le visiteur accepte la catégorie marketing, le CMP réécrit l'espace réservé pour charger collect.js. Tout événement en file d'attente est vidé au chargement.

2. Différer l'initialisation de Marketing Cloud Personalization

Le script Personalization ne doit pas s'initialiser avant le consentement. La plupart des CMP gèrent cela avec un modèle de chargement différé : l'élément script est présent dans le DOM, mais son attribut type est text/plain, et le CMP le réécrit en text/javascript lors de l'acceptation du consentement.

3. Contrôler les paramètres de suivi CloudPages

Si un visiteur arrive via un lien tracké et n'a pas encore donné son consentement, le paramètre subscriberkey entrant doit être capturé mais pas utilisé pour piloter une personnalisation immédiate. Le bon modèle consiste à le stocker dans l'état de session et à ne l'activer (corrélation avec les données de profil, déclenchement d'événements Journey Builder) qu'une fois le consentement enregistré.

4. Propager l'état du consentement vers Data Cloud

L'intégration Data Cloud doit connaître l'état du consentement de chaque visiteur pour que les activations en aval le respectent. SFMC prend en charge une extension de consentement qui permet au CMP d'écrire un enregistrement de consentement dans Data Cloud via l'API. Configurez-la de sorte que la décision de consentement du CMP devienne la source de vérité pour l'ensemble de la couche SFMC, pas seulement pour les scripts en page.

5. Mapper vers les champs de consentement des abonnés SFMC

Lorsqu'un abonné connu met à jour son consentement dans un centre de préférences CloudPages, le CMP et l'enregistrement d'abonné SFMC doivent rester synchronisés. Configurez une réécriture du CMP vers les champs de consentement de l'abonné SFMC, et configurez une lecture en retour pour que la bannière en page respecte ce que l'abonné a défini dans ses préférences e-mail.

Pièges courants

Trois erreurs d'intégration expliquent la majorité des résultats d'audit d'entreprise sur SFMC.

Traiter Collect comme de l'analytique

Parce que le script Collect signale des consultations de page et des événements de clic qui ressemblent à de l'analytique, les équipes le placent parfois sous la catégorie de consentement analytique. SFMC utilise ces données pour piloter l'automatisation du marketing Journey Builder, ce qui constitue sans ambiguïté un traitement à des fins marketing. Placez Collect sous marketing.

Laisser Personalization s'exécuter avant le consentement

Personalization est la plus lourde des surfaces de suivi de SFMC et la plus visible des régulateurs parce qu'elle modifie activement la page. Lui permettre de s'initialiser avant le consentement est, en termes d'audit, le schéma le plus exposant dans la pile SFMC.

Ne pas synchroniser le consentement dans toute la pile

Si la bannière en page enregistre une décision de consentement mais que le profil Data Cloud conserve un état plus ancien, les activations en aval vers les réseaux publicitaires continueront à se déclencher sur la base d'un consentement périmé. Le CMP doit détenir la source de vérité et la propager partout où la pile SFMC peut l'atteindre.

Liste de contrôle d'audit

Cinq questions concrètes auxquelles répondre pour tout déploiement SFMC touchant le trafic de l'UE, du Royaume-Uni ou de Californie.

• Collect attend-il le consentement ? Confirmez qu'aucune requête collect.js ou evgnet.com ne se déclenche avant l'acceptation de la bannière.
• Personalization est-il différé ? Confirmez que le SDK Personalization ne s'initialise pas avant que la catégorie marketing ne soit accordée.
• Les paramètres des liens trackés entrants sont-ils conservés jusqu'au consentement ? Confirmez que la personnalisation pilotée par subscriberkey attend un signal de consentement explicite.
• Data Cloud voit-il l'état du consentement ? Confirmez que l'extension de consentement est configurée et que le CMP écrit les décisions dans Data Cloud en temps réel.
• Les champs de consentement des abonnés sont-ils synchronisés ? Confirmez que les modifications du centre de préférences se propagent à la bannière en page et vice versa.

La place de SFMC dans une pile axée sur le consentement

SFMC est l'une des plateformes marketing les plus puissantes — et les plus exposantes — qu'une entreprise puisse déployer. Le schéma d'installation par défaut ne satisfait tout simplement pas les attentes européennes ou californiennes actuelles, et les contrôles natifs de la plateforme sont des primitifs utiles mais pas un substitut à une couche de gestion du consentement en amont. L'architecture correcte traite le CMP comme la source de vérité unique, place chaque module de suivi derrière lui, et utilise les extensions de consentement de SFMC pour que Data Cloud et les enregistrements d'abonnés propagent cette vérité au reste de la pile. Fait correctement, SFMC continue de faire ce pour quoi les marketeurs l'ont acheté — déclencheurs Journey Builder, décision Personalization, activation Data Cloud — tandis que la posture de conformité sous-jacente correspond à ce que les régulateurs attendent désormais de tout marketeur d'entreprise.