A useful tag is not decoration. It is a repeatable label that lets you put comparable trades in the same bucket, inspect the underlying rows, and make one decision. Without that discipline, a journal can look detailed while every spelling variation, hindsight label, and tiny category fragments the evidence.
This guide gives you a practical five-part starter framework, but five is not a universal law. Start with the fewest labels needed to answer your next review question. Define them before the outcome is known when possible, keep “unknown” available, and expand only when a new tag will change a real trading decision.
A strong first version usually covers setup, market context, execution or mistake, trader state, and outcome review. Give every value a written definition, decide when it is recorded, and review each group with trade count, expectancy, profit factor, drawdown, and the actual trades. No fixed number of tags or trades makes a result true automatically.
1. What Trade Tags Actually Do
A trade table already stores facts such as symbol, side, entry, exit, size, account, session, fees, and realized result. A tag adds a classification the raw execution may not contain: the setup traded, the condition observed, or the rule that was broken. Once the same label is applied consistently, the journal can compare that group with another group or with the rest of the selected history.
That makes tags useful for questions such as:
- Does my defined breakout setup behave differently from my pullback setup?
- Are late-entry trades carrying more downside than on-plan entries?
- Is a session result stable across several weeks, or driven by one outlier?
- Do trades marked as plan-adherent preserve the expected risk profile?
A tag does not establish a cause. If trades tagged “calm” have stronger results, the label may overlap with smaller size, a different session, easier market conditions, or selective tagging. The result is a lead to inspect, not proof that an emotion caused the P&L.
2. Field, Tag, or Note?
The cleanest journal does not turn every detail into a tag. Use the narrowest data type that preserves the information:
| Store it as | Use it for | Examples | Avoid |
|---|---|---|---|
| Structured field | A value the system already knows or calculates | Symbol, timestamp, side, size, fee, session, P&L | Duplicating the same fact as a manual tag |
| Tag | A repeatable category used for filtering | breakout, range, late-entry, rule-break | Long sentences or one-off events |
| Note | Context that matters to one trade | thesis, invalidation, screenshot explanation | Expecting free text to group cleanly |
| Unknown | A value that cannot be reconstructed honestly | unrecorded state, unclear setup version | Guessing during a retrospective cleanup |
If day, session, side, or instrument is already a structured field, filter that field. Save tags for classifications that otherwise disappear. The companion guide to choosing journal fields helps separate essential execution data from optional review context.
3. A Five-Part Starter Framework
These five categories cover common review jobs. You do not need to activate all five immediately, and the example values are prompts rather than a universal vocabulary.
Setup or Playbook
Question: Which declared method was this trade attempting to execute?
Use the exact name from your playbook: for example, opening-range-breakout, trend-pullback, or range-fade. If the setup changes materially, preserve a version or date boundary instead of silently reusing the same name. Otherwise old and new rules land in one bucket and the comparison stops meaning what you think it means.
Market Context
Question: Which observable condition was part of the trade thesis?
Possible values include trend, range, event-window, or a volatility regime that you define objectively. Prefer a structured market field when the journal already derives it. If a condition is subjective, write the test: “trend” might require a particular higher-timeframe structure, not simply “price moved after entry.”
Execution or Mistake
Question: What happened relative to the declared process?
Examples include on-plan, late-entry, oversized, early-exit, and rule-break. A mistake tag should name an observable deviation. “Bad trade” is too vague; “entered after the permitted trigger window” can be checked against the chart and rule.
Trader State
Question: What state was recorded before the result could rewrite the story?
Use a short, explicitly subjective scale such as clear, hesitant, rushed, or not-recorded. Record it before or immediately after entry. It remains self-report data, so treat any performance split as exploratory and inspect overlapping size, session, setup, and market context.
Outcome Review
Question: Did the process and the result agree?
A compact review can separate on-plan win, on-plan loss, off-plan win, and off-plan loss. This prevents a profitable rule break from being mistaken for good execution and a valid loss from being relabeled as a broken setup. It does not prove skill or luck from one trade; it preserves the question for a larger review.
4. Tagging Cheat Sheet
| Category | Example values | Record when | Review with |
|---|---|---|---|
| Setup | breakout, pullback, range-fade | At plan or entry | Count, expectancy, profit factor, drawdown |
| Context | trend, range, event-window | Before outcome | Setup × context comparison |
| Execution | on-plan, late-entry, oversized | When observed | Result, risk, screenshot, rule |
| State | clear, hesitant, rushed, not-recorded | At entry | Setup, size, session, missingness |
| Outcome review | on-plan win/loss, off-plan win/loss | After close | Plan evidence and later repetition |
“Breakout,” “break out,” and “BO” should not become three buckets. Choose one canonical label, record aliases during cleanup, and keep the definition beside the playbook. Short names help filtering; the full rule belongs in the setup definition or note.
5. Example of a Tagged Trade
The row below is fictional and demonstrates structure only. Its values are not evidence of a profitable setup or a recommended market rule.
| Record | Illustrative value | Why it belongs there |
|---|---|---|
| Structured fields | NQ · long · New York session · closed | Execution facts already available to filters |
| Setup | opening-range-breakout · v2 | Declared playbook and version |
| Context | event-window | Defined condition present before entry |
| Execution | late-entry | Observable deviation from the rule |
| State | rushed | Self-report captured at entry |
| Outcome review | off-plan win | Profitable result did not repair the process |
| Note | Entry occurred after the playbook’s trigger window; screenshot attached. | Evidence and context remain inspectable |
The useful part is not the label count. It is the chain from definition to row to review decision. Someone inspecting the record can see why the trade entered the group and what would make the label wrong.
6. How to Analyze Tagged Trades Without Fooling Yourself
- Freeze the scope. Choose the account, date range, currency treatment, closed/open status, and setup version before reading the result.
- Count every bucket. A result without its trade count hides how easily one trade can change the conclusion.
- Read a metric set. Pair P&L with expectancy, profit factor, average win/loss, drawdown, and exposure. Win rate alone can reward a poor payoff structure.
- Open the underlying trades. Check outliers, missing tags, inconsistent sizing, imports, duplicated rows, and whether the label followed its written definition.
- Check overlap. A setup split may also be a session, account, size, or market-condition split. Cross-filter before attributing the difference to one tag.
- Write a bounded decision. Keep, pause, test, or redefine one rule. State what later evidence would reverse that decision.
- Recheck on later trades. Do not relabel the original group to make the hypothesis look successful.
If expectancy, profit factor, payoff, or drawdown are unfamiliar, the performance-analysis guide explains how to read them together instead of optimizing one attractive percentage.
There is no universal “30 trades makes it statistically meaningful” threshold. The needed evidence depends on outcome variance, payoff distribution, how many groups you inspected, and the size of the decision. A practical warning is simpler: if removing one or two outliers reverses the verdict, the bucket is not ready for a permanent rule. Treat it as a test queue.
When you inspect many tags and combinations, some will look impressive by chance. Label the first discovery exploratory, define the next test before seeing later results, and preserve failed tests. The own-history backtest workflow shows how to keep the included rows and invalidation visible.
7. How Many Tags Should You Start With?
Start with one decision, not a target number. If the next review asks which playbook is performing as designed, setup and execution labels may be enough. If it asks whether the same setup changes across conditions, add one context category. A five-part framework is useful coverage, but activating all five before you can apply them consistently creates missing and contradictory data.
Use these gates before adding a category:
- It answers a named review question.
- Each value has a written, mutually understandable definition.
- You know whether one or several values may apply.
- You know when the tag is captured and who can change it.
- “Unknown” or “not recorded” is allowed instead of forced certainty.
If a category does not change a filter, comparison, or decision, keep it in notes or remove it. For a broader cleanup, use the journal-mistakes checklist to find fields that create work without producing evidence.
8. Can You Tag Old Trades?
Yes—when the evidence survives. A screenshot may support the setup and market context. Timestamps and executions support session, side, and sequence. A contemporaneous note may support the declared reason or state. If the only source is present-day memory, use unknown rather than creating false precision.
Keep retrospective cleanup distinguishable from labels captured in real time. That distinction lets a later reviewer test whether the tagging method itself changed. It also prevents a winning chart from quietly receiving a better setup or execution label than an equivalent losing chart.
9. Build a Tag Dictionary Before You Scale
For each category, write a tiny contract:
| Dictionary field | Question to answer |
|---|---|
| Canonical name | What exact label appears in filters? |
| Definition | What observable condition qualifies? |
| Exclusion | What similar case does not qualify? |
| Cardinality | May one trade carry one value or several? |
| Capture time | Plan, entry, management, close, or review? |
| Evidence | Which field, note, or screenshot supports it? |
| Version rule | When does a changed definition become a new version? |
Do not merge aliases by deleting history. Map spelling variants to one canonical value and preserve the original source. Do not reuse an old setup name for a materially different rule. Those two practices keep filters clean without pretending the taxonomy never changed.
10. A Repeatable Tag Review
A review should end with an auditable action, not a colorful dashboard:
- Freeze account and date scope, then record how many trades have missing or unknown labels.
- Compare one primary tag group with a relevant control or the remaining trades.
- Read counts and distribution-aware metrics; inspect the largest winners and losers.
- Cross-check one likely confounder such as setup version, session, size, or market context.
- Open representative rows and confirm the tag dictionary was applied consistently.
- Write one keep, fix, test, or stop decision plus its invalidation condition.
The full trade-review process connects this group analysis to screenshots, rule changes, and the next-session checklist.
11. How TSB Uses Tags Across the Evidence Loop
Ownership disclosure: Trader’s Second Brain is our product. In the current implementation, Journal supports canonical setup labels, multiple setup tags, review grades, plan-adherence fields, and mistake/behavior tags. Setup labels can resolve through a registry with aliases and version snapshots; the same normalized domain feeds Journal filters and downstream analysis instead of leaving every spelling as a separate value.
Tags are not trapped in the trade editor. Dashboard and Analytics can split selected closed-trade history by setup, session, symbol, side, result, and tags. Backtester recomputes results from the included and excluded saved trades, while AI Coach can use the selected scope, tags, notes, and review fields as evidence. Missing tags remain a limitation rather than permission to invent context.
TSB has processed 600K+ imported trades across its import history, and its canonical registry recognizes 328 exact broker, exchange, platform, and prop-export profiles. Those figures describe platform-wide import history and recognized routes—not users, one analysis sample, or proof that imported trades were tagged correctly.
Turn Your Imports Into Comparable Evidence
Import the history, define a small tag dictionary, then test one decision-shaped question against the underlying trades.
Import trade historyMethodology and Limits
This September 10, 2026 fact cycle compared the published guide with the local Journal, tag-domain, setup-registry, Analytics, Backtester, and Coach implementation. It removed fabricated trader results, universal performance deltas, mandatory sample thresholds, invented adherence rates, and unsupported statements about how quickly every trader tags or abandons a system.
The five-part taxonomy is an editorial starter framework, not a TSB requirement or a statistical standard. Illustrative rows are labeled as examples. No live commercial price or exact external company determines the decision, so a provider catalog component is not applicable. Article and BreadcrumbList remain; FAQPage stays tied to the visible FAQ content, with no artificial Review, Rating, Product, or ItemList schema.
Bottom Line
Good tags make a trade classification reproducible. Start with the question you need to answer, define only the labels that support that decision, capture them at the right time, and keep unknowns visible. Then read tagged results with scope, counts, payoff distribution, outliers, overlap, and the actual rows.
The goal is not five tags on every trade. It is a clean path from evidence to a rule that later trades can confirm or invalidate.
Disclosure: Trader’s Second Brain is our product. This guide is educational, does not provide individualized investment advice, and does not guarantee that tagging, filtering, Backtester, or AI Coach will improve trading results.
