What Happens When Consent Is Denied

The SDK enforces consent itself. You don't need to wrap your tracking calls in consent checks: call setUser, setCommerceAction and the rest as usual, and the SDK decides what can leave the page.

When identity is denied

Events keep flowing. What changes is that nothing identifies who the shopper is.

Identity already on the tracker is removed:

• the user context set by setUser or identifyUser
• the UID2 context set by setSurfId, and the stored UID2 token (surf_uid2) is deleted
• the tracker's user ID (uid)
• identity contexts waiting in the ecommerce buffer for the next setCommerceAction

New identity calls are held, not sent. These commands are held while identity is denied:

Command	Held while identity is denied
setUser	✅ (before any hashing, so the values aren't even processed)
identifyUser	✅
setSurfId	✅ (no request is made to the Surfside ID service)
setUserId	✅
setUserIdFromLocation	✅
setUserIdFromReferrer	✅
setUserIdFromCookie	✅

What still goes out: page views, ecommerce actions, impressions and every other event, with the anonymous browser ID (duid), session and IP address as normal.

If the shopper later grants identity

Held calls are kept in memory for the rest of the page view. If identity becomes granted on that page, they are replayed once, in order, and the identity that was removed is put back. Only the latest call of each kind is kept, so a page that called setUser three times replays only the last one.

Held calls don't carry over to the next page. On later pages your site makes its identity calls again as usual, and they're handled under whatever consent is in force then.

If the shopper withdraws consent they gave

When identity moves from granted (by a real source, not the default) to denied, anything held is discarded, not replayed later. The shopper has said no, so their earlier identity calls must not come back if they change their mind again.

If a setSurfId request is in flight

setSurfId checks consent again when the ID service responds. If identity was denied, or the shopper logged out, while the request was in flight, the token is thrown away and never stored.

When tracking is denied

Events are anonymised, not stopped. An opt-out shouldn't look like a broken tag, and aggregate measurement keeps working.

	Normal	tracking denied
Events sent	Yes	Yes
Surfside cookie IDs (duid, sid, visit count)	Sent	Not sent
Surfside ID and session cookies	Kept	Cleared
IP address	Collected	Anonymised by the collector
Collector's network user ID	Set	Not set
Business user ID (uid)	Sent	Kept only if identity is still granted
Consent context on the event	Yes	Yes

Only TCF (Purpose 1 refused) or your own setConsent({ tracking: false }) can deny tracking. GPC and GPP never do.

Anonymous tracking settings

If your source is configured for anonymous tracking, the SDK remembers that setting. While tracking is denied it tightens it (no session tracking, server-side anonymisation on). When tracking is granted again, it goes back to exactly what your source was configured with.

While tracking is denied, page code can't loosen it:

• disableAnonymousTracking is refused.
• enableAnonymousTracking is applied, but with session tracking forced off and server-side anonymisation forced on.

Logging out: removeUser

removeUser is the logout path, not a consent change:

surf('removeUser');

It removes every identity artifact for the current shopper (user context, UID2 context, user ID and the stored UID2 token) and discards anything held for them. Consent stays as it is, so the next shopper to log in on that browser is identified normally if identity is granted.

Enforcement and new trackers

Consent belongs to the browser, so it applies to every Surfside tracker on the page. A tracker created after a denial is enforced as soon as it's created, before it sends anything.

What enforcement does not do

• It doesn't delete data already collected. Events sent before a denial stay in Surfside. Each one carries the consent state it was collected under; see Consent Data in Your Events.
• It doesn't control other tags. It governs the Surfside SDK only. Your CMP stays responsible for any other vendors on the page.
• clearUserData doesn't clear consent. The stored consent decision survives clearUserData and other cleanup calls on purpose, because forgetting it would silently opt the shopper back in.