Backtesting trading strategies starts with market-data quality

A backtest is an evidence chain, not a verdict

A backtest asks a conditional question: what would this exact rule set have done on this exact historical dataset under these execution assumptions? It does not prove that the same outcome will occur again. Treating the run as an evidence chain keeps attention on the inputs and decisions behind the result rather than on one attractive metric.

The chain begins with data identity. Venue, market, interval, date range, timezone, and field definitions all affect what the rules see. Missing candles, duplicated rows, stale periods, or an unexplained symbol change can shift entries and exits. The practical overview of research datasets and quality fields shows why coverage, gaps, schema, and sample rows belong in the review before a strategy is tested. Researchers can also review the historical crypto and Polymarket data packages for backtesting when choosing the input for a study.

Pre-run checklist

Write down the research question first, then freeze a baseline configuration. Before starting a run, verify:

• The venue, symbol, interval, timezone, and date range are explicit.
• Coverage is measured and every known gap is located, not just counted.
• Price and volume fields have clear meanings and consistent units.
• Indicator lookbacks fit inside the available warm-up period.
• Entry, exit, and position-state rules are unambiguous.
• Signal timing states whether decisions use a completed bar or intrabar information.
• Fees, spread, slippage, and fill timing are stated, even when the baseline sets one to zero.
• The primary metric and the main risk constraint were selected before results were viewed.

The backtesting overview organizes these concerns around inputs, evidence, and review. If the rule itself is still vague, first use the companion guide to make strategy logic inspectable.

Methodical example: test one claim at a time

Suppose the research claim is: “A close above a moving average, after being below it, may identify a trend transition.” This is a hypothesis, not a promise. A reproducible test can be designed in six steps:

1. Define the data. Select one market, one interval, and a fixed historical window. Record the data source and inspect gaps before calculating the average.
2. Define the signal. Entry requires the previous completed close to be at or below the average and the current completed close to be above it. This prevents “above” from being confused with “crossed above.”
3. Define the position rule. State whether a new signal is ignored while a position is open and what event closes the position. Conflicting entry and exit signals need a deterministic priority.
4. Define execution. Decide whether the hypothetical fill occurs at the signal close or the next available bar, and apply the same fee and slippage assumptions to every variant.
5. Inspect events. Review several entries and exits against the underlying bars. A plausible summary cannot rescue events that were generated with future information or the wrong timestamp.
6. Separate evaluation. Use one period to form the rule and a later untouched period to evaluate it. Do not keep editing the rule against the evaluation period.

This sequence follows the broader Umbre research methodology: define, inspect, simulate, and compare. It also creates a short audit trail someone else can challenge without guessing what “moving-average strategy” meant.

Read the result in layers

Start with validity, then interpretation. Confirm that the run completed on the intended data and that trade events obey the stated logic. Next, inspect counts, returns, drawdown, and individual outcomes together. A result based on very few trades needs different caution from one spread across varied market conditions. An average can also hide whether losses are clustered in one period or data gap.

Only then compare alternatives. Change one assumption at a time and label the change. If many parameters are searched, examine a neighborhood rather than celebrating one isolated setting. The sweetspot analysis overview explains the difference between a lone optimum and a broader, more stable region. That comparison is a robustness check, not evidence that the region will remain profitable.

Limits every conclusion should state

• Historical data contains only conditions that actually occurred; it cannot represent every future regime.
• Candle data compresses intrabar paths, so some stop, limit, and ordering questions cannot be reconstructed exactly.
• Fee, spread, slippage, latency, and liquidity assumptions simplify real execution and can be wrong.
• Repeatedly selecting rules or parameters on the same period creates selection bias and overfitting.
• Missing markets, delisted assets, or changing symbol definitions can introduce survivorship and mapping bias.
• A clean backtest measures the chosen model consistently; it does not validate the economic reason behind the idea or provide financial advice.

Final review checklist

Before sharing a conclusion, confirm that the dataset identity and gaps are recorded, the rule and execution assumptions are versioned in plain language, representative trades were inspected, and an untouched period was retained. Note which neighboring settings were checked, what failed, and which limitations could change the interpretation. A useful backtest is one that another researcher can reproduce, question, and reject—not merely one with an appealing headline number.