Signals with a price tag: what to fix first, and the week explained

Most teams do not lack alerts. They lack an order. Monday morning brings a slow page, a spike in errors, a frustrated button and a traffic dip, each flagged in a different tool, each marked “warning”. Which one first? The usual answer is whichever someone noticed, or whichever belongs to the loudest team.

InsightClickIQ’s signals are found without setup — nobody configures a threshold — and each one carries an impact: the sessions and people it touched, an estimate of the conversions lost, the revenue that represents when purchases carry a value, and a 0–100 score. The Signals page is sorted by that score. This post shows the arithmetic behind each number, then the weekly digest that turns the top of the list into a paragraph.

What gets detected

A background round runs every 30 minutes. Detection is statistical and computed in code; the model is only asked to word what was found.

The arithmetic of a price tag

Take the top signal on Northwind this week: “/ loads slowly: LCP p75 is 4.8s”, from 594 samples, against a 2.5-second target.

1. Touched. 616 sessions (609 people) viewed the homepage in the last seven days.
2. Baseline. The project’s conversion rate over the same window: 10.48%.
3. Lost conversions. The touched sessions that did not convert, multiplied by the baseline: about 56. In words: if these sessions had converted at the site’s normal rate, 56 more of them would have bought.
4. Revenue. Lost conversions times the average value of a purchase-like event over 30 days (on Northwind, Order completed carries the order total, averaging $306.88): $17,185.28. When purchases carry no value, revenue is left empty rather than guessed.
5. Score. Severity weight (critical 3, warning 2, info 1) times log(1 + sessions), scaled so the project’s largest signal is 100. This one is a warning on 616 sessions: 100.

The logarithm in the score is a deliberate choice. Without it a problem on every page view would always outrank a severe one on fewer sessions. With it, a critical outage touching 43 sessions (score 88) sits just below a warning touching 616 (100), and well above a minor annoyance touching 14 (21).

This week on Northwind

Signals

Three of those are one event: the demo store received no traffic on October 25, so visitors, sessions and pageviews all fell to zero against an expected 327, 329 and 1,053. On a real site that is a removed tag, a broken deploy or an outage, and the recommendations say exactly that — “Check your tag manager and deployment history for changes made the day of the drop”. Ranking puts them second, not first, because they touched 43 sessions; the slow homepage touched 616 every week.

The coupon signal is the one that matters most per session. Its narrative: “The ‘Apply coupon’ element on /cart received 53 rage clicks and 110 dead clicks across 78 sessions this week, suggesting the coupon field or button is broken or unresponsive and is frustrating users at a critical checkout step.” Its recommendation is to test the button in staging and production, then “watch the rage-click session recordings to pinpoint the exact failure” — and the card lists those sessions as numbered links.

Signals — frustration

The recommendations come from the same narration call that words the narrative, which sees the signal’s figures and nothing else; without a model, a fixed rule per kind writes one. Every card also has Analyze with an agent, which starts the matching playbook with the signal as context: a frustration signal starts the frustration hunter, an error spike the error triage, a conversion drop the conversion analyst, a slow page the page audit on that path.

The four buttons on every card are the next steps, in increasing depth. Explain opens an AI reading of the signal’s chart against the previous period. Investigate opens an investigation on the sessions behind the signal, so the AI watches them and groups what went wrong. Analyze with an agent starts a playbook. Open in Analyze hands the signal’s query to the builder, where it can be changed, saved to a dashboard or turned into an alert. A signal can also be dismissed; dismissed signals are kept for 90 days and then removed.

The week, explained

Once a day the background loop writes each project’s weekly digest; it appears at the top of the Overview as This week, explained. The week is the last seven full days ending at the project’s local midnight. The facts are computed first: the six KPIs against the week before, the top three pages and sources up and down, the top conversion event, and the top three signals by impact. The model then writes a headline and at most 180 words, and is told to end with one thing to do.

Overview — This week, explained

For October 19–26 the headline was “Reddit traffic collapsed 88%, dragging visitors down 32% and orders down 37%”. The facts behind it:

The narrative connects them the way an analyst would: the lost Reddit referrals “almost single-handedly” explain the fall in visitors, the review article that Reddit was sending people to lost 539 views, and conversion itself barely moved. Then it turns to cost: the slow homepage, “affecting 683 sessions with an estimated 55 lost conversions and $16,976 at risk — the single costliest signal on site”, and the coupon loop on the cart. It ends with one action: compress the homepage hero image and give it fetchpriority="high", “the highest-impact fix you can ship this week regardless of what happens with Reddit”.

What runs where

• Signals: GET /api/ai/signals, sorted by impact score, then severity. Agents and MCP clients get the same list through list_signals.
• Digest: GET /api/ai/digest?period=week (or day), cached per project and period; refresh=true regenerates it.
• Without a model: signals are still detected and priced; a rule per kind words them. The digest is composed from the same facts by rules. Every number is identical; only the prose is plainer.

A signal without a cost is a notification. With one, it is a priority.

← All posts   Request a demo