Ditt makrobacktest handlade på den reviderade jobbrapporten

Hej du som byggt en strategi med ett lönefilter,

Du har byggt en enkel regel: efter den amerikanska jobbrapporten håller strategin en aktie-ETF i fem handelssessioner om den månatliga löneökningen överstiger 175,000. Annars ligger den i kontanter. Du har schemalagt ingången efter att aktiemarknaden öppnat, räknat med handelskostnader och hållit tröskelvärdet fast. Sedan laddade du ned en historisk löneserie och använde den för att återskapa varje signal.

Det återstående problemet är nedladdningen. En historisk ekonomisk tidsserie kan innehålla reviderade estimat som inte fanns tillgängliga de datum då strategin enligt simuleringen handlade. För att backtesta en makrosignal på ett rättvisande sätt behöver du den version som fanns tillgänglig vid varje beslutstillfälle. Att flytta ingången en stapel framåt rättar inte till en siffra som publicerades två månader senare.

Ditt januarivärde har flera födelsedagar

Titta på den här påhittade publiceringshistoriken. Datumen och löneförändringarna visar hur det fungerar; de är inte rapporterade ekonomiska utfall.

Om din nedladdning visar januari som +210,000 går simuleringen in i ETF:en i februari. Din faktiska regel skulle ha stannat i kontanter. Alla priser, ordertidsstämplar och provisioner kan vara korrekta, samtidigt som hela affären är påhittad.

Du kan inte utgå från att den här förvanskningen förbättrar resultaten. Revideringar kan skapa vinnande affärer, skapa förlustaffärer eller ta bort endera. Felet är att simuleringen besvarar en fråga som strategin inte hade kunnat ställa då.

Och januari är bara perioden som mäts. Det är inte datumet då du fick veta mätvärdet. En rad märkt 1 januari ger dig inte rätt att handla på den 1 januari.

Ge varje värde en tillgänglighetshistorik

Din forskningstabell behöver mer än en månad och en siffra. Spara referensperiod, värde, publiceringstid, versionsidentifierare och källa. Om du samlar in data löpande ska du också registrera när systemet tog emot publiceringen. Bevara äldre versioner i stället för att skriva över deras värden.

Vid en beslutstidpunkt väljer du den senaste giltiga versionen av varje observation vars tillgänglighetstid inte är senare än beslutet. Beräkna sedan dina variabler från den återskapade ögonblicksbilden.

Din innehavstid på fem handelssessioner gör inte den här bokföringen valfri. Den ger dig större utrymme att välja en försiktig ingångstid; den ger dig inte tidigare tillgång till revideringar.

I äldre forskning kanske du kan belägga publiceringstiden, men saknar uppgifter om när du själv tog emot informationen. Håll isär de två. Du kan modellera åtkomst efter en dokumenterad publiceringstid med en angiven fördröjning. Du kan inte beskriva det antagandet som en uppmätt historisk leveranstid.

Du behöver också tidsstämplar med tidszon. Spara publiceringens dokumenterade lokala tid och konvertera den korrekt; ett fast UTC-offset för New York fungerar inte när sommartiden växlar. Gör framtida du den lilla tjänsten. September-du ska inte behöva tyda mars-du:s kolumn med namnet date_actual_final2.

Dina rullande variabler behöver hela versionshistoriken

Anta att du ersätter det fasta tröskelvärdet med ”löneökningen överstiger genomsnittet för de senaste tolv månaderna”. Då behöver du de tidigare observationerna så som de såg ut vid beslutstidpunkten, inklusive revideringar som hade publicerats då.

Om du för alltid använder den första publiceringen för varje månad definierar du en annan variabel. Det kan vara ett legitimt upplägg om du uttryckligen vill följa de första offentliggörandena. Men det återskapar inte den ekonomiska historik som var synlig en viss morgon, eftersom den morgonens informationsmängd redan kan innehålla revideringar av tidigare månader.

Om du räknar fram månatliga löneförändringar från sysselsättningsnivåer ska du återskapa nivåserien för den relevanta versionen innan du beräknar förändringen. Om du blandar en nypublicerad nivå med föregående månads nivå från en äldre version kan du skapa en förändring som aldrig förekom i någon publicerad ögonblicksbild.

Därför behöver du precisera vad variabeln betyder: första publiceringar, den senast tillgängliga ekonomiska bilden eller själva revideringarna. ”Löneökning” lämnar för mycket oklart.

Rätta till en publicering innan du kör om tio år

Du kan börja med ALFRED, som tillhandahåller versionshistorik för många ekonomiska tidsserier. Kontrollera att just din serie och period täcks. Ett versionsdatum fastställer inte tillgänglighet under dagen; komplettera med dokumenterad publiceringstid innan du använder uppgiften för en signal samma dag.

Börja granskningen med en publicering och återskapa den manuellt:

1. Hitta den arkiverade publiceringen och registrera publiceringstid, referensmånad och ursprungligt värde.
2. Bygg upp den indatasnapshot som strategin skulle ha fått före ingången.
3. Beräkna signalen manuellt och jämför med simuleringen.
4. Lägg till en senare revidering i datalagret och kontrollera att det tidigare beslutet förblir oförändrat.

Den sista kontrollen är särskilt användbar i en automatiserad forskningspipeline. Ge din forskningsagent tidsgränsen för ögonblicksbilden och de valda versionsidentifierarna tillsammans med variabelvärdena. Du behöver tillräckligt med underlag för att spåra en affär tillbaka till en viss publicering, även när den underliggande databasen har vuxit.

När det enskilda beslutet går att återskapa kör du om historiken och jämför avvikande signaler innan du jämför avkastning. Räkna hur många ingångar som skapats, tagits bort eller flyttats av rättningen. Du lär dig mer av de ändrade besluten än av en ensam Sharpe-jämförelse före och efter.

Din februaribaffär måste hålla för informationen som fanns i februari. Låt aprilrevideringen stanna i april.