Tick Replay, Tick Resolution, and a Secondary 1-Tick Series Are Not the Same Thing

Desktop SDK - Indicators
,
1

I keep seeing these three concepts used almost interchangeably when discussing Volume Profile, delta, and other tick-driven indicators in NinjaTrader:

  • Tick Replay

  • Tick resolution

  • A secondary 1-tick data series

They can all involve tick data, but they solve different problems.

I thought it might be useful to separate them clearly.

1. Tick Replay is about historical event processing

Tick Replay is a NinjaTrader feature intended for NinjaScript indicators and strategies that need historical market-data events processed in sequence.

It is useful when an indicator depends on what happened inside a bar rather than only on the completed OHLC values.

For example, an indicator may care about:

  • individual trades,

  • intrabar state changes,

  • bid/ask/last events,

  • the sequence in which its logic develops historically.

Enabling Tick Replay does not simply change your chart into a 1-tick chart.

It also does not automatically make every indicator more accurate. The script has to be written to actually use the historical market-data events that Tick Replay provides.

There is also a performance cost. Reconstructing historical calculations event by event is much more work than processing completed minute bars.

So I would think of Tick Replay as:

“Replay the historical event stream through my NinjaScript logic.”

Not:

“Use more accurate bars.”

2. Tick resolution in Volume Profile is a source-data choice

This is a different concept.

For example, NinjaTrader’s Order Flow Volume Profile can build a profile using Minute or Tick resolution.

With Minute resolution, the profile is built from 1-minute data. NinjaTrader has to approximate how the volume inside that minute should be distributed across the prices traded by the bar.

With Tick resolution, the profile uses 1-tick data instead.

That changes the granularity of the data being used to construct the profile.

So Tick resolution means roughly:

“Build this profile from individual tick records instead of aggregated minute bars.”

It does not mean Tick Replay is enabled.

You can therefore have a Volume Profile using Tick resolution without confusing that setting with the Tick Replay option on a NinjaScript indicator.

This distinction becomes especially important for things like:

  • POC

  • VAH / VAL

  • delta

  • Buy/Sell profiles

  • narrow intraday profiles

  • profiles where a few price levels matter significantly

A profile calculated from minute-level approximation and one calculated from actual tick-level inputs can legitimately produce different results.

3. A secondary 1-tick series is an additional Bars object

A developer can also do something like:

AddDataSeries(BarsPeriodType.Tick, 1);

That creates another Bars series inside the NinjaScript.

The primary chart might be 5-minute bars while the secondary series is 1-tick.

The script can then process the secondary series separately through its BarsInProgress index and use those ticks to build its own calculations.

For example, you might use the secondary series to accumulate:

  • volume at each price,

  • tick counts,

  • custom delta logic,

  • intrabar statistics,

  • data mapped back to the primary bars.

But adding a 1-tick secondary series does not automatically turn the script into Tick Replay.

It simply gives the script another data series with 1-tick bars.

That is an important architectural difference.

A simple way to remember the difference

Tick Replay

Historical event-processing mechanism for NinjaScript.

Tick resolution

Granularity of the source data used to build something such as a Volume Profile.

Secondary 1-tick series

An additional Bars series explicitly added to a multi-series NinjaScript.

They can sometimes be used together, but they are not substitutes for one another.

One more common source of confusion: Playback / Market Replay

I would also keep Playback separate from all three.

Playback is about running a historical session forward as though time were progressing again.

That is a different use case from rebuilding an indicator’s historical state when a chart loads.

So if the question is:

“I want to watch the profile develop through the session again.”

Playback may be the relevant tool.

If the question is:

“My custom indicator needs historical intrabar events.”

Tick Replay may be relevant.

If the question is:

“I want the profile calculated from individual trades rather than minute-bar approximation.”

Tick resolution is the relevant setting.

And if the question is:

“I want complete control over what my NinjaScript does with every historical tick.”

A secondary 1-tick series may be the better architecture.

A useful test

One experiment I find useful is to take a simple 5-minute indicator and add a secondary 1-tick series.

Print:

  • BarsInProgress

  • timestamp

  • price

  • volume

Then compare the script with Tick Replay disabled and enabled.

