Cookie banner for a SaaS website

With Site Kit's Sign in with Google module, Cookie Rocks holds both Google's script (accounts.google.com/gsi/client) and Site Kit's own sign-in script until consent: before the choice there is no g_state or googlesitekit_auth_nonce cookie. After Accept all, without a reload, the button and One Tap appear. On wp-login.php, where no banner is shown, the button works as usual. If accounts.google.com does not answer, the button does not appear, as without Cookie Rocks. Before 2.5.2 both scripts ran before the choice.

With Site Kit's conversion tracking for WooCommerce and the gtagUserData flag (since 1.161.0), the purchase event carries user_data with the billing email, phone and name for Google's enhanced conversions. Its Reader Revenue Manager module loads news.google.com/swg/js/v1/swg-basic.js on the pages where its snippet is set.

GTM4WP's Google Consent Mode option is off by default. When on, it prints gtag('consent','default') before the container with all seven signals denied except those ticked, with no region and no wait_for_update. It never sends an update after the choice: that is left to the consent plugin. The filter gtm4wp_consent_mode_default_enabled (false) removes this default, and gtm4wp_overwrite_consent_mode_flag changes one signal.

GTM4WP always loads the Tag Manager container (gtm.js from www.googletagmanager.com or a custom domain) in the head of every page once a container ID is set: wp_head priority 10 (2 with its load-early option), after its data layer block at priority 1. It has no wait-for-consent setting and does not read WP Consent API. Its inline blocks carry data-cfasync="false" and data-pagespeed-no-defer.

GTM4WP's media events options are off by default. When on, the player SDKs (YouTube iframe_api, Vimeo, SoundCloud, Wistia, Twitch, Dailymotion and others) are requested by JavaScript only when the provider's iframe is found by its src address, so a banner that moves src to data-src or shows a placeholder prevents the request. The filter gtm4wp_media_sdk_blocked (true) holds all SDK requests, and the gtm4wp-media-gate script can be blocked.

GTM4WP's WooCommerce integration writes small first-party values only after an action: gtm4wp_item_list_attr (cookie, 3 days, when a product is clicked in a list), gtm4wp_orderid_tracked (localStorage on the order received page, or a 365-day cookie if localStorage is unavailable) and gtm4wp_readded_to_cart (localStorage). Its cache-safe data layer option (off by default) adds gtm4wp_woo_event (2 days), gtm4wp_login (logged-in users) and sessionStorage gtm4wp_visitor_session.

Once a HubSpot account is connected, the HubSpot plugin adds the loader js.hs-scripts.com/<portalId>.js (or js-eu1..., id hs-script-loader, async defer) in the footer of every front page, plus an inline _hsq.push(['setContentType']) in the head. It has no consent setting in WordPress and no WP Consent API code; consent handling exists only through HubSpot's own banner configured in the portal. Forms load from <hublet>.hsforms.net and meetings from static.hsappstatic.net, separately.

The HubSpot plugin has an optional reverse proxy, off by default: /_hcms/, /hs/, /hubfs/, /hs-fs/, /cs/c/, /e3t/ and /events/public/v1/ are relayed to HubSpot by WordPress, with HubSpot's headers and Set-Cookie included, so HubSpot requests and cookies then come from the site's own domain.

Cookie Rocks lists the Google tag as Google Analytics (gtag.js), statistics only, without the Google Ads cookie _gcl_au and storage key _gcl_ls, when nothing shows Google Ads (no Google Ads tag seen on the pages or declared in GTM, no Site Kit Ads module) and one sign says there is none (the answer No Google Ads, or Site Kit active without its Ads module). Otherwise a GT- tag stays in statistics and marketing. A Google Ads ID (AW-) in the gtag.js address or in gtag('config', 'AW-...') counts as Google Ads.

With Site Kit's Ads module (a test AW- conversion ID), the Google tag counts as statistics and marketing. After Accept all, Google Ads sets _gcl_au and calls doubleclick.net. With consent to statistics only, no Google Ads cookie is set, but the loaded tag still sends Google a cookieless request with advertising consent denied (pagead2.googlesyndication.com/ccm/collect).

Site Kit prints its Google tag (gtag.js) in the page head. Cookie Rocks holds it there in basic mode: before any choice, no request goes to Google. After Accept all, Google Analytics sets _ga and _ga_<ID>; with statistics only, the same happens and advertising stays denied; after Reject all, gtag.js is never loaded. With a GT- test ID Google returned no configuration and set no cookie; the cookies were seen with a G- test ID.

With its Consent Mode setting on, Site Kit sets Google's default consent a second time, after the banner's, and only for a fixed list of 32 countries (EU, IS, LI, NO, GB, CH): the regions saved in Site Kit are not read. With WP Consent API present, it also sends its own consent updates after each choice; they grant functionality_storage as soon as the page opens (the functional category of WP Consent API), while statistics and advertising follow the visitor's choice.

With Site Kit, Cookie Rocks pushes its 'denied' consent default first in the dataLayer and asks Google to wait 500 ms; on Accept all it records 'granted' before releasing Site Kit's tag, so the tag reads denied, Site Kit's settings and events, then granted, and everything is sent as granted. After a refusal the tag never loads. In a browser test: no request and no cookie before the choice, Analytics and its cookies after Accept all.

When a banner holds Site Kit's Google tag (gtag/js), two other Site Kit scripts still run before the choice: the inline tag settings (google_gtagjs-js-after: linker, js, developer_id, config) and its content events provider. They only fill the dataLayer and send nothing to Google. Site Kit also replaces window.gtag with an equivalent function writing to the same dataLayer. After consent, events pushed before the choice are processed by the tag.

With Site Kit's Tag Manager module, the container (gtm.js) is held in the page head and loads only after consent. With its AdSense module, the Auto ads script (adsbygoogle.js) is held as marketing: it loads after Accept all, not with statistics only or after Reject all.

Site Kit declares itself compatible with WP Consent API, but its code reads WP Consent API only when its own Consent Mode setting is on. With that setting off, Site Kit pushes no consent command at all, and the visitor's choice reaches Google only through the banner's own Consent Mode signals.

WP Consent API keeps its wp_consent_* cookies for 30 days by default. A banner that writes them only at the click leaves Site Kit reading no consent after 30 days, while the banner's own choice is still valid. Cookie Rocks writes the visitor's choice to WP Consent API on every page: in a test, the wp_consent_* cookies were deleted and the page reloaded; they were set again to allow, and Site Kit and Google read granted.