Point-in-time data for backtesting.

A backtest asks what a strategy would have done with the information available at the time. The data has to answer honestly, and most datasets cannot, because they store the current state of the world and overwrite the past. Point-in-time data keeps the past as it was known.

Two dates on every row

The first date is when the event happened or when the source published it: the deed recorded, the permit issued, the license status changed, the listing appeared. The second date is when the observer captured it. The gap between them is the lag, and the lag is the whole problem. A deed recorded on the first of the month might not appear in a county's public index for two weeks. A strategy that trades on the first, using data that was not visible until the fifteenth, has look-ahead bias, and its backtest is fiction.

Where look-ahead bias hides

Restatements are the obvious case: a value that was later corrected, with the correction silently replacing the original. Property data has subtler versions. Assessor values are set once a year but published on a rolling basis by county. License rosters are updated on the regulator's schedule, and a licensee's status on a given date is only knowable from a snapshot taken on that date. Listings are edited after they appear: price cuts overwrite prices, and a withdrawn listing may vanish entirely from a current-state table. Company headcounts on professional profiles are revised as profiles catch up with reality. In each case a current-state table tells you what is true now and destroys what was believed then.

Snapshots, not overwrites

The fix is to keep every capture. Monthly snapshots of a license roster let you reconstruct the active count on any past date, with the regulator's own vocabulary preserved. Daily captures of listings keep every price and every status, so a price-cut series can be built after the fact. Deeds and permits carry both the recording date and the first-seen date, so a study can shift its signal to the moment the record became visible. This costs storage and it costs discipline, which is why exhaust-data vendors rarely do it.

Building a panel from public record

Public-record panels have a property that app and card data lack: every source can be named. County recorders, assessors, city permit offices, state licensing regulators and public listing surfaces are all identifiable, their publication cadences are knowable, and their gaps can be documented. A compliance officer can read the source list. There is no panel of unknown people whose composition shifts. The trade-off is that public record is slower than exhaust, and a research team has to decide whether a defensible signal with a lag beats a fast signal with a provenance problem. For many housing, labor and construction questions it does.

What to ask a vendor

Whether both dates are on every row. How far back the snapshots go, per panel, because it varies. Whether deleted and withdrawn records are retained with their deletion date. Whether entity identifiers are stable across snapshots so that a company or a brokerage can be followed. And whether the methodology is written down, because a panel whose construction changes without notice cannot be backtested at all. Our alternative data page answers each of those for our own panels.

Questions