Cookies & Consent

warm.js tracks visitor behaviour on your site to enable real-time company identification, form analytics, and UTM attribution. Because it sets a first-party cookie and captures behavioural data, your site must handle visitor consent before the script runs — especially if you serve visitors in the UK or EU.

This guide covers exactly what warm.js stores, what each jurisdiction requires of you, and how to configure popular consent managers to handle it correctly.

What warm.js sets and stores

Cookies

sessionStorage

Data sent to Warm AI’s edge function

Each page view and session event sends the following to https://track.getwarmai.com:

• device_id — the UUID from warm_device (per-session)
• page_url, referrer, page_title
• session_start / session_end / page_view events
• form_start, form_update, form_submit, form_abandon events
• captured_email — when a visitor types an email address into a form field (see note below)
• UTM parameters (both last-touch and first-touch, persisted for the session)
• active_seconds — time on page while the tab is visible and the user is actively interacting
• IP address (proxied server-side, used for company identification)
• User-agent string

Jurisdictional quick-reference

Recommended: block warm.js until consent is granted

The cleanest way to stay compliant across all jurisdictions is to ensure warm.js does not execute until the visitor has given consent. Most consent management platforms (CMPs) do this automatically once you tag the script correctly.

What this looks like in practice:

1. Your CMP shows a consent banner on first visit.
2. Until the visitor clicks “Accept”, warm.js is not loaded or executed.
3. Once consent is granted, the CMP releases the script and tracking begins.
4. On return visits, the CMP checks the stored consent decision and either blocks or allows the script immediately.

This approach requires zero changes to warm.js itself — it all happens at the CMP layer.

Setting up with popular consent managers

Cookiebot

Add a data-cookieconsent attribute to the script tag. Cookiebot will block execution until the visitor consents to that category.

<script
  src="https://assets.warmai.uk/warm.js"
  data-id="YOUR_TRACKING_ID"
  async
  data-cookieconsent="statistics"
></script>

Cookiebot scans your pages automatically and picks up the data-cookieconsent="statistics" attribute. Visitors who decline statistics cookies will not load warm.js at all.

Alternative: If you’re using Cookiebot’s auto-blocking mode (script type rewriting), add warm.js to your Cookiebot dashboard under Cookies → Declared cookies so Cookiebot knows to block it in statistics or marketing depending on your classification.

OneTrust

OneTrust uses category-based script blocking. Tag warm.js with the appropriate optanon-category attribute:

<script
  src="https://assets.warmai.uk/warm.js"
  data-id="YOUR_TRACKING_ID"
  async
  class="optanon-category-2"
></script>

optanon-category-2 maps to Performance cookies in most OneTrust configurations (categories vary by tenant — check your OneTrust dashboard). OneTrust rewrites the script type to text/plain until consent is given, then restores and executes it.

You can also classify warm.js in the OneTrust Cookie Audit tool, which will auto-tag it in future scans.

Termly

Termly auto-scans and classifies third-party scripts. Once you’ve added Termly to your site, it will detect assets.warmai.uk/warm.js and classify it as an analytics script. You can review and adjust the classification in the Termly dashboard under Cookie Consent → Cookie Preferences.

Tag the script manually for explicit control:

<script
  src="https://assets.warmai.uk/warm.js"
  data-id="YOUR_TRACKING_ID"
  async
  type="text/plain"
  data-categories="analytics"
></script>

Termly replaces type="text/plain" with type="text/javascript" after consent.

If you don’t use a consent manager

If your site has no consent manager:

For US-only audiences: You can load warm.js unconditionally, provided you disclose the cookie in your Privacy Policy and provide an opt-out mechanism (for California visitors).

For UK/EU audiences: You are not compliant if warm.js loads before consent. The warm_device cookie is non-essential, and setting it without prior consent violates PECR (UK) and ePrivacy (EU). The ICO (UK) and national DPAs across the EU actively enforce this.

Your options are:

1. Add a consent manager — Cookiebot, OneTrust, Termly, CookieYes, and Axeptio all have free or low-cost tiers for small sites.
2. Build your own consent gate — load warm.js dynamically only after the user accepts:

// Only call this after the visitor has explicitly consented
function loadWarmAI(trackingId) {
  const s = document.createElement('script')
  s.src = 'https://assets.warmai.uk/warm.js'
  s.setAttribute('data-id', trackingId)
  s.async = true
  document.head.appendChild(s)
}

Data subject rights (GDPR / CCPA)

Visitors can exercise rights over their data — access, deletion, correction, portability (GDPR), or opt-out of sale (CCPA). Here’s how to handle these requests:

Finding a visitor’s data: The primary key for a visitor’s tracking data is their device_id (the value stored in the warm_device cookie). If a visitor provides their device_id, you can use it to locate and delete all associated events in your Warm AI account.

Deletion requests: Contact Warm AI support with the visitor’s device_id. We will delete all session events, form events, and identification records linked to that ID.

Export requests: We can provide a JSON export of all events linked to a device_id upon request.

Retention: Session and event data is retained for 12 months by default. If your legal basis requires shorter retention, contact us to configure a custom retention window for your account.

Our internal compliance stance

We take privacy seriously and build Warm AI to make compliance straightforward rather than an afterthought. warm.js v2 was designed with a minimal-footprint principle: we set one first-party cookie (UUID only), we do not fingerprint, we do not write to third-party cookies, and we enforce a sensitive-field deny-list on email capture. We are actively working on Release 3A, which will add native CMP integration so that warm.js auto-respects consent signals without any manual tagging. Our infrastructure is hosted in the EU (Supabase EU region, Cloudflare EU data localisation) and we do not sell or share visitor data with third parties. If you have compliance questions that aren’t answered here, email us at compliance@warmai.uk.