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.
At a glance
What this is: Ketch argues that tracker coverage, not page count, is the meaningful measure for cookie scanning because scanning methods that rely on random samples or page-embedded snippets miss important trackers.
Why it matters: Privacy and identity practitioners need coverage-based scanning because incomplete tracker discovery undermines disclosure accuracy, consent governance, and evidence about third-party data flows.
Context
Cookie and tracker scanning is a governance problem as much as a discovery problem. If a scanning method cannot reliably observe which cookies, storage writes, and network calls are tied to a site segment, the resulting inventory will drift and disclosure decisions will rest on incomplete evidence. For privacy teams, that means the control objective is completeness of observation, not raw crawl volume.
The article also surfaces an identity-adjacent issue: trackers often involve third-party domains, redirect chains, and data flows that are hard to see from inside the page itself. That makes the boundary between website telemetry and external identity or consent dependencies especially important for large digital properties, where site structure and vendor chaining shape what can actually be discovered.
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. Large sites are structured into cohorts, templates, and vendor-specific flows, so random or shallow sampling can miss the trackers that matter most. The result is unstable inventories, false confidence, and disclosures that do not match the actual data flows on the site.
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. It may detect that another vendor was contacted, but it cannot reliably inspect cookies set under a different domain. That makes it useful for partial telemetry, not for complete disclosure or inventory governance.
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. Good coverage means the scanner can explain what changed, what stayed stable, and which page groups represent the site’s real tracker diversity. If every run looks different without a structural reason, the sampling model is too weak.
Q: Should organisations prioritise random sampling or cohort-based scanning?
A: Cohort-based scanning is the better default when the site has multiple templates, vendor chains, or regional experiences. Random sampling can be economical, but it is weak at finding rare trackers that cluster at structural seams. The decision should hinge on whether the site’s tracker footprint is uniform enough for sampling to be trustworthy.
Technical breakdown
Why page count is a weak proxy for tracker coverage
A scanner can only find what its sampling strategy exposes. Loading more pages increases effort, but it does not guarantee better visibility into the tracker estate because trackers cluster by site segment, user state, and vendor chain. Two URLs that look similar may produce different tracker signatures, while one representative page can reveal the same stack across many templated pages. Coverage is therefore a discovery problem, not a page-volume problem. The right control question is whether the scanning method samples the structural diversity of the site, not how many URLs it touched.
Practical implication: Measure scanning success by tracker coverage across site cohorts, not by total pages crawled.
How headless browser scanning actually surfaces cookies and storage
A proper scan uses a headless browser to load a page, execute scripts, simulate interaction, and record observable activity such as cookies, local storage, session storage, and network requests. That matters because many trackers only appear after scrolling, clicking, or progressing through a flow. The scanner is reconstructing behaviour, not just fetching HTML. This is what makes scanner design expensive: each page requires time, interaction, and observation before it can be considered examined. In governance terms, the scan is a measurement instrument, and its method determines the quality of the evidence it produces.
Practical implication: Validate that your scanner observes runtime behaviour, not just static page content, before trusting its inventory.
Why in-page monitoring cannot see every third-party cookie
A script running inside the site can observe only what the browser makes visible to that page context. It cannot directly inspect cookies set under another company’s domain, even when that company’s tag is present on the page. That means in-page monitoring may confirm that a request occurred, but not what downstream cookies were set or how third-party redirects evolved. For privacy governance, that is a hard boundary, not a tuning issue. If the disclosure obligation depends on third-party-domain cookies, the monitoring model must sit outside the page context.
Practical implication: Treat page-embedded snippets as partial telemetry and pair them with external scanning if third-party cookies matter to disclosure.
Threat narrative
Attacker objective: The underlying risk is not a human attacker but an uncontrolled visibility gap that prevents accurate tracker discovery and disclosure.
- Entry occurs when a site visitor loads a page and a headless browser or page-embedded monitor begins observing runtime behaviour.
- Credential or tracker access emerges as scripts, redirects, and ad-tech exchanges set cookies and storage entries across multiple domains.
- Escalation happens when random sampling or in-page visibility misses the tracker chain, leaving the inventory incomplete and unstable across scans.
- Impact is inaccurate disclosure and weak privacy governance because the organisation cannot reliably see the trackers that actually operate on the site.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Coverage is the control objective, not crawl volume: page scanning in privacy programmes fails when teams confuse effort with evidence. A site can be heavily scanned and still remain poorly understood if the sampling model ignores site cohorts, visitor states, and vendor chains. Practitioners should treat coverage as the measurable outcome and page count as an input cost, not the reverse.
Tracker discovery is a site-structure problem, not a random-event problem: long-tail trackers concentrate at seams between templates, platforms, and regional experiences. That means the governance model must account for structural diversity, especially on large properties with commerce flows, support portals, and campaign-specific experiences. Privacy teams should expect materially different tracker signatures across cohorts, even when URLs look similar.
On-page monitoring creates a verification gap for third-party-domain activity: if the monitoring logic runs inside the page, it cannot fully observe cookies controlled by another domain. This is an identity and consent boundary issue as much as a privacy issue, because the site operator may be unable to prove what downstream parties actually set. Teams should assume inside-the-page telemetry is incomplete by design.
Cohort-based sampling is the more defensible governance model: grouping pages by tracker signature lets teams reason about coverage in a way that scales with site complexity. The named concept here is tracker coverage debt, the accumulated gap between what the site actually runs and what the scanning method can prove. Reducing that debt matters more than increasing scan frequency.
Privacy tooling should be evaluated on observability fidelity, not marketing metrics: if a vendor cannot explain how it classifies direct trackers, downstream hops, and separate domain cookies, practitioners should assume its completeness claims are not yet decision-grade. The practical test is whether the tool can support disclosure, not whether it can produce a large crawl count.
What this signals
Tracker coverage debt: the real risk in privacy scanning is the growing gap between what a site actually runs and what the scanning method can prove. As properties add commerce paths, campaign variants, and vendor chains, the discovery model has to change or the inventory becomes incomplete by design.
For practitioners, the question is no longer whether a tool can scan many pages. It is whether it can explain the structural cohorts it used, the tracker signatures it observed, and the third-party-domain activity it could not directly inspect.
For practitioners
- 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.
- Treat in-page snippets as partial monitoring Do not rely on page-embedded scripts alone for disclosure decisions when third-party-domain cookies or redirect chains are in scope.
- Review scan economics against decision value Set crawl budgets by the number of cohorts and disclosures that must be evidenced, then confirm the method still fits the privacy operating model.
Key takeaways
- Page-count metrics can hide serious discovery gaps when tracker behaviour varies by template, user state, and vendor chain.
- In-page monitoring is useful, but it cannot fully replace external observation when third-party-domain cookies matter to disclosure.
- Coverage-based sampling gives privacy teams a more defensible way to prove what is actually running on a large site.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical Devices and Systems | Site assets and tracker footprint need accurate inventory and visibility. |
| PR.DS-01 — Data-at-Rest | Cookies and storage writes are part of observable data handling on the site. | |
| Recommendation — Inventory site cohorts and tracker signatures to improve asset visibility and discovery. Map cookie and storage observations to data handling controls before relying on disclosure reports. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's governance problem is incomplete visibility into externally controlled tracking paths. |
| Recommendation — Review third-party tracking paths as managed dependencies, not just as page activity. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes observable chains of requests and downstream data movement, not adversary tradecraft. |
| Recommendation — Trace downstream requests and data movement to distinguish direct trackers from chained dependencies. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The core failure is incomplete inventory of trackers and vendor hops across a large site. |
| Recommendation — Treat tracker discovery as inventory management and validate that sampling covers every cohort. | ||
Key terms
- Tracker Coverage: The proportion of trackers on a site that a scanning method can actually detect and classify. It is a measurement of discovery quality, not crawl volume. Coverage is what matters when site structure, vendor chains, and visitor state determine which cookies and requests appear during observation.
- Cohort-Based Scanning: A scanning approach that groups pages by shared tracker signatures rather than treating each URL as an independent target. This improves efficiency on large sites because structurally similar pages usually expose similar tracker behaviour, allowing the scanner to sample representative pages instead of everything.
- Cookie syncing: The practice of copying browser session state from a human user into an agent-controlled browser so the agent inherits an already authenticated context. It is convenient for automation, but it collapses identity boundaries and makes the machine indistinguishable from the person whose cookies were copied.
- Third-Party Cookie: A third-party cookie is a cookie set by a domain other than the one a person is visiting. That third party can read the same cookie again on other sites that embed its content, which makes it useful for tracking across multiple domains. It is a core mechanism of cross-site profiling.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and related control patterns. It helps security and privacy practitioners connect identity governance to the operational risks their programmes actually face.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org