Good practice: cookies under Czech law

• Strict opt-in — no pre-checked boxes, no implied consent.
• Equal-prominence buttons — Accept and Reject must be visually equal.
• Granular choice — visitors must be able to select cookie categories individually.
• Cookie walls prohibited — you cannot gate content behind consent.
• 12-month renewal — consent is valid for a maximum of 12 months.
• Audit-ready logs — every consent must be recorded with a timestamp and an ID.

• Correct opt-in implementation — Waulter's default settings meet all Czech requirements.
• Equal-prominence buttons — the banner design does not favor one button over the other.
• Granular consent — visitors see categories and choose individually.
• Automatic renewal — Waulter tracks consent expiration and prompts for renewal.
• Audit logs — every consent is stored server-side with a transaction ID, timestamp, and choice detail.

• Pre-checked consent — not allowed. Waulter cannot do this even by accident.
• Hidden Reject button — commonly considered a dark pattern.
• Missing cookie information — Waulter automatically generates a cookie overview.
• Unrecorded consents — without logs you have no proof. Waulter stores everything automatically.

One cookie banner for your entire site is a compromise that costs you consents. Waulter's scenario rule engine lets you show the right banner variant based on where the visitor came from — and why they came.

General homepage traffic

Context: The visitor arrives directly or from organic search. You have no context about their intent.

Banner behavior: Balanced, standard presentation. All cookie categories visible, equal-prominence Accept / Reject buttons, full granular choice. No pre-checked boxes.

Why it works: For unknown traffic, a fair approach is the best strategy. The visitor has no reason to trust you more than anyone else — give them a clean choice.

Setting it up in Waulter:

• Create a default B2BWebSiteConfig with your standard banner design.
• In the scenario, set this config as the fallbackB2BWebConfigId — it applies whenever no other rule matches.

Whitepaper campaign (LinkedIn → gated PDF landing page)

Context: The visitor clicked a LinkedIn ad and landed on a page where they want to download a whitepaper. They arrive with a specific intent and are willing to "pay" with their data.

Banner behavior: Softer tone. A marketing message in the banner: "Analytics cookies help us create more content like this for you." The analytics category is visually emphasized. Buttons remain equal-prominence (regulatory compliance), but the messaging explains the value exchange.

Why it works: A campaign visitor has already expressed interest in your content. A contextual explanation of why consent helps can increase opt-in rates compared to a generic banner — without breaking any rules.

Setting it up in Waulter:

• Create a second B2BWebSiteConfig with a customized template and marketingMessage.
• Scenario rule: url contains "/whitepaper/" OR referer contains "linkedin.com" → use the campaign config.
• In the SDK, set customField1 to the campaign identifier for precise targeting.

Content campaign → blog

Context: The visitor arrived via a content campaign to a blog post. Primary goal: read the content. Any interruption reduces engagement.

Banner behavior: Minimal banner. Essential cookies only on first interaction. No full-screen overlay, no large dialog — a small, unobtrusive banner at the bottom of the screen. Analytics and marketing cookies are offered later, once the visitor shows deeper interest (reads 2+ articles).

Why it works: A blog reader came to consume content. An aggressive full-screen banner drives them away before they read the first paragraph. A minimal approach preserves the reading experience, and you get consent in a better context — once the visitor has a reason to trust you.

Setting it up in Waulter:

• Third B2BWebSiteConfig with a minimal template (essential cookies only).
• Scenario rule: url contains "/blog/" AND pageview < 3 → minimal config.
• Second rule: url contains "/blog/" AND pageview > 2 → standard config with all categories and forceStartCB: true.

Why this beats one-size-fits-all

A single generic banner is a compromise for everyone. The scenario rule engine lets you:

• Protect conversions from paid campaigns with contextual messaging.
• Avoid repelling readers on your blog with aggressive dialogs.
• Maximize consents where visitors are ready to give them.
• Stay fully compliant with GDPR and Czech regulations — no dark patterns, no pre-checked boxes.

Cookie consent is not a gate. It is a relationship. And relationships are built progressively.

People want to be safe online, but they do not want to spend their youth figuring it out. They do not understand what they share with websites or what they are consenting to — and that is exactly why they doubt their safety online. The solution is not to ask less. The solution is to ask clearly, at the right time, and only for what makes sense right now.

Most CMP tools work like toll collectors: show one big dialog with everything they need and hope the visitor clicks "Accept All." The result? Low consent rates, high rejection rates, and lost data.

Waulter Running Permissions works differently. You do not ask for everything upfront — you ask only for what is relevant right now. And as the relationship with the visitor deepens, you ask for more.

What it looks like in practice

1. First visit: essential + analytics

The visitor arrives for the first time. They do not know you, they have no reason to trust you. Show a minimal banner:

• Essential cookies (always active).
• Analytics cookies — with an explanation: "Helps us improve the content you read."
• No marketing, no remarketing.

