Methodology

Scope

Assessments are made exclusively against EU and EEA law - Article 5(3) of Directive 2002/58/EC (the ePrivacy Directive), as amended by Directive 2009/136/EC and transposed into member states' national laws, and the General Data Protection Regulation.

The methodology does not assess the CCPA/CPRA, the LGPD, or any other regime. Sites that do not serve EU or EEA visitors may be subject to different obligations, and a grade recorded here says nothing about them.

Changelog

Older scans link to the methodology version they were scored under. The grade attached to a specific /scan/<id> URL is the grade as it was recorded on that date, under the methodology in force at the time.

1. v7.86th September 2026

   A scan that could not exercise a consent decision no longer receives a letter grade. Where no consent state was walked - no consent control the scanner recognises could be driven, or the accept and reject interactions did not complete - the grade is withheld as I with a reason that names the cause. This applies to the public scanner and the published benchmark alike, from one rule.

   • A letter grade requires that at least one consent state was exercised. Where the scan drove no consent control, the grade is withheld as I and the reason states what could not be done, rather than what the site does.
   • The rule applies to every letter, not only to the clean ones. An adverse letter is a statement about a named organisation and rests on the same evidence a clean letter would; where that evidence is absent, neither is published.
   • The withheld reason names the cause. A scan the site's edge protection refused, a consent platform that suppressed its own banner, and a page where no consent control could be located each keep their own sentence.
   • A withheld scan carries no score, no gate and no route to a better grade. The published contract now holds a report that prints a letter beside a withheld verdict.
   • Where a capture that exercised no consent state nonetheless cited tracking before any state - an identifier, a storage write or a collection call - the grade is F, not withheld: the tracking is the finding, and the reason names the vendors and the state that could not be exercised.
2. v7.75th September 2026

   The rules behind a B are published before a B on that basis reaches anyone. A measurement collection call before consent caps the grade at B whichever endpoint receives it, including one on the site's own domain. A static asset fetch does not cap it. Where requests went before consent is carried by a three-state marker that records rather than grades. The post-rejection flush rule names its markers and their limits, and a vendor that only loaded before consent is recorded rather than counted.

   • A measurement collection call before consent caps the grade at B, and the endpoint is named. A pre-consent loader is recorded and not graded.
   • The first-party marker has three states: third-party by default, mixed, and first-party origin. It records where requests went before consent and never moves the letter, and the delegation question is answered from an out-of-band hostname map rather than from a lookup inside the run.
   • The post-rejection flush rule names the three markers it reads and states plainly that a marker is necessary but never sufficient. Request bodies are classified as well as request URLs from this release.
   • A vendor observed loading before consent with no cookie, identifier or collection call is recorded, not counted, and the vendor table says so rather than reading 'Yes'.
3. v7.6.15th September 2026

   The cap at B turns on the measurement collection call, never on the script that loads the measurement library. It applies to a collection call whatever host receives it, including the site's own tag server.

   • The gtag.js loader no longer caps the letter. Fetching a script discloses the visitor's IP and the page address to the host as a by-product of the protocol - the same disclosure gtm.js, a consent-banner CDN or a hosted font makes - and the enforcement decisions that define this area turn on the collection hit, not the loader. Every such contact before consent is still recorded on the report by name.
   • A collection call to a first-party endpoint caps the grade at B like any other endpoint. A is available where the operator evidences that the server container gates collection until consent and the report cites that artefact, marked as evidenced by the operator, not observed by the scan.
4. v7.627th August 2026

   The document version now matches the scoring-engine version a scan records, so a published grade and the methodology that produced it carry the same number. The gate table is generated from the engine's gate labels rather than written by hand, and two descriptions that did not match the code were removed.

   • One version number. The document version is the scoring-engine version a scan records, so a grade and the rules that produced it carry the same number. /methodology/v1.3 redirects here.
   • The gate table is generated at build time from the scoring engine's own gate labels, so every gate is named here in the words the engine uses.
   • The reject test carries no threshold and no delta-sized severity ladder. A single tracking request after reject, or one tracking cookie that survives it, is the finding.
   • A top grade does not depend on a positive capture confirmation. The engine records pre-consent capture confidence as inconclusive, or not at all, and has no confirming state.
