Blog
Blog
Most teams start with candles because candles are cheap to store, easy to reason about, and available almost everywhere. That is sensible at the start. It becomes a liability once the work stops being descriptive and starts becoming execution-sensitive.
Historical tick data matters because it preserves sequence. It records the market as events rather than as a summary after the fact. That distinction sounds technical until a research question depends on who was aggressive, how liquidity changed, or whether the path through an interval made execution far worse than the final candle implies. At that point, the difference between a summary and the event stream stops being academic. It becomes the boundary between an honest study and an optimistic one.
This is the practical guide to that boundary: what tick data actually contains, why many teams ask it to do the wrong job, and where the real cost shows up once someone decides they need more than bars.
Tick data is usually used as a catch-all phrase, but it covers several different layers of market history. That matters because those layers solve different problems.
Trade-level history records executions. A trade event tells you that something actually changed hands at a given price, size, and time. Depending on the feed, it may also tell you which side initiated the trade. That is often enough for signed-flow measures, activity clustering, and basic event-order studies.
Orderbook history is heavier. It attempts to preserve the displayed auction around those executions: bids, asks, changes in visible depth, cancellations, replenishment, and the sequence in which that displayed liquidity evolved. If the research question depends on spread, queue behavior, or the difference between displayed size and actual absorbable size, this is the layer that matters.
The common mistake is treating all event data as interchangeable. It is not. Saying "we need tick data" is often too vague to be useful. Many teams really mean one of two things: either they need trade history because candles are too lossy, or they need orderbook history because trades alone still do not preserve the liquidity conditions that shaped those trades.
Candles answer one question well: where did price print over the interval? They answer many other questions poorly.
They do not tell you whether the move happened through steady aggression or through one sudden sweep. They do not show whether the spread widened before the move. They do not show whether visible depth thinned before the breakout or whether the breakout occurred into a book that was already fragile. They do not show whether the path inside the bar made the strategy's assumed fills unrealistic.
That is why why the candle is not the market remains such a useful framing. The candle is the transcript. Tick data is closer to the recording. A transcript is fine until the omitted sequence contains the mechanism you needed to understand.
This does not make OHLCV worthless. It makes it bounded. A slower research question can survive compression. A path-sensitive question cannot. The error appears when users keep the same dataset while quietly changing the difficulty of the question.
Trade history is usually the first upgrade from candles because it is simpler to collect and already much closer to the market. It gives you event order, trade clustering, and often the raw material for signed-flow work.
For many studies, that is enough. If the goal is to understand whether flow was one-sided, whether participation accelerated around a level, or whether a short-horizon move had directional aggression behind it, trade history is a meaningful step upward from OHLCV.
Orderbook history is a different commitment. It matters when the question is not only what executed, but what liquidity was visible before the execution, what disappeared before being hit, how the spread evolved, or whether the book was stable enough that a printed price was realistically tradable. This is where a lot of research teams discover that they did not simply need "more data." They needed a different market record entirely.
That is why a strategy built on trade history alone can still overstate realism. It may know that a move happened. It may still have no honest way to represent how hard it was to get filled into that move.
Live feeds are more common than trustworthy archives. That difference is not small.
Exchanges often provide streaming access because current data is part of the product. Historical event integrity is more expensive. Someone has to capture the feed continuously, preserve enough detail, handle reconnects, detect missing sequences, maintain symbol continuity, and keep that archive queryable later. When the layer is orderbook rather than trades, the storage and consistency burden gets heavier again.
That is why full historical book reconstruction is rare compared with simple trade archives. In many environments, if the book was not recorded live at the time, the exact displayed state is gone. The price path may still be easy to discuss. The liquidity state that made that path possible may no longer be recoverable.
This is also why post-event narratives often sound more precise than the data deserves. People remember the move. Far fewer preserved the auction conditions around the move with enough fidelity to test what really happened under the hood.
The concept is simple: capture the feed and save it. The implementation is where the fantasy ends.
One venue for one symbol over one bounded period is manageable. A repeatable multi-venue archive is not the same problem. Schema differences, symbol changes, reconnect behavior, out-of-order messages, timestamp conventions, throttling rules, and venue-specific failure modes all become part of the system. If the archive is supposed to support real research later, then silent corruption is not acceptable. You need enough checks to know when the stored history no longer describes the market you think you captured.
This is where teams often rediscover the same lesson covered in The Problem With Free Crypto Data. The easy part is obtaining rows. The hard part is trusting them. Storage is obvious. Trust is the expensive layer.
That is also why the engineering bill is not just disk space. It is validation, replay confidence, sequence integrity, and enough operational discipline that a clean-looking result is not quietly built on a broken archive.
Three mistakes recur across almost every serious attempt.
The first is assuming that "historical" means the archive is neutral and complete. It may already contain aggregation choices, partial corrections, or venue-specific omissions that shape the later conclusion. The age of the data does not make it transparent.
The second is mixing venues without normalizing timing and symbol semantics carefully enough. This is one of the fastest ways to generate false lead-lag claims. If exchange clocks, sequence handling, or product mappings are not aligned tightly enough, the archive can manufacture cross-venue structure that never existed in tradable time.
The third is acting as if trade history alone is enough when the strategy's live behavior depends on liquidity conditions. A model may survive on trades if the question is directional and coarse. It will not survive there if spread stability, depth quality, or price impact under size are part of the live reality.
Before trusting the archive, it is worth forcing the same skepticism used in data quality for market-pressure context: where are the gaps, how are timestamps handled, which repairs were made after the fact, and what part of the live market state is still absent even in the cleaned history?
Historical tick data is not valuable because it sounds institutional. It is valuable because it narrows the distance between the question and the market record used to answer it.
It is the correct starting point when you need event order, trade direction, micro-burst behavior, short-horizon flow shifts, or liquidity-sensitive explanations that candles flatten away. It is also the minimum honest layer for many questions about order flow imbalance, price impact, or the difference between a visible print and a realistic fill.
The point is not to treat raw data as a status symbol. The point is to stop asking summary data to carry analytical weight that belongs to an event archive. Good research usually looks less magical once the dataset matches the actual complexity of the question.
If your work depends on what happened inside the candle, historical tick data is not a luxury feature. It is the minimum dataset that keeps the sequence intact.
If your work does not depend on path, pressure, or execution quality, then OHLCV may still be enough and there is no reason to pretend otherwise. The mistake is treating those two research conditions as interchangeable. They are not.
Most weak market-data research does not fail because the model was too ambitious. It fails because the dataset stayed too compressed for the question being asked. Historical tick work is expensive for a reason: it preserves the part of the market that simple summaries routinely throw away.
Tick data preserves events in sequence. OHLCV compresses those events into interval summaries after the sequence is already gone.
No. It is often enough for flow-sensitive work, but not for research that depends on spread, visible depth, queue behavior, or whether liquidity remained stable under pressure.
Because preserving every meaningful change in displayed liquidity is more expensive than recording executions alone. It requires tighter capture, more storage, and more trust checks.
Trust, not storage. Quiet feed damage, bad normalization, timing drift, and venue mismatch usually waste more time than the raw archive footprint itself.
When the question is slow-moving and coarse enough that losing the event sequence does not materially change the conclusion.