Fix, track, and verify findings

Put the finding in the right hands#

Each finding leads with a copyable handoff. Choose Marketing & analytics, Privacy & legal, or Developer / coding agent. The message includes the captured URL, visitor location, date, and private report link. Finding history also includes its latest assessment and lasting fix workflow.

• Marketing & analytics: explain the observed consent behavior and ask the analytics owner to check measurement or campaign impact with development.
• Privacy & legal: ask the privacy owner to review the evidence against the intended visitor choice and consent requirements.
• Developer / coding agent: copy the technical fix brief, with evidence, places to inspect, and verification steps.

Open a finding or report to edit the generated wording before copying. In the fix queue, short heads-ups and developer briefs can be copied directly. Cookie evidence does not measure lost visits, conversions, or under-reporting, and a finding is not a legal determination. Messages distinguish a confirmed observation, a returning finding, an uncertain follow-up, and a finding no longer observed.

Give the fix owner a useful starting point#

1. Open the finding in its report. Confirm the captured page, visitor location, and consent path.
2. Read the observed evidence, suggested fix, and verification steps. Inspect screenshots and cookie domains to locate the tag or consent configuration involved.
3. Copy the fix brief into your issue tracker or share a Markdown report with the person making the change.
4. Record a short note describing the intended change, deployment, or remaining question.

Typical investigation starts with tag initialization, consent category mapping, control handlers, and how a stored choice is persisted. Follow the finding’s specific suggested fix rather than assuming every tracker needs the same configuration.

Follow a finding across checks#

Open Findings for your workspace’s fix queue. Each persistent finding follows one rule at the same saved site, captured URL, and visitor location. A repeat check adds evidence to its history instead of creating a new work item. Different sites, URLs, and locations keep separate findings.

• Open the finding’s detail page to see its first and latest observation, fix guidance, and check history.
• Keep a persistent review status and note describing the investigation, deployment, or remaining question.
• Add an HTTP or HTTPS ticket link to connect the work to your issue tracker. This saves a link; it does not create a ticket or send anything to that service.
• In a workspace with Finding assignment included, assign a current teammate and use Assigned to me in the queue. Existing assignments remain readable after a plan change.

Persistent finding history and review notes are available on Free. Teammate assignment is included on Pro. Usage shows the active workspace’s current entitlements.

Use review status to track work#

The persistent finding’s review and note follow the issue across checks. A report’s saved review remains a separate annotation for that particular capture. Changing either review does not change measured evidence, rerun a check, or verify a fix. Earlier report annotations stay intact.

Read what the evidence says#

Verify the deployed change#

1. Deploy the change to the public URL captured in the original report.
2. Return to the original finding and choose Verify this fix, or verify all fixes from the report.
3. Wait for the follow-up check. It uses the same site URL and visitor location, and consumes a normal check slot.
4. Open the verification result and compare it with the original finding. Keep the original report as the baseline for this investigation.

Verification runs the consent audit and compares the selected original finding, or all original findings, against fresh evidence. If the site URL has changed, verification against that original URL is unavailable; run a new check for the updated site. An unrelated active check for that location must finish before a targeted verification can start.