Browser Storage & Consent
Exactly what the Octocom chat widget stores in a visitor's browser, when it stores it, and how to classify it for cookie-consent purposes.
This page documents everything the chat widget stores on a visitor's device, so your legal or compliance team can classify it for your cookie banner and privacy documentation.
The short version: the widget sets no cookies, stores nothing until the visitor opens the chat, and everything it then stores is functional — session continuity and UI state. No advertising, no cross-site tracking, no fingerprinting.
Nothing happens on page load
When a page with the widget loads, the visitor sees the chat bubble — and that's all. Before the visitor opens the chat:
- No cookies are set (the widget never sets cookies at all).
- Nothing is written to
localStorageorsessionStorage. - No visitor session is created on our servers.
Storage and session creation happen only when the visitor opens the chat — that is, when they actively request the service. Under the EU ePrivacy rules this is the fact pattern that matters: storage that is strictly necessary to deliver a service the user has explicitly requested is exempt from the consent requirement, in the same way a shopping-cart cookie is.
What is stored once the visitor opens the chat
All keys are first-party localStorage, namespaced under octocom:
| Key | Purpose | Written when | Lifetime |
|---|---|---|---|
octocom-browser-session-id:<id> | Random session reference that keeps the visitor's conversation continuous across pages and visits | Visitor opens the chat | Expires after 180 days of inactivity, then removed |
octocom-chat-window-open:<id> | Whether the chat window is open, so it stays open across page navigation | Visitor opens or closes the chat | Until changed |
octocom-last-interaction-at:<id> | Timestamp of the visitor's last interaction, used to avoid re-showing prompts they've already seen or dismissed | Visitor opens the chat or dismisses a prompt | Until changed |
octocom-exit-intent-cooldown | Short cooldown after the visitor dismisses an exit-intent prompt, so it isn't shown again immediately | Visitor dismisses the prompt | Minutes |
octocom:data:<key> | Optional custom data your own site chooses to pass into conversations | Visitor opens the chat (for URL-passed values) | Until removed |
Notes:
- The session reference is a random identifier. It contains no personal data and is not usable for tracking across other websites.
- The two prompt-dismissal keys can be written before the chat is opened, but only in direct response to a visitor action (dismissing a prompt) — storing a user's "don't show me this again" preference is itself a recognized exempt category.
- When a session is created, our servers process the visitor's IP address and user agent for abuse prevention and rate limiting.
- Chat events (opened, message sent) can optionally be forwarded to your own Google Analytics via your existing gtag/GTM setup. Those events run under your analytics cookies and your consent banner — the widget brings no analytics of its own.
Do you need cookie consent for the widget?
EU ePrivacy rules are technology-neutral: localStorage is treated the same as cookies. So the question is not "does it set cookies" but "is the storage strictly necessary for a service the user requested."
Because the widget stores nothing until the visitor opens the chat, and what it then stores is required to make the conversation work, the storage falls under the strictly necessary exemption on the standard reading — and this is how the large majority of our merchants' legal teams classify it.
In consent-banner terms, "strictly necessary" is the always-on category: no consent toggle, the widget simply runs, and the visitor is informed through your cookie declaration. Don't confuse it with your banner's Functional category — despite the name, Functional is an opt-in category in most consent tools, so classifying the widget there means it must not run until the visitor ticks that box.
Two honest caveats:
- The classification decision is yours as the data controller, and national implementations of ePrivacy vary in strictness. If your DPO prefers the conservative posture, classify the widget under your banner's Functional (opt-in) category — and then gate its loading behind that consent, using the recipe below.
- If you pass custom data into the widget — especially personal data like emails or user IDs — that is your data flowing under your lawful basis, and it's worth reflecting in your privacy policy.
For your cookie declaration, a one-line entry that covers it:
Octocom chat — first-party localStorage, strictly necessary (functional purpose). Stores a session reference so your support conversation stays continuous. Created only when you open the chat; expires after 180 days of inactivity.
Loading the widget only after consent (optional)
If you decide to gate the widget behind consent anyway, don't add the script tag directly — inject it from your consent tool's callback instead:
<script>
function loadOctocom() {
if (document.getElementById("octocom-widget-script")) return;
var s = document.createElement("script");
s.id = "octocom-widget-script";
s.src = "https://www.octocom.ai/chatbot/bundle.js";
s.async = true;
document.head.appendChild(s);
}
</script>Call loadOctocom() from the "functional consent granted" callback of your consent management platform (OneTrust, Cookiebot, Usercentrics, and similar all provide one).
Keep in mind the trade-off: visitors who ignore or decline the banner will never see the chat bubble, and lose the ability to contact you through it. Since the widget stores nothing until opened, always loading it and classifying the storage as strictly necessary avoids that cost — which is why we recommend the default approach.
Deleting widget data
- Browser side: the session reference expires automatically after 180 days of inactivity. A visitor can also clear it at any time by clearing site data for your domain.
- Server side: conversation data is retained and deleted under your instructions as the controller — see Data Handling & GDPR.