The consent log and export
Every time a visitor decides on the banner, one record is stored: what they accepted, under which mode, against which version of the banner, and when. That record is what you point at when someone asks, and it exports to CSV or JSON from the same page.
The consent record is the proof#
If someone asks you what a given user consented to in March, the answer has to be a row of data, not a screenshot of today's settings. That is what a consent record is: one row per decision, in Cookie consent under the Consent log tab.
Each record keeps:
| What | For |
|---|---|
| Timestamp and consent ID | when, and which decision |
| Action | first consent, update or withdraw |
| Accepted and rejected categories | the decision itself, from both sides |
| Mode | which default was in force at that moment — opt-in or opt-out |
| Revision and configuration fingerprint | proof of which version of the banner they saw |
| Locale | the copy that was shown to them |
| Anonymous ID | ties the record to that browser's behaviour |
| Hashed IP address and user agent | technical context, without keeping the address itself |
The configuration fingerprint is the most important column in that table and the most underrated: your banner changes several times a year, and without it there is no way to show which text a visitor was actually shown.
When a record is created#
Only when a visitor actually decides — Accept all, Reject all, or saving their own choices in the preferences panel. Seeing the banner without choosing creates nothing.
The action is inferred from the decision itself:
- First consent — there was no earlier choice on this browser.
- Withdraw — the end state is Necessary only, meaning everything non-essential was rejected.
- Update — an earlier choice existed and the new one is something other than Necessary-only.
Each decision gets a fresh consent ID, so a visitor's history stays as a series of records and an earlier record is never overwritten. A revision bump shows up the same way: a wave of new records carrying the higher revision.
If the browser sends the same request again — weak network, a retry — no duplicate row is created; the second write is a no-op. And if the write fails outright, nothing is returned into your page: the visitor's choice was written in their own browser and is valid from that moment.
The IP is never stored raw#
The visitor's IP address is hashed before storage and only the hash is kept. You can show that two records came from the same address, but you cannot get back to the address itself. That is deliberate: the record should be enough to prove consent, and no more.
The user agent and the anonymous ID are stored but have no column in the on-screen table and are not in the export. The page's search box does accept an anonymous ID, so if you have a visitor's id you can find their records.
The Consent log tab#
The second tab has three parts, and all three follow the date range at the top of the page.
Four KPIs. These count records, not visits — which is exactly what to keep in mind while reading them:
| KPI | What it actually counts |
|---|---|
| Consent prompts | records stored in the selected range. A visitor who saw the banner and did nothing is not here. |
| Accept-all rate | the share of records in which Marketing was accepted |
| Reject non-essential | the share of records in which only Necessary was accepted |
| Records stored | every record this property has, all time, regardless of the range |
Four charts. Consent actions over time stacks the three action types day by day — a wave of withdrawals after a change shows up here. Category opt-in rate shows how often each category is accepted; the gap between Statistics and Marketing is effectively what decides how complete your attribution can be. Consent mode and Top locales give you the make-up of the records.
The record list. Its columns are Timestamp, Action, Accepted categories, Mode, Rev, Locale and Consent ID. Three filters sit above it — All actions, All modes and a search box for a consent ID or an anonymous ID — and the list pages 25 at a time. Paging is done by cursor rather than page number, so on a property with millions of records the last page is as fast as the first. The trade-off is that you cannot jump to an arbitrary page; there is only previous and next.
The CSV and JSON export#
At the bottom of the same card are two buttons: Export CSV and Export JSON. Both return the same set of rows and differ only in format.
The CSV columns are exactly these nine, in this order:
| Column | Value |
|---|---|
consent_id |
the consent ID |
consent_at |
the time of the decision, RFC3339 |
action |
first_consent, update or withdraw |
accepted |
accepted categories, space-separated |
rejected |
rejected categories, space-separated |
mode |
opt_in or opt_out |
revision |
the revision at the moment of the decision |
config_version |
the fingerprint of the configuration the visitor saw |
locale |
the banner's language |
Three things to know before you rely on that file:
- The export ignores the date range and the page filters. It always returns the most recent 50,000 records for the property, newest first. If the property holds more than that, the file is truncated without warning.
- The hashed IP, the user agent and the anonymous ID are not in it. They stay in storage but do not come out through this path.
- The export is per property. For several properties, run it several times.
Records come back newest-first and are capped at 50,000, so on a busy property today's export does not contain last year's records. If long-term retention of the proof matters to you, export on a regular cadence — monthly, say — and file it wherever you keep the rest of your compliance evidence.
Who can see it#
Reading the log and running the export need report-read access to that property, and, like every read, are bounded by your own organization and property. But Cookie consent only appears in the sidebar for an Editor role and above, because the same page carries the banner builder. In practice that means the consent log is seen by the same people who can change the banner.
What this log is not#
A consent record proves a decision. It is not the mechanism that enforces it, and it is not an inventory of a user's data.
- Withdrawing does not delete earlier data. Collection stops at that moment and that category's cookies are cleared; events already recorded stay where they are. Deletion has its own path, in data retention and deletion.
- This log does not tell you what consent a given event was collected under. That is stamped on the event row itself, explained in how consent is enforced in the tracker.
- The list of cookies your site sets lives elsewhere: the Cookie declaration tab, covered in the cookie declaration.
Frequently asked questions#
Is the visitor's IP address stored?
Not in the clear. Only a hash of it is kept, so you can show that a record came from a particular address but you cannot recover the address from the record. That hash is not in the CSV or JSON export either.
Why are there far fewer records than visitors?
Because a record is only created when a visitor actually decides. Someone who sees the banner and leaves without choosing creates nothing. Under opt-in, that same visitor is not counted in the reports either.
Does the export respect the selected date range?
No. The list and the charts on the page follow the range above, but the export always returns the most recent 50,000 records for that property, regardless of the range or the page's filters.
A visitor withdrew consent. Is their earlier data deleted?
No. Withdrawing stops collection from that moment and clears that category's cookies, but it does not remove what was already recorded. Deleting data is a separate path.
Thanks — your feedback helps us improve the docs.