Dein Makro-Backtest handelte mit den revidierten Arbeitsmarktdaten

Hallo, Entwickler der Payroll-Filter-Strategie,

Du hast eine einfache Regel erstellt: Nach dem US-Arbeitsmarktbericht hält deine Strategie einen Aktien-ETF fünf Handelssitzungen lang, wenn das monatliche Beschäftigungswachstum über 175,000 liegt. Andernfalls bleibt sie in Cash. Den Einstieg hast du auf die Zeit nach der Markteröffnung gelegt, Handelskosten berücksichtigt und den Schwellenwert unverändert gelassen. Dann hast du eine historische Payroll-Reihe heruntergeladen und damit jedes Signal rekonstruiert.

Dein verbleibendes Problem ist der Download. Eine historische Wirtschaftsreihe kann revidierte Schätzungen enthalten, die an den Tagen, an denen deine Strategie angeblich gehandelt hat, noch nicht verfügbar waren. Um ein Makrosignal sauber zu backtesten, brauchst du die jeweils zum Entscheidungszeitpunkt verfügbare Version. Den Einstieg um einen Takt nach hinten zu verschieben, korrigiert keine Zahl, die erst zwei Monate später veröffentlicht wurde.

Deine Januar-Beobachtung hat mehrere Geburtstage

Nehmen wir diesen erfundenen Veröffentlichungsverlauf. Die Daten und Änderungen bei der Beschäftigung veranschaulichen den Ablauf; sie sind keine gemeldeten Wirtschaftsdaten.

Wenn dein Download für Januar +210,000 enthält, steigt dein Replay im Februar in den ETF ein. Nach deiner tatsächlichen Regel wärst du in Cash geblieben. Jeder Kurs, jeder Zeitstempel der Order und jede Provision kann stimmen, während der gesamte Trade erfunden ist.

Du kannst nicht davon ausgehen, dass diese Verunreinigung die Performance verbessert. Revisionen können profitable Trades erzeugen, Verlusttrades erzeugen oder beides entfernen. Der Fehler besteht darin, dass deine Simulation eine Frage beantwortet, die deine Strategie zu diesem Zeitpunkt gar nicht hätte stellen können.

Und Januar ist lediglich der gemessene Zeitraum. Es ist nicht das Datum, an dem du die Messung erfahren hast. Eine Zeile mit der Beschriftung 1. Januar berechtigt dich nicht dazu, am 1. Januar danach zu handeln.

Halte für jeden Wert fest, wann er verfügbar war

Deine Research-Tabelle braucht mehr als einen Monat und eine Zahl. Bewahre den Bezugszeitraum, den Wert, den Veröffentlichungszeitstempel, die Vintage-Kennung und die Quelle auf. Bei einer laufenden Datenerfassung solltest du zusätzlich festhalten, wann dein System die Veröffentlichung erhalten hat. Bewahre alte Versionen auf, statt ihre Werte direkt zu überschreiben.

Wähle zum Entscheidungszeitpunkt für jede Beobachtung die neueste zulässige Version aus, deren Verfügbarkeitszeitstempel nicht nach dieser Entscheidung liegt. Berechne anschließend deine Features aus diesem rekonstruierten Snapshot.

Die Haltedauer von fünf Sitzungen macht diese Dokumentation nicht überflüssig. Sie lässt dir mehr Spielraum für einen vorsichtigen Einstiegszeitpunkt, verschafft dir aber keinen vorzeitigen Zugriff auf Revisionen.

Bei älterer Research hast du möglicherweise Belege für den Zeitpunkt der öffentlichen Veröffentlichung, aber keine Aufzeichnungen darüber, wann du selbst die Daten erhalten hast. Halte diesen Unterschied ausdrücklich fest. Du kannst den Zugriff nach einem dokumentierten Veröffentlichungszeitpunkt mit einer angegebenen Verzögerung modellieren. Diese Annahme darfst du nicht als gemessene historische Zustellung bezeichnen.

