My range_bottom_reclaim screen ran 220,000 configs per pair-family across 386 symbols. After the GPU screen and a CPU verification pass, 50 configs across 4 coins made it to my deep-test shortlist β the same shortlist behind my hour-of-day post and stop-loss firing-rate post. Eight of those 50 rows are the same coin, ARIAUSDT, with slightly different parameters. Sorting them by net profit, two rows sit almost on top of each other in money terms and nowhere near each other in win rate.
The two configs
| Parameter | Config A | Config B | Difference |
|---|---|---|---|
| base_tp_pct | 1.468 | 1.484 | +1.1% |
| dca1_pct | β1.308 | β1.287 | +1.6% |
| tp_after_dca1_pct | 0.144 | 0.128 | β11.1% |
| final_invalidation_pct | β3.513 | β3.498 | +0.4% |
| time_stop_min | 120 | 120 | same |
| Win rate | 89.2% | 48.2% | β41.0 pts |
| Net profit | $431.92 | $430.27 | $1.65 |
| Profit factor | 1.71 | 1.73 | B slightly higher |
| Expectancy | 0.270 | 0.269 | 0.001 |
| DCA1 rate | 47.4% | 48.2% | 0.8 pts |
| Avg hold / Max MAE | 38.6m / β5.3% | 38.1m / β5.3% | identical |
1,600 trades per config, same ARIAUSDT price history, same entry rule (range_bottom_reclaim), same GPU deep-test verification pass.
Where the 41 points actually came from
The parameter that moved the most between the two configs is tp_after_dca1_pct β the take-profit target applied after a trade has already taken its first DCA add. Config A sets it at 0.144%, Config B at 0.128%, an 11% relative difference on that one knob while every other parameter moved by 2% or less. That's a tight target either way. Tight enough that a large batch of trades resolving in the 0.13%-to-0.14% zone flip from "closed for a small win" to "closed for a small loss" depending on which side of that line they land.
Those flipped trades are, almost by definition, close to breakeven. They don't move net profit much because they were never carrying much profit or loss to begin with β a few cents each, multiplied across roughly 650 trades' worth of win-rate gap on a 1,600-trade sample. What they do move is the win/loss column, because win rate counts every trade above zero the same as every trade that hit full take-profit, and every trade below zero the same as a full stop-out.
If I'd sorted this shortlist by win rate
I'd have kept Config A and thrown out Config B. 89.2% looks like a materially better strategy than 48.2% β it's the kind of gap that would make me stop looking at the rest of the row. But Config B's profit factor (1.73) is marginally higher than Config A's (1.71), its expectancy is within 0.001 of identical, and its net profit is $1.65 lower on 1,600 trades. Every metric that touches actual money says these two configs are the same strategy. Win rate alone said one of them was almost twice as good.
This is the same trap I found with MEGAUSDT's 96% win rate and wrote about again in the DCA illusion post β but those were about a high win rate hiding a bad tail risk. This one's simpler and, honestly, more unsettling: here the win rate isn't hiding anything. It's just noise. A 1-2% nudge to a take-profit threshold, and the exact same edge reports a 41-point swing in the metric most dashboards lead with.
What I check now before trusting a win-rate number
I stopped treating win rate as a ranking criterion for anything. It's a diagnostic I read after I've already ranked by net profit, profit factor and expectancy β never before. If two configs on the same coin have similar profit factor and expectancy but very different win rates, that's not a signal one config is better. It's a signal the strategy's exits are sitting close to a threshold, and a live version of it will drift across that same threshold with ordinary price noise, no re-optimization required.
Before I'd size either of these configs with real leverage, I run the trade log through trade expectancy and profit factor directly, not the summary win rate. A config search that optimizes for win rate is optimizing for exactly the number a 1% parameter tweak can manufacture out of nothing.
What to check before trusting a win-rate comparison
- Rank by net profit and expectancy first, win rate last. Two configs 1-2% apart on parameters had a 41-point win-rate gap and a $1.65 net-profit gap here.
- Check profit factor alongside win rate, never instead of it. The 48.2% win-rate config had the marginally higher profit factor of the two.
- Watch for exits sitting near a threshold. A small take-profit target close to breakeven is where win rate gets the most fragile to tiny parameter changes.
- Re-run expectancy and profit factor directly on the trade log with trade expectancy and profit factor calculators before trusting a summary win rate.
β Trade expectancy calculator Β· β Profit factor calculator Β· β DCA survival calculator
FAQ
How can two backtest configs have a 41-point win-rate gap but almost the same profit?
Because win rate and profit are counting different things. In my ARIAUSDT range_bottom_reclaim shortlist, two configs with take-profit and post-DCA thresholds within 1-2% of each other landed at 48.2% and 89.2% win rate, net profit of $430.27 and $431.92. The tighter post-DCA take-profit target in the high-win-rate config closed a large batch of scratch trades as small wins right at breakeven, instead of letting them run into the loss column. Same trades, same money, different label.
Which config should I have picked, the 89% win rate one or the 48% one?
On this data, it barely matters, they made the same money. Profit factor was 1.71 vs 1.73, expectancy 0.270 vs 0.269, net profit $431.92 vs $430.27. If I'd filtered my shortlist by win rate alone I'd have kept the 89% config and thrown out the 48% one, but the 48% config's profit factor was actually marginally higher. Win rate would have picked the worse-ranked config by every other metric that touched money.
What does this mean for tuning a trading strategy's parameters?
That a strategy's win rate is fragile to small parameter changes in a way its profit factor and expectancy usually are not. A 1-2% shift in a take-profit or DCA threshold can move win rate by 40 points without moving the money by 1%. If a config search is optimizing for win rate, it's optimizing for a number that a tiny parameter nudge can manufacture, not for an edge.
What should I check instead of win rate when comparing backtest configs?
Rank by net profit, profit factor and expectancy together, and treat win rate as a diagnostic, not a selection criterion. Two configs on the same coin, same rules, can have wildly different win rates and identical money. If a config's win rate changes by double digits after a 1-2% parameter tweak, that's a sign the strategy's edge is sitting right at a threshold, not a sign the new config is better.