What Sets Anomaly Detection Apart from Simple Thresholds
Classic monitoring alerts work with fixed thresholds: if response time exceeds 2 seconds, an alert fires. This works for clear technical metrics like uptime or SSL expiry. For business metrics like conversion rates or bounce rates, however, this approach is insufficient — because normal values fluctuate significantly depending on the day of the week, season, and traffic source.
An online shop typically has a different conversion rate on Monday than on Saturday. A campaign landing page shows a lower bounce rate during an advertising push than during normal operations. A fixed threshold would produce false alarms in both cases — or miss real problems because the threshold is set too generously.
Statistical anomaly detection solves this problem by checking not against fixed values but against the historical normal behavior of each metric. The XICTRAQ algorithm calculates a rolling mean and standard deviation for each combination of metric, URL, and website over 30 to 90 days. A deviation is only classified as an anomaly when it is statistically significantly different from the normal range.
The z-Test: The Math Behind Detection
Anomaly detection in XICTRAQ is based on the z-test, a proven statistical method. The formula is straightforward: z = (x - mu) / sigma, where x is the current value, mu is the historical mean, and sigma is the standard deviation. The z-score indicates how many standard deviations the current value lies from the average.
| z-score | Meaning | Severity | Action |
|---|---|---|---|
| |z| < 2.0 | Normal fluctuation range | None | No insight created |
| |z| 2.0 - 3.0 | Notable deviation | Info/Warning | Insight created, review recommended |
| |z| > 3.0 | Statistically highly significant | Critical | High-priority insight |
| |z| > 4.0 | Extreme deviation | Critical | Immediate investigation recommended |
For context: in a normal distribution, 95.4% of all values fall within two standard deviations and 99.7% within three. A z-score of 3.0 means the current value would occur randomly in fewer than 0.3% of cases. This minimizes false alarms without overlooking real anomalies.
Which Metrics Are Checked for Anomalies
The insights cron computeInsights() runs every night at 2 AM and checks four metric categories for statistically significant deviations. Each category has specific thresholds and contextual conditions.
Detects drops in goal completion rate. Particularly relevant for e-commerce checkout pages, lead forms, and booking portals. A sudden conversion drop typically indicates technical errors, layout changes, or broken forms.
Detects unusual increases in bounce rate. Common causes: slow load times, broken content, misleading meta descriptions, or changes in traffic source (e.g., low-quality ads).
Monitors the abandonment rate of individual form fields through form analytics. When a specific field suddenly generates significantly more abandonments, an insight is created — often indicating validation errors or UX issues.
Detects unusual changes in visitor volume. A sudden traffic spike could indicate a viral post; an unexplained decline could point to SEO issues, broken redirects, or bot traffic filtering.
Severity Classification: From Info to Critical
Not every anomaly is equally urgent. The automatic severity classification considers three factors: the z-score (statistical significance), the impact on business metrics, and the duration of the deviation.
- Info: Slight deviation worth monitoring. Example: bounce rate increased by 12%, z-score 2.1. Could be seasonal.
- Warning: Notable deviation with business relevance. Example: conversion rate on the checkout page dropped 25%, z-score 2.6. Action needed within 24-48 hours.
- Critical: Strong anomaly with high probability of a real problem. Example: form abandonment increased 45%, z-score 3.8. Immediate investigation recommended.
The severity levels are intentionally conservative. Better to have one relevant warning too few than ten irrelevant criticals per week. The system also considers the data basis: if a URL has fewer than 100 pageviews per week, the statistical significance is adjusted downward to prevent false alarms on low-traffic pages.
Insights in the Dashboard: Read, Understand, Act
Detected anomalies appear as insights in the monitoring dashboard. Each insight contains a title, a description with the relevant numbers, the severity level, and a dismiss button. Insights that are no longer relevant or should be deliberately ignored can be dismissed with a click.
The insights feed is sorted chronologically — the newest anomaly appears at the top. Through the API (GET /api/websites/:id/insights), you can also retrieve insights programmatically, for example to route them to Slack or your internal issue tracker. The dismiss endpoint (POST /api/websites/:id/insights/:id/dismiss) sets a dismissed_at timestamp so that dismissed insights are not shown again.
If the system detected an anomaly during the reporting week, the insight is automatically included in the weekly client report. This way, your clients learn about deviations proactively — not when it's too late.
Practical Example: Conversion Drop from Broken Form Field
An online shop updates its CMS and overlooks that the postal code validation in the checkout no longer works correctly. Customers with Austrian postal code formats (four digits) are rejected as invalid. Since the shop monitors revenue through analytics but has no anomaly detection enabled, the error is only spotted three days later during a manual dashboard check.
With automated anomaly detection, the process would be different: the insights cron detects on the first night after the update that the form abandonment rate for the postal code field has risen from 8% to 41% (z-score 4.2, severity critical). The shop owner sees the insight in the morning dashboard and can fix the bug before another day of revenue is lost.
What Anomaly Detection Is Not — and Cannot Do
Automated anomaly detection is not a substitute for manual monitoring and not an oracle that names the cause of a problem. It detects that a metric is behaving unusually — not why. Root cause analysis remains with the operator or tools like the AI assistant, which can correlate the relevant data sources.
- No root cause analysis: The system reports the anomaly, not the cause. You need to find the cause in the detail data — or ask the assistant.
- No real-time protection: The insights cron runs once nightly. For real-time alerting on technical outages, use uptime monitoring with minute-level intervals.
- Dependent on data volume: For websites with fewer than 50 pageviews per day, the statistical basis is too thin for reliable anomaly detection. The system adjusts thresholds automatically but cannot make meaningful determinations with very low traffic.
- No predictions: The system detects deviations from the historical normal value but does not make forecasts about future developments.
Technical Integration: Cron, API, Data Flow
The insights cron (analytics-insights) runs daily at 2 AM and calls the computeInsights() function. This function iterates over all websites with active analytics tracking and calculates z-scores for the configured metrics. Historical baselines are computed from the analytics_pageviews, analytics_sessions, and analytics_form_events tables.
Detected anomalies are written to the analytics_insights table with the fields website_id, kind (conversion_drop, bounce_spike, form_abandonment, traffic_anomaly), severity (info, warning, critical), title, body, and dismissed_at. The API endpoints follow the REST standard: GET for retrieval, POST .../dismiss for dismissal.
For agencies monitoring multiple client websites, the combination with automated reports is particularly useful: the report cron checks before sending whether open insights exist and automatically includes them in the report. This way, anomaly detection flows directly into client communication without additional effort.
Setup: Activate Insights in Three Minutes
- Open the XICTRAQ dashboard and navigate to your website
- Enable analytics tracking if not already done — the tracker captures the necessary data automatically
- Wait seven to fourteen days until enough historical data for a baseline has accumulated
- Check the Insights tab in the dashboard — anomalies appear automatically once the baseline is established
- Optional: configure alerting for critical insights to receive notifications via email, Slack, or Telegram
Automated Insights run automatically for all websites with active analytics tracking. You don't need to configure thresholds or define rules. The system learns normal behavior from your historical data and reports statistically significant deviations.
Anomaly Detection and GDPR
Anomaly detection works exclusively with aggregated data: conversion rates, bounce rates, abandonment rates per form field, visitor counts per URL. No personal data is analyzed — no IP addresses, no session IDs, no user profiles. Analytics tracking in XICTRAQ is fundamentally cookieless and GDPR-compliant, and the insights calculation inherits this property.
Insights are stored in the XICTRAQ database at Hetzner in Germany. There is no third-party access to the data — the entire computation runs server-side in the backend. Unlike tools that send analytics data to external AI services, XICTRAQ keeps data sovereignty entirely with the customer.
When Anomaly Detection Delivers the Greatest Value
Not every website benefits equally from automated anomaly detection. The greatest value arises for websites where metric changes have direct business impact. Typical examples:
- Online shops: Conversion drops cost measurable revenue per hour. A broken checkout is the most expensive problem that is noticed last.
- Lead generation: When the contact form suddenly produces 40% more abandonments, you're missing inquiries you never see.
- SaaS products: Unusual bounce rates on the pricing page can indicate pricing problems or technical errors.
- Agency clients: When you monitor multiple websites for clients, you detect problems proactively — before the client calls.
- Content websites: Traffic anomalies can indicate SEO issues, broken redirects, or Google algorithm updates.
This article is based on data from: [Forrester Research — The Cost of Delayed Anomaly Detection], [NIST — Statistical Methods for Anomaly Detection], [Google Web Vitals Documentation].
From Reactive to Proactive: Monitoring as an Early Warning System
Classic website monitoring answers the question: Is the site reachable? Anomaly detection answers a different, often more important question: Is the site working as intended? A website can run technically flawless — 100% uptime, fast response times, green security scores — and still have a business problem because a form field doesn't validate, a price calculation is wrong, or a landing page attracts the wrong visitors.
Automated Insights close this gap. They combine the reliability of uptime monitoring with the business relevance of analytics data, turning the monitoring dashboard into an early warning system for overall website performance — both technical and business.