How to evaluate a crypto event-study dataset before buying

How much crypto event-study data is actually usable for my research?

Usable crypto event-study data means rows that pass the fields, timing and outcome requirements of your declared research question. In this frozen September 28 audit, retrospective 24-hour description has 4,121 complete outcomes, while the stricter locally-known active-buy/24-hour task has eight eligible rows. A descriptive price study and a predictive decision backtest therefore need different denominators; neither count measures alert profitability.

The same dataset can therefore be useful for reviewing event outcomes yet too immature for a specific historical predictor. This is the procurement insight: request a task-conditioned denominator before negotiating a price or training a model. A large aggregate row count cannot answer how many observations contain your required fields at the required time.

Verify: Frozen population and eligibility results · Per-row diagnostic flags

Which events, controls and release versions were included?

We froze the 23 active daily releases for September 5–27, 2026 before analysis. They contain 4,284 observations: 2,714 public rule events and 1,570 scheduled controls. The market scope is BTCUSDT, ETHUSDT, SOLUSDT, BNBUSDT, XRPUSDT and DOGEUSDT spot on Binance. No claim about every crypto asset follows from this six-pair sample.

Seven event families—price, volume, flow, RSI, MACD, EMA and Bollinger—plus controls form a complete 6 × 8 matrix, including zero cells. A row is an observation, not necessarily an independent economic event: several rules can respond to the same move. Release IDs and original file hashes are preserved in the evidence.

These are the active versions present at the freeze, some generated after their underlying event day. They cannot be passed off as the exact file a customer would have downloaded on that historical day. A full version-by-version availability replay is a different study and needs that additional archive.

Verify: Complete 48-cell coverage CSV · Release IDs and file hashes

Why do 4,284 observations become eight for an as-known active-buy study?

The first eligibility gate requires feature_status='locally_known', a true feature PIT flag, and feature availability no later than the sample time. This retains 171 rows. Requiring valid active-buy data retains the same 171. Requiring non-missing, complete 24-hour return and excursion values reduces the set to eight. These gates were declared before counting.

This is not a claim that only eight rows in the product have any research value. Most remaining rows can still support explicitly retrospective analyses. Nor does passing this feature test certify an executable signal: an operational study must also audit when the event itself became available, its processing delay and the execution clock.

The frozen snapshot has many recent locally known observations whose outcomes have not yet matured. Other rows recover features retrospectively. More elapsed time may resolve pending outcomes; it cannot turn historical backfills into information recorded locally at the event time. Keep those two causes separate.

Verify: Reproduce the eligibility funnel · Exact flag definitions

Which coins have enough eligible observations for a specific comparison?

Counts need to be inspected by symbol and event family before choosing a hypothesis. The table shows symbol-level totals; the downloadable matrix preserves all 48 symbol × family cells. In the strict active-buy/24-hour task, XRP has zero eligible rows, while SOL has three. Neither a zero nor three can support a stable comparative performance ranking.

Do not rebalance these cells by duplicating scarce observations or by treating controls as events. If a relevant cell is empty, narrow the question, wait for prospective observations, or obtain another permitted source. Report the exclusion rather than silently changing the scope of the advertised research.

Verify: Every symbol and event-family coverage cell

How should pending, missing and mature event outcomes be handled?

An outcome is a label available after its observation horizon, not an input available at entry. A pending 24-hour result is not a zero return or failed trade. A completed horizon with a source gap is also different from an unmatured horizon. Filtering only successful or fully populated outcomes can change the sample composition; show the starting and final denominators.

The 24-hour counts below describe the frozen release state. Later regeneration may mature some pending rows, but this report keeps its original version for reproducibility. Missing 7-day outcomes in this snapshot are pending, whereas four 24-hour observations are labelled gaps; those states require different follow-up.

Verify: Outcome status counts by horizon

Are scheduled control rows a valid benchmark for event performance?

Not automatically. These controls are hourly observations without a recorded qualifying event in the preceding hour. They are not proof of a bearish signal, a genuinely event-free future period or a matched counterfactual. Comparing all events with all controls can mostly compare different coins, volatility regimes or hours rather than isolate an event effect.

For a new causal-style comparison, define matching using pre-event information: symbol, hour-of-week, volatility, prior trend and market regime. Predefine a distance rule, caliper, tie-break and whether controls can be reused. Exclude controls whose outcome windows overlap the event windows under the chosen design, and publish unmatched events instead of forcing a match.

Illustrative design only: an event at Monday 10:00 with a 24-hour horizon cannot use Monday 12:00 as an independent same-symbol control under a no-overlap design. A prior-week observation may qualify by clock hour but still fail a volatility or regime caliper. That example is a protocol explanation, not an additional empirical result from this audit.

