Page 1 of 1

How many trades per journal tag before comparing buckets: a 0.3R gap needs about 128 each

Posted: Thu Oct 29, 2026 1:30 pm
by Fairman
How many trades per journal tag before comparing buckets: a 0.3R gap needs about 128 each

Journals often get tags: setup type, session, day of the week, pair. The next step is comparing average R between tags, and that is where small samples cause trouble. Here are the numbers, using made up figures to show the method.

Say a single trade has a standard deviation of 1.2R, which is typical for a 1.5R reward and a win rate near 45%. One tag has 17 trades, the other 9. The error on the first average is 1.2 / the square root of 17, which is 0.29R. For the second it's 1.2 / the square root of 9, which is 0.40R. The error on the difference between them is the square root of (0.29 squared plus 0.40 squared), about 0.49R.

Suppose the first tag averages +0.30R more than the second. That gap is 0.30 / 0.49 = 0.6 standard errors, which is nothing. A gap needs to be about two standard errors to take seriously.

How many trades does a 0.3R gap need? Set the error on the difference to 0.15R, so that 0.3R is two errors. That means 1.2 x the square root of (2 / n) = 0.15, which gives n = 128 per tag. So 256 trades split in two, to detect a difference of 0.3R.

Most traders have fewer than that for any one pair of tags. So the tags are a way to organise reading and generate questions, not to decide anything on the numbers. A tag with 9 trades and a good average is a good prompt to look at the trades, nothing more.

Re: How many trades per journal tag before comparing buckets: a 0.3R gap needs about 128 each

Posted: Sat Oct 31, 2026 11:54 am
by Fairman
A related trap is the number of tags. If you have 20 tags and compare each with the average, you'll find some that look unusual even if every tag is the same. With a test at roughly two standard errors, there's about a 4.5% chance of a false hit on each comparison, and with 20 comparisons, 1 minus 0.9545 to the power 20 is about 60% for at least one. So finding a tag that stands out among 20 is what chance gives you most of the time. The more tags, the larger the sample you need for the same confidence.

Re: How many trades per journal tag before comparing buckets: a 0.3R gap needs about 128 each

Posted: Sat Oct 31, 2026 12:34 pm
by Fairman
What about using the tags to cut the trades that look worst? Suppose a tag has 30 trades averaging minus 0.3R with an error of 1.2 / the square root of 30, which is 0.22R. That's 1.4 errors from zero, so the interval runs from about minus 0.74R to plus 0.14R. It could be a real loser, and it could be break-even or slightly positive. The cost of dropping it is small, though, if you don't miss much. Costs of error are not symmetric: dropping a tag that's flat loses nothing, so this is a case where the decision can be made on weaker evidence.

Re: How many trades per journal tag before comparing buckets: a 0.3R gap needs about 128 each

Posted: Sat Oct 31, 2026 12:59 pm
by Fairman
Lowering the standard deviation shrinks the sample you need, with the square of the change. A spread of 0.8R instead of 1.2R would cut the need from 128 to about 57 per tag, a factor of 2.25. But the standard deviation comes from the strategy, with its 1.5R winners and 1R losers, so you can't lower it by choosing a different column. If your payoff is a fixed 1R and 1.5R, the spread is what it is, and the only lever left is more trades. That is also why a single month never answers a tag question.

Re: How many trades per journal tag before comparing buckets: a 0.3R gap needs about 128 each

Posted: Sat Oct 31, 2026 1:39 pm
by Fairman
For practical use, I'd keep two numbers beside every tag: the count and the average R. Anything under 30 trades is shown in grey and ignored in decisions. Anything between 30 and 100 is a hint to keep collecting. Only counts above 100 per tag go in the plan, and a comparison between tags needs the 128 or so from the formula for a 0.3R difference. It sounds strict, but a plan built on a tag with 12 trades is mostly built on luck, and the account pays for it later.