Cookie banner for an online shop

With Explicit Consent on but its Google and Microsoft UET Consent Mode settings left on (the default), Pixel Manager for WooCommerce 1.72.0 still loaded the Google tag and Microsoft UET before the choice, sent a GA4 page view with gcs=G100 and UET hits, and set _uetmsdns with an empty value. The other pixels waited.

With the WP Consent API on, consent type optin and no choice made yet, Pixel Manager for WooCommerce 1.71.0 still loaded the Google tag for GA4 and Google Ads and sent a GA4 page view with gcs=G100, a client ID and the page address. It also loaded Microsoft UET and sent hits with asc=D, and set _uetmsdns with an empty value. Meta, TikTok, Pinterest, Snapchat, Reddit, OpenAI and Hotjar waited. After a refusal nothing more was sent; after an acceptance all ten pixels started without a reload.

WooCommerce can store 11 cookies or browser keys for visitors: WOOCOMMERCE_CHECKOUT_IS_CUSTOMER_DATA_DIRTY, storeApiCartHash, storeApiNonce, wc_cart_created, woocommerce_geo_hash, woo-share, tk_ai, tk_lr, tk_or, tk_r3d, tk_tc. Cookie Rocks recognises them from 2.9.8 and lists them in the cookie policy, each with its category and purpose, when it sees them.

WooPayments can store these in a visitor's browser: wcpay_express_checkout_redirect_url (cookie, necessary: Keeps an express payment going); skip_woopay (cookie, necessary: Keeps an express payment going). Cookie Rocks recognises them from 2.9.8, with this category and purpose, and lists them in the cookie policy when it sees them.

WooCommerce Stripe Payment Gateway can store these in a visitor's browser: wc_stripe_express_checkout_redirect_url (cookie, necessary: Keeps an express payment (Apple Pay, Google Pay) going). Cookie Rocks recognises them from 2.9.8, with this category and purpose, and lists them in the cookie policy when it sees them.

WooCommerce PayPal Payments can store these in a visitor's browser: axoEnv (localStorage, necessary: Keeps the PayPal fast checkout (Fastlane) going); axoOriginalCheckoutFields (localStorage, necessary: Keeps the PayPal fast checkout (Fastlane) going). Cookie Rocks recognises them from 2.9.8, with this category and purpose, and lists them in the cookie policy when it sees them.

Facebook for WooCommerce can store these in a visitor's browser: wc_facebook_signals_seen_event_ids (session, marketing: Avoids sending the same event twice to Meta). Cookie Rocks recognises them from 2.9.8, with this category and purpose, and lists them in the cookie policy when it sees them.

Cookie Rocks 2.9.5 with the Audit and Pro showed no PHP error on PHP 7.4 and 8.3. On WooCommerce, cart and checkout work before and after the choice, and strict payments keep Stripe out of other pages only. On a multisite network, settings, the choice cookie (cr_consent_2) and tables are per site, including sites created later. Uninstall removes options, tables, the scheduled task and files.

With Cookie Rocks Pro, Meta Pixel for WordPress and Meta for WooCommerce set no _fbp or _fbc cookie from the server for a new visitor, even with fbclid in the address, and the page makes no request to facebook.com or connect.facebook.net before the choice, fbevents.js included. After Accept all or allowing the Meta Pixel service alone, the held events were released without a reload: one fbq('init'), a PageView, and _fbp, _fbc and wc_facebook_signals_state=active set by the page.

After Accept all, or after allowing the Meta Pixel alone, Cookie Rocks releases the held events of Meta Pixel for WordPress and Meta for WooCommerce on the same page, without a reload: the queued PageView is sent, _fbp (and _fbc with fbclid) is set, and fbq('init') runs once. On the next pages the server still sets no _fbp or _fbc cookie.

With Meta Pixel for WordPress or Meta for WooCommerce, CookieRocks.rejectAll() after Accept all reloaded the page and removed _fbp, _fbc and wc_facebook_signals_state; only the consent cookie stayed on the site and no request went to Meta afterwards. On a plain page without a Meta plugin, the purge list of the page (crConfig.pg) is absent.

