The Consent audit report: a table of findings with a Meta pixel from an Asset Injector asset, Google Analytics loaded from the page markup and a YouTube embed, each with its host or cookie, the consent phase, the script that caused it, the attribution, a count and when it was last seen, above the Delete all findings and Recompute attribution buttons and the filters.
The Consent audit entry of the status report, marked as an error: 6 third-party requests and 2 cookies before consent in the last 7 days, with a link to the consent audit report.

Consent Audit checks whether your cookie consent manager blocks what it should. While a visitor has not decided on consent, or has refused it, a small script in the page records every request to another site and every new cookie, and the report names the library, Asset Injector asset or markup that caused each one. It runs on your own pages, with your own trackers, and blocks nothing: it shows where the blocking fails.

 a table of findings with a Meta pixel from an Asset Injector asset, Google Analytics loaded from the page markup and a YouTube embed, each with its host or cookie, the consent phase, the script that caused it, the attribution, a count and when it was last seen, above the Delete all findings and Recompute attribution buttons and the filters.

Features

  • 📊 Every leak, with its cause. Each finding names the host or the cookie, the script that made the request or set the cookie, and what that script belongs to: a library of an installed module, an Asset Injector asset, one of core's aggregated files, or markup in the page. Repeated findings add to one row's count, so the table grows with the kinds of leaks a site has, not with its traffic.
  • 🛡️ Undecided and refused, told apart. A finding records the phase the visitor was in when it happened. Visitors who accepted contribute nothing, and auditing visitors who refused can be turned off.
  • ⚙️ Act from the report. Filter by attribution, kind and phase. Allow this host adds a host the site depends on, such as a payment provider or a CDN, to the first-party hosts and removes its finding. Delete one finding or all of them, and recompute the attribution after installing a module.
  • 📈 How many visitors decide, and what. Optional, off by default: per day, how many page views arrived undecided, having accepted or having refused, and how many of the undecided ones ended in accepting all, accepting in part or refusing. The report shows the decision rate and the acceptance rate per day, and every counter can be exported through Views. Only the date and the outcome are stored.
  • 📊 A status report entry. Reports > Status report shows an error while anything was found in the last seven days, and a warning when no consent source is enabled or collection is paused.
  • 🧩 Klaro! sub-module. Reads the decision from Klaro. Services Klaro marks as required are left out, because declining grants them consent, and the status report says when every service is required or on by default, in which case a refusal cannot be observed.
  • 🧩 EU Cookie Compliance sub-module. Reads the decision from EU Cookie Compliance, in categories mode too, and warns on the status report for the two configurations in which a refusal cannot be observed.
  • 🧩 COOKiES sub-module. Reads the decision from the cookiesjsr cookie that COOKiES writes.
  • 🔌 Any other consent manager. Drupal.consentAudit.registerSource() takes a state() function answering undecided, accepted or refused, and an optional change callback. With several managers on one page, the visitor counts as accepted only when all of them say so.

Quick start

composer require drupal/consent_audit
drush en consent_audit consent_audit_klaro
  1. Enable the sub-module for the consent manager the site runs: Consent Audit: Klaro!, Consent Audit: EU Cookie Compliance or Consent Audit: COOKiES.
  2. Go to Configuration > System > Consent audit and list under First-party hosts any other domain the site depends on, one per line. Click Save configuration.
  3. Open the site in a private window, leave the consent notice unanswered and browse a few pages.
  4. Go to Reports > Consent audit: each row is a request or a cookie made before consent, with the script that caused it.

 6 third-party requests and 2 cookies before consent in the last 7 days, with a link to the consent audit report.

The status report entry while something is leaking.

Good to know

  • It is a diagnostic. Every finding still needs a change elsewhere: in the tracker's loading condition, in the consent manager's configuration, or in the module or theme that adds the tracker.
  • Nothing about the visitor is stored: no IP address, user agent, identifier, cookie value or query string. A request is stored as its host and a cookie as its name, with the page path and the script responsible, which is a full URL when that script is on another site. The module sets no cookie and uses no browser storage.
  • Findings not seen again within 90 days, a setting, are deleted on cron, and so are daily counts older than that.
  • With the daily counts on, every page view sends one small request to /consent-audit/tally, and one more if the visitor decides on that page. Administration pages and browsers that identify as crawlers are not counted. The counts are page views, not visitors: nothing tells one visitor from another.
  • The observer is the same on every page and for every visitor, so pages stay in the page caches.
  • The browser reports its findings to /consent-audit/report, which accepts anonymous posts from the site's own pages only, with a per-site token, a size limit and a rate limit per IP address.
  • With JavaScript aggregation on, a finding from an aggregated file is attributed to every library in it that has a script. Turning aggregation off pins it to one.
  • Requests made inside a frame from another site and HttpOnly cookies cannot be seen from the page, so they are not reported.
  • A consent manager is read as a whole: the first acceptance ends the audit for that page, even where the manager separates analytics from marketing.
  • The report and the settings have separate permissions, View consent audit report and Administer consent audit. The row actions and the buttons need the second.

Additional requirements

Recommended modules/libraries

Community documentation

  • README: what is stored, the report and its attribution, the consent decisions table, the status report, every setting, registering another consent manager and the limitations.
  • The READMEs of the Klaro!, EU Cookie Compliance and COOKiES sub-modules: how each reads its manager's decision, checked against that manager's code.

Supporting this module

Developed and maintained by Bloomidea. Bloomidea offers support and custom development for this module.

Supporting organizations: 
Development and maintenance

Project information

Releases