Key Concepts¶

Understanding these terms will help you navigate every other section of this documentation.

Configuration¶

A Configuration is the core entity in Waulter. In its most general form, a configuration is a managed container for content, settings, and user interactions — but in CMP mode (the most common use case), each configuration represents a separate consent widget (cookie bot) deployed on a website.

A CMP configuration defines:

• Which purposes (cookie categories) are available
• The consent banner text, styling, and template
• Which legal documents (Cookie Policy, Privacy Policy) to display
• Google Consent Mode settings (Basic or Advanced)
• Whitelisted domains where statistics are collected
• Consent duration (how many days a decision remains valid)

Each configuration is identified by a unique CCID (Configuration ID), such as AG1035. This is the ID you pass to the SDK when implementing Waulter on your site.

Purpose¶

A Purpose is a specific data-processing activity for which you collect consent. Each purpose represents a category of cookies or tracking technologies on your site.

Purposes are organised into categories (broad groups) containing individual purposes (specific tracking activities). Each purpose has a unique code (e.g. PU046) that the SDK uses internally.

Essential purposes are always granted and cannot be toggled by visitors. All other purposes require explicit consent.

Each purpose maps to one or more Google Consent Mode signals — when a visitor accepts a purpose, the corresponding GCM signals are set to granted. The consent banner groups purposes by category, so visitors see clear choices like "Analytics", "Marketing" rather than individual purpose codes.

See Purposes for the full mapping table and Google Consent Mode 2.0 for how signals flow to Google tags.

Scenario¶

A Scenario enables dynamic consent configuration based on runtime context. Instead of always loading the same configuration, a scenario evaluates rules against the visitor's context and selects the appropriate configuration.

Use scenarios when you need:

• Different consent configurations for different pages or sections
• A/B testing of banner designs
• Varying consent options by user type (logged-in vs anonymous)
• Campaign-specific consent flows
• Re-consent prompts when legal text changes

How evaluation works:

1. Rules are evaluated top to bottom in the order they appear in the dashboard.
2. First match wins — the first rule whose conditions are satisfied determines which configuration loads.
3. If no rule matches, the fallback configuration is used.

Available targeting variables include url, referer, pageview, acceptance, and customField1–customField10. Array-level targeting on purposes is planned.

See Scenarios for a complete reference of operators and examples.

Whitelisted Domain¶

Whitelisted Domains are the domains where the Waulter SDK is allowed to render the consent banner. The SDK validates the current page's hostname against the list of whitelisted domains configured for your configuration.

• If the domain matches, the banner renders normally.
• If the domain is not whitelisted, the banner will not appear.

Add domains in the Waulter dashboard under your configuration's settings. Include all domains and subdomains where you deploy the SDK (e.g. example.com, shop.example.com, staging.example.com).

Configuration ID (CCID)¶

The CCID (Configuration ID) is the unique identifier for your configuration. It is the primary parameter you pass to the SDK on initialisation.

• CCID for direct configurations: AG1035, AG2048, etc.
• Scenario ID for scenario-based setups: SC00009, SC00015, etc.

You find your CCID in the Waulter dashboard under your configuration's Implementation tab.

// Using a CCID directly (loads one specific configuration)
window.WaulterConfig = { id: "YOUR_CONFIG_ID", useGtm: true };

// Using a Scenario ID (evaluates rules to pick the right configuration)
window.WaulterConfig = { id: "SC00009", useGtm: true };

Consent State¶

The Consent State is the current set of granted and denied purposes for a visitor. After a visitor makes a decision, the consent state is persisted and restored on subsequent visits.

There are three possible consent decisions:

When a returning visitor loads the page, the SDK retrieves the stored consent state and immediately updates Google Consent Mode signals — without showing the banner again.

GCM Signal¶

A GCM Signal (Google Consent Mode signal) is a consent type sent to Google Tag Manager's consent API. The Waulter SDK manages these signals automatically.

Default state: On page load, the SDK sets all signals to denied. They are updated to granted only after the visitor consents to the corresponding purposes.

See Google Consent Mode 2.0 for a detailed guide.

User Sharing (Cross-Domain Consent)¶

User Sharing allows a visitor to consent once and have that decision honoured across your entire domain portfolio. When the visitor navigates from Domain A to Domain B (both running Waulter under the same account), the SDK detects the existing consent and suppresses the banner.

This is useful for companies operating multiple domains (e.g. example.com, shop.example.com, blog.example.com) who want a seamless consent experience.

See User Sharing for setup instructions and privacy considerations.

Custom Fields¶

Custom Fields (customField1 through customField10) let you pass arbitrary context values to the SDK. They serve two purposes:

1. Scenario targeting — rules can match against custom field values (e.g. show a different banner to customField1 equals "premium" visitors).
2. Data layer enrichment — custom field values are included in all Waulter:* data layer events, enabling segmented consent analytics in GTM.

window.WaulterConfig = {
  id: "YOUR_CONFIG_ID",
  useGtm: true,
  customField1: "premium",        // User tier
  customField2: "en-GB",          // Language
  customField3: "campaign-summer"  // Campaign
};

Custom fields can be updated at runtime via window.WaulterSDK.setCustomFields(). See Custom Fields for details.