Tracker coverage vs page count: what privacy teams should measure

TL;DR: Page-count benchmarks hide the real problem in cookie and tracker scanning: coverage, not volume, determines whether privacy teams can see changing cookies, long-tail trackers, and third-party hops, according to Ketch. Random sampling and in-page snippets create blind spots that cohort-based scanning is designed to reduce.

Editorial analysis by NHI Mgmt Group, based on content published by Ketch: “Why cookie scanning is broken (and how Iris fixes it)”.

Key questions

Q: What breaks when cookie scanning relies on page count instead of coverage?

A: Page-count scanning breaks when teams assume volume equals visibility.

Q: Why does in-page monitoring miss some third-party cookies?

A: Because code running inside the page can only observe what the browser exposes in that page context.

Q: How do privacy teams know if scanner coverage is good enough?

A: They should look for coverage across structurally distinct cohorts, not just a high URL count.

Practitioner guidance

• Define tracker coverage as the primary KPI Replace page-count reporting with a coverage metric tied to distinct tracker signatures, site cohorts, and observable cookie sets.
• Map the site into operational cohorts Group URLs by template, platform, geography, and visitor state so that scanning samples represent structurally different tracker footprints.
• Test scanner visibility against known third-party flows Use checkout paths, campaign pages, and embedded vendor redirects to check whether the scanner sees downstream cookies and hop distance correctly.

Bottom line: Page-count metrics can hide serious discovery gaps when tracker behaviour varies by template, user state, and vendor chain.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →