The CMPStack API

What we send an AI provider

Tracker classification may consult an AI provider for trackers our pattern engine cannot name. What it is sent is site-level evidence only: the cookie or storage KEY, the host it is set on, the hosts the page made requests to, script URLs with the query string and fragment removed, and a policy page observed on the site. It is never sent cookie VALUES, and never anything belonging to a visitor — no identifiers, no IP addresses, no page content. The boundary is a schema in the code rather than a rule: an evidence bundle carrying any other field is rejected, and the tracker is recorded as unknown instead. The provider and its processing region are deployment configuration; a deployment may run with no provider at all, in which case classification is pattern-only.

A provider is also asked to EXPLAIN a consent-enforcement finding in plain words. It is sent the finding type, the vendor name, and the page URL reduced to scheme, host and path — never a query string, which is where an identifier would be — together with the list of integrations this deployment can advise about. What comes back is stored separately from the finding, labelled as generated wherever it is shown, and kept out of the PDF report until an operator has read it. No finding, count or verdict is ever produced by a model.

What is shared between customers

A classified tracker is cached platform-wide, so the same tracker on two customers' sites is classified once. The cache key is a hash of the tracker's name, the hosts it talks to and whether it is first or third party — deliberately NOT the cookie's scope, which for a first-party cookie is the customer's own hostname. Nothing identifying a workspace is in the key or the row, which is precisely why two customers with the same tracker produce the same entry. A workspace may switch off contributing to it (Workspace → Shared tracker knowledge) and goes on reading it either way.