Feature Request: Partial Exit Analytics — Hit Rates, Conditional Rates & Avg Exit per Partial

[electricar]

I created this text with the help of AI to make it as comprehensive as possible.
I'm wondering what you think about it, please let me know.

Background:

TradeTally stores individual partial executions in the executions[] array for every trade. This data is currently only used to calculate aggregate P&L and average exit price. Traders using partial exit strategies need to understand how each partial position performs across many trades — which partials are profitable, how often price reaches each level, and whether the final runner is being managed effectively.

All required data already exists in TradeTally. No new data entry is needed.

Worked Example:

Consider this single MES trade stored in TradeTally:
Entry: buy 12 MES @ 6000.00
stopLoss: 5992.50 (= −7.5 pts)

executions:
sell 3 @ 6007.00 ← P1, +7.0 pts
sell 2 @ 6017.00 ← P2, +17.0 pts
sell 1 @ 6050.00 ← P3, +50.0 pts
sell 6 @ 6000.25 ← P4, +0.25 pts (BE)

From this single trade, the feature derives:

• P1: profitable (+7.0 pts, R = +0.93)
• P2: profitable (+17.0 pts, R = +2.27)
• P3: profitable (+50.0 pts, R = +6.67)
• P4: BE/scratch (+0.25 pts ≤ 1 tick threshold)

Across 20 such trades, the feature aggregates these into the analytics table below.

What Should Be Calculated:

For each partial index (P1, P2 … Pn) across a filtered set of trades:

1. Absolute hit rate

Trades where Partial n was profitable ÷ trades with at least n partials

2. Conditional hit rate (P2 onwards)

Trades where Partial n was profitable ÷ trades where Partial n−1 was profitable

This distinguishes whether a later partial underperforms because the entry is weak (low P1 rate) or because price stalls between partials.

3. Exit breakdown per partial

• Count: Profitable / BE/Scratch / Loss
• Avg exit in pts — all exits
• Avg exit in pts — profitable exits only
• Avg R at exit — all exits (only where stopLoss is set)
• Avg SL in pts — average stop distance across eligible trades for that partial (derived as abs(entryPrice − stopLoss), only where stopLoss is set)

How to Derive Partials from Existing Data:

For each trade:

1. Filter executions to exits only: action = sell for long, action = buy for short
2. Sort exit executions by datetime ascending
3. Assign partial index: first exit = P1, second = P2, etc.
4. Calculate pts from entry:

• Long: exit_price − entry_price
• Short: entry_price − exit_price

5. Classify each exit:

• Profitable: pts > instrument tick size
• BE/Scratch: pts within ±1 tick of zero
• Loss: pts < −1 tick

Tick size: 0.25 pts for MES, ES, MNQ, NQ. Use stored instrument tick size where available.

Handling Mixed Partial Counts:

Trades in the same filter set may have 2, 3, or 4 partials. Apply one uniform rule:
For partial index Pn, the eligible trade set = all trades with at least n exit executions. The denominator for Pn = count of those eligible trades.

Example with 20 trades (some with 2, some with 3, some with 4 partials):

• P1 eligible: 20 trades (all)
• P2 eligible: 20 trades (all had at least 2 exits)
• P3 eligible: 11 trades (only those with 3+ exits)
• P4 eligible: 6 trades (only those with 4 exits)

No special role labels (first/middle/last) needed. The same formula applies to every partial index. Optionally add a subtle "last" badge to the row where the partial represents the final exit in the majority of its eligible trades — visual only, no separate logic.

Display Format:

Reading this table: the P4 row with 0% profitable exits and 75% BE/scratch immediately reveals that the runner is never capturing a profit — it sits at breakeven and never trails. The Avg SL column lets traders verify whether their stop distance is consistent across partials and over time, and whether it differs between setups or sessions.

• Trades without stopLoss: show pts columns, leave R and Avg SL columns blank
• Trades with only 1 exit execution: exclude entirely
• "last" badge is visual only

Filter Dimensions:

All metrics filterable by:

• Instrument / underlying asset
• Date range
• Strategy
• Any existing trade tag
• Number of partials (e.g. "only trades with exactly 4 partials") — useful for analysing a specific structure in isolation

Why This Matters:

Without this feature, traders must manually export the JSON backup and process executions[] externally. With 83 trades and 206 individual execution rows already stored in a typical TradeTally export, this analytics view would be immediately populated with zero additional input from the user.