5. v1.32nd July 2026

   Behaviour-based grading of Google Consent Mode v2. We grade enforcement behaviour, not artefact presence: a correctly configured gtag.js loader that writes nothing and sends only a cookieless denied ping before consent no longer caps the grade at D. Inconclusive captures are withheld as I rather than recorded as a non-reproducible D.

   • The pre-consent storage gate fires on evidenced storage or identifier transmission - a cookie / localStorage / IndexedDB write, a device identifier, or a payload beyond the cookieless gcs=G100 denied ping - not on the mere presence of the gtag.js loader.
   • A correct Consent Mode v2 site caps at B, not A: before consent it still sends the visitor's IP address and the page they are on to Google. Top marks (A) are reserved for sites that send nothing to a third-party measurement provider before consent.
   • A verified first-party CNAME (server-side GTM) discloses to the site's own endpoint, not Google, and is not capped.
   • Inconclusive capture is withheld, never downgraded: when Consent Mode is detected but the scan captured no enforcement proof, the grade is withheld as I (inconclusive) rather than recorded as a flaky D.
   • Clean results are described as 'no pre-consent storage or identifiers observed' - never 'compliant'.

   6th September 2026 - Under v7.6.1 a collection call caps the grade at B whatever endpoint receives it, a verified first-party CNAME included. The grade movements table above records that case as B.

6. v1.226th May 2026

   Precedent corpus expansion to 20 cited DPA enforcement decisions across DPC, ICO, CNIL, EDPB, AEPD and BfDI. New /precedent/ public route with per-case permalinks. 'Cite this scan' / 'Cite this case' citation blocks added.

   • Registry expanded from 7 to 20 cases; AEPD (Spain) and BfDI (Germany) added as primary regulators.
   • Public /precedent/ corpus route with filterable index, per-case pages, and versioned JSON export at /precedent/registry.v1.json.
   • Citation block on /scan/[id] and /precedent/[slug] - BibTeX, APA, Markdown, plain text.
   • Methodology page itself is now versioned. /methodology redirects to the latest version. Scan pages link to the version they were scored under.
7. v1.115th May 2026

   Three-zone narrative (Observed -> Regulatory context -> Precedent) goes live on /scan/[id]. Dual-citation Wayback snapshots on every registry entry.

   • Public scan results render Observed / Regulatory / Precedent zones explicitly, never blended.
   • Every primary-source URL in the enforcement registry carries a web.archive.org dual-citation.
   • Static-vs-runtime methodology note added for Consent Mode v2 detection.

   6th September 2026 - 36 of the 57 registry entries carry a Wayback snapshot today, and the registry marks which. No grading rule turns on it.

8. v1.012th April 2026

   Initial published methodology. Reject-state network-leak threshold (absolute + relative gate). Severity ladder caps grade at C, D, or F based on delta size.

   • Reject-state leak detected when post-reject requests exceed pre-consent by both 10 absolute and 10% relative.
   • Severity ladder: <=25 delta = Moderate (cap C), <=50 = High (cap D), >50 = Critical (cap F).
   • Non-operable reject button caps grade at D regardless of leak size.

How we scan

The scanner loads a site in headless Chromium, driven by Playwright from an Irish locale and timezone, and identifies itself in the user agent it sends. It records every network request and cookie before consent, after accepting consent, and after rejecting consent. The resulting grade (A through F) is a summary of those observations - principally what the site stores and transmits before the visitor has chosen, and whether it keeps making third-party tracking requests after the visitor has rejected.

Consent lifecycle: the scanner identifies the consent management platform (CMP), exercises its accept and reject controls, and observes the delta in network and cookie behaviour across the three phases. CMP detection happens via DOM signatures + window-object sniffing; no proprietary integration is required from the scanned site.

We grade behaviour, not presence

Loading a script is not, by itself, the storage of or access to information on the device that Article 5(3) turns on. We therefore stopped treating the mere presence of the gtag.js loader as a violation, and grade what the site does before consent.

We describe a clean result as "no pre-consent storage or identifiers observed" - never "compliant". We assess storage and transmission behaviour in a single automated visit; we do not adjudicate a site's full GDPR posture.

Collection Calls and Asset Fetches

Two requests can both disclose a visitor's IP address and the page they are on before consent, and only one of them caps the grade. The line the engine draws is a collection call to a measurement endpoint, against a static asset fetch.

