Instrumenting an insurance client-360 app: modules, filters, teams, logins and geography

Analytics products are designed around shops: a visitor arrives, browses, adds to a cart, pays. An insurer’s client-360 application is nothing like that. Its users are employees who log in every morning, move between a search page, client and broker dashboards, policy pages, claims and renewals, filter by division and line of business, read the AI insights on a client, export to Excel and, occasionally, create a quote. The people funding it want to know whether it is being used, by whom, for what — and they want it on one page every week.

This post is the instrumentation that answers those questions, taken from the guide we give the application’s developers. Everything in it is live in the Insurance 360 (demo) project, which carries 30 days of exactly this shape, so every number below is one you can reproduce.

Automatic versus named

One snippet (or npm install @insight/clickiq) captures the mechanics with no code: pageviews on every React Router navigation, clicks with the element’s text and position, rage and dead clicks, scroll depth and time on page, form timings (never values), JavaScript errors, Core Web Vitals, sessions, device and browser, and session replay with inputs masked. What the SDK cannot know is your product’s vocabulary. It sees /clients/C-10729; it does not know that is the Client dashboard for Northgate Logistics, a Property account. Those moments you name.

The taxonomy

Event names are sentences in title case, properties are snake_case, and values come from closed lists. That last rule matters more than it looks: the report breaks down by these strings, so Property and property become two bars.

Quote created and Policy bound are marked as the project’s conversion events, so sessions that produce one are flagged converted and journeys, zones and lift work against them.

The React side

A small loader module loads the SDK only when a key and host are configured and makes every helper a no-op otherwise, so the application never depends on analytics being reachable. Two helpers do most of the work. identify runs after every login, because traits change:

identify(me);   // id = stable employee id, never the email
// sends: name, email, manager, team, division, department, branch, role

Modules come from a route table, one event per route change (the SDK sends the pageview for the same navigation itself):

const MODULES = [[/^\/search/, "Search"], [/^\/clients\//, "Client dashboard"],
  [/^\/brokers\//, "Broker dashboard"], [/^\/policies\//, "Policy page"],
  [/^\/claims/, "Claims"], [/^\/renewals/, "Renewals"], [/^\/reports/, "Reports"]];
useEffect(() => {
  const module = MODULES.find(([rx]) => rx.test(pathname))?.[1];
  if (module) track("Module viewed", { module, path: pathname.replace(/\/[A-Z]-?\d[\w-]*/g, "/:id") });
}, [pathname]);

Filters send one event per filter in the applied set, debounced so a user adjusting three dropdowns sends three events, not thirty. Insights send an impression when one is rendered in view, once per insight per page. And four attributes in the JSX handle privacy and naming: data-clickiq-block around claims notes and documents (never captured, removed from replay), data-private on a rendered policyholder name (masked), data-clickiq-form on the quote form, and data-clickiq-name="Export" for a stable heatmap zone.

The Python side: what the browser cannot see

Three things only the server knows. A failed login never reaches a logged-in page, and the reason — a bad password, a locked account, an MFA timeout — is on the server. A bound policy and its premium come from the binding service. And the user’s real location: the application sits behind a VPN, so every browser reaches the analytics endpoint from one exit, and the map would show one dot.

A sender of about forty lines posts to the same ingest endpoint on a daemon thread with a four-second timeout, never on the request path, keyed by the same user_id the React app identifies with:

clickiq_service.track(attempted_user.id, "Login failed",
                      {"method": "password", "reason": "bad_password"}, branch=attempted_user.branch)
clickiq_service.track(user.id, "Policy bound",
                      {"premium": policy.premium, "lob": policy.lob, "product": policy.product},
                      value=policy.premium, branch=user.branch)

The branch argument maps to a country, region and city (Dallas, Chicago, Atlanta, Toronto, London, Sydney) and is sent as geo on the event, which wins over edge headers and the browser’s time zone. That is what puts Chicago and Dallas, not the VPN exit, at the top of the report’s city panel.

Thirty days of it

Events — Event definitions

With traits on every event, the questions an operations lead actually asks become one query each. These came from POST /api/query — Ask AI produces the same specs from the sentence:

The login row is the one that tends to start a conversation. Two-thirds of failures are MFA timeouts, not wrong passwords — a usability problem with the second factor, not a security one — and a handful of people account for a disproportionate share. That is an IT ticket with a list of names attached, produced by a breakdown nobody had to build a dashboard for.

Events — Stream

What it feeds

With this taxonomy in place, the executive usage report template keeps all fourteen of its panels and renders with no further configuration: an AI-written summary, top users, daily actives, top clients and brokers, four filter panels, module engagement and geography. The executive report post shows what it wrote about last week.

Reports — Filters used

The mechanics feed the rest of the product unchanged: heatmaps and zones on the client dashboard (is the Export button found?), form analytics on the quote form, journeys from search to quote, signals when errors spike after a release, and agents that can be asked “which teams adopted the renewal-risk insight this month?” and answer from the same events.

Traits also make audiences cheap. A segment such as “Claims Operations, mobile” is a filter on user.team plus a device, saved once and usable in every chart, alert, session list and AI answer — and it can be described in a sentence and drafted by the AI against the project’s real traits before anyone saves it.

A checklist for your developers

1. Install the loader; confirm the first event on the project’s Sites & apps page.
2. Call identify after every login with the stable employee id and the traits; reset on logout.
3. Add the module route table and the named events, with values from closed lists.
4. Send logins, bound policies and geo from the back end.
5. Wrap anything a policyholder would recognise in data-clickiq-block or data-private.
6. Mark Quote created and Policy bound as conversion events.
7. Create the executive usage report from its template and compare it with the demo, panel by panel.

The SDK sees paths and clicks. Your product has modules, clients and teams. Name the second, and every AI feature can talk about your business in its own words.

← All posts   Request a demo