Die SFMC-Tracking-Oberfläche

Für Consent-Zwecke ist es hilfreich, SFMC nicht als ein einzelnes Produkt, sondern als vier überlappende Tracking-Oberflächen zu behandeln, von denen jede ein eigenes Integrationsmuster hat.

Web Analytics Connector und Collect Tracking Code

Der Collect Tracking Code (oft collect.js genannt oder über cdn.evgnet.com referenziert) ist SFMCs Behavioral Tracker. Er setzt die Cookies _etmc und verwandte Cookies, identifiziert Besucher sitzungsübergreifend und leitet Pageview-, Click- und Conversion-Events an SFMC weiter, um sie in Journey Builder-Triggern und E-Mail-Retargeting zu nutzen. Aus regulatorischer Perspektive ist es eindeutig ein Marketing-Tracker — obwohl die Events wie Analytics aussehen, speisen die Daten direkt die Marketing-Automatisierung.

Marketing Cloud Personalization Skript

Das Personalization Skript (legacy Interaction Studio) ist schwerer als Collect. Es lädt ein SDK, das das gesamte DOM überwacht, Click-Stream- und Formular-Interaktionsdaten erfasst und diese an ein Personalisierungs-Decision-Engine weiterleitet, die Seiteninhalte in Echtzeit umschreiben kann. Zu den gesetzten Cookies gehören _ev_* Identifikatoren und ein Session-Token. Dies ist eindeutig Marketing-Zweck-Verarbeitung und erfordert Opt-in-Consent in jeder EU- oder UK-Gerichtsbarkeit.

CloudPages-Formulare und verfolgte Links

CloudPages-gehostete Landing Pages und die verfolgten E-Mail-Links, die durch SFMC weitergeleitet werden, tragen ihre eigenen identifizierenden Parameter (subscriberkey, jb, mid Parameter in URLs). Wenn ein Besucher über einen verfolgten Link ankommt, kann SFMC die Session mit seinem Subscriber-Record korrelieren, noch bevor ein In-Page-Tracking auslöst. Dies ist eine bedeutungsvoller andere Rechtsposition als anonymes Tracking — die Subscriber-Identität ist beim ersten Kontakt bekannt — und das Consent für Marketing-Kommunikation muss bereits vorliegen.

Data Cloud Connectoren

Die Data Cloud Integration von SFMC (die Customer Data Platform Ebene) zieht Identifikatoren aus Web-Tracking, Mobile SDKs, CRM-Records und Offline-Daten in ein einheitliches Profil. Der Consent-Status muss nicht nur in den Surface-Level-Tracking-Pixel, sondern auch in Data Cloud propagiert werden, damit nachgelagerte Aktivierungen zu Ad Networks die aufgezeichneten Präferenzen des Besuchers respektieren.

Native SFMC-Datenschutzkontrollen

SFMC stellt mehrere native Kontrollen zur Verfügung, aber wie bei den meisten Enterprise-Marketing-Plattformen gehen sie davon aus, dass eine Consent-Entscheidung bereits upstream erfasst wurde und weitergegeben wird. Die nativen Kontrollen erfassen selbst keine Consent.

Tracking-Opt-out für Web Analytics Connector

Das Collect Skript liest ein do_not_track Flag und eine konfigurierbare Opt-out-Funktion. Das Setzen dieser Parameter verhindert, dass Collect Daten sendet, aber nicht, dass das Skript selbst geladen wird. Für Prior-Consent-Gerichtsbarkeiten müssen Sie das Skript-Laden steuern, nicht nur das Flag umschalten.

Consent-Präferenzen in Subscriber-Records

Das Subscriber-Profil in SFMC hat Felder für Kommunikations-Consent, Profildaten-Consent und rechtliche Grundlage. Dies sind die richtigen Primitiven, um die rechtliche Grundlage zu verfolgen, unter der ein bekannter Kontakt vermarktet wird, und der CMP sollte in diese Felder zurückschreiben, wenn ein Besucher akzeptiert oder widerruft.

Marketing Cloud Personalization Consent

Das Personalization SDK akzeptiert ein Consent-Flag während der Initialisierung. Setzen Sie es auf false, bis der Benutzer die Marketing-Kategorie im CMP-Banner akzeptiert hat, und initialisieren Sie dann das SDK neu, wenn das Consent gewährt wird.

Schritt-für-Schritt CMP-Integration

Die zuverlässige Architektur besteht darin, alle vier Tracking-Oberflächen hinter dem CMP zu schließen und SFMCs native Flags zu verwenden, um das nachgelagerte Verhalten zu verfeinern, sobald das Consent gewährt ist.

1. Verhindern Sie, dass das Collect Skript standardmäßig geladen wird

Entfernen Sie das Collect Skript aus dem Document Head und ersetzen Sie es durch einen Platzhalter, den der CMP aktivieren kann. Wenn der Besucher die Marketing-Kategorie akzeptiert, schreibt der CMP den Platzhalter so um, dass collect.js geladen wird. Alle warteschlangigen Events spülen beim Laden.

2. Verschieben Sie die Marketing Cloud Personalization Initialisierung

