Your macro backtest is probably cheating

Ask a macro series what GDP growth was in a given quarter and you get one number. Ask it what that number was on the day it first printed, and you often get a different one. Employment, output, and inventory series are revised — sometimes for years, sometimes materially — and the revision is not noise. It is a systematic correction that later data makes possible.

Why this quietly breaks backtests

A backtest that reads today's value of last decade's data point gives your strategy information that did not exist at the time. The bias runs in a predictable direction: revisions tend to sharpen turning points, so a model trained on revised history looks unusually good at calling recessions it could not have called live.

• Release lag — the reference period ends well before the number is published. Aligning on reference date instead of publication date leaks the future.
• Revision vintages — the same reference period has many values over time, one per vintage.
• Benchmark revisions — periodic rebasing rewrites long stretches of history at once.

The discipline

1. 1.Store the publication timestamp alongside the reference period, and index on publication.
2. 2.When in doubt, lag the series by its typical release delay rather than assuming same-day availability.
3. 3.Test the sensitivity: rerun with an extra month of lag. If the result collapses, the edge was in the revisions, not the signal.

Our macro endpoints return the current value of each observation against its reference date, along with the series frequency — which is what you need to apply the right release lag yourself. We do not yet serve historical vintages, so if your study depends on what a number looked like on a specific past day, lag it deliberately rather than assuming the stored value was live.

curl -H "Authorization: Bearer $HEDGEFRIEND_KEY" \
  "https://api.hedgefriend.dev/v1/macro/series/UNRATE?from=2015-01-01"