Backtesting guide

Backtest Trades: How to Analyze Individual Trade Results

Backtest trades are simulated entries and exits produced by applying trading rules to historical data. Review the individual records to check whether the implementation matches the rules and whether a few trades dominate the result. They are not evidence of actual broker fills.

Read the practical guide

Key Takeaways

  • Reconcile imported records with the original report before calculating metrics.
  • Keep event order for sequence analysis and a separate profit-sorted view for outliers.
  • Loss streaks and extreme metrics prompt investigation; they do not prove a cause.
  • No fixed trade count certifies reliability or rules out overfitting.

Start with the trade definition and the original report

Establish whether a row represents an order fill, a closed trade, or a complete position. Scaling in and partial exits can create several records for one trading idea. Keep the original export, strategy version, symbol, timezone, dates, and cost settings together. Compare imported trade counts and total profit with the source report before analyzing derived metrics. TradingView provides simulated trade details and an export option. Check the format offered by your current interface: its strategy documentation describes XLSX downloads, while its export help page describes CSV. Do not assume an analysis tool accepts either format. Indicator values at entry are not guaranteed fields in the default trade export.

  • Check entry and exit timestamps, direction, quantity, prices, and profit units.
  • Separate open positions from closed trades and preserve partial-exit relationships.
  • Confirm whether fees are already included before subtracting costs again.

Reconcile suspicious trades with the simulation settings

Inspect entries and exits around gaps, session boundaries, and bars where both a stop and target could have been reached. Compare the order creation time with its simulated fill time. TradingView uses a broker emulator; its calculation settings, available intrabar data, and order assumptions affect the result. A bar gap or partial exit alone does not establish a data error. Review position size as well as prices. Margin requirements, capital constraints, liquidation, and equity-dependent rules can change which trades occur. Increasing risk is not guaranteed to preserve the same trade list. Record any implementation correction before making a new performance comparison.

Use a chronological copy and a profit-sorted copy

Keep one copy ordered by the relevant event time to inspect losses and overlapping positions. Use another sorted by profit to identify outliers. Do not calculate drawdown from a profit-sorted list. When positions overlap, entry order and realized exit order can differ; account equity also includes unrealized gains and losses. For an arithmetic illustration, 90 wins of $50 and 10 losses of $500 produce gross profit of $4,500, gross loss of $5,000, and profit factor 0.9. Forty losses of $100 and 10 wins of $800 produce profit factor 2.0 with a 20% win rate. These are hypothetical distributions before any additional costs. Summary win rate and profit factor already distinguish them; the individual records add sequence, duration, and the location of large outcomes.

Treat loss clusters as questions to test

Consecutive losses can occur even when outcomes are independent. A cluster does not prove a defective trading session or market regime. Inspect possible associations with volatility, direction, liquidity, and time of day, then document how many explanations or filters you tried. A time filter selected after viewing the largest losers has already used that history for selection. Keep the original baseline and evaluate the revised rule on data not used to choose the filter. Removing difficult historical trades is not evidence that future drawdown will fall.

There is no universal minimum trade count

The uncertainty of a metric depends on the distribution, dependence between trades, period covered, and selection process as well as sample size. Thirty, 100, or 500 trades does not certify reliability. A large sample of overlapping trades in one regime can still contain little independent information. Report sample size and dates, inspect how much profit comes from the largest outcomes, and state the assumptions behind any confidence interval. An extreme profit factor or win rate deserves investigation, but no numerical threshold by itself proves overfitting. Changing the dataset, strategy, or sizing rule requires a new test rather than a promise of the same outcomes.

Using the Pineify Backtest Report

The report analyzes a compatible CSV trade export; it does not reconstruct broker execution or accept every spreadsheet layout. Its current importer groups records by trade number, uses the first recognized entry and exit within each group, and sorts trades by entry time. Check partial exits and overlapping positions against the original report before relying on sequence-based statistics. Missing fields can become zero values, so a calculated metric is not proof that the input was complete.

Primary sources

This page is educational. Backtests depend on historical data and simulation assumptions and do not guarantee future returns. Trading can result in substantial loss.

Frequently Asked Questions