A cookie consent manager built into your analytics

Nothing of ours runs before a choice

In opt-in mode the PulsePanda snippet waits for a decision before it starts. Until the visitor accepts analytics there is no session replay, no heatmap or click, scroll and input capture, no event tracking, and no identifier written to the browser.

Third-party tags wait on their category

To hold back Google Analytics, the Meta pixel or any other tag, change its type to text/plain and add data-pp-consent with the category it belongs to. The browser ignores a script of that type, so it never runs. When the visitor grants the category, PulsePanda swaps each tagged script for a live copy with the same attributes, so external and inline scripts both run. External ones load asynchronously, so a tag that must run before another should be inlined or chained.

<!-- Runs only after the visitor accepts "marketing" -->
<script type="text/plain" data-pp-consent="marketing"
        src="https://connect.facebook.net/en_US/fbevents.js"></script>

<!-- Inline scripts work the same way -->
<script type="text/plain" data-pp-consent="analytics">
  gtag('config', 'G-XXXXXXXXXX');
</script>

Auto-block catches the cookies you missed

Tagging covers the scripts you know about. With auto-block on, PulsePanda also watches every cookie a script tries to write through document.cookie. A cookie from a category the visitor has not granted is dropped. In opt-in mode, a cookie that is not in your registry at all is dropped too until the visitor decides. Strictly necessary cookies always pass.

It is best-effort by design, and it is worth knowing where it stops: it cannot see cookies your server sets with a Set-Cookie header, or cookies written inside a third-party iframe. Gate those at the source.

Withdrawing consent cleans up

When a visitor turns a category off, PulsePanda expires the cookies your registry lists for that category, on both the current host and the parent domain, instead of leaving them to linger until they expire.

When the PulsePanda banner is your consent tool, every decision reaches Google tags as a Consent Mode v2 update, through the same dataLayer that gtag.js and Google Tag Manager read. A returning visitor's stored choice is sent again on each page, and withdrawing consent sets the signals back to denied.

• Analytics sets analytics_storage.
• Marketing sets ad_storage, ad_user_data and ad_personalization.
• Preferences sets functionality_storage and personalization_storage.

A category your banner does not offer stays denied, so turn on Marketing if you run Google Ads tags.

Set the defaults before Google tags load

Consent Mode needs a default state before any Google tag runs. In Google Tag Manager, the PulsePanda Analytics tag template sets it: tick Set Google Consent Mode defaults, fire the tag on Consent Initialization - All Pages, and optionally list the regions where consent is required. It also restores a returning visitor's choice before other tags fire. With gtag.js, set the defaults above your Google tag:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag() { dataLayer.push(arguments); }
  gtag('consent', 'default', {
    analytics_storage: 'denied',
    ad_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    wait_for_update: 500
  });
</script>

Each update is followed by a pulsepanda_consent event in the dataLayer, which you can use as a Tag Manager trigger. If another platform collects consent and passes it to PulsePanda with setConsent, PulsePanda leaves Google consent to that platform.

The PulsePanda snippet does not set cookies. Once a visitor has consented it keeps three keys in localStorage:

• _sr_vid: the current visit, which ends after 30 minutes without activity.
• _sr_uid: a random anonymous ID, so returning visits can be connected.
• _pp_consent: the visitor's choice per category, the policy version and when it was made, so the banner does not reappear on every page.

If a visitor rejects analytics or withdraws it later, capture stops and the visit and anonymous ID keys are deleted. List the three keys in your cookie policy; the dashboard shows them next to the banner settings.

Each decision is also recorded in your workspace with the anonymous ID, the categories chosen, the policy version and a timestamp. Consent insights shows the recent ones with your accept rate, and exports them as CSV when someone asks you to show consent was given.

You do not have to replace a consent platform you already run. Leave the PulsePanda banner off, and pass the decision your platform collects to PulsePanda from its consent callback:

<script>
  window.PulsePanda = window.PulsePanda || [];
  // Call from your CMP's consent callback:
  window.PulsePanda.push(['setConsent', true]);   // visitor granted analytics
  // window.PulsePanda.push(['setConsent', false]); // visitor refused or withdrew
</script>

Using the PulsePanda banner instead? Link “Cookie settings” in your footer to window.PulsePanda.push(['showConsentBanner']) so visitors can change their mind at any time, which GDPR requires to be as easy as giving consent.

PulsePanda's consent manager is built for teams that want consent and analytics in one place. It is not the right tool for every site. Choose a certified consent platform such as Cookiebot or OneTrust if you need any of these:

• IAB TCF v2.2. PulsePanda does not generate a TCF consent string, which programmatic ad stacks in the EU require.
• A crawler-based cookie scan. The registry is built from what real visitors' browsers hold, not from a scheduled crawl of every page.
• One consent across several domains. Choices are stored per site, so a visitor who accepts on one domain is asked again on another.

If all you need is a banner and no analytics, the free cookie consent banner generator gives you a dependency-free one to paste into any site.