No new fields, no new data entry, no changes to the import pipeline are required.

[electricar]

Here is additional information on how the values in the table are calculated:

Worked Example — Aggregated Table Across 20 Trades:

Assume 20 MES trades all with 4 partials and avg SL of 7.5 pts. Here is how each cell in the summary table is calculated:

P1 row:

20 trades had at least 1 exit → eligible = 20

6 exits were profitable (pts > 0.25), 11 were BE, 3 were losses

Abs hit% = 6 / 20 = 30%

Cond. hit% = n/a (no previous partial)

Avg exit pts (all) = sum of all 20 P1 exit pts / 20 = +1.59 pts

Avg exit pts (profit) = sum of 6 profitable P1 exits / 6 = +7.0 pts

Avg R (all) = 1.59 / 7.5 = +0.21R (shown as +0.27 in table due to per-trade R averaging)

Avg SL = sum of SL pts across 20 trades / 20 = 7.5 pts

P2 row:

20 trades had at least 2 exits → eligible = 20

3 exits profitable, 14 BE, 3 losses

Abs hit% = 3 / 20 = 15%

Cond. hit% = trades where P2 profitable AND P1 profitable / trades where P1 profitable = 3 / 6 = 50% (meaning: when P1 hits, P2 hits half the time)

Avg exit pts (all) = +1.42 pts

Avg exit pts (profit) = +12.67 pts

Avg R = +0.20R

Avg SL = 7.5 pts (identical to P1 — same eligible trade set)

P3 row:

Only 11 trades had at least 3 exits → eligible = 11

1 profitable, 9 BE, 1 loss

Abs hit% = 1 / 20 = 5% (denominator stays total trades = 20 for comparability)

Cond. hit% = trades where P3 profitable AND P2 profitable / trades where P2 profitable = 1 / 3 = 33%

Avg exit pts (all) = +0.89 pts

Avg exit pts (profit) = +13.0 pts

Avg R = +0.12R

Avg SL = 7.2 pts (slightly different — only the 11 trades with 3+ partials, which happened to have tighter stops)

P4 row (last):

Only 6 trades had 4 exits → eligible = 6

0 profitable, 5 BE, 1 loss

Abs hit% = 0 / 20 = 0%

Cond. hit% = 0 / 1 = 0% (P3 was profitable in only 1 trade, P4 was never profitable)

Avg exit pts (all) = −0.71 pts (the 1 loss drags below zero)

Avg exit pts (profit) = n/a (no profitable exits)

Avg R = −0.14R

Avg SL = 7.8 pts (the 6 four-partial trades happened to have slightly wider stops)

[GeneBO98]

This has been implemented and pushed to the develop branch.

New page: /metrics/partial-exits (accessible from the Metrics dropdown in the navbar)

What it does:

• Analyzes each partial exit level (P1, P2, P3, etc.) across your filtered trades
• Shows absolute hit rate, conditional hit rate (P2+), profitable/BE/loss counts, avg exit in pts, avg exit for profitable only, avg R-value, and avg SL distance
• Derives everything from existing execution data — no new data entry needed
• Supports all standard trade filters plus min/max partials filter
• Only includes trades with 2+ exit executions
• "last" badge shown on the partial index where most eligible trades end

Available in the nightly Docker image once the build completes.

[electricar]

Hello Brennon,
thank you so much for implementing this!
Unfortunately I was extremely busy with work this week.
Sorry for my late reply.
I will look into it this week.

[electricar]

It seems that everything is implemented exactly as requested, thanks a lot!
What would be useful is to add a configurable filter, e.g. "hide partials with fewer than x eligible trades".
E.g. currently I have 1 trade which has 12 executions.
This is statistically meaningless and visually noisy.

[GeneBO98]

Added a Min Eligible Trades filter to the Partial Exit Analytics page. This lets you hide partial index rows (P3, P4, etc.) where the sample size is too small to be statistically meaningful.

How it works:

• New dropdown filter alongside the existing Min/Max Partials filters
• Threshold options: Any, 2, 3, 5, 10, 15, 20, 25, 50
• Rows where eligible_trades is below the threshold are hidden from the table
• The "Partial Indices" summary stat updates to reflect visible rows
• Contextual empty state message when all rows are filtered out

This is a client-side filter — no additional API calls needed since the eligible trade count is already returned in the response.

Available now in the nightly build.

[electricar]

Yes, it's working. Thank you!