The consent log, receipts, and export
Every banner decision becomes a record you can inspect and export. Here's what each record contains, why we chose those fields, and how long records are kept.
Why the log exists
Under GDPR Article 7(1), the burden of demonstrating consent sits with you. If someone asks whether a visitor consented, when, and to what, you need a record of the specific decision, and "our banner was live that month" won't answer the question.
UserGuard writes that record automatically. Every decision a visitor makes in the banner, on any site and in any region, goes into the consent log. You don't have to configure logging or turn it on. If the banner ran, the record exists.
What does each record contain?
A consent record is only useful if it can stand on its own later, so each one includes:
- The site the decision belongs to.
- The exact banner version that was on screen.
- The region the configuration resolved and the language actually rendered.
- Whether a Global Privacy Control signal was present.
- The per-category choice the visitor made.
- A salted visitor hash, which links that visitor's own decisions but isn't re-identifiable as a person.
- A truncated-then-hashed IP.
- The page URL and a UTC timestamp.
The visitor hash lets you show a coherent history (this visitor accepted in March and withdrew in June) without storing anything that identifies who the visitor is. The IP is truncated before it's hashed for the same reason. That leaves enough to support the record, but not enough to work out who the person is.
Why does the banner version matter?
Because a record that says "accepted" proves little if you can't show what the visitor accepted. Published banner configurations in UserGuard are immutable. Once a version is live, it never changes. Each consent record points at the exact version that was on screen, and the two together prove what was shown (the wording, the categories, the choices offered) at the moment of the decision. If you edit the banner later, old records still point at the old version.
What counts as a decision
Not every recorded action is a click on Accept all. The log records each of these distinctly:
- Accepted all
- Rejected optional
- Saved preferences
- Withdrew
- Honored GPC
- Dismissed
- Opted out of sale
- Withdrew the opt-out
The log keeps these apart because they mean different things. A withdrawal ends consent that previously existed, which makes it different from a rejection. A GPC signal is honored without any click at all, and the record says so. If these all went into one "opted out" bucket, you'd lose the detail a regulator would ask about.
Reading the Consent tab
The site's Consent tab shows two views of the same data, and one filter row at the top controls both. You can narrow the slice by range (7, 30, or 90 days, all time, or a custom date range), by choice, and by region. The aggregates and the receipts read the same filters, so they always cover the same slice. The aggregates come first, with accept and reject rates, daily volume, and breakdowns by choice and by region. Below them is Receipts, the whole filtered record as a paginated ledger, 25 to a page, newest first. The page number is in the URL along with the rest of the slice, so you can link to a filtered page. Open a row and you'll see the full record of that decision: banner version, region, language, signal, per-category choice, visitor hash, page, and time.
Exporting the log
The CSV export gives you the slice as it stands on screen. The same range, choice, and region filters that apply to the page apply to the file. If you leave the filters alone you export the full window, and if you narrow them the file narrows too. Each row has a language column and a region column, because both change the meaning of a record. Consent gathered from a banner rendered in Spanish under a GDPR-region configuration is a different fact from the same click by a US visitor, who gets the consent model you set. The export keeps that context on every row, so the file stands alone when you hand it to counsel or a client.
Retention
We don't keep records forever. You can configure retention per account. The default is 400 days, with choices of roughly 13, 24, or 36 months, and records older than the window are pruned nightly. Keeping consent records indefinitely is a compliance problem of its own, since the log is there to demonstrate consent and shouldn't turn into a permanent archive of visitor behavior. Pick the window that matches your obligations, and if you need a longer paper trail, export before the window closes.