Außerdem brauchst du einen zeitzonenbewussten Zeitstempel. Speichere die dokumentierte Ortszeit der Veröffentlichung und rechne sie korrekt um. Ein fester UTC-Versatz für New York funktioniert wegen der Zeitumstellung nicht das ganze Jahr über. Gönn deinem zukünftigen Ich diese kleine Erleichterung. Dein Ich im September sollte nicht erst herausfinden müssen, was dein Ich im März mit einer Spalte namens date_actual_final2 gemeint hat.

Für deine rollierenden Features brauchst du den vollständigen Vintage

Nehmen wir an, du ersetzt den festen Schwellenwert durch „das Beschäftigungswachstum liegt über seinem Durchschnitt der vergangenen zwölf Monate“. Nun brauchst du die vorherigen Beobachtungen so, wie sie zum jeweiligen Entscheidungszeitpunkt vorlagen, einschließlich aller bis dahin veröffentlichten Revisionen.

Für immer die Erstveröffentlichung jedes Monats zu verwenden, definiert ein anderes Feature. Das kann ein sinnvolles Design sein, wenn du ausdrücklich die Historie der ersten Meldungen abbilden möchtest. Es rekonstruiert aber nicht das Wirtschaftsbild, das an einem bestimmten Morgen verfügbar war, denn der Informationsstand an diesem Morgen kann bereits Revisionen früherer Monate enthalten.

Wenn du monatliche Beschäftigungsänderungen aus Beschäftigungsständen ableitest, rekonstruiere zuerst die Reihe der Beschäftigungsstände für den jeweiligen Vintage und bilde dann die Differenzen. Vermischst du einen neu veröffentlichten Stand mit dem Vormonatsstand aus einem älteren Vintage, kann eine Änderung entstehen, die in keinem veröffentlichten Snapshot enthalten war.

Du musst also festlegen, was dein Feature bedeutet: Erstveröffentlichungen, das jeweils aktuellste verfügbare Wirtschaftsbild oder die Revisionen selbst. „Beschäftigungswachstum“ lässt zu viele Fragen offen.

Repariere eine Veröffentlichung, bevor du zehn Jahre neu berechnest

Beginnen kannst du mit ALFRED. Der Dienst stellt Vintage-Historien für viele Wirtschaftsreihen bereit. Prüfe, ob deine konkrete Reihe und der gewünschte Zeitraum abgedeckt sind. Ein Vintage-Datum allein belegt keine Verfügbarkeit innerhalb des Tages. Ergänze es um dokumentierte Veröffentlichungszeiten, bevor du es für ein Signal am selben Tag verwendest.

Wähle für deine erste Prüfung eine Veröffentlichung aus und rekonstruiere sie von Hand:

1. Finde die archivierte Veröffentlichung und notiere ihren Veröffentlichungszeitstempel, den Bezugsmonat und den Erstwert.
2. Rekonstruiere den Input-Snapshot, den deine Strategie vor dem Einstieg erhalten hätte.
3. Berechne das Signal von Hand und vergleiche es mit deinem Replay.
4. Füge dem Datenspeicher eine spätere Revision hinzu und prüfe, ob die frühere Entscheidung unverändert bleibt.

Diese letzte Prüfung ist besonders nützlich in einer automatisierten Research-Pipeline. Gib deinem Research-Agent den Snapshot-Stichtag und die ausgewählten Vintage-Kennungen zusammen mit den Feature-Werten. Du brauchst genügend Belege, um einen Trade auch dann auf eine bestimmte Veröffentlichung zurückzuführen, wenn die zugrunde liegende Datenbank weitergewachsen ist.

Sobald sich diese einzelne Entscheidung reproduzieren lässt, berechne die Historie neu und vergleiche zuerst die abweichenden Signale und danach die Renditen. Zähle, wie viele Einstiege durch die Korrektur hinzugekommen, weggefallen oder verschoben worden sind. Aus diesen geänderten Entscheidungen lernst du mehr als aus einem einzelnen Sharpe-Vergleich vorher und nachher.

Dein Februar-Trade muss mit dem Informationsstand vom Februar Bestand haben. Lass die April-Revision im April.