A collection call is a request to a measurement endpoint - /g/collect, /collect, /s/collect and their equivalents - carrying a payload about the visit. The parameters name the event, the page URL, the referrer, the screen dimensions, the browser language, the container hash and, on a Google endpoint, a per-pageload client identifier and any ad-click data present on the URL. A static asset fetch is a request for a file. It discloses the visitor's IP address, user agent, language and the referring page, because every HTTP request does, and it carries no payload about the visit.

A measurement collection call before consent caps the grade at B - not C, and not D. A pre-consent loader script is recorded on the page and is not graded at all. We do not treat a library fetch, on its own, as a collection call; that is our grading rule, not a statement of the law. The engine grades what the site sends rather than which files it fetches.

First-party Tagging

Serving a collect endpoint from the site's own domain does not lift the pre-consent collection cap. A measurement collection call before consent caps the grade at B whichever endpoint receives it, and A is possible where the operator evidences that the server container gates collection until consent and the report cites that artefact. What stands beside the grade is a marker. It records where requests went before the visitor decided anything, and it never moves the letter.

Where requests went before any consent decision was made. Recorded, not graded: the marker does not affect the grade and takes no view on whether the traffic was lawful.

The three states

The marker has three states and no others. In each sentence below, {domain} is the site's own registrable domain, and the sentence is the one the scan page prints with that domain filled in.

Third-party by default

Before any consent decision, this page contacted hosts outside {domain}.

Mixed

Before any consent decision, the only host this page contacted outside {domain} was the consent platform's own.

First-party origin

Before any consent decision, no request was observed leaving {domain}.

A tag-manager loader does not earn Mixed. The consent platform's own host is the one third party a site cannot avoid contacting before consent, because contacting it is how the visitor is asked. A tag manager is measurement infrastructure the site chose to fetch from a vendor before anyone decided anything, and it is exactly the contact the report records by name.

What denies the marker

Every distinct host contacted before any consent decision - the banner untouched - is taken in turn. A host either denies the marker or it does not. Four reasons deny, and the phrase the scan page prints for each is the phrase below.

• third-party-host - the host is outside the site's registrable domain. The page prints outside <domain>. A geolocation lookup by the consent platform denies here rather than as consent infrastructure: asking a vendor endpoint which rules apply to this visitor has already sent that visitor's IP address to the vendor.
• consent-infrastructure - outside the registrable domain, but it is the consent platform's own script host. The page prints consent platform host (<vendor>). This is the only denial Mixed tolerates.
• cname-delegated - on the site's own domain, but the recorded chain for it ends outside that domain. The page prints delegated to <host>. A vanity CNAME that lands back on the site's own domain never left it and does not deny.
• unverified-host - on the site's own domain, and the record does not answer for it. The page prints resolution not on record. This is not evidence of delegation; it is the absence of evidence against it, and it denies, because unknown is never treated as benign.

Two hosts never deny. The first is the document's own hostname and its www. sibling: a delegated vendor host there would mean the whole site is that vendor's, which is a different finding entirely, so it is stated as a carve-out rather than inferred from a lookup we do not perform. The second is a declared first-party origin, described below.

No denial at all is First-party origin. Denials that are all consent-infrastructure are Mixed. Anything else is Third-party by default.

No DNS runs inside the scan, and Cloud Run is allowed by name

The delegation question is answered from an out-of-band hostname map built before the run, never from a lookup inside the run that the run is also measuring. A hostname on the site's own domain that the map does not answer for is resolution not on record and denies. A public scan of an arbitrary site has no such map, so that is the state such a hostname reports.

A hostname on the site's own domain that resolves by an A record to an operator-provisioned load balancer - a server-side GTM container on Google Cloud Run is the ordinary case - counts as first party for this marker. It counts because it is declared, by name, in a register a reviewer can read, and never because the scan inferred it from a response header, a latency or a hostname that looks like a tag server. What is being claimed - that the endpoint is operated by the site's own organisation - is not observable from a browser, and a detector for it would be a detector for a claim. Each declaration names the one registrable domain it is valid for, so it can only ever make that organisation's own subdomain first party and can never make a vendor's domain first party for anybody.

