Strategy Tagging: inputs at a glance
Strategy Tagging is a method for assigning labels to trading activity so you can later compare outcomes across categories. To explain it accurately, focus on the inputs that are fed into the labeling rules and the inputs used to judge whether the labeled result was successful.
Because different tools and providers implement different tagging schemas, the most reliable approach is to separate stable mechanics (what the tagging logic needs) from variable conditions (what your market, broker execution, and data sources provide). This article describes the common, non-time-sensitive inputs you typically need.
Mechanism: the inputs Strategy Tagging generally uses
A practical way to model Strategy Tagging is as a two-step process: (1) tag creation and (2) result evaluation. Each step has different inputs.
1) Inputs used to create tags (the “labeling” side)
These are the fields that a rule or classifier uses to decide which strategy/category label applies.
Common inputs include:
- Event timing: entry timestamp and (if applicable) exit timestamp. Tagging rules often assume consistent time zones.
- Instrument identity: which market/instrument the trade refers to (for example, currency pair). Label logic usually relies on a consistent instrument identifier.
- Trade direction and type: buy/sell and whether the trade is a market order, limit order, or similar category (if your system records it).
- Execution and price facts: at minimum, the prices the trade is based on (entry price; and exit price when known).
- Order/position parameters: such as position size, leverage (if used in reporting), or risk/stop parameters if your tagging rules reference them.
- Context metadata: any categorical fields you choose to tag on, such as “setup type,” “session,” or “pattern name,” depending on how you define your taxonomy.
2) Inputs used to evaluate what happened (the “outcome” side)
Even if tagging labels are created from context, you still need outcome inputs to compare performance later.
Common outcome inputs include:
- Exit information: exit timestamp and exit price (or the method that determines exit).
- Profit/loss measure: either absolute profit/loss or a normalized measure (for example, return on invested amount), as long as the rule uses a consistent definition.
- Costs: commissions, fees, and spread-related costs, if your system includes them in net results.
- Assumptions for measurement: whether profit/loss is based on last price vs. fill price, and whether slippage is modeled or ignored.
Stable vs. variable inputs
- Stable mechanics: the tagging rules, the mapping from input fields to labels, and the measurement definition for outcomes.
- Variable conditions: market behavior, execution quality, and the completeness of your recorded data.
Evidence or example: what “inputs” look like in a checkable record
Consider a single trade record as a row of data. Strategy Tagging typically needs a subset of fields from that row.
A checkable example input set (illustrative, not live data) might be:
- Label-related fields: entry time, instrument ID, direction, setup name (if you recorded it), and position parameters referenced by rules.
- Outcome-related fields: exit time, exit price, net profit/loss definition, and whether costs were included.
To make the tagging reproducible, your example must state assumptions such as:
- Timezone handling for timestamps.
- Which price is used for entry and exit (fill vs. quoted).
- What “net” means in your profit/loss calculation (includes fees and spreads or not).
If any of these assumptions change between trades or between testing and evaluation, the inputs cease to be comparable.
Limitations and failure modes
Even with a clear input list, Strategy Tagging can fail or mislead when its inputs are inconsistent.
Material limitations include:
- Missing or incomplete fields: if the tagging rule expects setup context but your records lack it, you may end up with unknown or forced categories.
- Label inconsistency: if the meaning of a context field changes over time (for example, you rename categories or redefine what “setup type” means), tags become non-comparable.
- Outcome definition drift: historical results may have been computed using different cost or fill assumptions than new trades.
- Execution and costs: ignoring commissions, spreads, or slippage can change outcomes enough to alter comparisons.
- Data timing mismatch: if timestamps are recorded differently (timezone changes, clock differences), grouping trades into sessions or patterns becomes unreliable.