Testing, Debugging & Troubleshooting

The Mine CMP exposes a set of URL parameters and inspection tools to help you test banner behavior, validate your integration, and diagnose issues without modifying your site code. This article covers the available mock parameters, how to enable debug logging, how to intercept analytics events, and the most common failure modes to look for when something isn't working.

⚠️

Debug and mock parameters are for development and testing only. Do not use them in production.

Testing different banner variations

The CMP picks which banner to display by evaluating rules against the user's geo location, URL, and browser language. You can override each of these inputs at runtime with URL parameters, which makes it possible to preview every banner variation from a single browser without leaving your machine.

Mock geo location

Use cmp-mock-geo to test region-specific banners (e.g., GDPR for EU users, CCPA for California).

https://example.com?cmp-mock-geo=US
https://example.com?cmp-mock-geo=DE
https://example.com?cmp-mock-geo=FR

The cmp-mock-geo parameter overrides all other geo sources, including the meta tag (<meta name="cmp-geo">), global variable (window.__CMP_GEO__), and script attribute (data-geo).

Geo matching is case-insensitive — DE, de, and De are all equivalent.

Mock URL

Use cmp-mock-url to test URL-based rules without actually navigating to that path:

https://example.com?cmp-mock-url=/checkout
https://example.com?cmp-mock-url=/account/settings

This overrides the current URL for rule matching only.

Mock browser language

Use cmp-mock-lang to preview localized banner content in any configured language:

https://example.com?cmp-mock-lang=de
https://example.com?cmp-mock-lang=fr

This overrides the browser language for localization. If the requested language is not configured for the banner, the standard fallback chain applies (English, then the first available language).

Combining parameters

Mock parameters can be combined to test a specific scenario end-to-end:

https://example.com?cmp-mock-geo=DE&cmp-mock-lang=de&cmp-mock-url=/checkout

A/B testing buckets

Rules that use A/B testing (configured with mainBannerId, secondaryBannerId, and mainBannerTrafficPercentage) persist the assigned bucket in local storage so the same user sees the same banner variant across sessions. To re-roll the bucket assignment during testing, clear local storage for the site.

Verbose logging

Enable detailed console logging to see what the CMP is doing at each step — which rule matched, what consent was loaded, which categories were blocked or unblocked, and so on.

https://example.com?cmp-debug=true

Open your browser's developer console to view the output. This is the first thing to check when the banner is not displaying as expected.

Forcing a specific banner or layer

The following two features are planned but not yet implemented. They are documented here so you know what to expect when they are released.

Force show a specific banner

Bypass rule matching and force-show a banner by ID, regardless of rules, domain policies, or consent state:

https://example.com?debugBanner=901

Control initial layer

Force the banner to open directly on a specific layer:

https://example.com?debugLayer=second   # Cookie preferences
https://example.com?debugLayer=first    # Default first layer

Mocking analytics events

The CMP sends analytics events to https://cmp.mineos.ai to track banner displays, dismissals, consent changes, and errors. During testing, you can redirect these events to a mock endpoint to inspect them without polluting production analytics.

https://example.com?cmp-mock-analytics-endpoint=https://mock.test/events

All analytics events that would normally be sent to the production endpoint are sent to the mock endpoint instead.

Event types

There are four event types you may observe at the mock endpoint:

All events also include a set of base fields: eventType, timestamp, domainGroupId, bannerId, sessionId, userId, configVersion, geo, pageUrl, userAgent, sdkVersion, and platform (always 'web').

Delivery mechanism

Events are sent using sendBeacon (fire-and-forget). If sendBeacon fails or is unavailable, the CMP falls back to fetch with exponential backoff (3 attempts, delays of 1s → 2s → 4s). Error events are sent immediately rather than batched.

Note: CMP operational analytics are exempt from consent requirements under GDPR Article 6(1)(c) and are sent regardless of the user's Analytics category consent.

Checking the SDK state

If verbose logging isn't enough, you can inspect the CMP state directly from the browser console using the MineCMP global object:

// Is the CMP initialized?
MineCMP.isReady();

// What is the current banner state?
MineCMP.getBannerState();
// → { visible: true, layer: 'first', bannerId: 'banner-eu' }

// Has the user made a consent choice?
MineCMP.hasConsentChoice();

// What is the user's current consent?
MineCMP.getConsent();

You can also force the banner open for inspection:

