September 7, 2026 correction: the previous version contained a broken Gross Loss R formula, treated 100 trades and fixed profit-factor bands as universal rules, implied that a Notion database could establish an edge by itself, and said Notion had no chart view. Those claims are withdrawn. This version gives a copyable database blueprint, separates row formulas from portfolio-level calculations, uses uncertainty instead of a magic sample size, and documents Notion's current chart and export limits.
What Is Manual Backtesting (and What It Is Not)
Notion can be the evidence ledger for a manual backtest; it is not the market-replay engine. A defensible workflow uses one tool to reveal historical bars in sequence, a rule set to decide what qualifies before the outcome is known, and a database to preserve every eligible observation. Notion is strongest in the third role: structured records, formulas, filtered views, relations, rollups, notes, screenshots, and current database charts.
Decision log and research database
Record the historical timestamp, exact setup version, entry decision, stop, target, costs, realized R, screenshot, and whether the row belongs in the locked sample. Then filter the same records by setup, session, instrument, or regime.
Replay or programmatic simulation
Notion does not reveal bars one at a time, reconstruct fills, execute Pine/Python/MetaTrader rules, or supply historical market data. Use a replay platform or code for that work, then keep the decision record in Notion.
That boundary matters. Scrolling a fully revealed chart and marking attractive entries after the move is analysis with hindsight, not a blind test. A replay tool can reduce look-ahead exposure by advancing the chart from a chosen historical point. For example, TradingView documents selectable starting bars and forward controls, while its separate Replay Trading results are available only in that replay session and are not saved. A Notion log can supply the persistent audit trail that the replay session does not.
Checked September 7, 2026 against current Notion database, formula, relation, chart, import, and export documentation; current TradingView Bar Replay documentation; NIST guidance for proportion intervals; and published research on backtest overfitting. Product interfaces and plan limits can change, so verify the linked help pages before rebuilding a large workspace.
Building the Backtest Database
Create one full-page database named Backtest Log. Keep it separate from live trades unless every view has an explicit Data Origin field; otherwise a historical simulation can silently contaminate live statistics. The blueprint below is free to copy. It does not pretend to be a one-click Notion template link: building the properties yourself makes their types and assumptions visible.
Free Notion Backtesting Template: Property Blueprint
| Property | Notion type | What to store | Why it matters |
|---|---|---|---|
| Test | Title | A stable human label such as rule version plus sequence number | Every Notion database needs a title property; do not use the row number as the only identity |
| Test ID | ID or Text | A durable unique identifier | Lets you reconcile exports and detect duplicate imports |
| Historical Time | Date | The market timestamp, including time when the rule depends on intraday context | Separates event time from the date the row was created |
| Instrument | Select or Text | Exact symbol and venue/data source convention | EURUSD, EUR/USD, and broker-suffixed symbols must not split silently |
| Timeframe | Select | The decision timeframe, plus a separate context timeframe if required | A setup tested on M5 is not automatically evidence for H1 |
| Setup Version | Relation or Select | A frozen rule identity such as Breakout v2 | Rule changes create a new sample instead of rewriting history |
| Direction | Select | Long or Short | Makes directional asymmetry testable |
| Session | Select | A timezone-defined session label | “London” without timezone and daylight-saving rules is not reproducible |
| Regime | Select | A rule-defined state, not a label invented after seeing the outcome | Prevents winning trades from being relabeled as “trend” after the fact |
| Rule Match | Checkbox | Whether the candidate met every frozen entry condition before reveal | Keeps rejected candidates visible instead of deleting inconvenient evidence |
| Entry / Stop / Target | Three Number properties | The levels available at decision time | Supports planned-risk arithmetic and invalid-geometry checks |
| Exit | Number | The simulated exit under the frozen management rule | Do not substitute the most favorable later price |
| Net R | Number | Outcome in risk units after modeled costs | Keeps winners, losers, partials, and different account sizes comparable |
| Cost Assumption | Number or Text | Commission, spread, slippage, funding, or an explicit zero-cost assumption | A gross backtest must not be described as net |
| Data Origin | Select | Backtest, forward test, demo, or live | Stops simulated and executed trades from sharing one headline statistic |
| Evidence | Files & media plus URL | Decision-time screenshot and a link or reference to source data | Makes later classification audits possible |
| Notes | Text | The reason for entry, invalidation, ambiguity, and any deviation | Preserves context without turning prose into an untestable rule |
Use controlled Select values for short vocabularies and a relation to a separate Setup Registry when rule versions need their own definitions. Notion's documented Relation property connects pages across databases; Rollup can aggregate a property from those related pages. A Select label is faster to build, while a relation gives every setup version one canonical definition. Choose one deliberately.
Template integrity rule: never overwrite Breakout v1 with v2. Archive v1, create v2, and tag each observation with the version actually tested. Otherwise the summary combines different hypotheses and the result cannot be reproduced.
What to Log for Each Trade Observation
The minimum useful row records what the tester could know at the decision point and what happened under a predeclared exit rule. Capture the candidate before revealing more bars. If a setup is ambiguous, keep the row and mark the ambiguity; deleting it after the loss biases the sample.
- Identity: Test ID, historical timestamp, instrument, data source, timezone, and setup version.
- Decision state: direction, session, regime rule, entry trigger, stop, target, and whether every rule matched.
- Outcome state: simulated fill, exit, gross R, modeled costs, net R, and the exact reason the position closed.
- Audit evidence: screenshot taken before reveal, screenshot after exit, source reference, notes, and any manual override.
- Separation: Backtest, forward test, demo, and live records must remain distinguishable in every exported row.
Session and regime labels are useful only when their definitions are frozen. “High volatility” cannot mean “a day that produced a large winner.” Write a measurable condition first—for example, a declared volatility indicator range at entry—and version the rule when it changes. The same applies to discretionary labels such as clean, strong, textbook, or A+.
Log actual simulated Net R, not only Winner or Loser and not only planned reward-to-risk. A partial exit, time stop, gap, or slippage assumption can turn a planned 2R target into a different result. The outcome label is for filtering; Net R carries the arithmetic.
Calculating Your Edge Statistics
Notion trading formulas calculate a value for each database row. Database calculations and rollups aggregate rows. Keeping those levels separate prevents the common mistake of pasting a portfolio formula into a trade row and assuming it sees the whole table.
Copyable Row Formulas
| Formula property | Formula | Interpretation |
|---|---|---|
| Risk Distance | abs(prop("Entry Price") - prop("Stop Price")) | Price distance only; validate that it is nonzero and that units match |
| Planned R:R | abs(prop("Target Price") - prop("Entry Price")) / abs(prop("Entry Price") - prop("Stop Price")) | Valid only after filtering out missing values and zero stop distance |
| Is Win | prop("Net R") > 0 | Boolean result for percent-checked calculations; zero stays non-winning, not losing |
| Gross Win R | if(prop("Net R") > 0, prop("Net R"), 0) | Positive contribution used in the profit-factor numerator |
| Gross Loss R | if(prop("Net R") < 0, abs(prop("Net R")), 0) | Positive loss magnitude used in the denominator; this repairs the truncated old formula |
Notion's current formula documentation still supports property references such as prop("Number"), comparison operators, arithmetic, and functions including abs(), if(), and list operations. Select property tokens in Notion's formula editor after creating the columns; copied quotation marks or renamed properties are frequent causes of errors.
Aggregate the Sample, Not the Story
Count included rows, then count empty Net R, setup-version, and evidence fields. A large sample with silent blanks is not a clean sample.
This is sample expectancy in R. Report the count and dispersion beside it.
If the denominator is zero, report “not estimable”; do not call the result infinite proof.
Calculate a running cumulative Net R, its prior peak, and the drop from that peak. Longest losing streak is not the same metric.
For a single database, use column calculations such as Count, Average, Sum, or Percent checked and repeat them in filtered or grouped views. For a durable dashboard, connect observations to a Setup Registry and use rollups or Formula 2.0 relation lists. Notion documents relation-list expressions such as prop("Trades").filter(...); that makes a setup-level summary possible, but it still depends on every intended trade being related to the correct version.
Notion now has chart views. The old claim that it cannot visualize a backtest is stale. Current documentation lists line, vertical bar, horizontal bar, donut, and number charts. It also states that paid plans can create unlimited charts while a Free Plan workspace can try one chart, and that a chart displays at most 200 groups and 50 subgroups. A chart of per-trade Net R is not automatically a cumulative equity curve: precompute a running-balance property or export the data to a tool that can calculate it correctly.
How Many Backtest Trades Do You Need?
There is no universal “100 trades proves the strategy” rule. Required evidence depends on the question, win probability, payoff distribution, trade dependence, number of variants tried, regime coverage, and the uncertainty you can tolerate. One hundred tightly clustered trades from one week can contain less independent information than a smaller sample spanning genuinely different conditions.
The table below shows a narrow illustration: if the observed win rate is exactly 50% and trials are independent, a two-sided 95% Wilson interval remains wide even as the row count grows. These are statistical illustrations, not trading thresholds.
| Independent observations | Observed wins | Approximate 95% Wilson interval | What it shows |
|---|---|---|---|
| 25 | About half | 31.8%–68.2% | Very large uncertainty around a 50% point estimate |
| 50 | About half | 36.6%–63.4% | Still too wide for fine distinctions |
| 100 | 50 | 40.4%–59.6% | A familiar count is not a precise estimate |
| 200 | 100 | 43.1%–56.9% | More precision, assuming independence |
| 400 | 200 | 45.1%–54.9% | A roughly ±5-point interval under the stated assumptions |
NIST discusses Wilson and related intervals for proportions; trades add complications that a simple binomial model does not capture. Overlapping positions, repeated signals during one trend, shared news shocks, changing volatility, and adaptive rule changes create dependence. Report the raw count, time span, regime coverage, and assumptions rather than presenting an interval as certainty.
Choose a stopping rule before testing: a calendar span, a fixed number of eligible signals, or a target precision. Then keep an untouched chronological holdout. If you test ten filters and publish only the best one, the nominal result ignores the selection process. Research on backtest overfitting formalizes why repeated search can produce apparently optimal historical strategies that fail out of sample.
The Backtesting Process Step by Step
Use this database as the evidence layer inside a complete strategy backtesting workflow; it does not replace rule definition, historical data, replay, or an untouched holdout.
Define the setup rules before you look at outcomes
Write an entry rule, invalidation, exit rule, costs, allowed instruments, timeframe, session definition, and exclusions. Give the document a version and timestamp. If a human judgment remains, describe the evidence that should support it.
Freeze the sample and holdout
Choose the historical range and reserve the latest chronological segment for a final check. Do not keep extending the in-sample window until the result turns favorable. Record every strategy variant you intend to compare.
Use blind replay for each candidate
Start before the signal and advance only information that would have been available. Record the decision, stop, target, screenshot, and Rule Match state before revealing the outcome. Platform replay settings and data depth are part of the evidence.
Log every eligible observation immediately
Keep losses, breakevens, no-trades, ambiguous candidates, and data failures. A later exclusion needs a predefined reason and an audit trail. Never change the setup label because the result was inconvenient.
Model execution honestly
State whether fills use touch, next-bar, bid/ask, limit priority, or another rule. Include commissions, spread, slippage, funding, and gaps where they matter. Keep gross and net outcomes separate.
Review checkpoints without tuning the test
Check missing data and logging consistency during collection, but do not edit entry rules after every small block. If a rule changes, close the version, create a new one, and start a separately labeled sample.
Open the holdout, then forward test
Evaluate the locked version on the untouched period. If it survives, run it in chronological demo or very small controlled execution before increasing risk. Compare live assumptions with realized spread, slippage, missed signals, and deviations.
Reading and Acting on the Results
Do not reduce the result to one green or red threshold. Read the point estimate beside sample size, uncertainty, drawdown, costs, missing data, and the number of alternatives tested.
| Observed pattern | Defensible reading | Next check |
|---|---|---|
| Profit factor below 1 after modeled costs | Gross losses exceeded gross wins in this sample | Audit data and assumptions; do not rescue the result by deleting losses |
| Profit factor just above 1 | The sample has little room for omitted costs or estimation error | Stress costs, inspect holdout performance, and report uncertainty |
| High profit factor with few losses | The denominator is sparse and the ratio may be unstable | Show counts, largest-trade sensitivity, and a longer untouched period |
| One session or regime looks best | This is exploratory if the split was chosen after inspection | Freeze the filter and test it on new chronological data |
| Average Net R is positive but drawdown is deep | The sample payoff and path tell different parts of the risk story | Inspect sequence, concentration, longest recovery, and feasible sizing |
| Forward results lag the backtest | Execution, behavior, regime change, or overfitting may be responsible | Reconcile exact trades before changing the rule |
A profit factor above 1 means gross winning R exceeded gross losing R in the recorded sample. It does not prove future profitability. Likewise, a high win rate can coexist with negative expectancy when losses are much larger than wins. Use our separate expectancy formula guide for the arithmetic and sample-size guide for a deeper uncertainty workflow.
How to Leave Notion Without Losing Tests, Journals, or Templates
Portability is part of the template design, not an emergency task for the day you switch tools. Notion currently allows page, database, and workspace export, including Markdown & CSV. But a CSV is a data table, not a faithful copy of a relational workspace.
- Export an unfiltered table view. Compare the exported row count with the database count and keep the export date.
- Export the surrounding page and files. Screenshots, instructions, and setup definitions may not live in the database cells that your CSV preserves.
- Save a data dictionary. Record every property name, type, formula, select option, timezone convention, unit, and null-value rule.
- Preserve stable IDs. Use Test ID and Setup Version to reconcile rows after import instead of relying on display order.
- Document relations separately. Notion states that relation properties export as plain-text URLs and that importing the CSV does not recreate those relations.
- Expect formulas and rollups to need rebuilding. Notion's CSV importer creates rows and properties, but a new import cannot create formulas, rollups, or relations.
- Test in a scratch destination. CSV imports and merges add rows rather than updating existing rows, so a repeat can create duplicates. Verify a small batch before the full migration.
- Reconcile outcomes. Compare row counts, first and last timestamps, total Net R, gross win/loss sums, missing fields, and a sample of screenshots before retiring the original.
Migration stop condition: if the destination cannot reproduce setup versions, Data Origin, timestamps, Net R, and the included/excluded decision for every row, keep the original workspace read-only and resolve the mapping first.
When Notion Is Not Enough
Notion Backtesting Has Real Limits
- No market-data engine: Notion does not provide historical bars, quotes, corporate actions, contract rolls, or tick reconstruction.
- No blind replay: use a replay tool to control what is visible before each decision.
- No automatic fill model: a database cannot determine queue position, bid/ask execution, gaps, or slippage unless you supply rules and data.
- No automatic strategy execution: programmatic rules belong in a backtesting engine such as Pine, MetaTrader, or a tested code workflow.
- Relational export loss: CSV preserves values but not the whole workspace behavior; relations, formulas, rollups, and views require separate documentation.
- Chart limits: current chart views cap displayed groups/subgroups, and a simple result chart is not automatically a cumulative equity curve.
Use Notion when the main problem is a disciplined research log, human review, screenshots, setup definitions, and a portable evidence table. Use dedicated replay when the main problem is hiding future bars and practicing decisions in sequence. Use code when rules and execution assumptions can be specified precisely enough to automate. Many discretionary workflows legitimately use all three.
Where Trader's Second Brain Fits After the Historical Test
Ownership disclosure: Trader's Second Brain is our product. Its Backtester is a retrospective hypothesis tool over saved Journal evidence. It filters an exact account and period by setup version, session, symbol, direction, day, and other recorded fields; compares matching trades with the rest; and shows recorded metrics, exact trades, cumulative P&L, and sequence-risk evidence. It does not reveal historical market bars, generate new simulated trades, infer causality, or replace a replay engine.
If your Notion backtest or forward-test log contains closed-trade fields, preserve the original export and map a test batch into the Journal. TSB's current source registry includes a Notion journal migration path and flexible file imports, but mapping quality still depends on the exported columns. Keep Data Origin and Setup Version explicit so simulated records never masquerade as live execution.
Try the TSB Backtester demo with sample data → · Check current import paths →
Common Notion Backtesting Mistakes
Seeing the Outcome Before the Decision
A screenshot of a completed move is useful evidence only if the entry was frozen earlier. Use replay, record the pre-entry image, and reveal forward in fixed increments.
Changing Rules Inside One Setup Label
If stop placement, session, confirmation, or management changes, create a new version. Mixing versions makes the aggregate impossible to interpret.
Optimizing Every Filter on the Same Data
Testing many sessions, weekdays, regimes, and parameter values increases the chance of finding a lucky winner. Keep a research log of every variant and validate the chosen rule on untouched data.
Calling Gross Results Net
Record costs explicitly. If a cost cannot be estimated, label the result gross and stress a range later; do not silently assume zero.
Confusing a Clean Database With Valid Evidence
Beautiful cards, formulas, and charts cannot repair hindsight, missing losers, an unrealistic fill model, or a contaminated holdout. Audit the collection process before interpreting the dashboard.
Sources and Verification Method
Notion product claims were checked against current first-party help pages. Replay behavior was checked against TradingView's own support documentation. Statistical interval guidance comes from NIST; the selection-bias warning is grounded in published backtest-overfitting research. TSB statements were checked against the local server implementation, documentation, and canonical supported-source registry. Editorial interpretations remain fixed until review even if a linked product page later changes.
- Notion — database properties
- Notion — formula syntax and functions
- Notion — relations and rollups
- Notion — chart views and current limits
- Notion — exporting pages and databases
- Notion — CSV import behavior and limits
- TradingView — Bar Replay controls and limitations
- TradingView — historical Replay Trading and session-only results
- NIST — confidence intervals for proportions
- Bailey et al. — Backtest Overfitting in Financial Markets
