Adaptive On-Page Assistance SaaS - Customer Confusion Detection & In-Page Guidance Modal System

Background & Problem

Websites lose customers silently. A visitor stalls on a confusing form field, clicks a button repeatedly out of frustration, or cycles through dropdown options not knowing which to pick — and then they leave. Currently there is no mechanism to detect these moments in real time and intervene with the right guidance before the customer abandons the journey. Generic live chat prompts are too broad and interrupt visitors who are not actually confused. What is needed is a precise, contextual intervention — triggered only when a specific frustration signal is detected on a specific element — that delivers the exact guidance that element requires.

The Solution

A rule-based customer intervention engine that monitors visitor behaviour passively and fires contextual guidance modals at the right moment on the right element. Business admins configure rules through a dashboard: they specify a page URL pattern, a CSS selector for the problematic field or button, the type of confusion signal to watch for (rage clicks, repeated value changes, or prolonged focus), and the guidance content to display (text explanation, a walkthrough video, an audio message, or a mix). When the tracker detects a matching signal on a matching element, it renders a polished modal directly on the visitor's page — no page reload, no chat agent required.
Part of the project is to generate the script that host websites could put in their head/body/custom HTML tag to allow this SaaS to track.

Suggested Technical Approach

The solution has four components that must work together:

Admin Configuration UI — A form within an existing dashboard where admins create and manage guidance rules. Each rule captures: a URL pattern (e.g. /checkout*), a CSS field selector (e.g. #cvv-field), which frustration signals should trigger it, a modal title, and one or more content blocks (text, video URL, audio URL) that can be ordered and combined. Rules can be toggled on/off without deletion.

Rules API — A lightweight REST endpoint that serves the enabled rules for a given project. The tracker script fetches this once on page initialisation and holds the ruleset in memory. No further network calls are made at trigger time, keeping intervention latency at zero.

In-Browser Tracker Logic — A small JavaScript snippet (already embedded on client websites) that listens for three frustration signals: rage clicks (3+ rapid clicks on the same element), field cycling (a visitor changes the same field value 4+ times within 10 seconds), and long dwell (a visitor remains focused on a single field for over 30 seconds). When a signal fires, the tracker checks the in-memory ruleset for a matching page + element rule. If found, it renders the guidance modal. If not, it falls through to the default chat trigger behaviour.

Guidance Modal Renderer — Injected into the host page via the tracker script using only vanilla JavaScript and CSS — no external libraries, no dependencies on the host site's tech stack. Renders a centred overlay modal with a semi-transparent backdrop, a dismiss button, and content blocks rendered in the order the admin configured them. Video content uses the browser's native video element or a YouTube iframe. Audio uses the browser's native audio player. The modal respects a cooldown period to avoid repeatedly interrupting the same visitor.

Important Project Requirements — Enterprise Readiness, Security & Privacy

Support CSS selector as the primary method, with data attributes as the explicitly recommended and documented stable alternative. The admin UI should show a note recommending data- attributes for sites where class names are unstable.

These are non-negotiable requirements:

Zero host site impact: The entire tracker is wrapped in a fail-safe circuit breaker. If the script encounters 5 consecutive errors it disables itself automatically and does not attempt to recover until it receives a healthy server response. Under no circumstance should the tracker script break, slow down, or interfere with the host website.

No third-party content fetched at trigger time: All rules are loaded once at page initialisation. The modal fires from memory, meaning trigger latency is zero and there is no dependency on the UXIntel server being reachable at the moment of intervention.

Admin-supplied media URLs only: Admins provide external URLs for video and audio (YouTube, Vimeo, or their own CDN). The system does not handle file uploads, eliminating a significant attack surface and storage compliance concern.

XSS prevention: All admin-configured text content (guidance messages, titles) must be HTML-escaped before DOM insertion. Color values must be validated against a strict allowlist (hex, rgb, hsl formats only) before use in inline styles. No user-supplied content may be injected as raw HTML.

No eval() or dynamic code execution: The tracker must not evaluate any string as code. All provider integrations must use direct function references or DOM event dispatch.

Input validation and payload limits: All API endpoints must validate inputs against strict schemas with field length caps and payload size limits to prevent abuse.

Rate limiting: Public-facing tracker endpoints must enforce per-IP rate limits to protect against scraping and denial-of-service abuse.

CORS domain validation: Tracking and config requests must be validated against the project's registered domain to prevent unauthorised sites from impersonating a project.

Data minimisation: The guidance system stores only the rule configuration (page pattern, selector, content URLs). It does not log which visitors saw which modals or capture any visitor input from the guided fields. No PII is collected as part of the intervention layer.

Session cookie security: Any authentication cookies must be httpOnly, secure, and sameSite-restricted. Show More