Din makrobacktest handlede på den reviderede jobrapport

Kære udvikler af lønfilterstrategien,

Du har bygget en enkel regel: Efter den amerikanske jobrapport holder din strategi en aktie-ETF i fem sessioner, hvis den månedlige lønvækst overstiger 175,000. Ellers bliver den stående i kontanter. Du har planlagt indgangen efter aktiemarkedets åbning, medregnet handelsomkostninger og fastholdt tærsklen. Derefter downloadede du en historisk lønserie og brugte den til at genskabe hvert signal.

Det resterende problem er dataene, du har downloadet. En historisk økonomisk serie kan indeholde reviderede estimater, som ikke var tilgængelige på de datoer, hvor din strategi angiveligt handlede. Hvis du vil backteste et makrosignal på retvisende vis, skal du bruge den version, der var tilgængelig på hvert beslutningstidspunkt. At flytte indgangen én bar frem retter ikke op på et tal, der først blev offentliggjort to måneder senere.

Din observation for januar har flere fødselsdage

Se på denne opdigtede offentliggørelseshistorik. Datoerne og lønændringerne illustrerer mekanikken; de er ikke offentliggjorte økonomiske resultater.

Hvis din download viser januar som +210,000, går din replay ind i ETF'en i februar. Din faktiske regel ville være blevet stående i kontanter. Alle priser, ordretidspunkter og provisioner kan være korrekte, selv om hele handlen er fiktiv.

Du kan ikke gå ud fra, at denne forurening forbedrer resultaterne. Revisioner kan skabe vindende handler, skabe tabende handler eller fjerne begge dele. Fejlen er, at din simulering besvarer et spørgsmål, som din strategi ikke kunne have stillet på det tidspunkt.

Og januar er kun den periode, der måles. Det er ikke datoen, hvor du fik kendskab til målingen. En række mærket 1. januar giver dig ikke lov til at handle på den 1. januar.

Før en tilgængelighedshistorik for hver værdi

Din researchtabel har brug for mere end en måned og et tal. Gem referenceperioden, værdien, offentliggørelsestidspunktet, vintage-id'et og kilden. Hvis du løbende indsamler data, skal du også registrere, hvornår dit system modtog offentliggørelsen. Bevar gamle versioner i stedet for at opdatere værdierne på stedet.

På et beslutningstidspunkt skal du vælge den nyeste kvalificerede version af hver observation, hvis tilgængelighedstidspunkt er senest på beslutningstidspunktet. Beregn derefter dine features ud fra dette genskabte øjebliksbillede.

Din holdeperiode på fem sessioner gør ikke denne registrering valgfri. Den giver dig mere spillerum til at vælge et forsigtigt indgangstidspunkt; den giver dig ikke tidlig adgang til revisioner.

I ældre research har du måske dokumentation for det offentlige offentliggørelsestidspunkt, men ingen registrering af, hvornår du selv modtog dataene. Hold den forskel tydelig. Du kan modellere adgang efter et dokumenteret offentliggørelsestidspunkt med en angivet forsinkelse. Du kan ikke beskrive den antagelse som en målt historisk levering.

Du får også brug for et tidsstempel, der tager højde for tidszoner. Gem offentliggørelsens dokumenterede lokale tidspunkt, og konvertér det korrekt; en fast UTC-forskydning for New York holder ikke, når sommertid skifter. Gør din fremtidige version af dig selv den lille tjeneste. September-dig skal ikke afkode en kolonne fra marts-dig, der hedder date_actual_final2.

Dine rullende features kræver hele vintagen

Forestil dig, at du erstatter den faste tærskel med “lønvæksten overstiger gennemsnittet for de foregående tolv måneder”. Nu skal du bruge de tidligere observationer, sådan som de så ud på beslutningstidspunktet, inklusive revisioner, der allerede var offentliggjort på det tidspunkt.

Hvis du bruger den første offentliggørelse for hver måned for altid, definerer du en anden feature. Det kan være et legitimt design, hvis du udtrykkeligt ønsker en historik over de første meddelelser. Det genskaber ikke den økonomiske historik, der var synlig på en bestemt morgen, for morgenens informationsgrundlag kan allerede omfatte revisioner af tidligere måneder.

Hvis du udleder månedlige lønændringer fra beskæftigelsesniveauer, skal du genskabe niveauserien for den relevante vintage, før du beregner differencer. Hvis du blander et nyoffentliggjort niveau med forrige måneds niveau fra en ældre vintage, kan du skabe en ændring, som ikke fandtes i noget offentliggjort øjebliksbillede.

Du skal derfor definere, hvad din feature betyder: de første offentliggørelser, det senest tilgængelige økonomiske billede eller selve revisionerne. “Lønvækst” efterlader for meget uafklaret.

Reparér én offentliggørelse, før du genkører ti år

Du kan begynde med ALFRED, som tilbyder vintagehistorik for mange økonomiske serier. Kontrollér, om netop din serie og periode er dækket. En vintage-dato dokumenterer ikke i sig selv tilgængelighed i løbet af dagen; supplér den med dokumenteret offentliggørelsestidspunkt, før du bruger den til et signal samme dag.

Vælg én offentliggørelse til din første kontrol, og genskab den manuelt:

1. Find den arkiverede offentliggørelse, og registrér offentliggørelsestidspunktet, referencemåneden og den oprindelige værdi.
2. Genskab det inputøjebliksbillede, som din strategi ville have modtaget før indgangen.
3. Beregn signalet manuelt, og sammenlign det med din replay.
4. Tilføj en senere revision til datalageret, og kontrollér, at den tidligere beslutning forbliver uændret.

Den sidste kontrol er særligt nyttig i en automatiseret researchpipeline. Giv din researchagent skæringspunktet for øjebliksbilledet og de valgte vintage-id'er sammen med featureværdierne. Du har brug for tilstrækkelig dokumentation til at spore en handel tilbage til en bestemt offentliggørelse, også efter at den underliggende database er vokset.

Når den ene beslutning kan genskabes, skal du genkøre historikken og sammenligne uenigheder mellem signalerne, før du sammenligner afkast. Tæl indgange, som reparationen har tilføjet, fjernet eller flyttet. Du lærer mere af de ændrede beslutninger end af en enkelt Sharpe før og efter.

Din handel i februar skal kunne stå på februars information. Lad aprils revision blive i april.