Backtest analytics dashboard: where the calculation breaks
Typical picture: a strategy is run in a notebook, metrics are put into a table, the next version goes into a new tab with a different name. A month later, no one can say what the returns, drawdown, and number of trades were for the configuration discussed last week.
Disparate strategy calculations diverge not because someone made a mistake, but because each run has its own logic for accounting for commissions, slippage, and data period.
Divergence in testing results shows up late: two analysts launch the same set of rules and get different return curves.
The reason lies in details that are not recorded anywhere: position size rounding, the order of signal processing within a bar, funding rate recalculation, instrument selection in the sample.
Until these details are gathered in one place, comparing strategies turns into a debate about methodology rather than the quality of the hypothesis.
The bottleneck in calculations is not run speed, but the absence of a single layer where the result is stored together with parameters, data version, and cost composition.
Because of this, decisions are made on an incomplete picture: final return is visible, but not what produced it or how the strategy will behave when costs shift.
This leads to a typical failure: a hypothesis is discarded or, conversely, put into production based on a number that cannot be reproduced.
The backtest analytics dashboard closes exactly this gap: calculations become reproducible, metrics become comparable across runs, and discrepancies are visible immediately, not after a week of reconciliations. Below we break down how this is structured.
What a unified calculation panel provides: effect and metrics
Strategy decisions are made not from a single run, but from a series of runs on different data windows.
While calculations live in disparate scripts and tables, every follow-up question from an analyst requires an environment to be rebuilt, and two strategy versions can only be compared manually — and that takes days.
A unified panel removes this layer. Every run goes into a shared log: dataset version, configuration, instrument composition, and metrics — return, maximum drawdown, recovery time, share of profitable trades — are tied to it and are not lost between iterations.
Intermediate layers are calculated incrementally and stored in columnar Parquet, so new slices across thousands of runs are assembled in minutes, without a full recalculation from scratch.
Measurable effect: rerunning a set of strategies is reduced from hours to minutes, manual operations — exports, table consolidation, reconciliation — leave the process, and the share of calculations reproducible to the last digit on rerun approaches complete.
The same input data produces the same result, and divergence in metrics between runs stops being a mystery.
Drawdown and risk are visible before money goes into the strategy: the panel shows the return curve, depth and duration of decline, contribution of individual instruments, and correlation between strategies.
Threshold values are set in advance and highlighted when exceeded, so discussion of risk proceeds using the same numbers for the analyst, risk manager, and client.
Panel assembly options: comparison of approaches
The backtest analytics dashboard is a presentation layer on top of recalculations: return curve, drawdown, trade distribution, impact of commissions and execution delays.
The assembly method determines what the team maintains itself and what is delegated to a ready-made environment, and how quickly a metric reaches the report after a change in strategy logic.
The choice comes down to three questions: how non-standard the metrics are, how often the data schema changes, and who is responsible for discrepancies in the numbers. The answers almost always lead to one of three options.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made presentation layer | Standard metrics, result needed quickly | Non-standard calculations hit the platform ceiling; the data schema is dictated by the vendor |
| In-house panel | Unique metrics, need control over recalculation and access | Longer launch; the storage layer, update regulations, and support are on the team |
| Hybrid option | A ready-made visualization layer plus your own calculation layer for metrics | Data contracts between layers must be coordinated, otherwise discrepancies silently accumulate |
The practical criterion is simple: look at where the responsibility of the ready-made presentation layer ends.
If disputed metrics are calculated outside it, and the panel only shows the result, the hybrid option saves months of work; if all calculation logic is inside, an in-house build is more predictable.
In any case, we record what remains on your side: data source, recalculation regulations, and access rules.
How we assemble the panel: stages of engineering work
The backtest analytics dashboard usually breaks not on charts, but on data: missing candles, different time zones across sources, discrepancies between node history and exchange archive.
Therefore, implementation stages go from sources to the presentation layer, not the other way around — each next step relies on the established quality of the previous one.
- Data source audit. We verify the depth and completeness of history, time zones, handling of gaps and reorgs, record discrepancies between sources, and choose the primary one.
- Calculation schema. We describe metrics — return, drawdown, commissions, and slippage — and aggregation rules by instrument and period, so that identical runs produce identical numbers.
- Storage layer. We lay out raw and aggregated data across levels and set up incremental recalculation: a restart does not require a full rebuild of history.
- Dashboard assembly. Comparison of runs on one screen, filters by period, instrument, and strategy parameters, export for external analysis.
- Results verification. We reconcile calculations against a reference on control sets, run edge cases: empty run, short history, sharp price gap.
- Solution handover. Access, documentation on metrics, recalculation regulations, and training for your team — the panel remains operational without us.
What we hand over: configurations and regulations
The backtest analytics dashboard is not only charts on a screen.
A month after launch, no one will be able to distinguish a change in the strategy itself from a loading failure unless it is recorded where data comes from, how metrics are calculated, and under what conditions history is recalculated.
Therefore, the handover package is a set of artifacts by which the system can be reproduced, verified, and maintained further without us.
- Calculation configurations — run parameters (period, commissions, slippage, candle alignment interval, method for accounting for partial entries and exits) are moved into version-controlled files rather than hardcoded: any run is reproducible from the saved set of settings.
- Data schemas — description of trade, candle, and aggregated metric tables: keys, granularity, relationships, source of each column, and gap handling rule, so that a discrepancy can be localized to a specific field.
- Recalculation regulations — the procedure for updating when history is backfilled: which aggregates are calculated incrementally, which are rebuilt entirely, how reproducibility of the result is ensured when rerunning on the same data.
- Access policies — roles at the strategy and trade set level, visibility separation between teams, user action log, and the procedure for granting and revoking access when team composition changes.
- Metric documentation — formulas and assumptions for each value on the dashboard: return, drawdown, Sharpe ratio, share of profitable trades. This removes the main source of disputes — different interpretations of the same number.
- Support regulations — what to do when reconciliation diverges, how changes to the source schema are coordinated, who is responsible for restarting, and within what timeframes typical failures are resolved.
- Deployment instructions — assembly and launch in the customer's environment, backup procedure, restoration from a database state snapshot, and a verification scenario confirming that the restored copy calculates the same numbers.
Each item is checked at acceptance according to a pre-agreed scenario: deploy from scratch, run a test period, reconcile metrics against the reference, revoke access, and confirm that visibility changed. Such a checklist turns handover from transferring files into transferring a working system.
Case study: how strategy recalculation was accelerated and discrepancies were removed
What it was
The client is a team of quantitative strategies on blockchain markets: dozens of rules, each calculating return, drawdown, and turnover under its own conditions. Reports were assembled manually: export from run logs, merging in a table, charts in a separate panel.
A full recalculation took about six hours, and metrics on the dashboard and in logs diverged — a desynchronization of time zones and rounding produced a drawdown deviation of several percent.
What was changed and what became
Run results were consolidated into a single time-series storage on ClickHouse, manual merging was replaced by a calculation pipeline: for each new run, only the affected interval is updated, and the dashboard reads ready-made marts instead of full recalculation on open. A unified metric layer brought to a single time scale removed the source of discrepancies itself.
Full portfolio recalculation was reduced from six hours to eleven minutes, manual operations per report release — from two dozen to zero.
A whole class of errors — "the number on the chart does not match the log" — disappeared: reconciliation of the backtest with the actual run matches, and drawdown deviation remains within rounding.
What to do if backtests already live in spreadsheets?
Yes, we migrate them — a spreadsheet is already almost a data model, except calculations rest on manual formulas and are therefore not reproducible.
The same set of parameters, recalculated on another day, gives a different result: the wrong reference was extended, the instrument slice was updated in the middle of the run.
Migration of calculations proceeds layer by layer: reference data — instruments, horizons, parameter sets — is moved into dimensions, and result rows are loaded as facts.
Formulas move into the calculation core, and the backtest analytics dashboard reconciles the new run with the old one on historical slices: the same return curve, the same risk metrics.
Preserving history is a mandatory condition; past results are not recalculated. They are loaded as an archive layer with a source label, and the dashboard shows them next to new runs in the same view.
"Before and after" comparison remains possible, and previous conclusions do not lose force.
A smooth transition is a parallel period: for some time, calculations run both in spreadsheets and in the new environment, and discrepancies are reconciled on control slices.
If deviation in a key metric is above a specified threshold, the switch is paused and the cause is investigated.
At the same time, we keep exports in the familiar form — the same columns and order, so external reporting does not break. Spreadsheets are then used only for one-off checks.
Technical doubts: frequent questions about the panel
Technical doubts about the panel come down to four points: whether there is enough history, whether the calculation will repeat on restart, how to connect a new source, and what happens to the panel after handover. We answer directly.
Is there enough historical data?
The panel calculates coverage by each instrument and period and shows gaps explicitly rather than smoothing them over. Gaps due to trading halts and loading failures are marked separately, and a metric on an incomplete window is flagged as low confidence.
Will the calculation repeat on restart?
Each run has an identifier, configuration version, and link to an input data snapshot. Restarting on the same snapshot produces the same result down to trade order, and discrepancy is localized by calculation steps. Assumptions — commissions, slippage, order execution rule — are recorded next to the result.
How to connect a new data source?
The source is connected by a loader for its format: column mapping, time zone, units of measurement, handling of duplicates and gaps.
Then it passes reconciliation at the intersection with already loaded history, and if the discrepancy is above tolerance, it goes into quarantine rather than substituting data in the panel.
What is included in panel support?
We hand over the regulations: monitoring loading delays, checking data freshness, alerts on calculation anomalies, and a reference set for regression checks. Adding a metric or changing the schema does not break history — past runs remain reproducible.
Let's discuss the task: what we need from you and what we do
To come back with an estimate and plan rather than general wording, we need context on the data and on the decisions you make based on numbers. Let's divide preparation: part falls to your side, part to us immediately after the conversation.
- List of strategies or models being compared, and their run parameters.
- Historical data sources: where quotes come from, in what form they are exported, what history depth and candle frequency are needed.
- Already calculated backtest results — tables, exports, column names, and units of measurement.
- Metrics by which you evaluate a strategy: return, drawdown, share of profitable trades, turnover.
- How reporting is currently assembled: manual exports, scripts, regular calls between the analyst and you.
- Who will view the dashboard and what decisions are made based on it — stop a strategy, increase allocation, change parameters.
Then we work: we analyze the source data, check history completeness and discrepancies between sources, fix metrics and slices — and only then calculate.
- Screen composition: which metrics, periods, and views will go onto the backtest analytics dashboard.
- Data update format and recalculation rules when new runs appear.
- Estimate and plan: stages, stage timelines, and what is needed from you at each of them.