Facebook for WooCommerce sets _fbp and _fbc from the server with setcookie() when they are missing, before any choice, unless its signals are held. The held state comes from the PHP filter facebook_signals_held (since 3.6.0) or the cookie wc_facebook_signals_state. While held, events are queued and no cookie is set; window.fbwcsignal.release() then sends the queue, and the page sets _fbp and _fbc from the values returned by the server.

When Meta for WooCommerce releases held events (POST to admin-ajax, action facebook_release_signals), the PageView it sends to its server carries the same event ID as the PageView the browser sends to facebook.com/tr. Without an access token, the release request fails with 'Plugin not configured.' and nothing is released.

Meta for WooCommerce releases held events only when it has an access token: without one, the release request answers 'Plugin not configured.' and nothing is released. With a token, its admin-ajax release waits for Meta's Conversions API before answering, so the pixel started 7 to 19 seconds after the click in our tests.

window.fbwcsignal.release() sends a WordPress nonce printed in the page (security parameter, checked with check_ajax_referer). A WordPress nonce expires after 12 to 24 hours, so on a page served from a cache older than that the release request is refused: this public release API is fragile with page caches.

When a visitor accepts, Cookie Rocks does not reload the page: held tools start at once. The page reloads in two cases only: when the visitor withdraws a consent already given, because a script that has already run can only be stopped by a reload; and when the visitor allows only reCAPTCHA or hCaptcha, which a form needs from page load. Tools that read consent on page load, such as Pixel Manager for WooCommerce without WP Consent API, get the consent signal on the same page instead.

Cookie Rocks holds the script of Pixel Manager for WooCommerce (pmw-public.p1.min.js) and its pmwDataLayer settings under one service, pixel-manager-for-woocommerce, in the marketing category. In the test, nothing from the ten pixels set up in Pixel Manager loaded before the choice, and allowing the Meta Pixel service alone loaded none of them, Meta included.

Without the WP Consent API plugin, Cookie Rocks adds a relay to the inline script pmw-js-before that sends its choice to Pixel Manager for WooCommerce through the wp_listen_for_consent_change event. In the test, Accept all started all ten pixels set up in Pixel Manager without a reload, and all ten started again on the next page view. With the WP Consent API plugin installed, the relay was not added and Accept all also started all ten without a reload.

When the visitor withdrew marketing after Accept all, Cookie Rocks sent deny to Pixel Manager for WooCommerce at once: Pixel Manager set its statistics, marketing and preferences consent to false, and Google Consent Mode updates with ad_storage and analytics_storage denied were pushed to dataLayer. On the next page none of the ten pixels loaded.

On a page with Pixel Manager for WooCommerce and a hard-coded GA4 tag, a visitor who saved statistics only got the hard-coded GA4 tag without a reload: gtag.js, a /g/collect hit and the _ga cookies. Pixel Manager stayed held as a marketing service, so its own GA4 and its marketing pixels did not load, and it received statistics allow, marketing deny through the relay.

Withdrawing marketing after Accept all reloaded the page and removed every first-party cookie set by the ten pixels of Pixel Manager for WooCommerce, including _rdt_uuid, __oaiq_consent and __obref, even on the very first page view of a new site. Only the consent cookie of Cookie Rocks stayed on the site; cookies on the providers' own domains are out of reach of a site script.

Pixel Manager for WooCommerce keeps its consent state in window.pmw.consent (categories statistics, marketing, preferences, necessary) and acts on the wp_listen_for_consent_change event even when the WP Consent API plugin is not installed. On a deny for all three categories, it pushed Google Consent Mode updates with every storage type denied except security_storage.

Pixel Manager for WooCommerce starts the Google tag (GA4 and Google Ads) and Microsoft UET as soon as its script runs, even while its own marketing and statistics consent is denied. It relies on Consent Mode: the GA4 hit is sent with gcs=G100, the UET hits with asc=D, and UET writes the _uetmsdns cookie. The other pixels (Meta, TikTok, Pinterest, Snapchat, Reddit, OpenAI, Hotjar) wait for its consent state.