Verify: Existing matched breakout study

Are forward returns, MFE and MAE the same as trading performance?

No. A forward reference-price return measures a price change from the recorded observation, not a filled trade. MFE and MAE summarize favorable and adverse excursions over a defined path; their interpretation must specify direction and reference price. A short trade can gain when a raw asset return is negative. Do not use an unsigned price-return column as long/short P&L.

Before constructing a strategy, define signal availability, next executable entry, fee and slippage assumptions, funding or borrowing if relevant, stops, targets and intrabar ambiguity. If a bar touches both stop and target, a conservative ordering rule or finer data is required. A candle high is not proof that the full position could exit there.

Future outcomes must remain label columns. Splitting rows at random can leak overlapping windows and repeated market episodes across train/test sets. Use chronological evaluation and a horizon-aware purge or embargo suited to the design. Freeze all feature selection and thresholds before the test period.

Verify: Backtesting data types and execution limits · Market Events sample field dictionary

How many independent event samples are enough?

There is no universal minimum that turns observations into a reliable trading edge. Required sample size depends on effect size, variance, dependence and the number of hypotheses tested. Our eight strict eligible rows are a procurement warning, not a basis for a success-rate claim. Even thousands of rows can represent a few correlated market shocks.

A performance report should publish event and matched-control counts, number of distinct dates or blocks, effect-size intervals, cost sensitivity and subgroup failures. Block bootstrap intervals can reflect temporal dependence if the block choice and randomization contract are disclosed; they do not remove selection bias or make eight cases robust.

This report is a deterministic census of frozen records, so its counts do not need sampling confidence intervals. It makes no estimate of future dataset eligibility rates. Before accepting generalization, repeat the task-conditioned audit on different months, regimes and release versions.

Verify: Full event-study coverage report

How can a data team reproduce the sample audit before procurement?

Download events.json, event-diagnostics.csv, event-matrix.csv and the schema. The public diagnostic IDs are hashed identities; flags expose eligibility and maturity without publishing exact event timestamps, paid raw features or forward returns. The JSON lists release IDs and hashes so an entitled customer can reconcile the corresponding complete files.

To run the bundled standard-library audit, put reproduce.py beside all three study JSON files and their diagnostic CSVs, then run python reproduce.py, or python3 reproduce.py if Python 3 is installed under that command. It reaggregates row uniqueness, feature gates, every horizon and all 48 matrix cells. It verifies diagnostic arithmetic, not the truth of the underlying prices or a strategy's profitability.

An entitled evaluation should go further: reconcile raw feature values and return calculations against source candles, check correction history, prove event availability and reproduce a small end-to-end analysis. API consumers should use the published authentication, catalog and pagination contract, pin release IDs, and distinguish current public Research responses from immutable paid files.

A successful diagnostic run must recover 4,284 unique frozen rows, 4,121 complete 24-hour outcomes, eight strict eligible rows and all 48 symbol-by-family cells, including zeros. If these disagree, first verify the September 28 manifest and file versions, then compare each eligibility gate; a newer release is not a correction to this frozen denominator. A passing diagnostic run still needs a permitted raw extract to validate prices and an execution study to validate trading performance.

Verify: Public diagnostic reproducer · Evidence manifest · API URLs, authentication and file delivery

When should you buy, request more evidence or defer a dataset?

Buy only when the offered release can answer the declared task and its usage terms fit the workflow. For descriptive event reviews, the 4,121 complete 24-hour outcomes are a meaningful starting population, subject to event/control selection and execution limits. For our strict prospective active-buy task, eight eligible rows justify waiting or expanding the evidence before estimating an edge.

Request a task-specific sample containing missing, retrospective, pending and valid rows—not only clean winners. Agree on release immutability, corrections, coverage updates, API/file entitlements and an acceptance procedure. A larger team plan does not automatically grant a different historical source universe.

Current CoinNudge purchases are one-time fixed-edition research packs, not a new Market Events-only monthly subscription. The September 28 evidence in this report remains frozen and is not the current catalogue. Use the single coverage inventory to verify the exact pack, edition, fields and hosted-delivery term, then inspect its real sample before payment. Internal records or another public Research page do not automatically become included rights.

Verify: Inspect public data samples · Check current purchasable coverage · Compare data plans and entitlements

Frequently asked questions

Sources and verification

• Frozen release audit23 release IDs, hashes, maturity counts and matrix.
• Diagnostic protocolPredefined eligibility and scope.
• Market Events field dictionaryFeature, control and outcome definitions.
• Public API contractAuthentication, catalog and delivery methods.

Validate timing, controls and mature outcomes before buying.

Inspect the public diagnostics and request the exact release and rights your intended study requires.