A host accepted this way is printed under the marker, with the name of the operator who declared it and the date of the declaration. The declaration is the one thing the marker takes on trust, so a reader can see it and disagree with it. A site that contacted nobody at all carries no such line, and the two cases therefore read differently.

The transfer a Cloud Run container implies is assessed separately and is not softened by the declaration: the endpoint's jurisdiction is recorded. The marker itself moves no letter and takes no view on whether the transfer is lawful.

Tracking After a Rejection

Not every request observed after a reject click is something the site decided to send after the rejection. A tag already loaded and running keeps its own in-page timers alive for the rest of that page view, and dispatches a hit describing engagement that had already been measured. That is a different fact from a tag that starts collecting after a rejection, and different again from a tag that fires on a fresh page load with the rejection stored.

Three markers are read, each bound to the hostname that emits it so a marker cannot be borrowed by an unrelated tracker: a GA4 user_engagement event carrying the time already spent (_et), a GA4 dispatch delay (tfd), each on a Google measurement host or a first-party endpoint observed speaking Consent Mode in the same capture, and a Taboola time-on-site value (tos) on a Taboola endpoint.

A GA4 hit-sequence number (_s) above one is not read as a marker. It says only that the hit is not the first of its session, which is equally true of a click, a scroll or a single-page navigation started after the rejection. Scans recorded before 5th September 2026 read it as one.

From this release the classifier reads request bodies as well as request URLs. A beacon sent as a POST with its parameters in the body used to be classified on its URL alone, which under-reported what the request carried. Scans recorded before 5th September 2026 were scored without it.

Identifiers Under a Denied Signal

A cookieless denied ping can still carry a client-identifier parameter. Google documents that under analytics_storage='denied' GA4 will not read or write first-party analytics cookies, and is silent on whether an identifier is sent at all. The question we can answer from the browser is narrower and more useful: does the value hold across page loads, or is it regenerated each time?

The rule is that the answer is recorded and never graded. Where the scan can compare the value across page loads in one consent state, it records whether the value held or was regenerated, and it records the number of loads the comparison rests on. The record sits beside the capture that produced it and moves no letter.

A record of this kind is a statement about one site in one capture, never a general property of Consent Mode. It says nothing about what the value is derived from, and nothing about whether a value of this kind is personal data - that decision is the controller's.

Recorded, Not Counted

A vendor whose script was fetched before consent, where the capture observed no cookie, no identifier and no collection call, is recorded, not counted. It appears in the vendor table with its own mark, it is named in the assessment prose, and it does not contribute to the pre-consent tracking count.

The vendor table never reads "Yes" for such a row. "Yes" is reserved for a request carrying data. A bare load reads as loaded, and the legend beside the table says what the mark means, because a reader who cannot decode a mark reads the column heading instead.

Whether a given pre-consent load is strictly necessary is the site operator's call. We record what the browser did and stop there.

Grade movements in the behaviour-based rebaseline (v1.3)

Re-baselines were human-reviewed, not auto-applied. Every grade that moved did so because a rule in the table below changed, and the rule is named beside it.

What rejecting consent has to achieve

There is no threshold and no delta arithmetic. After the scanner operates the reject control, a Finding is recorded if any tracking tag fires, or if a tracking cookie set before the visitor chose is still in the jar afterwards. One request is enough. There is no request floor, no percentage floor and no severity ladder scaled to the size of the delta.

Three carve-outs exist, all of them in the code rather than in editorial judgement:

• Infrastructure only. If the only traffic after reject is the consent platform and other non-tracking infrastructure, no Finding is recorded.
• Downgraded signal. If Consent Mode v2 is functional, every post-reject tracking request carries an observed on-wire downgrade (gcs storage denied, or Microsoft asc=D), and no tracking cookie persisted, the result is the D2 gate rather than the F4 gate. The vendor was told the visitor said no. One unrestricted post-reject tracker removes this carve-out for the whole scan.
• Divergent page content. If the accept-branch and reject-branch browsers were served materially different pages (A/B test, geo-targeting, a late SDK), the tag half of the comparison is unsound and is suppressed. Cookie persistence is a direct before-and-after observation of the jar, so it still counts.

Gate definitions

