Monitor platform health, business performance, data quality, model accuracy, and channel attribution from five purpose-built dashboards.
KaireonAI ships with five 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.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?
Path:/dashboards/operationsThe Operations Dashboard is the primary system-health view for platform engineers. It answers: Is the decisioning engine running fast and correctly?
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.
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.
Suppose you notice offer_summer_promo dropped from 12% to 3% acceptance overnight. Here is how to investigate:
Check the Decision Pipeline panel. If “After Qualification” is normal but “After Contact Policy” drops sharply, a new frequency cap is filtering aggressively.
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.
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.
Path:/dashboards/businessThe Business Dashboard answers: How are my offers performing? Designed for analysts and marketers who need to track conversion rates, channel effectiveness, and revenue.
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.
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.
Path:/dashboards/model-healthTracks scoring model status, accuracy trends, and experiment activity. Designed for data scientists monitoring model performance.
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.
Source:GET /api/v1/treatments/uplift?windowDays=NPer-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.
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.
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.
Source:POST /api/v1/models/[id]/driftInteractive 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.
Path:/dashboards/attributionMulti-touch attribution analysis comparing how different models distribute credit across channels. Helps answer: Which channels actually drive conversions, and how should I allocate budget?
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
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.
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.
Six of the Business and Operations dashboard queries accept an optional segmentId query parameter to scope their aggregation to customers in a specific segment. When provided, the underlying SQL joins the segment’s materialized view (seg_<id_prefix>) 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=<id> 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.
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.
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 (optional).
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.