Scenario rule: acceptance equals "empty" → minimal config (only PU046 — basic analytics).

2. Visitor reads 3+ articles: personalization

The visitor returns, reads more content. They are showing interest. Now is the right time to ask for personalization:

• New banner with an explanation: "Want to see content tailored to your interests?"
• Category: personalization (PU072).

Scenario rule: pageview > 3 AND purposes not-contains "PU072" → personalization config with forceStartCB: true.

3. User creates an account: marketing

The user registers. Trust is at a higher level — they gave you their email. Now is the right time to ask for marketing consent:

• Post-registration banner: "Want to receive tips and updates? Enable marketing cookies."
• Category: marketing/remarketing (PU047, PU073).

Scenario rule: customField1 equals "registered" AND purposes not-contains "PU047" → marketing config with forceStartCB: true.

4. User makes a purchase: full tracking

The customer completed an order. The relationship is at its strongest. The final step:

• Post-purchase banner: "Thanks for your order! Enable ad measurement so we can show you relevant offers."
• Category: ad measurement, remarketing audiences (PU074, PU073).

Scenario rule: customField2 equals "purchased" AND purposes not-contains "PU074" → full config with forceStartCB: true.

Why Running Permissions works

• Higher overall consent: Instead of a single big "Accept All / Reject All," you collect progressive consents in contexts where they make sense. Overall consent rates can increase as a result.
• Less banner fatigue: The visitor does not see a giant dialog on their first visit. Each consent request is small, contextual, and relevant.
• Better data quality: Consents collected in context are higher quality — the visitor knew what they were enabling and why.
• Full GDPR compliance: Every consent is granular, informed, and specific. No pre-checked boxes, no dark patterns. Regulatory authorities have nothing to question.

Technical implementation

Running Permissions leverages three key features of Waulter's scenario rule engine:

1. Purpose-based conditions — rules evaluate which purpose codes the visitor has already consented to (purposes contains/not-contains).
2. forceStartCB flag — forces banner display even when valid consent already exists (to ask for additional categories).
3. Custom fields — the SDK passes user state information (registered, purchased) via customField1–customField10.
4. Pageview tracking — rules react to the number of pages viewed within a session.

The result: consent is not a one-time question. It is a conversation that evolves alongside the visitor's relationship with your site.

Cookie consent is not just a button click. GDPR and Czech law define six conditions that must be met simultaneously — otherwise consent is invalid and you are processing data without a legal basis.

1. Freely given

The visitor must not be forced to consent. No cookie walls blocking content, no dark patterns, no "accept or leave."

Waulter ensures this by default: Accept and Reject buttons are always visually equal. Content access is never gated behind consent.

2. Specific

Consent must be given for a specific purpose, not as a blanket agreement. "Accept All" without per-category choice is not enough.

Waulter displays granular choice — the visitor sees individual categories (analytics, marketing, personalization) and decides on each separately.

3. Informed

The visitor must know: what data you collect, who processes it, for how long, and for what purpose. In plain language, not legal boilerplate.

Waulter auto-generates a cookie overview from the database and links it to legal documents — the privacy policy and cookie policy.

4. Unambiguous

Active opt-in. No pre-checked boxes, no implied consent by continued browsing. The visitor must take an affirmative action.

Waulter cannot pre-check boxes even by accident — the design makes it technically impossible.

5. Withdrawable

Withdrawing consent must be as easy as giving it. One click to change preferences, at any time.

Waulter displays a preference management widget accessible from every page. Withdrawal is immediate and reflects across the entire consent state.

6. Documented

Every consent must be recorded: who, when, what, which banner version. Without an audit trail, you have no proof.

Waulter stores every consent server-side with a transaction ID, timestamp, configuration version, and the visitor's detailed choice. Audit-ready from day one.

Why this matters

Invalid consent = no consent. If you fail even one of the six conditions, you are processing data without a legal basis. The Czech data authority (UOOU) carries out audits and can impose fines. Waulter meets all six conditions by default — you do not have to rely on your team not missing anything.

Every cookie consent is a transaction. You are asking the visitor for something valuable — access to their data. In return, you should offer transparency, trust, and value.

Two sides of the transaction

Transparency as the foundation

A Permission Transaction only works when both parties understand the terms. That means:

• Clear language — not a legal template, but an understandable explanation. "We want to measure how many people read our articles" instead of "processing of analytical cookies for the purpose of statistical analysis."
• Visible overview — the visitor can see what they consented to at any time and change their decisions.
• Versioning — every change to the banner configuration is versioned. If you change processing purposes, the visitor is prompted for fresh consent.

A documented transaction

Every consent interaction in Waulter is a documented transaction:

• Transaction ID — a unique identifier for every consent.
• Timestamp — the exact moment of granting or withdrawing consent.
• Configuration version — which banner was shown, with which purposes.
• Choice detail — exactly what the visitor allowed and what they rejected.
• Context — from which page, which scenario was active.

