# How visitor consent is stored and re-asked

> How visitor consent is stored locally and synced to the server, when the banner re-asks, and how consent expires.

Author: OptinStack Team  
Published: 2026-06-28  
Page: https://community.optinstack.com/articles/how-visitor-consent-is-stored-and-re-asked  
Markdown: https://community.optinstack.com/llms.md/articles/how-visitor-consent-is-stored-and-re-asked

When a visitor makes a choice, OptinStack records it locally and syncs a copy to the server\. This article explains where consent is stored, when it is re\-asked, and how it expires\.

## Where the record lives

The consent record is stored on the visitor's device and a synced copy is sent to the OptinStack server, where it appears in the Analytics & Logs area and can be exported\. The synced record includes the choices, a timestamp, and the GPC signal if present\.

> **Info:** The gpc field in the synced record reflects whether Global Privacy Control was active when the visitor made the choice. This helps you audit opt-out signals.

## When the banner re\-appears

Once a visitor chooses, the banner stays hidden until consent expires or is reset\. Re\-consent can be triggered by a materially relevant consent revision, an expiry, or a manual reset from the preferences dialog\.

## What's inside the consent record

OptinStack keeps two complementary copies of each choice\. The visitor's browser holds a local first\-party record under the cookie name `optinstack`, and a richer copy designed to support audit workflows is synced to the OptinStack server and surfaced in Analytics & Logs\.

### Local record \(browser cookie\)

The cookie is a small JSON object scoped to your host \(path /, Secure by default\)\. It is host\-only by default, which means it is not shared across subdomains\. On Business and Enterprise projects where share\-across\-subdomains is enabled, the cookie is scoped to the root registrable domain so a single visitor choice can be honored across subdomains\. It stores the visitor's choice and the metadata OptinStack needs to honor it on return visits:


_Local optinstack cookie payload_
```json
{
  "id": "c_01J...",
  "choices": {
    "necessary": true,
    "analytics": false,
    "marketing": false,
    "preferences": false
  },
  "timestamp": 1783000000000,
  "configVersion": "rev_2026_07_05_abc"
}
```

> **Info:** necessary is always true and can never be set to false. analytics, marketing, and preferences reflect the visitor's actual choice and follow the banner mode until the visitor decides.

### Synced server record

When a choice is made, the runtime syncs an expanded record to the OptinStack server\. This is the shape stored for analytics, audit, CSV, and PDF export:


_Synced consent record (Analytics & Logs)_
```json
{
  "id": "c_01J...",
  "action": "submit",
  "mode": "opt-in",
  "analytics": false,
  "marketing": false,
  "preferences": false,
  "timestamp": 1783000000,
  "region": "DE",
  "page_url": "https://example.com/",
  "gpc": false,
  "runtime_version": "2.0.3",
  "expires_at": 1800000000
}
```

> **Tip:** The server record flattens the choices into top-level booleans (analytics, marketing, preferences) and adds audit context: the visitor's region, the page URL, the banner mode, the runtime version, the GPC signal, and the consent expiry. These are the fields that appear in CSV and PDF export.

## When consent is re\-asked automatically

The banner re\-appears on its own when the local record can no longer be trusted\. There are three triggers:

1. Expiry — the consent duration set for the rule \(visible in the wizard's Consent Framework step\) has passed since the stored `timestamp`\. The default varies by preset; review it before going live\.
1. Configuration change — when you republish the banner and the stored `configVersion` no longer matches, OptinStack treats the old choice as stale and re\-asks\. This keeps published changes enforceable\.
1. Manual reset — the visitor reopens the preferences dialog and resets consent, or the local cookie is cleared by the browser\.

> **Info:** Some configurations ask again silently. When re-ask on consent expiry is turned off for a rule, an expired record is refreshed to the banner-mode defaults instead of re-showing the banner, so return visits keep their gating without interrupting the visitor.

### How long does the visitor banner stay hidden after a choice?

Until the rule's consent duration elapses, the banner configuration is republished (a configVersion change), or the visitor resets it. That duration is set per rule in the Consent Framework step and is separate from how long OptinStack keeps server-side audit records (12 months on standard plans).

### Where is the Global Privacy Control signal recorded?

The local cookie does not store GPC. The synced server record carries a top-level gpc boolean that reflects whether Global Privacy Control was active when the visitor made their choice, alongside the region and page URL for audit.

### How does a visitor change or withdraw their consent?

Visitors reopen the preferences dialog from the banner, your site's consent link (which dispatches the runtime's open-preferences event), or a floating reopen button if configured. Inside the dialog they can update individual toggles and save, accept all, or reject all. The new choice is written to the local optinstack cookie and synced to the server immediately. There is no separate 'reset' button — saving any new choice replaces the previous record.

### Can I export consent records?

Yes. From Analytics & Logs you can request an individual PDF proof on every plan or a CSV report on Pro and above. Exports are generated in the background and emailed to you with the consent choices, timestamp, and GPC signal.

## How long records are kept

Consent records collected through your configuration are retained for twelve \(12\) months on standard plans, measured from the date of each consent event\. Retention is rolling: new records continue to be collected, while older records become eligible for automatic deletion after the window\. Enterprise customers may negotiate a different retention period under a separate written agreement\.

> **Info:** Automated purge runs on a rolling schedule (about 12 months, with a short technical buffer). Individual proof PDFs and Consent Forwarding are available on every active Free or paid hostname; CSV consent exports are available on Pro and above.

Editors and system admins can delete individual records from Analytics & Logs\. For broader deletion, contact support with your project ID and the scope to remove\. Export an individual proof PDF or configure Consent Forwarding on any active Free or paid hostname; CSV consent exports remain available on Pro and above\.

### How long are consent records kept for?

Twelve (12) months on standard plans from the date of each consent event. You can delete individual records sooner. Archiving a project stops runtime activity but retains its records; verified project-wide erasure requires a support request. Enterprise customers may negotiate a different window under a custom agreement.

### Are records deleted automatically after 12 months?

Yes. Records outside the retention window are removed automatically and cannot be recovered from OptinStack. Individual proof PDFs and Consent Forwarding are available on every active Free or paid hostname; CSV exports are available on Pro and above.