MineCMP.show('second');

Or clear stored consent to re-trigger the auto-show flow:

MineCMP.clearConsent();
// Then reload the page

Inspecting stored consent

Consent is stored in browser localStorage under a key in the format:

cmp_{domainGroupId}_consent_{bannerId}

Each banner has its own independent consent record. Open the Application tab of your browser's developer tools to inspect, edit, or delete these entries directly. This is the fastest way to simulate "first visit" behavior or to test expired-consent scenarios.

If localStorage is unavailable (e.g., private browsing, quota exceeded), the CMP falls back to sessionStorage, and then to in-memory storage if sessionStorage is also unavailable.

Common issues

The banner is not appearing

When the banner does not appear, work through this checklist in order:

1. Configuration didn't load. If configuration.js is not included on the page or fails to load, window.__MINE_CMP_CONFIG is never set and the CMP fails open — no blocking and no consent UI. Check the Network tab to confirm configuration.js loaded with a 200 status.
2. Domain doesn't match. The CMP only operates on domains listed in the configuration's domainPolicies. If the current domain doesn't match any policy (including wildcard patterns like *.example.com), the CMP does nothing.
3. No rule matched. Rules are evaluated by sortKey descending. A rule matches only if all conditions are met (regions and url). If no rule matches or the matched rule has no banner, the CMP does nothing.
4. User has already consented. If a rule matches but valid consent already exists in localStorage for that banner, the banner stays hidden and the existing consent is applied. Clear the relevant cmp_{domainGroupId}_consent_{bannerId} key and reload to re-trigger the banner.
5. SoftOptIn with hidden first layer. SoftOptIn banners configured with firstLayerHideBanner: true do not auto-display. The website is responsible for opening the banner — typically from a "Cookie Settings" link calling MineCMP.show('first').
6. Bot detection. The CMP detects bots and crawlers (via user agent, navigator.webdriver, and headless-browser indicators) and skips CMP logic for them to avoid SEO impact. If you're testing with an automation tool, this may suppress the banner.
7. CSP is blocking resources. A strict Content Security Policy can prevent cmp.js from loading or applying styles. If CSP blocks CMP resources, the library logs errors and fails open. Verify your CSP whitelists the CMP domain for script-src and connect-src, and either allows inline styles or uses nonces for style-src.

Enable ?cmp-debug=true to see which of these checks short-circuited the initialization.

The banner appears, but cookies are still being set

This usually means scripts are running before the CMP installs its blocking interceptors. Confirm:

• configuration.js and cmp.js are the first scripts in <head>.
• Neither script uses async or defer. Both must load synchronously so blocking activates before any other scripts run.
• If you have set data-auto-blocking="disabled" on the cmp.js script tag, you are responsible for tagging every blockable element with data-cookieconsent attributes. The HTTP cookie cleanup sweep and CSS-selector-based blocking are skipped in this mode.

The banner doesn't update on client-side navigation (SPAs)

Rules are evaluated once at initialization. The CMP does not re-evaluate rules on client-side route changes from React Router, Vue Router, Angular Router, or similar libraries. If your application changes routes and you need the CMP to re-evaluate, call MineCMP.show() explicitly after the navigation. Full automatic SPA route-change support is not currently implemented.

Wrong language is displayed

The CMP picks language in this order:

1. Browser language (if available in the configuration)
2. English ('en')
3. First available language in the configuration

If the wrong language is showing, confirm the language is included in the banner's localized content and that the browser is actually reporting the language you expect. Use ?cmp-mock-lang=xx to force a specific language and isolate the issue.

The wrong banner is shown for the user's region

Geo detection uses the following sources, in this order:

1. Meta tag: <meta name="cmp-geo" content="DE">
2. Global variable: window.__CMP_GEO__ = "DE"
3. Script attribute: <script data-geo="DE" ...>

If none of these are set, geo will be unavailable and only rules with empty regions will match. Use ?cmp-mock-geo=XX to verify the region-specific rule works in isolation.

CSP is blocking the CMP

Sites with strict CSP must whitelist the following:

• script-src — CMP domain (cmp.mineos.ai or cmp.staging.mineos.ai), required for both configuration.js and cmp.js
• style-src — 'unsafe-inline' for customCss, or a nonce-based approach
• connect-src — CMP domain, required for analytics

If CSP blocks CMP resources, the library logs the error in the console and fails open.

Quick reference