Every grade is the output of a named gate. The letter in the gate code is the cap it applies: an F gate caps the grade at F, a D gate at D, and so on. When more than one gate fires on the same scan the strictest cap wins. A gate can only cap a grade, never raise it.

The table is generated from the scoring engine. These are the exact strings the scanner uses when it names a gate on a result page, so the description here cannot drift from the code that produced your grade.

F gates - cap F

Substantive failure. Tracking without a working consent gate, or personal data in a tracking request.

D gates - cap D

Consent infrastructure is present but did not do its job on this visit.

C gates - cap C

Consent mechanics or transfer safeguards are weak, but tracking is gated.

B gates - cap B

Something reached a third party before consent, in a restricted or non-tracking form.

The theatrical-CMP sub-grade

A D can carry one sub-grade. Where a reject produces no material reduction in tracker activity, the result is marked theatrical: the banner is deployed and the reject button changes little about what the page then sends.

The comparison is between two counts from the same capture. The denominator is the vendors that fire on accept, excluding pure infrastructure and Consent Mode restricted pings that are respected on both branches. The numerator is the vendors still firing after a recorded rejection. At a ratio of 0.8 or above the sub-grade attaches, which is four of every five.

Below two accepting vendors the comparison is not made at all. On a site with one tracker a single leak reads as a ratio of 1.0, and a floor is what stops that being reported as a decorative consent platform.

The sub-grade attaches to a D reached through the consent gates. A D reached by demotion for a Consent Mode contradiction does not carry it: the comparison would be theatrical-shaped for a reason that has nothing to do with the reject button.

What this is, and what it isn't

Why these signals matter

The behaviour-based stance and the post-reject gates are grounded in published regulator guidance and enforcement decisions, not in any private interpretation. The full corpus is published at /precedent/; representative anchors:

• EDPB Cookie Banner Taskforce - Report of work undertaken (Report 2/2023)

  European Data Protection Board guidance on the practical application of Article 5(3) of the ePrivacy Directive and the Article 7 GDPR consent obligations to cookie banners and trackers.

• CJEU C-582/14 (Breyer v Germany)

  A dynamic IP address is personal data in the hands of a party with the legal means to identify the visitor. The basis for capping a pre-consent Google measurement disclosure at B: the visitor's IP reaches Google before consent.

• CNIL SAN-2020-012 (Google) and SAN-2020-013 (Amazon)

  Foundational French DPA cookie precedent: advertising cookies set on arrival without consent are unlawful under Article 82 of the French Data Protection Act.

Machine-readable

The same contract is published as JSON at /methodology/v7.8.json. It carries the dimension weights for both tiers, the grade band midpoints, the gate table, the cross-border transfer weights, the five consent states and where each one can be measured. Every number in it is read from the scoring engine at build time, so the published contract and the code that grades a scan cannot part company.

Frozen at publication. This corpus is the record as it stood on its asOf date. Corrections are published as new dated versions at their own URL, and nothing here is edited in place. Reuse is covered by the ConsentMark corpus compilation licence 1.0: cite it with attribution to Obscurity Ltd (CRO 622475) and do not re-characterise what it says.

@misc{consentmark-methodology-v7.8,
  author       = {{ConsentMark}},
  year         = {2026},
  title        = {ConsentMark methodology v7.8},
  howpublished = {\url{https://www.consentmark.com/methodology/v7.8}},
  note         = {ConsentMark methodology v7.8}
}

ConsentMark. (2026, September 6). ConsentMark methodology v7.8. Methodology v7.8. https://www.consentmark.com/methodology/v7.8

[ConsentMark methodology v7.8 - ConsentMark](https://www.consentmark.com/methodology/v7.8)

ConsentMark methodology v7.8 - ConsentMark, 2026-09-06, methodology v7.8, https://www.consentmark.com/methodology/v7.8

Disputing a grade

If you believe a published scan misrepresents your site, write to contact@consentmark.com with the scan URL and the specific Finding you contest. We commit to:

• Reading every dispute, with Dónal Troddyn as the named responder, and amending or retracting findings where the evidence is contested. No clock is published: it would hand the complainant the stopwatch.
• A 14-day notification window before any change to the public grade of an affected site, where a regrade is the result of a methodology change rather than a fresh scan.
• Preserving the original scan record alongside any correction, so the audit trail is never silently rewritten.