Stape's Data Client: Client ID generation (and consent)

Consent & Privacy
1

Hi,

We’re running Stape sGTM setup with Cookiebot as our CMP. Google Consent Mode is setup in web container. Data is sent to the server container via both a GA4 config tag and Stape’s Data Tag (with ‘Add consent state’ enabled) and Data Client. The web container Data Tag itself has no consent conditions and so fires unconditionally. Our various server tags/triggers are conditioned for consent checks based on this.

We’ve noticed that the _dcid cookie is being set by the Data Client even when a user rejects all non-essential cookies. We do believe this has GDPR compliance issues. This seems to happen because the Web GTM Data Tag fires unconditionally and the Server GTM Data Client generates a client ID (and sets _dcid) when none is present in the request.

We do want the _dcid cookie to be generated and set in cases where a client ID is missing for reasons other than consent rejection — e.g. expired cookies, or Safari ITP resets. So simply disabling ‘Generate Client ID’ in the Data Client settings does not seem like a great solution.

On the other hand, we also would still want to support Advanced Consent Mode. So simply adding ad_storage and analytics_storage conditions to the web container Data Tag doesn’t seem viable either.

Stape adding a consent condition setting to the client id generation option in the Data Client would be great!

But maybe i’m missing something in my logic here? Or maybe there is some other great approach for this?

Any recommendations?

2

Hi @Boel , thanks for flagging this. Indeed you currently can either disable the cookie altogether or enable it at all times. Originally the vision was that non-consented hits should not be reaching Data Client.

We will however introduce some additional settings to to make this managable.

3

Hey @Dan, thank you for your response. Sounds great! Do you have an ETA on those additional settings? :blush:

At the moment, we are using SST exclusively for campaign tracking and analytics. Running GA4, Google Ads, Meta, TikTok, LinkedIn, Snapchat conversion APIs etc.

Do you have any input on what is more important for this; Client ID’s (non-consented hits not reaching Data Client) or Advanced Consent Mode (disabling Client ID generation in Data Client)?

4

Hey Boel, ran into the same issue a few months back on a similar setup: Cookiebot, Data Tag firing unconditionally, and consent checks handled in the server container.

Your concern is valid.

The _dcid cookie is still a unique identifier written to the browser via the Set-Cookie response header. Under ePrivacy Article 5(3), that is still storage on the user’s terminal equipment. It doesn’t really matter that it originates from the server container. The cookie lands in the browser, and if it’s used for tracking, I would not treat it as strictly necessary.

The annoying part is the tradeoff you described. If you disable “Generate Client ID” globally, you lose the Safari / ITP recovery benefit. But if you add consent conditions to the web Data Tag, you also risk breaking Advanced Consent Mode because the cookieless pings stop reaching the server container.

Until Stape exposes a consent-aware setting, the cleanest workaround I’ve used is server-side gating: let the Data Tag fire, but check consent state in the server container before any tag that relies on _dcid.

For example, trigger GA4 / Meta / other downstream server tags only when analytics_storage is granted before using _dcid as the client_id or event identifier input.

That keeps the cookieless hits flowing for modeling, while preventing your downstream tags from using _dcid when consent is denied.

But it does not fully solve the issue.

The remaining gap is that Data Client can still write _dcid in the response regardless of consent state. That part needs a native Stape setting. You could probably hack around it with response header handling, but I would not want to maintain that unless there is no other option.

I’d push Dan for an ETA on the consent-aware setting. Until then, I’d treat server-side gating as damage control, not a full fix.

1 Like