Das Personalization Skript darf sich nicht vor dem Consent initialisieren. Die meisten CMPs handhaben dies mit einem Deferred-Load-Muster: Das Script-Element ist im DOM vorhanden, aber sein type Attribut ist text/plain, und der CMP schreibt es beim Consent-Akzeptanz zu text/javascript um.

3. Steuern Sie CloudPages Tracking-Parameter

Wenn ein Besucher über einen verfolgten Link ankommt und noch keinen Consent gegeben hat, sollte der eingehende subscriberkey Parameter erfasst werden, aber nicht zur Steuerung der sofortigen Personalisierung verwendet werden. Das richtige Muster besteht darin, es im Session-Status zu speichern und es nur dann zu aktivieren (Korrelation mit Profildaten, Auslösen von Journey Builder-Events), wenn das Consent aufgezeichnet ist.

4. Propagieren Sie den Consent-Status zu Data Cloud

Die Data Cloud Integration muss den Consent-Status jedes Besuchers kennen, damit nachgelagerte Aktivierungen ihn respektieren. SFMC unterstützt eine Consent-Erweiterung, mit der der CMP einen Consent-Record über API in Data Cloud schreiben kann. Konfigurieren Sie dies so, dass die Consent-Entscheidung des CMP die einzige Quelle der Wahrheit über die gesamte SFMC-Schicht wird, nicht nur für die On-Page-Skripte.

5. Ordnen Sie SFMC Subscriber Consent-Felder zu

Wenn ein bekannter Subscriber sein Consent auf einem CloudPages Preference Center aktualisiert, müssen der CMP und der SFMC Subscriber Record synchron bleiben. Konfigurieren Sie ein Write-Back vom CMP in die Consent-Felder des SFMC Subscribers, und konfigurieren Sie ein Read-Back, damit das On-Page-Banner respektiert, was der Subscriber in seinen E-Mail-Präferenzen festgelegt hat.

Häufige Fehler

Drei Integrationsfehler machen die meisten Enterprise-Audit-Erkenntnisse bei SFMC aus.

Collect als Analytics behandeln

Weil das Collect Skript Pageviews und Click-Events meldet, die wie Analytics aussehen, behandeln Teams es manchmal unter der Analytics-Consent-Kategorie. SFMC nutzt diese Daten, um die Journey Builder Marketing-Automatisierung zu steuern, was eindeutig Marketing-Zweck-Verarbeitung ist. Steuern Sie Collect unter Marketing.

Personalization vor Consent ausführen lassen

Personalization ist die schwerste der SFMC-Tracking-Oberflächen und am sichtbarsten für Regulatoren, weil sie die Seite aktiv ändert. Zulassen, dass sie sich vor dem Consent initialisiert, ist in Audit-Begriffen das einzelne am meisten offenliegende Muster im SFMC-Stack.

Consent nicht über den Stack synchronisieren

Wenn das On-Page-Banner eine Consent-Entscheidung aufzeichnet, aber das Data Cloud Profil einen älteren Status behält, werden nachgelagerte Aktivierungen zu Ad Networks basierend auf veralteter Consent weiterhin ausgelöst. Der CMP muss die Quelle der Wahrheit besitzen und überall dort propagieren, wo der SFMC-Stack reicht.

Audit-Checkliste

Fünf konkrete Fragen, die für jede SFMC-Bereitstellung mit EU-, UK- oder California-Traffic beantwortet werden müssen.

• Wartet Collect auf Consent? Bestätigen Sie, dass keine collect.js oder evgnet.com Anfrage vor der Banner-Akzeptanz abgefeuert wird.
• Ist Personalization aufgeschoben? Bestätigen Sie, dass das Personalization SDK sich nicht initialisiert, bis die Marketing-Kategorie gewährt ist.
• Werden eingehende verfolgte Link-Parameter bis zum Consent gespeichert? Bestätigen Sie, dass subscriberkey-gesteuerte Personalisierung auf ein explizites Consent-Signal wartet.
• Sieht Data Cloud den Consent-Status? Bestätigen Sie, dass die Consent-Erweiterung konfiguriert ist und der CMP Entscheidungen in Echtzeit in Data Cloud schreibt.
• Werden Subscriber Consent-Felder synchronisiert? Bestätigen Sie, dass Preference-Center-Änderungen im On-Page-Banner weitergegeben werden und umgekehrt.

Wo SFMC in einen Consent-First-Stack passt

SFMC ist eine der mächtigsten — und eine der exposantesten — Marketing-Plattformen, die ein Unternehmen einsetzen kann. Das Standard-Install-Muster erfüllt einfach nicht die aktuellen europäischen oder kalifornischen Erwartungen, und die nativen Kontrollen der Plattform sind nützliche Primitive, aber kein Ersatz für eine Upstream-Consent-Management-Ebene. Die richtige Architektur behandelt den CMP als die einzige Quelle der Wahrheit, sperrt jedes Tracking-Modul dahinter, und nutzt SFMCs Consent-Erweiterungen, um Data Cloud und die Subscriber-Records diese Wahrheit über den Rest des Stacks zu propagieren. Richtig gemacht, behält SFMC, was Marketer dafür kaufen — Journey Builder Trigger, Personalization Decisioning, Data Cloud Activation — während die zugrunde liegende Compliance-Posture dem entspricht, was Regulatoren von jedem Enterprise-Marketer erwarten.