Didomi Cookies Before Consent: Debugging and Audit

If cookies appear before a Didomi choice, first identify which integration launches the script. The notice collects choices; your integration must apply them to the relevant vendor and purpose. A vendor label in the notice is not evidence that an independently embedded script waits.

Set up a repeatable audit

Use a fresh browser profile, record the page URL, time, browser and test region, and open Network with Preserve log enabled. Run the free cookie audit for an initial server-browser check. Use the extension for interactive tests in your own browser; region, login and saved choices can produce different results.

Verify the vendor gate before loading the script

1. Check the live notice configuration and vendor API ID against the script you are investigating. A display name is not a substitute for the configured ID.
2. With direct script integration, verify Didomi’s inactive script type and vendor attributes. Check Didomi’s custom script instructions before changing markup.
3. Wait for SDK readiness before reading the user’s status. Treat unavailable status as unresolved rather than accepting it as permission to initialize an optional tracker.
4. Check consent-change handling using the SDK events documentation. Test a later choice as well as the first page load.
5. Reject, accept a limited category, and revoke it. Record which vendor requests start or stop at each step; also inspect requests after navigation.

Test the four consent states

Symptoms and next checks

Interpret evidence before reporting a violation

A necessary consent-preference cookie is not equivalent to an advertising identifier. Existing cookies are not necessarily new writes. A Google request under denied consent can be a cookieless ping in advanced Consent Mode; inspect its behavior and your intended configuration with the Consent Mode checker. Classifications are review prompts, not a legal verdict.

Save a reproducible issue

Include the exact URL, clean-session steps, chosen categories, expected result, request or cookie name, initiator and timestamp. For developer handoff use Initiator Trace and a redacted debug snapshot. Repeat the same test after a fix and review any remaining redaction needs before sharing.

Investigate a vendor that starts before the SDK is ready

A common debugging scenario is an analytics loader running during application startup while the consent SDK is still resolving its state. Reproduce it with a fresh session and a slower connection in browser developer tools. The goal is not to manufacture a legal conclusion from a slow test; it is to see whether your application has an unsafe initialization path.

Find the code that decides to start the vendor. Does it check a service-specific permission, or does it simply check that Didomi exists? Does it fall back to enabled after a timeout? Record that decision point. A timeout should not silently become the user's permission to start optional processing.

Check the service identifier across the whole integration

Keep the vendor identifier used by the page alongside the service configured in the consent property. A correct consent UI can coexist with a mismatched identifier in application code. A renamed service or copied environment configuration is worth investigating when the banner state and SDK behavior disagree.

Trace more than one loading path. The same service can appear through application code, GTM and an embedded widget. Fixing one path does not automatically stop the others. Use the network view to find the destination, then confirm its owner in the implementation.

Test transitions that a fresh scan cannot cover

Run these cases separately and name them in your report. Clearing storage before every action hides returning-visitor and withdrawal bugs. Conversely, retaining storage for the initial baseline makes it impossible to distinguish new visitors from people who already granted permission.

Didomi troubleshooting FAQ

Is a consent-change callback enough to start a vendor?

The callback tells your integration that something changed. Read the relevant permission before starting a service. Rejection and withdrawal are changes too. Keep startup idempotent so repeated callbacks do not create duplicate SDK instances.

What if Didomi is detected but no consent event is recorded?

Record that uncertainty instead of treating it as acceptance. Check which SDK version and integration path are deployed, when the extension started observing and whether the action was a saved preference rather than a new click. Use Didomi's documentation for the deployed integration.

Can ConsentScope fix the vendor mapping?

No. It observes browser evidence and helps identify a place to investigate. Apply the fix in Didomi, the application or the tag manager, then repeat the same scenario. Save a debug snapshot when another team owns that part of the stack.

For recurring client audits, see the bulk URL scanner and plans and limits. A passing scan describes only the page and conditions observed.