It becomes much easier to see that the secondary tick series and Tick Replay are affecting different parts of the processing model.

I’m curious how others here choose between these approaches.

For people building Volume Profile, footprint, delta, or other tick-driven indicators: do you normally prefer a secondary 1-tick series, Tick Replay, or a combination depending on the calculation?

2

Nice breakdown, matches what I’ve run into building volume-profile stuff myself.

My take: secondary 1-tick series is usually the better trade-off. You get full tick granularity for building your own volume/delta logic, without paying the Tick Replay tax of re-running OnBarUpdate on every single tick for your whole indicator - only the secondary series’ processing gets that granularity, primary stays cheap.

Tick Replay makes sense when you genuinely need Bid/Ask/Last classification per print (real footprint/delta with trade-side detection) - that’s data a secondary tick series alone doesn’t give you, it’s just OHLCV bars. But if you’re building profile-type stuff where you mainly need price+volume at tick granularity (not necessarily side-of-trade), secondary series gets you there with way less overhead and way less risk of choking on large historical loads.

Your test (dump BarsInProgress/timestamp/price/volume with Replay on/off) is a good one - I’d throw MarketDataType in there too, since that’s really the only thing Tick Replay buys you that a secondary series doesn’t.

1 Like
3

In my testing, 1 tick secondary data series along with Lee-Ready buy/sell classification algorithm is very close to tick reply when building volume profiles, delta, etc.

4

Good points from both of you.

One distinction I would keep explicit with the secondary-series + Lee-Ready approach is where the bid/ask context comes from.

A secondary 1-tick series based on Last gives you the trade price and volume, but Lee-Ready-style classification still needs quote context around that trade. If you want to reconstruct that historically without Tick Replay, that generally means maintaining separate historical Bid/Ask series and synchronizing them with the Last ticks.

That gives you a different architecture and performance trade-off rather than a direct substitute for Tick Replay.

There is also an important limitation on the Tick Replay side: it should not be thought of as providing a native “buy/sell aggressor flag.” Historically, NinjaTrader replays the Last events and retains the best inside bid/ask associated with the Last trade event. Your logic still has to decide how that trade should be classified.

So I would frame the choices more like this:

  • Secondary 1-tick Last series → very useful for price/volume-at-price, tick counts, and custom intrabar aggregation.

  • Last + separate historical Bid/Ask series → enough information to implement your own trade-classification logic, with its own synchronization and performance considerations.

  • Tick Replay → useful when the NinjaScript needs the historical Last-event sequence together with the bid/ask context NinjaTrader stored for those trades.

For delta-by-price or footprint-style calculations, I would still compare both approaches over a volatile session before assuming they are interchangeable. If the resulting Buy/Sell classification diverges, that difference can propagate directly into the delta distribution.

@YevhenSolod’s suggestion to include MarketDataType in the test output would make that comparison especially useful.

5

Personnellement ce qui me dérange en utilisant les indicateurs qui utilisent les tick replay c’est quand l’instrument est volatile (ex NQ RTY.. a l’ouverture USA) les résultats (output) sont souvent faux et il faux a chaque fois faire une mise a jour (F5 Roload) et ceci est vrai dans le cas des indicateurs de l’Order Flow ou du Carnet d’orders donc méfiez vous il faut de temps en temps F5

6

Thanks for sharing that — that’s an interesting observation, especially on instruments like NQ and RTY around the US open.

One thing I would be careful about, though, is attributing the discrepancy directly to Tick Replay itself.

If an F5/Reload changes the output, it could also point to how the indicator rebuilds or synchronizes its internal state when historical and real-time processing meet, particularly during periods with a very high event rate.

There is also an important distinction with order-book/depth indicators: Tick Replay does not reconstruct the full historical Level II market-depth event stream in the same way it reconstructs trade-related historical processing.

It would be interesting to know:

  • Which specific Order Flow / order-book indicators have you seen this with?

  • After pressing F5, do the values consistently become correct and remain stable?

  • If you reload the same historical session again, do you always get the same result?

If the behavior is reproducible, that would be a very useful test case. Comparing the output before/after reload while logging timestamps and MarketDataType could help determine whether the source is Tick Replay, the indicator’s state-management logic, or the underlying historical/real-time data transition.