Reporting
Consent analytics that actually help teams make decisions
Consent numbers earn their keep when they answer questions: what visitors chose, under which banner version, in which region, and what moved after a change.
Reporting 3 min read The UserGuard team
- A consent number earns its keep only if it leads to a decision — rewrite the copy, review a vendor, rescan the site — and total banner views lead to none.
- UserGuard logs consent as append-only per-event records carrying site, banner version, region, language, any GPC signal, per-category choices, hashed identifiers and a timestamp.
- Every event stamps the immutable banner version that produced it, and an unexplained acceptance jump after a redesign usually means rejecting got harder to find.
Start from questions, not charts
Consent reporting is worth your time when it answers questions you would actually act on. Which categories do visitors reject, and how often? Did last month's copy change move anything? When the scanner found a new marketing cookie, did the consent picture change with it? Total banner views answer none of these.
The test for any consent report, ours included, is whether a number leads to a decision: rewrite the copy, review a vendor, rescan the site, or check whether a script is firing before it should.
Per-event records make the answers possible
Aggregates cannot answer those questions on their own, so UserGuard records consent as individual events. Each one carries the site, the banner version, the region, the language, any Global Privacy Control signal, the per-category choices, hashed visitor and IP identifiers, and a timestamp. The log is append-only; nobody can tidy it up after the fact.
Every useful breakdown is a slice of those fields: rejection rate by category, choices by region, behavior before and after a banner change. The same records double as evidence when someone asks what one visitor chose on one afternoon, which is the question enforcement actually asks.
Version stamps keep your trends honest
Banner publishes in UserGuard are versioned and immutable, and every consent event records the version that produced it. That turns before-and-after questions into queries instead of guesswork: you can put a shift in choices next to the exact banner that caused it, and say which design a given visitor actually saw.
One warning from the enforcement record: when acceptance jumps after a redesign and nobody can explain why, the usual mechanism is that rejecting got harder to find. That is the pattern equal-prominence expectations exist to catch, and it is far better discovered in your own version comparison than in a regulator's.
The numbers have to leave the building
Records you can only view inside a tool are not records you control. UserGuard exports the consent log as CSV, so a lawyer, an auditor, a client, or a spreadsheet can work with it directly. Retention defaults to 400 days and is adjustable up to three years to match your own policy.
If you report to clients, the same export is your raw material: how many visitors accepted optional categories, what was rejected where, and what changed after the work you billed for. Numbers a non-technical client can read beat a screenshot of a dashboard.
A monthly habit worth keeping
Once a month, export the log and ask three questions. Did rejection rates move, and does the banner version history explain it? Did the latest scan add anything the banner and policy now need to cover? Is anything in the numbers surprising enough that you cannot explain it in a sentence?
If a number moved and you do not know why, find out before someone outside your company does. That is the whole discipline, and it takes about fifteen minutes.
Go deeper: consent analytics in UserGuard