Blog
A cookie banner in front of server-side tagging: what changes, and what does not
Published · Updated · 2 min read
Your banner asks the visitor. Consent Mode tells Google's tags what they chose. Script blocking decides whether the SignalHost snippet runs at all. These are different jobs. A visible banner alone is not enough.
What server-side tagging changes about consent: nothing
A first-party hostname is a technical property of a request. It is not permission. If you needed consent to set an analytics cookie yesterday, you need it today, and the fact that the cookie is now set by metrics.yoursite.com instead of google-analytics.com does not enter into it. The regulator's question is what you collect and why, not which server the packet visited on the way.
Configure your cookie banner
Your banner asks the visitor. Consent Mode tells Google's tags what they chose. Script blocking decides whether the SignalHost snippet runs at all. These are different jobs.
In your banner provider's settings, enable its Google Consent Mode v2 integration. A visible banner alone is not enough. Do not add a second banner or a duplicate Google tag.
Basic or Advanced: what is the difference?
Choose the mode that fits your organisation's policy. Do not disable deliberate script blocking just to make events appear.
- **Basic:** block the tracking snippet until the relevant consent is given. No pre-consent tracking events are expected in SignalHost.
- **Advanced:** load Google's tags with `denied` defaults. Google may receive cookieless measurement pings before a choice or after rejection. A ping is not consent.
Set defaults, then send the visitor's choices
Set `analytics_storage`, `ad_storage`, `ad_user_data` and `ad_personalization` to `denied` before the SignalHost snippet runs. Your banner then updates each permission to match the visitor's choices.
- Analytics permission alone must not grant advertising permission.
- Remember the choice on return visits, and send an update when the visitor changes or withdraws it.
- Google Ads Enhanced conversions also needs `ad_user_data` permission and its own Ads setup. `ad_personalization` concerns personalised advertising, not ordinary event counting.
If your banner blocks scripts
Add the exact loader URL from your SignalHost installation snippet to your banner's blocking rules. Your own hostname may not match its usual Google rules. Release it only after the required consent.
Before enabling contact matching
This optional feature can read email addresses typed on your site. Hashing does not make contact data anonymous, and ordinary event counts do not need it.
In Advanced mode, contact data can reach SignalHost before SignalHost removes it when `ad_storage` is `denied`. If you require no contact transfer before consent, keep matching off or block the snippet until consent.
Check both accepting and rejecting
Open a fresh private window for each test. In Google Tag Assistant, enter your site URL and inspect the earliest and latest Consent events. Check these cases:
- Before a choice and after Reject: the relevant permissions stay `denied`.
- Analytics only: `analytics_storage` may be granted; advertising permissions stay denied.
- Marketing allowed: grant only the advertising purposes the visitor actually agreed to.
- Withdraw permission: the affected values return to `denied`. Reload and check the saved choice.
Does seeing an event mean consent is correct? No. Live events show arrival at SignalHost, not all four consent settings or delivery to an ad platform. Use Tag Assistant to check consent, then check the destination separately.