> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kaireonai.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Dashboards
> Monitor platform health, business performance, data quality, model accuracy, and channel attribution from five purpose-built dashboards.
KaireonAI ships with a suite of monitoring dashboards, each designed for a different audience and set of questions. Together they give you real-time visibility into every layer of the platform — from infrastructure health to business outcomes to model drift. All dashboards auto-refresh every 30 seconds. This page covers the five operational dashboards below; the [Executive dashboard](/operations-reporting/executive-dashboard) is documented on its own page.
Navigate to **Dashboards** in the sidebar to access them.
| Dashboard | Audience | Questions It Answers |
| ---------------- | ------------------- | ------------------------------------------------------------------------- |
| **Operations** | Platform engineers | Is the system healthy? How fast are decisions? Is the DLQ growing? |
| **Business** | Analysts, marketers | Which offers convert? Which channels perform? What is the funnel? |
| **Data Health** | Data engineers | Are connectors up? Are pipelines running? How many schemas exist? |
| **Model Health** | Data scientists | Is model accuracy stable? Which features matter? Are experiments running? |
| **Attribution** | Growth, analytics | Which channels drive conversions? How should credit be split? |
***
## Operations Dashboard
**Path:** `/dashboards/operations`
The Operations Dashboard is the primary system-health view for platform engineers. It answers: *Is the decisioning engine running fast and correctly?*
### Performance KPI Cards
Four cards across the top row:
| Card | What It Shows | Source |
| ---------------- | ------------------------------------------------ | -------- |
| **Total Runs** | Count of all Decision Flow executions | Runs API |
| **Avg Latency** | Mean latency in milliseconds | Runs API |
| **P95 Latency** | 95th-percentile latency | Runs API |
| **Success Rate** | `completed / (completed + failed)` as percentage | Runs API |
### Latency Visualizations
| Chart | Description |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Latency Distribution** | Bar chart where each bar = one run, height proportional to latency vs. P95. Hover for run ID and exact latency. |
| **Latency Trend (7-day)** | Line chart with P50 and P99 series over the past week. Shows sample data badge when no real time-series data exists. |
### Acceptance Rate by Offer
Bar chart plus detail table showing per-offer acceptance rates from the `interaction_summaries` table:
| Column | Description |
| ----------- | -------------------------------------- |
| Offer ID | Unique identifier |
| Impressions | Total presentations |
| Positive | Accepted/converted interactions |
| Negative | Rejected/dismissed interactions |
| Accept Rate | `positive / impressions` as percentage |
### Budget Utilization
Progress bars for offers with budget allocations. Color-coded:
| Color | Condition | Meaning |
| ----- | --------- | ---------------------------- |
| Green | Below 70% | Healthy spend rate |
| Amber | 70--90% | Approaching limit |
| Red | Above 90% | Near or at budget exhaustion |
### Decision Pipeline Panel
Reads persisted `DecisionTrace` aggregates via `GET /api/v1/dashboards/decision-pipeline`. The window is driven by the page's period selector and capped at 168 hours (7 days); the panel header shows the effective window ("last 7d", "last 24h", etc.) derived from the API response's `windowHours` field — so it is always truthful.
Query param: `windowHours` (1–168, default 24). The period selector now correctly refetches the panel on change.
| Field | Description |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Duration P50 / P95 / P99** | Percentile aggregates of `totalLatencyMs` across all traces in the window |
| **Funnel** | Average candidate counts at 5 stages: Initial Candidates, After Qualification, After Suppression, After Contact Policy, After Scoring |
| **Filter rates** | Cumulative fraction of initial candidates dropped — `qualification` = (initial − after\_qual) / initial; `contactPolicy` = (initial − after\_contact) / initial. Both are cumulative (not stage-isolated), shown as progress bars (red > 80%, amber > 50%) |
When `traceCount === 0` the panel shows an empty state. The empty state note mentions `decisionTraceSampleRate` (configurable under Settings → Tenant) in case tracing is turned down or off.
The panel loads via a direct `fetch` that respects the page's period selector (`periodDays → windowHours = min(periodDays × 24, 168)`); auto-refreshes every 30 seconds alongside the rest of the dashboard.
### Dead Letter Queue (DLQ) Panel
| Status | Condition | Color |
| -------- | ------------ | ----- |
| Healthy | 0 events | Green |
| Warning | 1--10 events | Amber |
| Critical | 10+ events | Red |
Shows topic breakdown (e.g., `decision.outcome`, `pipeline.error`) with **Retry All** and **Purge** action buttons.
### Circuit Breaker Panel
Displays state change history for each breaker (e.g., `enrichment-redis`, `connector-snowflake`). Color-coded badges: red for `open`, amber for `half_open`, green for `closed`.
### Investigating a Drop in Acceptance Rate
Suppose you notice `offer_summer_promo` dropped from 12% to 3% acceptance overnight. Here is how to investigate:
1. **Check the Decision Pipeline panel.** If "After Qualification" is normal but "After Contact Policy" drops sharply, a new frequency cap is filtering aggressively.
2. **Open a Decision Trace.** The trace shows candidates at each stage. If the offer is present at Qualification but absent after Contact Policy, expand the contact policy section to see which rule suppressed it.
3. **Check the Filter Rate bars.** Contact Policy filter rate above 80% (red) means most candidates are being suppressed — likely a misconfigured policy.
If DLQ depth rises while acceptance rates drop, check whether the outcome recording pipeline is failing. Missing outcomes make acceptance rate calculations unreliable.
***
## Business Dashboard
**Path:** `/dashboards/business`
The Business Dashboard answers: *How are my offers performing?* Designed for analysts and marketers who need to track conversion rates, channel effectiveness, and revenue.
### Summary Cards
| Card | Source |
| --------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Active Offers** | `Offer` records with `status = "active"` |
| **Active Channels** | `Channel` records with `status = "active"` |
| **Experiments** | Active `Experiment` records |
| **Journeys** | Total `Journey` records |
| **Active Triggers** | Active **trigger rule** records |
| **Pending Approvals** | Pending **approval request** records |
| **Acceptance Rate** | Aggregate positive / total interactions across all offers (last 30 days, from the `interaction_summaries` table) |
### Offer Funnel
Four-stage funnel showing conversion from configuration to delivery readiness:
1. **Total Offers** -- all offers in the tenant
2. **Active** -- offers with `status = "active"`
3. **With Creatives** -- active offers that have at least one active creative
4. **Active Creatives** -- total count of active creatives
If you have 20 active offers but only 5 have creatives, 15 offers cannot be delivered. The funnel makes this gap immediately visible.
### Charts
| Chart | What It Shows |
| ------------------------------- | -------------------------------------------------------------------- |
| **Channel Effectiveness** (pie) | Each channel's share of conversions (`positive / impressions * 100`) |
| **Offer Performance** (bar) | Horizontal bars ranking offers by conversion count |
| **Daily Trend** (line, 7-day) | Impressions and conversions over time from **interaction history** |
### Offer Performance Detail Table
| Column | Description |
| ----------- | ---------------------------------------------- |
| Offer | Offer name |
| Priority | Configured priority value |
| Creatives | Count of active creatives |
| Impressions | Total presentations |
| Conversions | Positive interactions |
| Conv. Rate | `conversions / impressions * 100` |
| Revenue | Sum of `totalValue` from interaction summaries |
High impressions but zero conversions? Check if the creative is compelling and the channel matches the audience. Conversions but zero revenue? Verify that Respond API calls include a `value` field.
***
## Data Health Dashboard
**Path:** `/dashboards/data-health`
Monitors the ingestion layer — connectors, pipelines, and schemas.
### Summary Cards
| Card | Description |
| --------------------- | ------------------------------------------------------ |
| **Total Connectors** | All configured connectors (S3, Kafka, Snowflake, etc.) |
| **Active Connectors** | Connectors with `status = "active"` |
| **Pipelines** | Total pipeline definitions |
| **Schemas** | Total data schema definitions |
### Connectors Table
| Column | Description |
| ------ | ------------------------------------------------------------- |
| Name | Connector name |
| Type | e.g., AWS S3, Snowflake, Kafka |
| Status | `active` (green), `error` (red), `inactive` (gray) |
| Auth | Authentication method (e.g., `iam_role`, `api_key`, `oauth2`) |
A connector showing `error` usually means the last connection test failed. Navigate to **Data > Connectors**, select it, and run **Test Connection** for the specific error. Common causes: expired credentials, changed IP allowlists, network policy changes.
***
## Model Health Dashboard
**Path:** `/dashboards/model-health`
Tracks scoring model status, accuracy trends, and experiment activity. Designed for data scientists monitoring model performance.
### Summary Cards
| Card | Description |
| ----------------- | ------------------------------- |
| **Total Models** | All registered algorithm models |
| **Active Models** | Models with `status = "active"` |
| **Experiments** | Total experiment definitions |
### Charts
| Chart | What It Shows |
| ---------------------------- | ------------------------------------------------------- |
| **AUC Trend** (line, 7-day) | Area Under Curve over time for the primary active model |
| **Feature Importance** (bar) | Top predictors ranked by importance weight |
### Models Table
| Column | Description |
| ------ | ---------------------------------------- |
| Name | Model name |
| Type | Scorecard, Bayesian, or Gradient Boosted |
| Status | `active`, `error`, or `draft` |
| AUC | Latest AUC metric as percentage |
A sudden AUC drop (more than 5 points in a week) suggests feature drift. Check the Feature Importance chart for ranking changes, then consider retraining with recent data.
### Analysis panels
Four additional analysis panels sit below the main cards:
#### Uplift
**Source:** `GET /api/v1/treatments/uplift?windowDays=N`
Per-creative observational uplift cards. Window selector: 7 / 30 / 90 days; auto-refetches on change. Renders a bar chart of uplift value per creative and a table with sample counts, p-value, and 95% confidence interval (unpooled Wald standard error). A `samplesBelowMinimum` badge flags creatives without enough data for reliable inference.
#### CATE Explorer
**Source:** `GET /api/v1/algorithm-models/[id]/uplift?customerId=...&method=...`
Submit-driven panel for per-customer Conditional Average Treatment Effect (τ). Pick a model, enter a `customerId`, select a method (`t_learner` or `x_learner`), and submit. Renders an offers table with τ values, color-coded segment badges (persuadable / sure\_thing / lost\_cause / sleeping\_dog / uncertain), and an overall ATE summary line.
#### Fairness
**Source:** `POST /api/v1/fairness/evaluate` with `{ mode: "inline", samples: [...] }`
Inline-mode fairness evaluation. Paste a JSON array of `{ group: string, prediction: boolean, label?: boolean }` decision samples and submit. Renders per-group stats (count, positive rate, TPR/FPR when labels are present), key metric cards (demographic parity gap, disparate impact ratio, four-fifths badge), and a warnings list.
There is no persisted fairness history table. The fairness-recheck cron writes outcomes to AuditLog entries but does not store structured `FairnessEvaluation` rows. The panel is therefore form-driven and stateless — it evaluates samples you provide inline. To see historical gate outcomes, query `GET /api/v1/audit-logs?action=fairness_evaluate`.
#### Drift Check
**Source:** `POST /api/v1/models/[id]/drift`
Interactive drift analysis. Select a model, paste JSON for reference and current feature distributions (`{ featureName: number[] }`), and submit. Renders a per-feature PSI and KS table with severity badges (`none` / `monitor` / `alert`) and an overall verdict.
***
## Attribution Dashboard
**Path:** `/dashboards/attribution`
Multi-touch attribution analysis comparing how different models distribute credit across channels. Helps answer: *Which channels actually drive conversions, and how should I allocate budget?*
### Attribution Models
Five models are selectable. Two additional models appear as disabled Coming Soon entries in the picker — they are rendered but not selectable and the API enum is unchanged.
| Model | How Credit Is Assigned | Status |
| ------------------ | --------------------------------------------------- | ---------------------------- |
| **Last Touch** | 100% to the final touchpoint before conversion | Live |
| **First Touch** | 100% to the first touchpoint | Live |
| **Linear** | Equal split across all touchpoints | Live |
| **Time Decay** | More credit to touchpoints closer to conversion | Live |
| **Position Based** | 40% first, 40% last, 20% split across middle | Live |
| **Shapley** | Game-theoretic credit assignment across touchpoints | Coming soon — not selectable |
| **Cross-Device** | Identity-stitched attribution across devices | Coming soon — not selectable |
### Summary KPIs
| Card | Description |
| -------------------------------- | ---------------------------------------- |
| **Total Conversions** | Number of attribution results |
| **Channels** | Distinct channels across all touchpoints |
| **Total Credit** | Sum of all credit values |
| **Avg Touchpoints / Conversion** | Mean touchpoints per conversion journey |
### Channel Contribution Chart
Horizontal bar chart showing each channel's percentage contribution to total credit, with raw credit values.
### Conversions Per Channel Table
| Column | Description |
| -------------- | ------------------------------------- |
| Channel | Channel identifier |
| Touchpoints | Interaction count for this channel |
| Total Credit | Sum of credit assigned |
| Contribution % | `channel credit / total credit * 100` |
Compare the same data across attribution models. If a channel ranks number 1 under Last Touch but number 4 under First Touch, it is strong at closing but weak at introducing — useful for budget allocation decisions.
***
## Prometheus Metrics
KaireonAI exposes a Prometheus-compatible scrape endpoint at `/api/metrics` (requires `admin` role).
### Scrape Configuration
```yaml theme={null}
scrape_configs:
- job_name: "kaireon"
scheme: https
metrics_path: /api/metrics
authorization:
type: Bearer
credentials: ""
static_configs:
- targets: ["your-kaireon-instance.com"]
scrape_interval: 15s
```
### Key Metrics
**Decision Engine**
| Metric | Type | Description |
| --------------------------------------------- | --------- | -------------------------------------------------------------------------------------------- |
| `kaireon_decision_latency_ms` | Histogram | Decision engine latency (by channel) |
| `kaireon_decision_pipeline_duration_ms` | Histogram | Full pipeline execution time |
| `kaireon_decision_candidates` | Gauge | Candidate count at each stage |
| `kaireon_decision_qualification_filter_rate` | Gauge | Qualification filter ratio |
| `kaireon_decision_contact_policy_filter_rate` | Gauge | Contact policy filter ratio |
| `kaireon_decision_delivery_total` | Counter | Total responses delivered |
| `kaireon_qualification_unknown_rule_total` | Counter | Unknown decisioning gate types — drift signal between code and tenant config (by `ruleType`) |
**HTTP & API**
| Metric | Type | Description |
| --------------------------------------- | --------- | ------------------------------------------------ |
| `kaireon_http_request_duration_seconds` | Histogram | HTTP request duration (by method, route, status) |
| `kaireon_http_error_total` | Counter | HTTP 4xx/5xx errors |
**Pipelines & Connectors**
| Metric | Type | Description |
| --------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------- |
| `kaireon_pipeline_execution_latency_ms` | Histogram | Pipeline execution time |
| `kaireon_pipeline_rows_processed_total` | Counter | Total rows processed |
| `kaireon_connector_test_latency_ms` | Histogram | Connector test duration |
| `kaireon_connector_test_total` | Counter | Connector test attempts (by `connectorType`, `status`) — pair with the latency histogram for failure-ratio alerting |
**Infrastructure**
| Metric | Type | Description |
| --------------------------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `kaireon_cache_hits_total` / `kaireon_cache_misses_total` | Counter | Cache performance |
| `kaireon_dlq_depth` | Gauge | Dead letter queue depth (by tenant) |
| `kaireon_circuit_breaker_state_change_total` | Counter | Circuit breaker transitions |
| `kaireon_active_worker_jobs` | Gauge | Active background jobs |
| `kaireon_outbox_pending_count` | Gauge | Per-tenant outbox backlog. Refreshed by the outbox processor on every poll tick. See [Outbox publisher](/self-host/configure/outbox-publisher#recommended-prometheus-alert) |
| `kaireon_identity_resolution_total` | Counter | Identity-graph resolution attempts (by `result`: `matched` / `created` / `ambiguous` / `error`) |
**Experiments & Models**
| Metric | Type | Description |
| ------------------------------------- | ------- | ------------------------------------------- |
| `kaireon_experiment_assignment_total` | Counter | Experiment variant assignments |
| `kaireon_scoring_model_failure_total` | Counter | Scoring model failures (fallback triggered) |
| `kaireon_mandatory_cap_hit_total` | Counter | Mandatory offer daily cap hits |
**AI Intelligence**
| Metric | Type | Description |
| ------------------------------------------ | --------- | -------------------------------------------------------------------------------------------------------------------------- |
| `kaireon_ai_intelligence_calls_total` | Counter | AI tool invocations (by `tool`, `status`) — covers MCP intelligence tools, in-app AI assistant, and intelligence dashboard |
| `kaireon_ai_intelligence_duration_seconds` | Histogram | AI tool execution duration (by `tool`); buckets 0.1, 0.5, 1, 2, 5, 10 seconds |
**Compliance**
| Metric | Type | Description |
| ---------------------------- | ------- | --------------------------------------- |
| `kaireon_gdpr_erasure_total` | Counter | GDPR erasure requests |
| `kaireon_dsar_request_total` | Counter | DSAR requests (by type, status) |
| `kaireon_sso_auth_total` | Counter | SSO auth attempts (by provider, result) |
The `/api/v1/metrics/summary` endpoint returns a curated subset of these metrics as JSON. This is what the Operations Dashboard uses internally — it does NOT include every metric on this page; the full scrape feed lives at `/api/metrics`.
For the full operator-grade reference of the seven post-W10 metrics — including registered file-line, alert guidance, and PromQL expressions — see [Metrics Reference](/self-host/operate/metrics-reference).
***
## Segment Dimension
Six of the Business and Operations dashboard queries accept an optional `segmentId` query parameter to scope their aggregation to customers in a specific [segment](/ai-ml/ai-segmentation). When provided, the underlying SQL joins the segment's materialized view (`seg_`) onto the interaction tables by `customerId`.
| Dashboard data `type=` | Segment filter behavior |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `acceptance_rate` | Per-offer acceptance scoped to the segment. |
| `offer_performance` | Top-20 offer impressions/conversions/revenue within the segment. |
| `offer_performance_grouped` | `groupBy=segment` fans the response out by every active materialized segment; each offer row is decorated with `segmentId` + `segmentName`. Alternatively, pass `segmentId=` with `groupBy=channel` or `groupBy=category` to filter within one segment. |
| `channel_effectiveness` | Channel-level impressions/conversions scoped to the segment. |
| `daily_trend` | 7-day impression/conversion line scoped to the segment. |
| `revenue_trend` | N-day revenue line from interaction summaries scoped to the segment. |
### Behavior when a segment is not ready
Segments are materialized to PostgreSQL views asynchronously. If a segment exists but its view has not been built (for example a draft segment), the endpoint returns `{"data": [], "warning": "segment view not materialized"}` — dashboards can render an informational banner instead of an error. An unknown `segmentId` returns `{"data": [], "warning": "unknown segmentId"}` under the same pattern.
### Example
```bash theme={null}
curl -H "X-API-Key: $API_KEY" -H "X-Tenant-Id: $TENANT_ID" \
"https://playground.kaireonai.com/api/v1/dashboard-data?type=offer_performance&segmentId=seg_vip&days=7"
```
See the [Dashboard Data API reference](/api-reference/dashboard-data) for complete parameter and response definitions.
***
## Export and Save as Report
Every dashboard in the platform ships with two header-bar buttons that turn the current view into a report artefact:
**Export works unconditionally — no cron wiring required.** Clicking
Export renders the artifact server-side and streams the file back to the
browser immediately.
**Save as Report** also creates the template + schedule immediately, but
the resulting saved schedule only fires on cadence once
`/api/cron/tick` is being invoked by an external scheduler. During pilot
/ initial deployment this is usually not wired. Use the **Run Now**
button on the saved template in `/settings/reports` for on-demand
delivery until you follow
[EventBridge Setup](../self-host/deploy/eventbridge-setup) (optional).
### Export
Dropdown with PDF / CSV / Markdown / HTML options. Clicking a format:
1. Builds a transient report template from the dashboard's current filters (date range, segment, etc.) via the `view-to-template.ts` bridge.
2. POSTs the transient template to `/api/v1/reports/preview` — no database row is created.
3. Receives a base64-encoded artifact and triggers a browser download via `Blob` + `URL.createObjectURL`.
CSV exports skip LLM narration to keep latency low; PDF / Markdown / HTML include a narrated executive summary when an AI provider is configured.
### Save as Scheduled Report
Opens a modal pre-filled from the current view. Pick:
* **Name** (required; defaults to `{Dashboard label} · {days}d`).
* **Formats** (multi-select; default PDF).
* **Narrative** toggle.
* **Schedule** (preset: Daily 8am / Weekly Mon 8am / Monthly 1st 8am / Custom cron).
* **Destinations** (multi-select of configured notification providers — Slack, Teams, webhook, Ops-email).
Submitting creates a **report template** and a **report schedule**. When the cron is wired (AWS EventBridge → `/api/cron/tick`), the schedule runs on cadence and delivers artefacts to every destination. Until then, trigger delivery from `/settings/reports` using **Run Now**, or invoke the run-now endpoint at `/api/v1/reports/templates/[id]/run-now` directly. View the persisted template at `/settings/reports`.
### Which data sources are sent?
Each dashboard declares its source list in the dashboards-to-report-template bridge:
| Dashboard | Data sources |
| ------------ | ---------------------------------------------------------------------------------------------------------- |
| Executive | `offer_performance`, `channel_effectiveness`, `revenue_trend`, `anomaly_candidates`, `selection_frequency` |
| Business | `offer_performance`, `channel_effectiveness`, `revenue_trend`, `funnel` |
| Operations | `daily_trend`, `decision_traces_summary` |
| Model Health | `selection_frequency`, `anomaly_candidates` |
| Data Health | `daily_trend` |
| Attribution | `offer_performance`, `channel_effectiveness` |
Every source is tenant-scoped — the API enforces tenant context and filters every database query by tenant.
***
## Related
C-suite summary with narrated weekly highlights and KPI deltas.
Templates, schedules, formats, and delivery — the engine behind Save-as-Report.
Forensic tracing for debugging qualification and ranking.
Operator-grade reference for the post-W10 metrics with PromQL alert expressions.
Understand the scoring models tracked by Model Health.