Pixel Manager for WooCommerce (free) prints one inline script, window.pmwDataLayer, that holds the IDs of every pixel set up in the plugin, and one local script, pmw-public.p1.min.js, that loads a chunk per pixel. In a test with ten pixels set up (GA4, Google Ads, Meta, Microsoft UET, TikTok, Pinterest, Snapchat, Reddit, OpenAI, Hotjar), all ten started from these two scripts. The page has no separate script tag per service.

Pixel Manager for WooCommerce loads no browser pixel when navigator.webdriver is true or when the user agent matches its bot list (Googlebot, bingbot and others). An automated scan with a default headless browser therefore sees none of its pixels, although real visitors get them.

Pixel Manager for WooCommerce reads consent through the WP Consent API (wp_consent_type and the wp_listen_for_consent_change event). With the WP Consent API plugin installed, a consent given on the page started all its pixels without a reload. Without that plugin and with wp_consent_type set to optin, only Google and Microsoft UET started after consent; the other pixels stayed off.

With Brand Agents connected and front-end injection on, the Microsoft Clarity plugin loads a script module from adsagentclientafd-b7hqhjdrf3fpeqh2.b01.azurefd.net on every front page for visitors who are not logged in. On WooCommerce stores, a REST endpoint called by that script sets the brandagent_attrs cookie for 2 hours (session, customer and conversation IDs, Clarity data, language, currency, country).

WooCommerce Analytics (Jetpack module, on with WooCommerce) checks wp_has_consent('statistics') before each event, on the server and in the browser. Without WP Consent API, consent is assumed and pixel.wp.com/t.gif and stats.wp.com/s-*.js are sent for every visitor.

On the WooCommerce checkout, wck-started-checkout.js (classic) and includes/blocks/build/events.js (block checkout), both served by the site, set the __kla_id cookie (base64 of email, first and last name, 2 years) and POST profile and Started Checkout data to a.klaviyo.com/client/profiles/ and client/events/ without klaviyo.js: on load for a logged-in customer, otherwise when the email or name is typed. Holding Klaviyo's own addresses does not stop them.

When a product is added to the cart and the __kla_id cookie is present, the Klaviyo plugin's server sends an Added to Cart event to a.klaviyo.com/client/events/ (wp_remote_post). Without the cookie nothing is sent, so removing __kla_id on withdrawal stops it.

With Track ecommerce on (default), Matomo for WordPress sends WooCommerce carts and orders from PHP during AJAX or REST requests, in Tag Manager mode, or with MATOMO_TRACK_ECOMMERCE_SERVER_SIDE, with no consent check in that code; the PHP tracker sets no cookie but reads _pk_id. A browser-side consent signal does not hold these hits. Use server generated Visitor ID (off by default) starts the WooCommerce session for visitors without _pk_id.

With cart tracking on (all, by default), Mailchimp for WooCommerce's site script sets the session cookie mailchimp.cart.current_email when the visitor leaves the email field at checkout, login or registration, then sends the address to admin-ajax.php?action=mailchimp_set_user_by_email, before any order. The server then passes cart data to Mailchimp's API.

Mailchimp for WooCommerce sets its cookies from PHP for 28 days (2 419 200 s, Secure, SameSite=Strict): mailchimp_campaign_id and mailchimp_email_id when a visitor arrives with ?mc_cid= or ?mc_eid=, mailchimp_user_email, mailchimp_user_previous_email and mailchimp_cart_token (HttpOnly) for cart recovery, and mailchimp_landing_site on the first page only if landing page tracking is on (off by default). A consent plugin cannot hold them; all go through the mailchimp_allowed_to_use_cookie filter.

