HubSpot Consent Mode: What CookieBeam Actually Sends
HubSpot consent mode is a consent signaling integration that connects your cookie banner to HubSpot's browser-side tracking code through two queue-based APIs: the _hsq analytics queue and the _hsp privacy queue. CookieBeam's HubSpot bridge listens for the visitor's banner decision and translates it into the calls HubSpot understands. When a visitor accepts the analytics category, the bridge calls _hsq.push(['doNotTrack', { track: true }]) to confirm tracking should run. When they reject or withdraw, it calls _hsp.push(['revokeCookieConsent']) to delete HubSpot's cookies and prevent new ones, then _hsq.push(['doNotTrack']) to stop the tracking pipeline. Unlike the Meta or Microsoft bridges, HubSpot's bridge keys off the analytics category, not marketing, because HubSpot's tracking code measures page views and form interactions rather than serving ads. This guide covers the exact mapping, the behavior at each consent stage, and how to verify it in DevTools.
TL;DR
CookieBeam listens for cookiebeam:consentUpdate (consent changes) and cookiebeam:consentRestored (returning visitors). If analytics_storage is granted (mapped from your banner's analytics category), the bridge calls _hsq.push(['doNotTrack', { track: true }]). If denied, it calls _hsp.push(['revokeCookieConsent']) and _hsq.push(['doNotTrack']). Enable the HubSpot vendor bridge in your banner settings; no code changes needed.
How HubSpot's Own Consent Mechanism Works
HubSpot's tracking code exposes two consent-related queues. The _hsq queue (HubSpot analytics queue) accepts a doNotTrack command. When called without arguments, it puts the tracker into do-not-track mode: the __hssc, __hssrc, and __hstc cookies are cleared, and no further tracking calls are made. When called with { track: true }, it re-enables tracking. The _hsp queue (HubSpot privacy queue) accepts revokeCookieConsent, which deletes HubSpot's cookies and disables their creation. Together, the two calls ensure both the tracking pipeline and the cookie storage are turned off. For the full reference, see HubSpot's cookie tracking documentation and the tracking code API reference.
How CookieBeam Maps Categories to HubSpot's Signal
The bridge reads the analytics_storage key from the resolved Consent Mode v2 state. That key maps from your banner's analytics category. It does not read ad_storage or any marketing-related keys. This is deliberate: HubSpot is primarily an analytics and CRM platform, not an advertising pixel. Its tracking code measures page views, form submissions, and session behavior. These are analytics activities, not ad targeting. If your banner has separate analytics and marketing toggles, a visitor who rejects marketing but accepts analytics will still have HubSpot tracking active.
| Banner Category | Consent Mode v2 Key | HubSpot Signal |
|---|---|---|
| Analytics (accepted) | analytics_storage = granted | _hsq.push(['doNotTrack', { track: true }]) |
| Analytics (rejected) | analytics_storage = denied | _hsp.push(['revokeCookieConsent']) + _hsq.push(['doNotTrack']) |
| Marketing | ad_storage, ad_user_data, ad_personalization | Not used by HubSpot bridge |
| Preferences | personalization_storage | Not used by HubSpot bridge |
| Necessary | security_storage (always granted) | Not relevant |
Behavior at Each Stage
Before consent (first visit, banner untouched): The bridge hasn't fired yet. If HubSpot's tracking code is loaded on the page (it typically is, since it's a single script in the <head>), it will track by default. This is why prior blocking matters: without tagging HubSpot's tracking code as analytics in CookieBeam, HubSpot tracks before the visitor decides. The bridge fires only after the visitor interacts with the banner, so it can't prevent pre-consent tracking on its own. If you've tagged HubSpot's script as analytics, CookieBeam blocks it until the visitor accepts.
Visitor accepts analytics: CookieBeam dispatches cookiebeam:consentUpdate with analytics_storage: 'granted'. The bridge calls _hsq.push(['doNotTrack', { track: true }]), confirming tracking should be active.
Visitor rejects analytics: The bridge calls both _hsp.push(['revokeCookieConsent']) (clears cookies, prevents new ones) and _hsq.push(['doNotTrack']) (stops the tracking pipeline). Both calls are needed because they control different layers of HubSpot's tracking.
Returning visitor: On later page views, the runtime re-announces the stored explicit choice as cookiebeam:consentRestored, and the bridge re-applies the matching HubSpot calls. A consent change on the current page fires cookiebeam:consentUpdate. This restatement ships with the runtime release that includes the vendor bridge fix. Machine-written defaults (such as US opt-out auto-grants) are not restated.
Consent withdrawal: Revoking analytics in the preferences panel fires both calls immediately on the same page view.
What the Bridge Does Not Do
The bridge controls HubSpot's browser-side tracking code only. It does not affect HubSpot's server-side features: email open tracking, CRM contact records, workflows, or form submissions handled by HubSpot's hosted pages. If a visitor fills out a HubSpot form on your site, that submission goes to HubSpot regardless of the bridge state, because it's a deliberate action, not passive tracking.
The bridge also does not interact with HubSpot's own cookie banner. If you're using both CookieBeam and HubSpot's built-in consent banner, you'll have two banners competing for the same decision. Disable HubSpot's banner in your HubSpot settings when using CookieBeam. For the HubSpot banner setup itself, see Cookie Consent on HubSpot: Banner Settings.
How to Verify in Your Browser
Clear cookies and open DevTools
Open DevTools (F12), go to Application, and clear all cookies for your site. Reload the page.
Check the pre-consent state
With the banner visible and untouched, look for __hssc, __hssrc, and __hstc cookies. If HubSpot's script is tagged as analytics in CookieBeam, these should be absent. If the script loads without blocking, they may already be set.
Accept analytics and check again
Accept cookies (or just analytics). The three HubSpot cookies should appear. In the Console, type window._hsq and inspect the array for the doNotTrack entry with { track: true }.
Withdraw consent and verify revocation
Open preferences and deselect analytics. The __hssc, __hssrc, and __hstc cookies should be cleared. Check the Network tab: no further requests to forms.hubspot.com or track.hubspot.com should appear for tracking calls.
Common Mistakes
Categorizing HubSpot as marketing instead of analytics. HubSpot's tracking code is session and page-view analytics. If you put it in the marketing category, the bridge won't fire for it because the bridge reads analytics_storage, not ad_storage. A visitor who accepts analytics but rejects marketing would have a broken HubSpot state: the bridge says granted, but the script is blocked. Keep HubSpot in analytics.
Running two consent banners. HubSpot ships its own cookie banner. If both it and CookieBeam are active, visitors see two banners and the consent state can contradict itself. Disable HubSpot's banner in Settings > Privacy & Consent when you use CookieBeam.
Assuming form submissions are blocked. The bridge stops passive tracking (page views, session recording). It does not block form submissions, which are active user actions. If a visitor submits a HubSpot form, the data reaches your CRM whether the bridge has revoked tracking or not.
Frequently Asked Questions
Does HubSpot track visitors before cookie consent is given?
By default, yes. HubSpot's tracking code runs immediately when loaded. If you tag the script as analytics in CookieBeam, it's blocked until the visitor consents. If you leave the script unblocked, the bridge sends the consent signal but can't undo tracking that already happened before the signal fired.
What happens to HubSpot forms when analytics consent is denied?
Form submissions still work. They're explicit user actions, not passive tracking. The bridge controls page-view and session tracking only. A visitor who rejects analytics can still fill out a HubSpot form, and that contact will appear in your CRM.
Can I use HubSpot's own cookie banner alongside CookieBeam?
You shouldn't. Running both creates two banners that can set contradictory consent states. Disable HubSpot's built-in banner (Settings > Privacy & Consent) and let CookieBeam handle the decision for both HubSpot and your other tools.
Why does the HubSpot bridge use the analytics category instead of marketing?
HubSpot's tracking code measures page views, sessions, and form interactions. That's analytics, not ad targeting. The analytics_storage consent mode key is the right match. Ad platforms like Meta and Microsoft use ad_storage because they're serving ads. HubSpot isn't.
Does the bridge affect HubSpot email tracking?
No. Email open tracking and click tracking are server-side features controlled by HubSpot's email settings, not by the browser-side tracking code. The bridge only affects the JavaScript tracker that runs on your website.
Next Steps
For all vendor bridges in one place, see the consent mode integrations overview. If you also run Matomo, the Matomo consent bridge shares the same analytics_storage key and follows the same pattern. For the difference between Google's Advanced and Basic consent modes, see Consent Mode v2: Advanced vs Basic. For a broader view of how Google's consent mode works end-to-end, start with Google Consent Mode v2: Complete Implementation Guide.