Blog
Six consent signals, what each one controls, and where they need to land in your sGTM payloads.
Consent Mode v2 introduced two new signals on top of the original four. The full set is six, and they each control a different downstream behaviour. Get the mapping wrong and you will either over-collect (regulatory risk) or under-collect (data quality loss with no compliance benefit).
| Signal | Controls |
|---|---|
ad_storage | Cookies for advertising purposes (Google Ads, DV360). |
analytics_storage | Cookies for analytics (GA4 client_id persistence). |
functionality_storage | Functional cookies (language preference, login state). |
personalization_storage | Personalisation cookies (recommended products). |
ad_user_data | Whether user data may be sent to ad platforms. |
ad_personalization | Whether ads may be personalised based on this user. |
In a server-side GA4 event, the consent signals come in as the gcs and gcd parameters. The first encodes the legacy four signals; the second encodes the v2 additions. Your server container reads both automatically when you forward via the standard GA4 client.
For Meta and TikTok, the consent signal needs to be mapped explicitly. Meta uses the opt_out field; TikTok uses limited_data_use. Both expect a boolean, not the full Google-style state.
If you are starting from zero, the safest baseline is: deny all six by default, set them to granted on user consent, propagate the state via the data layer to your client GTM, and let the client GTM forward them to your tagging server. Skipping the explicit propagation is the most common mistake; the destinations downstream do not see the page.
If you use Cookiebot, OneTrust, or Didomi, they all ship a Consent Mode integration that handles the mapping. Use the integration. Hand-rolled consent code is rarely worth the maintenance.