For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

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 for more information.

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.

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.

Last updated