With WP Consent API, WooCommerce writes the result of wp_has_consent('marketing'), read from the request's cookies, into the page as the attribution allowTracking value, so a cached page carries the value of the visitor who generated it. Its footer script wp-consent-api-integration corrects it only at the wp_consent_type_defined event and on each consent change. Only order attribution reads consent; the session cookie wp_woocommerce_session_<hash> (HttpOnly, 2 days, 7 when logged in) and the cart fragments storage (wc_cart_hash_<md5> in localStorage, wc_fragments_<md5> in sessionStorage) do not depend on it.

When WooCommerce needs the visitor's country (default customer location set to Geolocate, or taxes by geolocation) and neither a MaxMind key nor a CDN country header gives it, its server looks the country up at ipinfo.io or api.country.is, sending the visitor's IP address. With Geolocate (with page caching support), it sets woocommerce_geo_hash for 1 hour from the first page and adds a v= parameter to addresses.

WooCommerce passes a lifetime of 0.00001 month to its sourcebuster library, which converts and truncates it to 0 minutes: the sbjs_ attribution cookies are session cookies, except sbjs_session (30 minutes). sourcebuster sets them on the host name without www. (domain=.<domain>), while WooCommerce's own removal on withdrawal uses domain=.<hostname>.

WooPayments' checkout bundle (served by the site) computes a FingerprintJS device ID sent with the payment for fraud checks, with monitoring off (no call to openfpcdn.io); it sets and deletes a cookietest cookie, keeps wcpay_appearance_<context> in localStorage and reads or sets skip_woopay (1 day). When the account's fraud configuration includes Sift, the same bundle creates <script src="https://cdn.sift.com/s.js"> itself, so it is not in the page HTML. The block checkout also stores woopay_preferred_card (card brand and last 4 digits) in localStorage; multi-currency keeps wcpay_mc_async_config in sessionStorage for 5 minutes. It does not read WP Consent API.

WooPayments sends shopper Tracks events from the server to pixel.wp.com (wp_remote_get), only for stores in the United States with WooCommerce usage tracking allowed, mostly when WooPay is on; it respects a tk_opt-out cookie. The anonymous ID is a tk_ai session cookie set in PHP. No banner can hold a server-side call.

WooPayments loads Stripe.js (js.stripe.com/v3) at checkout and pay-for-order, and on product and cart pages when express buttons or pay-later messages (Affirm, Afterpay, Klarna) are shown there. Its defaults offer Apple Pay and Google Pay, WooPay and Amazon Pay buttons on product, cart and checkout pages, so Stripe.js runs on those pages; not on the home page or posts. It uses the same script handle as the Stripe extension to avoid loading it twice.

The Stripe extension for WooCommerce loads Stripe.js (js.stripe.com) on product, cart, checkout, pay-for-order and add-payment-method pages by default, not only at checkout, and never on the home page, posts or shop. On product and cart pages it still loads when express buttons are off there, because two filters (wc_stripe_load_scripts_on_product_page_when_prbs_disabled and the cart one) default to true. When express buttons show, it adds preconnect hints to js.stripe.com, m.stripe.network, q.stripe.com and b.stripecdn.com in the head, and sets wc_stripe_express_checkout_redirect_url (10 minutes) on an express redirect. Its shop bundles write no cookie or localStorage.

The Stripe extension for WooCommerce has no consent setting, does not read WP Consent API and sets no Consent Mode. Before charging, its checkout code checks that Stripe.js was loaded from https://js.stripe.com, so the script must stay on Stripe's address and run normally for card payments to work.

PayPal Payments always loads FraudNet in version 4.1.3 (the enabled check returns true): fraudnet.js, served by the site, creates a JSON config tag and <script src="https://c.paypal.com/da/r/fb.js"> at the page load event, at checkout whenever a PayPal method is active and on product, cart and pay pages where buttons are; its session ID is kept in the WooCommerce session. Its optional reCAPTCHA protection (off by default) loads www.google.com/recaptcha/api.js where buttons are. It has no consent setting and does not read WP Consent API.

