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.

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:

{
  "id": "c_01J...",
  "choices": {
    "necessary": true,
    "analytics": false,
    "marketing": false,
    "preferences": false
  },
  "timestamp": 1783000000000,
  "configVersion": "rev_2026_07_05_abc"
}

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:

{
  "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
}

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.
2. 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.
3. Manual reset — the visitor reopens the preferences dialog and resets consent, or the local cookie is cleared by the browser.

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.

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.