This record is your proof during an audit. Without it, "consent" is just a claim with no evidence.

For a detailed technical description of the transaction model, see the Waulter documentation.

Most cookie banners display technical categories: "analytics cookies," "marketing cookies," "functional cookies." The visitor has no idea what that means. They click "Reject All" and move on.

Waulter approaches consent differently. Instead of technical categories, it uses business activities as processing purposes — exactly as GDPR requires.

Technical categories vs. business activities

Why this works better

For the visitor: They understand what they are consenting to. "Traffic evaluation" makes sense. "Third-party analytical cookies for the purpose of statistical processing" does not.

For the business: Business activities match what the company actually does with data. A marketing manager understands "offer personalization" — no translation from technical jargon needed.

For compliance: GDPR requires processing purposes to be specific and understandable. Business activities meet this naturally — they are real processes, not abstract categories.

Automatic mapping

Waulter automatically maps business activities to:

• Purpose codes (PU046, PU047, PU072...) — internal identifiers for technical processing.
• Google Consent Mode signals — analytics_storage, ad_storage, ad_personalization.
• Cookie categories — which specific cookies fall under which activity.
• Legal documents — linking to the cookie policy and privacy policy.

The result: you set up business activities once and Waulter handles the rest. The visitor sees understandable purposes, the tech stack gets correct signals, and legal documents are generated automatically.

Practically automatable

Because business activities directly correspond to processing purposes in the GDPR sense, the entire chain is automatable:

1. You define a business activity (what you do with data).
2. Waulter assigns the correct purpose codes and cookie categories.
3. The cookie banner shows an understandable purpose to the visitor.
4. Google Consent Mode receives the correct signals.
5. Legal documents update automatically.

No manual mapping, no risk of inconsistency between the banner and the documentation.

A cookie banner does not have to be just a compliance obligation. With Waulter, it is a marketing tool that actively increases consent rates.

Social proof: real-time consent rate

Attach your real-time consent rate to the cookie banner: "92% of visitors trust us." (example)

• A real number — this is not a made-up statistic. Waulter calculates the actual consent rate from your data.
• Automatically updated — the number changes in real time. You do not need to configure or update anything.
• Your text — you control the wording. "92% of visitors trust us," "Most of our readers consent to cookies" — your brand, your voice.
• Protected — it only appears when the consent rate is high enough to serve as a positive signal.

Why it works: people follow what others do. When a visitor sees that, for example, 92% of people before them consented, trust grows and consent rates continue to increase. A positive feedback loop.

Custom incentive banners

Attach custom marketing to the cookie banner:

• "Consent gives you access to personalized content."
• "You help us improve the services you use."
• "Thanks to analytics, we bring you more relevant content."

Each banner is configurable via marketingMessage in the CCID configuration — text, color, link.

Measurable links with campaign codes

Every link in the marketing banner can be:

• Tagged with a campaign code — a campaign identifier for precise attribution.
• Measured — clicks and conversions tracked automatically.
• Signaled to the datalayer — the campaign code automatically appears as an event in Google Tag Manager.
• Connected to your analytics pipeline — data flows directly into your dashboards.

The result: the cookie banner is not a dead compliance element, but a measurable marketing touchpoint with real data.

For implementation details, see the Waulter documentation.

Good practice is not a one-time setup. It is ongoing oversight. The Waulter crawler regularly scans your website and checks six key areas — together, they give you a documented picture of the consent setup on your website.

1. Where your data flows

We scan network traffic (HAR files) to see which external services and third parties your website communicates with. In simple terms: we check who your site talks to behind the scenes. Every service, every request — you know exactly where data goes.

2. External services and scripts

Detection of all third-party scripts, trackers, and services loaded on your pages. Facebook Pixel, Google Analytics, ad networks, chat widgets — Waulter finds them all. Do you know every script running on your site?

3. Visual verification

We take screenshots of your cookie banner on different devices and browsers. Desktop, tablet, mobile — visual proof that your consent banner looks correct, renders properly, and works across all platforms.

4. Cookie banner presence

Automatic verification that your consent banner actually displays on every page — not just the homepage. A surprisingly common issue: the banner works on the main page but fails to appear on campaign landing pages.

5. Google Consent Mode settings

We verify your Google Consent Mode 2.0 signals are correctly configured and firing. Default state denied before consent, granted after — exactly as Google requires. We check all four signals: analytics_storage, ad_storage, ad_user_data, ad_personalization.

6. Detailed logging

Every consent interaction is logged with a timestamp, configuration version, user decision, and page context. A transaction ID for every consent. Audit-ready records for regulatory inspection — proof, not claims.

A protective shield, not a checkbox

Together, these checks give you a documented picture of the cookies, scripts and consents your website uses. This is not a one-time audit — it is ongoing monitoring that alerts you to problems before the regulator finds them.