[BUG] Trade-analysis metrics in reports are wrong (computed from returns)

[swordzonked]

QuantStats currently takes a returns/equity series only. Properly supporting trade metrics would require accepting trade-level input alongside returns, which is a bigger change.

Until QuantStats handles trade data alongside returns, any metric that assumes trade data should not be used in reports/metrics because the results are totally wrong.

A returns series cannot reconstruct trade win/loss distribution, streaks, payoff, profit factor, etc.

Please remove these metrics from reports.py / report.html (returns-only context):

• Max Consecutive Wins / Losses
• Gain/Pain Ratio, Gain/Pain (1M)
• Payoff Ratio
• Profit Factor
• Common Sense Ratio
• CPC Index
• Tail Ratio
• Outlier Win Ratio / Outlier Loss Ratio

And remove dependent metrics too:

• Kelly Criterion
• Risk of Ruin

(For reference: a fork, quantstats_lumi, already removed these trade-assuming metrics, which matches the returns-only limitation.)

Chris

[ranaroussi]

Thank you for this detailed analysis. You raise valid points about the distinction between trade-level metrics and return-series metrics.

Clarification on current implementation:

The metrics you mention (Max Consecutive Wins/Losses, Payoff Ratio, Profit Factor, Kelly Criterion, etc.) are computed from the daily returns series, not from trade-level data. This is by design, as QuantStats is a returns analysis library, not a trade journal.

When computed from returns:

• Consecutive Wins/Losses: Counts consecutive positive/negative return days
• Win Rate: Percentage of days with positive returns
• Payoff Ratio: Average positive return / average negative return
• Profit Factor: Sum of positive returns / sum of (absolute) negative returns
• Kelly Criterion: Optimal position sizing based on daily win rate and payoff ratio

These are valid metrics for returns analysis, but their interpretation differs from trade-level metrics:

• For daily returns: they measure day-over-day performance characteristics
• For trade-level data: they measure per-trade performance characteristics

Options going forward:

1. Improve documentation: Add clearer documentation explaining that these metrics are computed from returns, not trades
2. Rename metrics: Consider adding "Daily" prefix (e.g., "Daily Win Rate") to make this clearer
3. Add trade-level support: Accept optional trade-level data for computing "true" trade metrics

We're documenting this as a valid clarification issue. The metrics behave correctly for their intended purpose (returns analysis), but better documentation would help users understand what they're measuring.

Would you prefer option 1 (better docs), option 2 (clearer naming), or both?

[ranaroussi]

Thanks for raising this concern, Chris. After reviewing the implementation, here's my analysis:

Assessment

The claim is partially valid but overstated.

What the code actually does:

• consecutive_wins/losses - counts consecutive positive/negative return periods, not discrete trades
• win_rate - percentage of periods with positive returns
• payoff_ratio - avg winning return / avg losing return per period
• profit_factor - sum of positive returns / sum of negative returns

The metrics ARE valid for:

• Systematic/algorithmic strategies with daily rebalancing (each day IS effectively a trade)
• Return-series analysis (which is QuantStats' purpose)
• Same methodology used by Sharpe, Sortino, and other standard return-based metrics

The metrics could be misleading for:

• Discretionary traders with multi-day trades (a 5-day trade might have 3 up + 2 down days)
• Users expecting trade-level statistics from a trade journal

Our position:

Rather than removing these metrics (which would eliminate genuinely useful information for systematic traders), we'll clarify in documentation that these are period-based metrics, not trade-based metrics.

The docstrings already specify "consecutive winning periods" rather than "trades", but we'll add a note to the README to make this distinction clearer for users.

This is consistent with how other portfolio analytics libraries handle return-series analysis - they operate on return periods, not discrete trade entries/exits.