Makrobacktesten din handlet på de reviderte jobbtallene

Kjære utvikler av lønnsfilterstrategien,

Du har laget en enkel regel: Etter den amerikanske jobbrapporten holder strategien din en aksje-ETF i fem handelsøkter hvis den månedlige lønnsveksten overstiger 175,000. Ellers står den i kontanter. Du har lagt inn inngang etter at aksjemarkedet åpner, tatt med handelskostnader og holdt terskelen fast. Deretter lastet du ned en historisk lønnsserie og brukte den til å rekonstruere hvert signal.

Det gjenstående problemet er nedlastingen. En historisk økonomisk serie kan inneholde reviderte estimater som ikke var tilgjengelige på datoene strategien angivelig handlet. For å backteste et makrosignal på en redelig måte trenger du den versjonen som var tilgjengelig på hvert beslutningstidspunkt. Å flytte inngangen én bar frem reparerer ikke et tall som ble publisert 2 måneder senere.

Januarobservasjonen din har flere fødselsdager

Se på denne oppdiktede publiseringshistorikken. Datoene og lønnsendringene illustrerer mekanikken; de er ikke rapporterte økonomiske resultater.

Hvis nedlastingen din viser januar som +210,000, går simuleringen din inn i ETF-en i februar. Den faktiske regelen din ville ha blitt stående i kontanter. Alle priser, ordreklokkeslett og provisjoner kan være riktige, mens hele handelen likevel er oppdiktet.

Du kan ikke gå ut fra at denne forurensningen gjør resultatene bedre. Revisjoner kan skape vinnende handler, skape tapende handler eller fjerne begge deler. Feilen er at simuleringen besvarer et spørsmål strategien din ikke kunne ha stilt på det tidspunktet.

Og januar er bare perioden som måles. Det er ikke datoen da du fikk vite målingen. En rad merket 1. januar gir deg ikke tillatelse til å handle på den 1. januar.

Gi hver verdi en historikk over når den ble tilgjengelig

Forskningsdatasettet ditt trenger mer enn en måned og et tall. Ta vare på referanseperioden, verdien, publiseringstidspunktet, vintage-ID-en og kilden. Hvis du samler inn data løpende, bør du også registrere når systemet ditt mottok publiseringen. Behold gamle versjoner i stedet for å oppdatere verdiene på stedet.

På et beslutningstidspunkt velger du den nyeste kvalifiserte versjonen av hver observasjon der tilgjengelighetstidspunktet ikke er senere enn beslutningstidspunktet. Beregn deretter funksjonene dine ut fra dette rekonstruerte øyeblikksbildet.

At du holder posisjonen i fem handelsøkter, gjør ikke denne registreringen valgfri. Det gir deg større rom til å velge et forsiktig inngangstidspunkt; det gir deg ikke tidlig tilgang til revisjoner.

I eldre forskning har du kanskje dokumentasjon på offentlig publiseringstidspunkt, men ingen registrering av når du selv mottok dataene. Hold dette skillet tydelig. Du kan modellere tilgang etter et dokumentert publiseringstidspunkt med en oppgitt forsinkelse. Du kan ikke omtale den antakelsen som en målt historisk leveranse.

Du bør også bruke et tidssonebevisst tidsstempel. Lagre det dokumenterte lokale klokkeslettet for publiseringen og konverter det riktig; et fast UTC-avvik for New York vil slå feil ved overgang til og fra sommertid. Gjør denne lille tjenesten for ditt fremtidige jeg. September-deg skal slippe å tyde kolonnen March-deg kalte date_actual_final2.

De rullerende funksjonene dine trenger hele vintagehistorikken

Tenk deg at du erstatter den faste terskelen med «lønnsveksten overstiger gjennomsnittet for de foregående 12 månedene». Nå trenger du de tidligere observasjonene slik de så ut på det aktuelle beslutningstidspunktet, inkludert revisjoner som allerede var publisert da.

Å bruke førstegangspubliseringen for hver måned for alltid definerer en annen funksjon. Det kan være et legitimt design hvis du uttrykkelig ønsker en historikk over de første kunngjøringene. Det rekonstruerer ikke den økonomiske historikken som var synlig en bestemt morgen, fordi informasjonsgrunnlaget den morgenen allerede kan omfatte revisjoner av tidligere måneder.

Hvis du beregner månedlige lønnsendringer fra sysselsettingsnivåer, rekonstruerer du nivåserien for den aktuelle vintagen før du beregner differansene. Hvis du blander et nylig publisert nivå med nivået fra forrige måned i en eldre vintage, kan du lage en endring som ikke fantes i noe publisert øyeblikksbilde.

Du må derfor spesifisere hva funksjonen din betyr: førstegangskunngjøringer, det siste tilgjengelige økonomiske bildet eller selve revisjonene. «Lønnsvekst» avgjør for mye uavklart.

Reparer én publisering før du kjører 10 år på nytt

Du kan begynne med ALFRED, som tilbyr vintagehistorikk for mange økonomiske serier. Sjekk dekningen for akkurat den serien og perioden du trenger. En vintagedato fastslår ikke i seg selv når dataene var tilgjengelige i løpet av dagen; kombiner den med dokumentert publiseringstidspunkt før du bruker den til et signal samme dag.

Velg én publisering til den første kontrollen, og rekonstruer den manuelt:

1. Finn den arkiverte publiseringen, og noter publiseringstidspunktet, referansemåneden og førstegangsverdien.
2. Bygg opp øyeblikksbildet av inndata som strategien din ville ha mottatt før inngangen.
3. Beregn signalet manuelt, og sammenlign det med simuleringen din.
4. Legg en senere revisjon inn i datalageret, og kontroller at den tidligere beslutningen forblir uendret.

Den siste kontrollen er særlig nyttig i en automatisert forskningspipeline. Gi forskningsagenten din grenseverdien for øyeblikksbildet og de valgte vintage-ID-ene sammen med funksjonsverdiene. Du trenger nok dokumentasjon til å spore en handel tilbake til en bestemt publisering, også etter at den underliggende databasen har vokst.

Når den ene beslutningen gjenskapes riktig, kjører du historikken på nytt og sammenligner uenigheter mellom signalene før du sammenligner avkastning. Tell hvor mange innganger reparasjonen skapte, fjernet eller flyttet. Du lærer mer av disse endrede beslutningene enn av én Sharpe-verdi før og etter.

Februarhandelen din må bygge på informasjonen som var tilgjengelig i februar. La aprilrevisjonen bli i april.