> Customer-facing KB content for help.velaro.com article 781. Updated 2026-06.

Summary

The Velaro widget is a chat service, not a tracking tool. How you classify it in your CMP depends on the experience you want to deliver. This article explains your options. Your legal and compliance team makes the final classification decision — we can tell you what the widget does technically, not what your DPO requires.

---

What the widget does on page load — technically

This matters for any CMP classification decision.

Standard embed (no boot flags): On page load the widget loads fully. It registers the visitor, writes session data to localStorage, and sets load-balancing cookies on api-visitor-us-east.velaro.com. Chat availability is checked and the launcher appears if agents are online.

With deferLoadUntilInteraction: true: On page load the widget fetches only your button appearance (colors, icon) and checks agent availability. No visitor is registered, no localStorage is written, no tracking cookies are set. The launcher button appears. When a visitor clicks the button, the full widget loads and the chat session begins.

With deferStorageUntilInteraction: true: The full widget mounts on page load but visitor registration and localStorage writes are held until the visitor opens the chat window.

Azure load-balancing cookies (ARRAffinity, ARRAffinitySameSite on api-visitor-us-east.velaro.com): These are set by Azure infrastructure regardless of boot flags. They contain no personal data, exist only to keep a visitor on a consistent server, and expire with the session. Every CMP has a Strictly Necessary / Essential / Required category for this type of cookie.

---

Choose your path

Path 1 — Let your CMP handle it (simplest)

Classify the Velaro widget as Functional / Preferences / Performance in your CMP. Your CMP's auto-blocking will hold the widget until the visitor consents to that category. Visitors who decline see no chat widget. No embed code changes are needed.

This is the correct path if your DPO is comfortable with the widget being visible only to visitors who have consented to Functional cookies.

Path 2 — Show the launcher to all visitors, defer tracking until click

Use this if your DPO requires the chat button to be visible to all visitors regardless of cookie choice, with no visitor data sent to Velaro until someone actively opens the chat.

Required changes — three things:

1. In your CMP auto-blocking: Move the Velaro CDN entry (eastprodcdn.azureedge.net) to Strictly Necessary / Essential. This prevents your CMP from blocking the widget script for visitors who have not consented to Functional cookies.

2. In your CMP cookie declaration: Classify the Azure load-balancing cookies as Strictly Necessary:

3. In your embed code: Add deferLoadUntilInteraction: true to your boot command:

Velaro('boot', {
  siteId: YOUR_SITE_ID,
  deferLoadUntilInteraction: true
});

Replace YOUR_SITE_ID with your numeric site ID. Remove any existing deferStorageUntilInteraction if present — these two flags are not interchangeable.

What this delivers: The chat launcher button (with your configured icon and color) is visible to all visitors. Agent availability shows in real time. No visitor is registered and no data is sent to Velaro until someone clicks the button. At that point the visitor has explicitly requested the chat service, and the full session loads.

---

CMP-by-CMP setup for Path 2

OneTrust

OneTrust's OtAutoBlock reads category assignments from your consent configuration. Changes can take several hours to propagate to production. Use OneTrust's Test script version to validate without waiting for propagation. Clear OptanonConsent and OptanonAlertBoxClosed cookies between tests.

Important: Do not add data-ot-ignore to the Velaro script element. This attribute bypasses OtAutoBlock's category check but also breaks the cross-window communication the widget relies on. The correct fix is to change the category to C0001, not to use data-ot-ignore.

---

Cookiebot (Usercentrics)

---

TrustArc

Classify eastprodcdn.azureedge.net under Required (Path 2) or Functional / Preference (Path 1). The Azure load-balancing cookies are Required.

---

Osano

---

Termly

---

Choosing between the two paths

If you use proactive chat invitations or timed pop-ups, those features require visitor data that is not collected before the click in Path 2. Proactive invites will not fire until the visitor opens the chat.

---

Regulatory context for Path 2

Several data protection authorities have explicitly addressed click-deferred chat as a legitimate architecture. These references are provided for informational purposes only — this article is not legal advice. Your organisation's legal and compliance team must make the final determination of what your specific deployment requires under applicable law.

Summary in plain language: Under Path 2, nothing is stored or transmitted until the visitor clicks the chat button. The click is the visitor's explicit request for the chat service. The three authorities above — and the underlying ePrivacy Art. 5(3) text — all recognise this pattern as falling within or consistent with the user-requested exception to prior consent. Your DPO must confirm this analysis applies to your specific context and jurisdiction.

---

Test your setup

Use our interactive test tool to verify your configuration before going live: velaro.com/cmp-test

Enter your site ID and optionally your OtAutoBlock URL (OneTrust customers). The tool runs four live scenarios in your browser and lights up green when each one passes. No account login required.

---

Need help?

Contact Velaro support to confirm your site ID, check your group configuration, or enable deferLoadUntilInteraction on your account.