Forecasting is live on clariBI. Pick any metric in your workspace, set a
horizon, and let the platform handle the rest: a deterministic projection
with a prediction band, the other series in your account that move with
your target, anomalies on the historical record, and structural breaks in
the trend. It runs on a schedule you control or on demand, ships in the
in-app sidebar, the REST API at /api/v1/forecasts/, and the MCP server
as five new tools.
Forecasting is part of the Starter, Professional, and Enterprise plans. The math is deterministic and runs on numpy, pandas, and scikit-learn, so the result is reproducible and does not consume LLM tokens.
Why we built it differently
Forecasting in BI tools usually lands in one of two shapes. The first is a single hand-picked method (almost always exponential smoothing or ARIMA) applied uniformly to every series. That works on the series the method was designed for and silently fails on the rest. The second shape is the "predict button" stuck onto a chart with no information about how confident the projection is, or what it depends on.
clariBI Forecasting picks a different angle: a forecast is a configuration row, the engine evaluates several methods per series, and every artefact the run produces carries the evidence behind it.
What that looks like in practice:
A run picks a winning method from nine candidates by walk-forward backtest, scored on sMAPE. The winner is reported by name; you can see which methods came second and third, and you can audit the backtest error before trusting the projection.
The projection comes with an 80 percent prediction interval shaded
on the chart as a band. The band width is calibrated from the
backtest error of the winning method: a series the engine forecast
cleanly during the holdout gets a tight band, a noisy series gets a
wide one. The same bounds also ship as lower and upper arrays on
the REST API and MCP response, so you can wire your own alert
thresholds or downstream visualisation off the raw envelope.
Every other numeric series in the workspace is tested for Pearson, Spearman, and cross-lag correlation against the target. The lag search runs up to 14 days, so a leading indicator surfaces as a positive lag even if its same-day correlation is weak. Benjamini- Hochberg adjusts p-values across the candidate pool at q=0.05. Reading the table you get the lag in days, the adjusted p-value, and a stability flag from a 200-iteration bootstrap.
Anomaly detection combines z-scores on the detrended residuals with an IQR fence on the raw values. Each anomaly is labelled mild, moderate, or severe based on the larger of the two scores. The historical chart marks each one on the date it happened, not on some smoothed window.
Structural breakpoints come from segmented OLS with a Chow-style F test. The table reports the slope before and after each break, so when a new pricing change or channel launch rewrote the trend you can put a date on it.
What's bound to what
A forecast attaches to one metric. The "metric" can live in four places:
report metrics use the path inside a generated report's insights
JSON. Each regeneration adds a datapoint. Best for KPIs that are
already computed and presented as part of an existing report.
dashboard widget metrics read from the data source the widget is
bound to. Useful when you have a widget that already shows the right
slice of a source.
goal progress uses the Goal's historical progress entries, either
the raw value or the percentage. Forecast a sales quota's progress
ahead of quarter-end, or a campaign goal's percentage trajectory.
data_source aggregations read straight off the preprocessed time
series clariBI builds when a source connects. This is the path for
raw connector data: Stripe MRR, Google Ads spend, GA4 sessions.
The same configuration drives the in-app view, the public REST API, and the MCP server. There is no second model to keep in sync.
Credit cost is the cost of the work
Per-run pricing is deterministic. The breakdown shows up in the detail page so you can see what each component cost:
cost = 1 # base run
+ (2 if target method not cached) # backtest
+ ceil(correlated_count / 4) # discovered drivers
+ (1 if history_days > 180) # long history
+ (1 if granularity == 'weekly' # weekly long history
and history_days > 365)
floor = 1, cap = 10
A repeat run of a forecast clariBI has already characterised hits the
floor. A first run on a long series with many correlated drivers can
hit the cap. The pricing breakdown is exposed in the in-app run page
and in the estimate-cost API endpoint so you can preview the cost
before running.
On a failure the credits reserved up front are refunded in full and
the run is marked refunded. Three consecutive failures on a
scheduled forecast auto-pause the schedule so it stops burning
credits.
How to start
In the app:
- Open Forecasting in the left sidebar.
- Click New Forecast, pick a source and metric, set the horizon, choose a cadence (default monthly, or daily, weekly, or manual).
- Run it. The detail page shows the projection, the correlated drivers, the anomalies, and the changepoints. Each correlated driver gets its own forecast you can drill into.
From a goal:
Open any goal's detail modal and click Forecast this metric. clariBI reuses an existing forecast for that goal if one exists, otherwise creates one with defaults and lands you on the detail page.
From the REST API:
POST /api/v1/forecasts/
{
"name": "Weekly MRR",
"source_type": "data_source",
"source_id": "...",
"metric_path": "mrr",
"granularity": "weekly",
"horizon_days": 60,
"schedule_frequency": "weekly"
}
Scopes: forecasts:read, forecasts:write, forecasts:run.
From Claude Desktop or Cursor via the MCP server:
The new tools are list_forecasts, get_forecast,
get_forecast_run, create_forecast, and run_forecast. Ask the
client to forecast a metric and it will pick the right tool, run it
synchronously up to 60 seconds, and surface the result envelope
inline.
What it is not
Forecasting is not a recommendation engine, not a causal-inference toolkit, and not a backstop for missing data. It surfaces statistical relationships and projects time series. The "consistency flag" on a driver tells you when the relationship is unstable enough to discount; treat the rest as a hypothesis you can test, not as guaranteed causation.
The projection horizon is capped at 90 days. Long-range forecasts on volatile series carry uncertainty the model cannot fully express in the interval band. Use shorter horizons for fast-moving series.
Where to go next
- The Forecasting feature page has the technical reference and the credit math.
- The knowledge base article walks through binding a forecast and reading the result.
- The REST API reference at
/api/v1/forecasts/covers the public endpoints. - The MCP server reference lists the five new tools alongside the existing catalog.
If you already have a workspace, the new sidebar entry is waiting on your next refresh. If you do not, trial signup takes 60 seconds and includes the full feature set for 14 days.