WooCommerce PayPal Payments does not print the PayPal SDK as a tag: its own button.js (served by the site) creates www.paypal.com/sdk/js from an address in its localized data. After setup, buttons are on product, cart and checkout pages, so the SDK loads there; Pay Later messages load it on product, cart and checkout pages in 8 countries (US, DE, GB, FR, AU, IT, ES, CA), and on home and shop pages only if turned on. Mini-cart buttons (off by default) load it on every page.

Meta for WooCommerce can hold Pixel and Conversions API events until consent: signals are active by default (no wc_facebook_signals_state cookie), and a consent plugin holds them with the PHP filter facebook_signals_held or window.fbwcsignal.hold(), then window.fbwcsignal.release(). While held, PHP writes no _fbp or _fbc, fbq('consent','revoke') is sent and events are queued, but fbevents.js still loads. The state cookie lasts 1 year. It does not read WP Consent API.

Meta for WooCommerce prints the Pixel as an inline snippet in wp_head that starts with if(f.fbq)return;, so a fbq function defined before it stops fbevents.js from loading. It keeps sent event IDs in sessionStorage wc_facebook_signals_seen_event_ids, adds a facebook.com/tr noscript image, and lets the filter wc_facebook_pixel_script_attributes change the script tag attributes. Nothing loads without a Meta connection and pixel ID.

When the shop is connected to Meta and signals are not held, Meta for WooCommerce sends Set-Cookie _fbp (90 days) from PHP on a visitor's first page, and _fbc when the visitor arrives with ?fbclid=. A consent plugin that only blocks scripts cannot stop it. It also loads Meta's Param Builder from cdn.jsdelivr.net (fallback unpkg.com) on every page, which writes _fbp and _fbc on the root domain unless wc_facebook_signals_state=held.

With Google for WooCommerce's enhanced conversions on (off by default), every page of a known customer's session prints gtag('set','user_data') with the email, first name, last name and phone hashed (SHA-256), but the street, city, region, postal code and country in clear text in the HTML.

When WP Consent API is present and Google Analytics for WooCommerce is not, Google for WooCommerce loads wp-consent-api.js, which reads the WP Consent API statistics and marketing cookies and sends gtag('consent','update') at DOMContentLoaded (statistics to analytics_storage; marketing to ad_storage, ad_user_data, ad_personalization), and listens for wp_listen_for_consent_change. It sets wp_consent_type to optin if empty and does not register with WP Consent API.

Mailchimp for WooCommerce prints Mailchimp's connected-site snippet (chimpstatic.com/mcjs-connected) inline in wp_footer on every page by default (option mailchimp-woocommerce-code-snippet, filter mailchimp_add_inline_footer_script). The Mailchimp pixel scripts are enqueued on every page unless MAILCHIMP_PIXEL_ENABLED is false, and the logged-in customer's email is written into window.mcPixel for identification. No WP Consent API or Consent Mode code.

When order attribution waits for consent, it starts on the page where the visitor accepts. A visitor who lands from a campaign link and accepts on a later page is recorded as a direct visit. This respects the choice, but shops that follow their campaigns should know it.

The WooCommerce block cart and block checkout keep storeApiNonce, storeApiCartData and storeApiCartHash in the browser's local storage, plus WOOCOMMERCE_CHECKOUT_IS_CUSTOMER_DATA_DIRTY on the checkout page. The classic checkout keeps nothing in local storage.

Browsing a WooCommerce shop sets no cookie. Adding a product to the cart sets woocommerce_items_in_cart, woocommerce_cart_hash and wp_woocommerce_session_* before any choice. They keep the cart, so they are necessary cookies and Cookie Rocks never holds them.

With Cookie Rocks, WooCommerce order attribution (the sbjs_ cookies) waits for consent to marketing, with or without WP Consent API. After Reject all, a cash on delivery order goes through and carries no origin data; after Accept all, it does. Withdrawing marketing consent deletes the sbjs_ cookies at once.

Without a consent integration, WooCommerce order attribution sets seven sbjs_ cookies (sbjs_migrations, sbjs_current_add, sbjs_first_add, sbjs_current, sbjs_first, sbjs_udata, sbjs_session) as soon as the visitor arrives, before any choice, and they stay after a refusal.