> For the complete documentation index, see [llms.txt](https://docs.spara.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.spara.com/developers/installation/iframe-and-cookies.md).

# iFrame & Cookies

How the Spara chat widget loads on your site, what data it stores, and how it interacts with cookie consent policies.

This page explains how the Spara chat widget works from a technical perspective, what data it stores in the browser, and how it relates to your website's cookie consent policies.

## How the Spara widget loads

When you add the Spara JavaScript snippet to your website, it creates an **iframe** (inline frame) that loads the [Chat](https://docs.spara.com/agents/channels/chat) interface. An iframe is a standard web technology that embeds one webpage inside another — similar to how a YouTube video embed works.

The iframe approach means:

* **Spara's code runs in isolation** from your website's code. It cannot access your page's JavaScript variables, DOM, or other data unless explicitly passed through the embed snippet.
* **Your website's code runs in isolation** from Spara. Your scripts cannot access the contents of the Spara iframe.
* **Styling is independent.** Spara's styles do not conflict with your website's CSS, and vice versa.

## What Spara stores in the browser

Spara uses **localStorage** (not cookies) to persist a small amount of data in the visitor's browser. localStorage is a browser storage mechanism that keeps data on the user's device, similar to cookies but with key differences:

* localStorage data is **not sent to servers** with every HTTP request (unlike cookies)
* localStorage is **scoped to your website's domain** — it cannot be read by other websites
* localStorage persists until explicitly cleared by the user or your code

### Data stored

| Key                     | Purpose                                                                                                                                                                                                                                                       |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Prelead UUID**        | A randomly generated identifier that associates a visitor with their conversation across page loads and return visits. This is how Spara remembers that a visitor on your pricing page is the same person who chatted on your homepage.                       |
| **Page visit tracking** | A per-day, per-URL hash that prevents duplicate page visit recording. This ensures each unique page view is counted once per day. Not written for visitors who have declined tracking — see [#cookie-consent-and-spara](#cookie-consent-and-spara "mention"). |

Spara does **not** store:

* Names, email addresses, or other personally identifiable information in localStorage
* Third-party tracking data
* Cross-site identifiers

### Cookies

Spara does **not** set any cookies on your website. The embed snippet reads (but does not write) certain existing cookies on your site for analytics integration purposes:

* **Google Analytics cookies** (`_ga`, `_ga_*`) — If present, Spara reads the GA4 client ID and session ID so that Spara lead activity can be correlated with your Google Analytics data
* **Google Click ID cookies** (`_gcl_aw`, `_gcl_au`) — If present, Spara captures these for ad attribution

These cookies are set by Google Analytics, not by Spara. Spara will ingest the GA4 client ID and session ID automatically and can read the `gcl_au` and `gcl_aw` cookies if they are mapped as query parameters. See [Query Parameters](/developers/installation/query-parameters.md) for more information.

## Cookie consent and Spara

A common question is whether Spara needs to be behind your cookie consent banner. Here are the technical facts:

* **Spara does not set cookies** — it uses localStorage only
* **Spara does generate a pseudonymous identifier** (the prelead UUID) stored in localStorage, which some privacy regulations may classify similarly to cookies
* **Spara does read existing Google Analytics cookies** if present, for attribution purposes

### OneTrust integration

Spara integrates directly with OneTrust. Rather than hiding the chat widget, Spara reads the visitor's category selection and turns off its own background tracking for visitors who have not consented. The chat is treated as required functionality and always loads.

To enable it, go to **Chat Settings → Configuration → Cookie Consent**, set the provider to **OneTrust**, and enter the consent category that should enable tracking — typically `C0002` (Performance/Analytics). Enter the group ID exactly as your OneTrust tenant reports it: most use the prefixed form (`C0002`), but some are configured with bare numbers (`2`), and the two are not interchangeable.

No engineering work is required on your side. Spara reads the OneTrust JavaScript already present on your site, via the `OnetrustActiveGroups` global and the `OneTrustGroupsUpdated` event.

**When the visitor has not consented to that category, Spara does not:**

* record page visits or log the visitor's path around your site
* store the visitor's IP address
* run visitor deanonymization (reverse-IP company lookup)
* forward analytics events to your Google Analytics property
* read Google Ads click cookies (`_gcl_aw`, `_gcl_au`) for attribution

**It still does:**

* load and run the chat widget
* keep the conversation going as the visitor moves between pages
* retain the conversation transcript, including any personal information the visitor chooses to type into chat
* record the visitor's country, used for country-based display rules

Consent changes take effect immediately: granting consent mid-session starts tracking, and revoking it stops further tracking. Two limitations are worth knowing:

* Third-party deanonymization scripts already loaded into the page before a revoke cannot be unloaded without a page reload, which Spara will not trigger on your site.
* A chat window already open when consent changes keeps its previous setting until the visitor navigates.

{% hint style="warning" %}
Spara does not provide legal advice, and this integration does not by itself make your site compliant. Spara does not currently support Global Privacy Control (`Sec-GPC`) signals and does not keep a server-side record of consent decisions. Consult your legal or compliance team to determine the correct configuration for your privacy policy and applicable regulations (GDPR, CCPA, etc.).
{% endhint %}

### Without a consent platform

If no consent provider is configured, Spara behaves as it always has and tracks page visits for all visitors. Organizations that would rather not load Spara at all before consent can continue to insert the embed snippet conditionally, based on their consent management platform's API.

## Z-index and stacking

The Spara chat widget uses a high `z-index` to ensure it appears above most page content. If your cookie consent banner also uses a high `z-index`, both elements can coexist — the banner will typically appear above or alongside the chat widget depending on your CSS. If you need to adjust layering, contact your Spara account manager.


---

# 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.spara.com/developers/installation/iframe-and-cookies.md?ask=<question>&goal=<endgoal>
```

`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.
