Retrospective features
A valid historical price or active-buy measure can have been recovered later. A row marked retrospective can support descriptive analysis, but cannot prove the input was available for a decision at that historical time.
CRYPTO DATA BUYER’S GUIDE
How to evaluate crypto data quality before you buy.
A buyer’s acceptance checklist for research-ready crypto data: what to ask, what to test, and when to reject a delivery.
How do you evaluate a crypto data provider?
Start with one research task: for example, joining settled funding with OI available before each settlement. Send every shortlisted supplier the same instrument list, dates, fields and delivery requirements. Compare evidence for that task, not headline market counts.
| Quality check | Evidence to request | Acceptance test |
|---|---|---|
| Instrument identity | Exchange, spot/perpetual, quote asset, contract multiplier and symbol changes. | Join on venue and instrument identity, not a ticker alone. Reject a delivery that silently combines different contracts. |
| Coverage and gaps | First/last timestamps, expected grid, missing intervals, duplicates and delisted instruments. | Compare expected versus unique valid records over your requested window. Endpoints alone do not prove continuity. |
| Point-in-time availability | Event time, first observation, ingestion time and revision timestamps. | Features must be available before the simulated decision. Retrospective imports are not contemporaneous observations. |
| Units and alignment | Funding settlement interval; OI quantity versus notional; candle open/close time. | Normalize only with a documented formula. Use a backward as-of join with an explicit maximum age, not future or nearest observations. |
| Missing values and labels | Pending outcomes, unavailable inputs, invalid active-buy data and quality flags. | Keep unavailable values null with a reason. Do not turn missing flow into zero buying or pending returns into losses. |
| Revisions and reproducibility | Release ID, schema version, calculation version, checksum and corrections log. | Repeat a calculation on the same release. A checksum proves file identity, not that its market values are correct. |
| Delivery and rights | Sample/API parity, pagination, rate limits, export format, allowed use and redistribution. | Run the real workload before signing. Derived data is not automatically exempt from source licensing restrictions. |
How should you test a sample before subscribing?
- Freeze the specification. Name the venue, instrument, dates, interval, units and permitted use. Decide acceptable gap rates and maximum input age before seeing a vendor’s result.
- Sample difficult periods. Include a quiet period, a volatile period and any known listing or outage boundary. A clean BTC example does not prove every contract is usable.
- Check the expected grid. A full UTC day contains 288 five-minute slots. Count unique valid timestamps in the requested interval; investigate duplicates, gaps and off-grid observations separately. Scheduled funding needs its actual settlement calendar, not an assumed fixed interval.
- Reproduce one calculation. Rebuild a return, a settlement cost or an OI change from documented units. Compare API rows with the downloaded release, allowing only disclosed rounding differences.
- Run a point-in-time join. Require each feature’s availability time to precede the decision. A later recovered historical value must not silently enter a live-information backtest.
- Record the decision. Keep sample version, checksums, failed checks and agreed exclusions. Sign off the tested scope only; expand acceptance tests when adding markets or sources.
What do retrospective, pending and gap mean in a real sample?
CoinNudge’s dated evaluation pack deliberately includes different availability states. These are field-interpretation examples, not a representative performance study.
Pending versus missing outcomes
Pending means the forward observation window has not matured. A gap means required evidence is unavailable. Neither means a zero return. Report complete-case counts alongside any result.
Comparison is not causation
An hourly observation without a qualifying recorded event is a comparison row. It is not proof that no signal existed or a control matched on volatility, hour and market regime.
Provenance is not accuracy
Availability timestamps explain when a value was recorded. They do not certify correctness. Validate units, check against the named source and retain subsequent corrections separately.
Which red flags should stop a data purchase?
Pause if a provider cannot identify the instrument or source, conflates historical backfill with point-in-time data, silently fills gaps, cannot explain revision behavior, or will not confirm permitted use. Fixing those issues after a backtest can invalidate the result.
A gap does not automatically make a provider unsuitable. Document whether your task tolerates it: daily descriptive research and an execution simulator have very different requirements. Reject unexplained omissions, not honest disclosure.
Evaluate historical funding and OI suppliers → · Compare providers by backtesting workload →
Verify the source documentation, not only the sales page.
Binance’s public archive documentation describes file checksums, later archive corrections and a change in Spot timestamp precision. These are concrete reasons to test units and preserve source versions.
Tardis’s data documentation distinguishes exchange timestamps from local arrival timestamps and discusses ordering and normalization. Ask any provider how its equivalent fields behave.
Kaiko’s published terms distinguish internal derived works from commercial client-facing uses requiring additional consent. This is one example, not a universal license: review the actual supplier agreement for your intended use.
Documentation reviewed 2026-09-27. This is a procurement checklist, not a certification of any provider or a legal opinion.
Questions before you choose
Does a larger dataset mean better quality?
No. Quality depends on the exact instruments, dates, fields, units, availability timing and gaps required by your research. Row counts alone cannot establish fitness for a task.
Is historical backfill the same as point-in-time data?
No. Backfill recovers past values later. Point-in-time use requires evidence that the features were available before the simulated decision, with revisions kept separate.
Should missing values be replaced with zero?
Not by default. Missing inputs, pending outcomes and true zero measurements have different meanings. Retain a reason flag and disclose any imputation.
What should a provider deliver with a sample?
Request a field dictionary, source and unit definitions, time semantics, gap report, revision policy, release identifier, checksums and permitted-use terms. Then reproduce a calculation.
Where can I find CoinNudge asset coverage?
The data coverage catalogue is the single inventory of dataset families, contract dates, intervals, samples and access boundaries. This page explains how to evaluate that evidence.
Use evidence to choose your next step.
All CoinNudge asset counts, coverage and access boundaries live in one catalogue. Use this guide to evaluate that inventory—or another provider—against your own acceptance criteria.