Direct answer
Pullback Trend (as a trading idea) generally uses inputs that come from price history and a small set of rule parameters. The most common inputs are (1) how you define the prevailing trend, (2) how you define a “pullback” against that trend, and (3) what additional constraints you apply before considering any action.
Because the term is used in different ways across writers and providers, “Which inputs it uses” is best answered by listing the data categories and the computations you need to make those rules explicit. The data categories are typically stable, while the specific thresholds vary.
Mechanism or definition
At a practical level, Pullback Trend uses a simple model built from three components:
-
Trend state input: data used to decide whether the market is trending up, trending down, or neither. This can be based on price structure (for example, recent higher highs and higher lows, or recent lower highs and lower lows) or on a derived trend measure (for example, whether price is on one side of a moving average).
-
Pullback condition input: data used to detect that price has moved against the trend for a limited time or limited distance. Inputs here are usually derived from candles or bars: prior highs/lows, the size of the retracement, and where the current close sits relative to a reference level.
-
Rule parameters and dependencies: numerical choices that govern the behavior of the above inputs. Examples of parameter types include:
- Lookback window(s): how many past bars are considered.
- Thresholds: allowed pullback size (in points/percent), and what counts as “limited.”
- State confirmation logic: whether you require one bar, multiple bars, or a particular pattern of closes.
- Execution-related assumptions: whether rules use candle closes only or also intrabar information (many systems using only bar data cannot know intrabar extremes precisely).
Uncertainty to keep in mind: two implementations can use “the same concept” but different definitions of trend and pullback, yielding materially different rule inputs and outputs.
Evidence or example (self-check)
Here is a concrete, checkable example of the types of inputs Pullback Trend implementations often require. This is not a claim about any specific provider; it is a template for independent verification.
Assume you use bar data with OHLC (open, high, low, close). A Pullback Trend rule might require:
- A trend definition: for instance, compute a trend state using the last N bars. One common form is comparing recent swing highs/lows (needs N and a swing rule), or comparing the close to a derived line (needs N or a smoothing choice).
- A pullback definition: detect a retracement after the trend state is established. This needs a retracement measure (for example, pullback percent from a prior swing) and a threshold (for example, “not deeper than X”).
- A confirmation rule: specify what “pullback completed” means. Using only OHLC bars typically uses conditions on close and sometimes on high/low relative to the reference.
Material limitation: if your definition uses intrabar extremes, but your data source only stores OHLC aggregates, you may not be able to replicate the same decision points. Even small differences—like using close versus mid-price—change what counts as pullback completion.
Limitations and risks
Pullback Trend has several failure modes that come directly from how inputs and parameters are defined:
- Ambiguous trend state: markets can alternate between trending and ranging. If your trend definition is too sensitive (short lookback or tight thresholds), the “trend input” can flip frequently.
- Noisy pullback measurement: pullbacks are not clean events; they depend on the exact reference level and retracement calculation. Small parameter changes can change which bars satisfy the pullback condition.
- Data and calculation mismatch: different feeds, different bar sizes (timeframes), and different handling of time zones and session breaks can produce different input series.
- Execution and cost sensitivity: even with the same rule inputs, real results depend on spreads, slippage, and execution timing. Backtests that assume perfect fills can materially overstate what bar-based rules can achieve.
- Non-predictive history: historical relationships do not establish future results. The same input definitions can perform differently across regimes.