The SFMC Tracking Surface

For consent purposes it helps to treat SFMC not as a single product but as four overlapping tracking surfaces, each with its own integration pattern.

Web Analytics Connector and Collect Tracking Code

The Collect tracking code (often called collect.js or referenced via cdn.evgnet.com) is SFMC's behavioral tracker. It sets the _etmc and related cookies, identifies visitors across sessions, and forwards pageview, click, and conversion events to SFMC for use in Journey Builder triggers and email retargeting. From a regulatory perspective it is squarely a marketing tracker — even though the events look analytics-like, the data feeds direct marketing automation.

Marketing Cloud Personalization script

The Personalization script (legacy Interaction Studio) is heavier than Collect. It loads a SDK that watches the entire DOM, captures click-stream and form-interaction data, and forwards it to a personalization decision engine that can rewrite page content in real time. Cookies set include _ev_* identifiers and a session token. This is unambiguously marketing-purpose processing and requires opt-in consent in any EU or UK jurisdiction.

CloudPages forms and tracked links

CloudPages-hosted landing pages and the tracked email links that route through SFMC carry their own identifying parameters (subscriberkey, jb, mid parameters in URLs). When a visitor arrives via a tracked link, SFMC can correlate the session with their subscriber record even before any in-page tracking fires. This is a meaningfully different legal posture from anonymous tracking — the subscriber identity is known at first contact — and consent for marketing communications must already exist.

Data Cloud connectors

SFMC's Data Cloud integration (the customer data platform layer) pulls identifiers from web tracking, mobile SDKs, CRM records, and offline data into a unified profile. Consent state needs to propagate into Data Cloud, not just into the surface-level tracking pixel, so that downstream activations to ad networks respect the visitor's recorded preferences.

Native SFMC Privacy Controls

SFMC exposes several native controls but, as with most enterprise marketing platforms, they assume that a consent decision has been gathered upstream and is being passed in. The native controls do not collect consent themselves.

Tracking opt-out for Web Analytics Connector

The Collect script reads a do_not_track flag and a configurable opt-out function. Setting these prevents Collect from sending data but does not prevent the script itself from loading. For prior-consent jurisdictions you need to gate the script loading, not just toggle the flag.

Consent preferences in subscriber records

The subscriber profile in SFMC has fields for communication consent, profile data consent, and lawful basis. These are the right primitives for tracking the legal basis under which a known contact is being marketed to, and the CMP should write back into these fields when a visitor accepts or revokes.

Marketing Cloud Personalization consent

The Personalization SDK accepts a consent flag during initialization. Set it to false until the user has accepted the marketing category in the CMP banner, then re-initialize the SDK when consent is granted.

Step-by-Step CMP Integration

The reliable architecture is to gate all four tracking surfaces behind the CMP and use SFMC's native flags to refine downstream behavior once consent is granted.

1. Stop the Collect script from loading by default

Remove the Collect script from the document head and replace it with a placeholder the CMP can activate. When the visitor accepts the marketing category, the CMP rewrites the placeholder to load collect.js. Any queued events flush on load.

2. Defer Marketing Cloud Personalization initialization

The Personalization script must not initialize before consent. Most CMPs handle this with a deferred-load pattern: the script element is present in the DOM but its type attribute is text/plain, and the CMP rewrites it to text/javascript on consent acceptance.

3. Gate CloudPages tracking parameters

If a visitor arrives via a tracked link and has not yet given consent, the inbound subscriberkey parameter should be captured but not used to drive immediate personalization. The right pattern is to store it in session state and only activate it (correlating with profile data, triggering Journey Builder events) once consent is recorded.

4. Propagate consent state to Data Cloud

The Data Cloud integration needs to know each visitor's consent state so downstream activations honor it. SFMC supports a consent extension that lets the CMP write a consent record into Data Cloud via API. Configure this so the CMP's consent decision becomes the source of truth across the entire SFMC layer, not just for the on-page scripts.

5. Map to SFMC subscriber consent fields

When a known subscriber updates their consent on a CloudPages preference center, the CMP and SFMC subscriber record need to stay in sync. Configure a write-back from the CMP into the SFMC subscriber's consent fields, and configure a read-back so that the on-page banner respects what the subscriber set in their email preferences.

Common Pitfalls

Three integration mistakes account for most enterprise audit findings on SFMC.

Treating Collect as analytics

Because the Collect script reports pageviews and click events that look like analytics, teams sometimes gate it under the analytics consent category. SFMC uses that data to drive Journey Builder marketing automation, which is unambiguously marketing-purpose processing. Gate Collect under marketing.

Letting Personalization run pre-consent

Personalization is the heaviest of the SFMC tracking surfaces and the most regulator-visible because it actively modifies the page. Allowing it to initialize before consent is, in audit terms, the single most exposing pattern in the SFMC stack.

Not syncing consent across the stack

If the on-page banner records a consent decision but the Data Cloud profile retains an older state, downstream activations to ad networks will keep firing based on stale consent. The CMP must own the source of truth and propagate it everywhere the SFMC stack can reach.

Audit Checklist

Five concrete questions to answer for any SFMC deployment touching EU, UK, or California traffic.

• Does Collect wait for consent? Confirm no collect.js or evgnet.com request fires before banner acceptance.
• Is Personalization deferred? Confirm the Personalization SDK does not initialize until the marketing category is granted.
• Are inbound tracked-link parameters held until consent? Confirm subscriberkey-driven personalization waits for an explicit consent signal.
• Does Data Cloud see consent state? Confirm the consent extension is configured and the CMP writes decisions into Data Cloud in real time.
• Are subscriber consent fields synced? Confirm preference-center changes propagate to the on-page banner and vice versa.

Where SFMC Fits in a Consent-First Stack

SFMC is one of the most powerful — and one of the most exposing — marketing platforms an enterprise can deploy. The default install pattern simply does not satisfy current European or California expectations, and the platform's native controls are useful primitives but not a substitute for an upstream consent management layer. The right architecture treats the CMP as the single source of truth, gates every tracking module behind it, and uses SFMC's consent extensions to make Data Cloud and the subscriber records propagate that truth across the rest of the stack. Done correctly, SFMC keeps doing what marketers bought it to do — Journey Builder triggers, Personalization decisioning, Data Cloud activation — while the underlying compliance posture matches what regulators now expect from any enterprise marketer.