Consent and privacy

Trace observes tracking and consent signals. Your cookie banner, such as SiteOS Cookie, and website integrations still determine what the visitor permits and which tags run.

Choose a consent source

In Settings → Collection → Consent source, choose SiteOS Cookie banner, OneTrust, Cookiebot, Usercentrics, IAB TCF v2.2 (Didomi, Quantcast, Sourcepoint…), iubenda, Google Consent Mode, Explicit CMP / evidence adapter or No consent observation, then save and publish. Independent CMP state remains separate from Google Consent Mode commands.

The iubenda source reads iubenda’s public Measurement and Marketing permissions, with no account connection or API key, and needs observer 0.10 or later. Lifecycle checks need the iubenda callbacks observed on the same page; if Trace starts after iubenda, it sees only the current permissions.

The OneTrust, Cookiebot and IAB TCF v2.2 sources need observer 0.14 or later and no account connection or API key. They read each CMP's public permission state: OneTrust's default groups C0002 (Performance) for analytics and C0004 (Targeting) for advertising, Cookiebot's statistics and marketing consent, and TCF purposes 1 and 8 for analytics and 1, 3 and 4 for advertising. TCF covers Didomi, Quantcast, Sourcepoint and other TCF CMPs. Renamed OneTrust groups read as denied. Trace never reads TC strings, consent IDs, cookies or storage, and never changes a visitor's choice.

The Usercentrics source needs observer 0.18 or later. Because Usercentrics categories are set up per account, you list what each purpose follows, one per line: a service template ID such as 87JYasXPF (Google Analytics 4) or a service name, or a category key such as marketing or a category name such as Analytics. A purpose is allowed when every listed entry is allowed, refused when any is refused, and unknown otherwise. The defaults are the Google Analytics 4 service for analytics and the Marketing category for advertising. It reads Usercentrics Web CMP v3 and never its controller ID or consent hash.

The explicit adapter, for another CMP’s public API, supplies readiness, analytics and advertising state, the origin of the choice, advertising opt-out and Google Consent Mode status. Implement it through the Trace skill using the actual CMP contract. A custom adapter is not an automatic integration with every banner provider.

Trace can compare supported requests or selected SDK loads with the observed purpose, inspect behavior after a grant and evaluate an expected event after consent readiness. With service discovery, activity from an analytics or marketing service while that purpose was denied, or after a withdrawal on the same page, is flagged for review using the service's registry category. A reply a service sends within 250 ms of the withdrawal, such as its answer to the banner’s stop call, is not flagged. Google Advanced Consent Mode can intentionally send cookieless signals under denial; an uncertain or advanced-mode signal requires review, not an automatic legal conclusion.

See consent on the service map

With the SiteOS Cookie banner, Services shows Cookie scan and Cookie banner columns, and Real traffic marks a service Before consent when it has an open consent finding.

With another consent source, such as OneTrust, Cookiebot, Usercentrics, IAB TCF, iubenda or an explicit CMP adapter, the Cookie columns and actions are hidden. One consent column, such as Consent · iubenda, shows each service as Waits for consent, Runs without consent, No issue found or Not checked (no analytics or marketing purpose), and the Without consent filter lists the services that run without consent. Google Consent Mode without SiteOS Cookie in the Project also gets this column. Without any consent source, the map asks you to choose one in Settings → Collection.

Review banner decisions

Consent shows Banner decisions: of sampled pages where the banner was shown without a stored choice, the shares Accepted, Rejected, Custom and No decision on the page, the Median time to decide and the share Decided after 30 s. It counts sampled page views, not people, and a page without a decision may simply have been left.

Decisions are available for the SiteOS Cookie banner, OneTrust, Cookiebot, Usercentrics, IAB TCF, iubenda and explicit CMP adapters; iubenda pages count from observer 0.14. Google Consent Mode does not report when the banner is shown or what the visitor chose, and collection that starts after consent never observes refusals, so decisions are unavailable there. With SiteOS Cookie, Exact counts in Cookie Analytics leads to unsampled numbers.

For a concrete first-visit, reject, accept and withdrawal sequence, follow the Cookie verification walkthrough. It starts with one configured optional service and pairs each choice with the browser evidence to inspect. Use Trace as an additional observation source when available; Cookie verification can also run independently.

Strict collection

New installations use strict mode. It limits exported evidence to built-in event/property vocabulary plus names explicitly approved in your published configuration. Unknown names are omitted, and property values are not stored.

Routes are omitted unless they match an approved template. For example, /users/:id is recorded as that template, not a person’s identifier. Keep personal information out of approved names, static path segments, runtime labels and adapter identifiers.

In Settings → Collection, review the mode, allowed names, route templates, sampling, excluded services and campaign tagging. Save a draft, then publish it to apply the change. Allowing an event to be observed does not automatically make it required.

Extended and older installations

Extended mode allows broader syntactically valid event and property names with heuristic route masking. Those names can contain identifying text; choose this deliberately. Older configurations can retain legacy behavior. Loading an existing installation does not silently migrate its policy.

Check the installed runtime as well as the saved configuration. Strict collection and the newer service catalog require a compatible observer. Use the installation’s returned snippet for an upgrade.

What is retained

See Visitor data for everything the observer reads and sends, where it goes and how long it is kept. In short: normalized browser evidence does not include raw event payloads, property values, cookie/storage values, page content or persistent visitor identifiers. For third-party services, Trace keeps only the recognized service and its registrable domain, such as widget-cdn.io; the hostname sent by the observer is replaced before storage, in strict and extended mode alike, and subdomains, paths and queries are never kept. Random page and operation identifiers are temporary. Browser evidence and imported Google configuration are different datasets; configuration strings can contain private technical information.

Raw observations are deleted after seven days. Aggregates, findings, configuration history and operational records have separate retention periods. This does not mean every related record disappears after seven days.

Cookie-free operation does not by itself establish anonymity or remove consent obligations. Requests still pass through network infrastructure. Review your deployment, applicable policy and processing terms for the intended installation.

If Trace itself requires consent

Set Settings → Collection → Start collecting to After analytics consent and publish. With observer 0.9 or later, Trace then keeps and sends nothing until the selected consent source grants analytics, starts on the grant and stops on withdrawal, clearing pending observations. It needs a consent source other than No consent observation; an older snippet stops collecting instead of starting early. Alternatively, your CMP can start the snippet itself after the required permission and stop its controller on withdrawal.

With the SiteOS Cookie banner as the source, Settings → Collection → Consent banner → Add to banner lists SiteOS Trace under Analytics in that banner, so visitors see it among the services their choice covers. You can also turn on Personal data checks in any collection mode: Trace keeps working without cookies, and only while a visitor allows analytics does the browser also report where an email address or phone number reaches a service, never the value. Ecommerce value checks work the same way: while analytics is allowed, the browser checks ecommerce events such as purchase for a three-letter currency with every value, a value of zero or more, a resolved transaction ID and items, and reports only the kind of problem. Personal data checks need observer 0.17 and ecommerce value checks 0.18.

Either way, gating removes the pre-consent evidence Trace could otherwise observe, so it cannot show what loads before a choice or after rejection. Document that limit when interpreting missing signals. Never grant consent, replay business events or weaken a visitor’s choice just to produce a passing check.