> For the complete documentation index, see [llms.txt](https://docs.crobox.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.crobox.com/getting-started/first-steps/cookie-wall-settings.md).
# Cookie Wall Settings
This document explains how to implement Crobox according to your cookie policy.
## Storage Types & Purpose
#### First Party Cookie
The cookie \_crbx is a **first party cookie**, and will not be used outside of our client’s domain.
If your cookie policy requires explicit consent (the setting “Opt-in needed to persist visitor data” is turned on), **Crobox sets no cookies at all before that consent is given**. Visitors will be able to see and use the Crobox functionality, but will not be included in analytics data, will always be shown the default variant of any AB test, and no data will be persisted in connection to that session.
Once consent is given by the visitor, or if it is not needed according to our client's cookie policy, the \_crbx cookie is set as a “*persistent*” cookie, which will expire after the set time by our client (default 180 days). It is then used for *aggregated* analytics & AB testing and to remember a given consent. It is in no way used for tracking or marketing purposes. The cookie keeps a returning visitor in the same AB test variant across visits, but it is not used to pre-fill or personalise content: information the visitor gave, such as product finder answers, is kept in temporary local storage only (see below) and is not restored once that has expired.
If a visitor revokes consent, the \_crbx cookie is removed. Where explicit consent is not required, the cookie is instead reduced to a marker that records the opt-out itself, so that the choice survives into the visitor’s next visit; it no longer holds a profile identifier.
#### Temporary Local Storage
Crobox makes use of *necessary*, non-persistent local storage. Local storage is used rather than per-tab session storage so that the experience stays consistent when the visitor uses multiple browser tabs, but it is treated as *temporary*: it is reset and removed after 30 minutes of inactivity (configurable by our client). It is scoped to a single domain, so this state is not shared between subdomains.
Before consent is given, this storage holds functional state only — such as the answers a visitor gave in a product finder, and messages or campaigns the visitor dismissed — so that the visitor is not asked the same thing twice within a session. No analytics or AB test assignment data is stored before consent. Apart from an explicit opt-out, no data connected to the session is persisted without proper consent.
## Visitor’s Consent - Website Integration Instructions
If your cookie policy requires an explicit consent to store data for analytics (and AB testing), turn on the setting “Opt-in needed to persist visitor data” in your website integration general settings, and make sure that in any case the [Crobox snippet](/getting-started/first-steps/get-started-with-crobox.md) is loaded and [events like pageview](/getting-started/first-steps/event-tracking-implementation.md) are sent on page load or visitor action. Before consent is given these events still drive the functionality on the page, but they are not sent to Crobox, they are not queued, and they cannot be counted retroactively. Only events sent after the consent has been given are persisted (anonymously) for analytics purposes — so be sure to send a pageview at the moment consent is given, and not only on the next page load.
Call the Opt-in Javascript event, described below, for visitors that have given the consent.
#### Opt-in: set \_crbx Cookie on Explicit Consent
Needed if according to your cookie policy you require explicit consent for analytics or AB testing. When the user gives the consent on your platform, call the Opt-in Javascript event as followed:
```
const crobox = window.crobox || [];
crobox.push(crobox => crobox.optIn());
```
{% hint style="info" %}
Ideally this Opt-in event is called in a routine that looks at the consent state of your visitor, and not directly on a button click event in your cookie banner. This is because your cookie banner might not be shown anymore to returning visitors for a longer period than the Crobox persistence time, for example because of stricter expiration rules that are enforced by browsers like Safari.
{% endhint %}
{% hint style="info" %}
It is only needed to call this method once (for example when visitors are accepting cookies, or denying them), so there is no need to call them every time the page loads.
{% endhint %}
#### Opt-out: Revoke Explicit Consent
To opt-out for a previously given consent, call the Opt-out Javascript event as followed:
```
const crobox = window.crobox || [];
crobox.push(crobox => crobox.optOut());
```
#### Loading the Crobox snippet after consent in the cookie banner
It is advised to load the [Crobox snippet](/getting-started/first-steps/get-started-with-crobox.md) and send [events like pageview](/getting-started/first-steps/event-tracking-implementation.md) in any case (see above). Otherwise, functionally for which no consent is needed cannot be shown to the visitor’s first, and most important, the landing page. In case the Crobox snippet can only be loaded after a consent in the cookie banner, be sure that the snippet is loaded and the [pageview event](/getting-started/first-steps/event-tracking-implementation.md) for that page is called on consent action (f.e. In the cookie banner), and not on the next page load. Otherwise the visitor that gave the consent will be missed out on these important landing pages, both functionally and in analytics data.
## No Explicit Consent Needed for Analytics Cookies
If you do not require an explicit consent for analytics cookies, turn off “Opt-in needed to persist visitor data” in your website integration general settings, and make sure the [Crobox snippet](/getting-started/first-steps/get-started-with-crobox.md) is loaded in any case. The cookie will now be default set without further implementation requirements.
## FAQs
Why don't my experiences show up right after users accept cookies?
Because giving consent does not by itself replay the current page. Crobox evaluates which experiences to show off the pageview event, and while the visitor is still opted out no events are sent to Crobox and none are queued — so a pageview that was already sent before consent cannot be counted, and no AB test variants are assigned for it.
Call `optIn()` first and then send the pageview for the current page, in that order. A pageview sent before `optIn()` is still treated as opted out:
```javascript
window.crobox = window.crobox || [];
crobox.push(function(crobox) {
crobox.optIn();
crobox.pageview({
pt: crobox.PAGE_INDEX,
lc: "en-GB"
});
});
```
Send the same pageview data you would normally send for that page — see [Event Tracking Implementation](/getting-started/first-steps/event-tracking-implementation.md). This applies whether the snippet was loaded on page load or only after the cookie banner: in both cases the visitor is otherwise missing from analytics for the landing page, and keeps seeing the default variant of any AB test until the next pageview.
How can I verify my cookie consent setup is working properly?
Look at the `_crbx` cookie under Application → Cookies, rather than at the Network tab: Crobox sends requests for the functionality that needs no consent, so the presence of "crobox" requests tells you nothing about the consent state.
Before consent there should be no `_crbx` cookie at all. After the visitor accepts, it should appear immediately — no page refresh needed — holding a 22-character profile id. If it only shows up after a refresh, `optIn()` is not being called at the moment consent is given.
A value ending in `|dnp` means the visitor is recorded as opted out, and carries no profile id. That is what you should see after `optOut()` in a container where explicit consent is not required; where it is required, opting out removes the cookie instead. Seeing either of those after an accept means the opt-in routine is reading the wrong consent state.
## Next step
If your website enforces a Content Security Policy, continue with [Content Security Policy Header](/getting-started/first-steps/content-security-policy-header.md).
That shows which Crobox domains and directives to allow.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.crobox.com/getting-started/first-steps/cookie-wall-settings.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.