Consent Banner Speed Test

---
name: consent-banner-speed-test
description: Audit a live website’s consent banner against an approved DataGrail implementation on matched desktop and mobile runs, identify the likely CMP and consent footprint, apply publication-quality gates, and generate detailed HTML/JSON plus a branded PNG summary. Use for consent-banner speed tests, CMP comparisons, cookie-banner diagnostics, and DataGrail competitive evidence. Do not use for legal compliance conclusions or claims that have not passed the included quality gate.
---

# Consent Banner Speed Test

Measure what a visitor actually experiences. Preserve every result internally, but generate an external comparison claim only when the evidence passes the quality gate.

## Comparison input

Accept one public target URL. Compare it with one DataGrail implementation that the user or DataGrail team has approved as the benchmark.

Use the environment variable `DG_CONSENT_BASELINE` in `Label|URL` form when the environment has an approved default. Otherwise ask for the approved benchmark URL before running a competitive comparison. Do not silently use a vendor marketing site or pick a customer merely because its logo appears on a customer page.

Default comparison conditions:

- five fresh-browser runs per URL and device
- desktop and mobile profiles
- a 15-second banner-detection window
- the user's current locale and timezone when known
- one region disclosed in the report
- balanced sequential order so the same URL is not always tested first

## Run the comparison

Use [scripts/audit.cjs](scripts/audit.cjs). It needs Node.js, Playwright, and a Chromium-compatible browser. First use the skill's local `node_modules/playwright` when present. Otherwise, in Codex desktop call `load_workspace_dependencies` and use the bundled Node.js packages. Then run:

```bash
NODE_PATH="<node_modules>" "<node>" scripts/audit.cjs 
  --target "Target site|https://example.com" 
  --baseline "Approved DataGrail benchmark|https://approved.example" 
  --baseline-approved 
  --region-label "California, US" 
  --output-dir "<absolute-output-directory>"
```

Run the audit from the local command environment. Do not use the in-app browser, computer-use browser, `web.open`, or a personal browser as the measurement surface. Those surfaces may return `ERR_BLOCKED_BY_ADMINISTRATOR` even when the website is reachable and the Playwright runner works.

If the local runner reports a navigation or security-page block, preserve that first result and perform one diagnostic check with an ordinary HTTP HEAD request. A successful HEAD request does not count as a measurement; it only distinguishes a browser-surface restriction from a site or network block. When full local Chrome is available, rerun the entire matched session once with `--headed` and an explicit `--chrome-path`, keeping every other condition unchanged. Use the complete replacement session only if no tested profile returns a block page. If the headed retry is also blocked, keep the result as blocked and do not substitute inferred data.

`--baseline-approved` means the benchmark is approved for external comparison use. It does not mean the resulting claim is approved. The script still applies the evidence gate.

Use `--help` for all options. Without a baseline, repeatable `--target` values still run a neutral multi-site diagnostic with three runs per device.

## Outputs

Keep the generated files together:

- `consent-speed-share.png`: concise DataGrail-branded result image, including a clear blocked or inconclusive state
- `consent-speed-report.html`: detailed diagnostic report
- `consent-speed-report.png`: full-page rendering of the detailed report
- `consent-speed-audit.json`: raw measurements, comparisons, and quality-gate status
- first-run screenshots for every URL/device pair

The share image must still be produced when access is blocked or no banner is detected. Missing measurements are labeled `Not detected` or `Not measured`, never `0 ms`.

## Publication quality gate

Read [references/methodology.md](references/methodology.md) before interpreting a comparison or writing competitive copy.

A device-profile claim is `publishable` only when all of these are true:

- both sites have at least 80% detection coverage, with a minimum of two successful detections
- the benchmark has direct DataGrail evidence
- the benchmark was explicitly marked approved
- the DataGrail median is faster than the target median
- the observed ranges do not overlap

The overall report is externally publishable only when every tested profile passes. Otherwise it is `internal_review`. Do not hide, rewrite, or reverse an unfavorable result. Keep it internal and either diagnose the implementation or run a new matched session for a legitimate methodological reason.

Use “faster in this test” rather than an unqualified product-wide claim. A live-site test measures the whole implementation: CMP configuration, tag manager, network, page code, geography, and vendor delivery.

## Failure handling

If bot protection, authentication, a CAPTCHA, an administrator policy, or a network restriction blocks a site:

- preserve the error in JSON
- generate the blocked-state share image
- report the target as unmeasured
- do not substitute a search result, earlier benchmark, or inferred CMP

## DataGrail content handoff

When the user also requests Daniel Barber or DataGrail LinkedIn copy, hand only current-session, quality-gated results to `dg-content-machine`. Get human approval before publishing, sharing outside the intended audience, or scheduling the post.