आपके मैक्रो बैकटेस्ट में संशोधित रोजगार रिपोर्ट पर कारोबार हुआ

पेरोल-फ़िल्टर रणनीति बनाने वाले प्रिय साथी,

आपने एक सरल नियम बनाया है: अमेरिकी रोजगार रिपोर्ट के बाद, अगर मासिक पेरोल वृद्धि 175,000 से अधिक हो तो आपकी रणनीति पाँच सत्रों तक इक्विटी ETF रखती है। वरना, यह नकद में रहती है। आपने इक्विटी बाज़ार खुलने के बाद प्रवेश तय किया, ट्रेडिंग लागत शामिल की और सीमा स्थिर रखी। फिर आपने ऐतिहासिक पेरोल डेटा श्रृंखला डाउनलोड करके उससे हर संकेत दोबारा बनाया।

अब समस्या उस डाउनलोड में है। ऐतिहासिक आर्थिक डेटा श्रृंखला में संशोधित अनुमान हो सकते हैं, जो उन तारीखों पर उपलब्ध नहीं थे जब आपकी रणनीति के कारोबार करने का दावा है। मैक्रो संकेत का ईमानदारी से बैकटेस्ट करने के लिए, आपको हर निर्णय के समय उपलब्ध संस्करण चाहिए। प्रवेश को एक बार आगे खिसकाने से दो महीने बाद प्रकाशित हुआ आंकड़ा ठीक नहीं हो जाता।

जनवरी के आपके आंकड़े की कई वर्षगाँठें हैं

यह काल्पनिक रिलीज़ इतिहास देखें। ये तारीखें और पेरोल में बदलाव प्रक्रिया समझाने के लिए हैं; ये रिपोर्ट किए गए आर्थिक परिणाम नहीं हैं।

अगर आपके डाउनलोड में जनवरी का आंकड़ा +210,000 है, तो आपका रीप्ले फ़रवरी में ETF में प्रवेश करता है। आपका असली नियम नकद में ही रहता। कीमतें, ऑर्डर का समय और कमीशन—सब सही हो सकते हैं, फिर भी वह पूरा कारोबार काल्पनिक है।

यह मानकर नहीं चल सकते कि इस गड़बड़ी से प्रदर्शन बेहतर हो जाएगा। संशोधन से मुनाफ़े वाले कारोबार बन सकते हैं, घाटे वाले कारोबार बन सकते हैं या दोनों में से कोई भी हट सकता है। खामी यह है कि आपका सिमुलेशन ऐसे सवाल का जवाब देता है जो आपकी रणनीति उस समय पूछ ही नहीं सकती थी।

और जनवरी सिर्फ़ वह अवधि है जिसे मापा जा रहा है। यह वह तारीख नहीं है जब आपको माप का पता चला। जनवरी 1 के नाम वाली पंक्ति आपको उसे जनवरी 1 को ट्रेड करने की अनुमति नहीं देती।

हर मान के लिए उपलब्धता का इतिहास रखें

आपकी शोध तालिका में माह और संख्या से अधिक जानकारी चाहिए। संदर्भ अवधि, मान, रिलीज़ का टाइमस्टैम्प, विंटेज पहचानकर्ता और स्रोत रखें। लगातार डेटा जुटाते समय यह भी दर्ज करें कि आपके सिस्टम को रिलीज़ कब मिली। पुराने संस्करणों के मानों को वहीं बदलने के बजाय उन्हें सुरक्षित रखें।

निर्णय के टाइमस्टैम्प पर, हर अवलोकन का सबसे नया पात्र संस्करण चुनें जिसका उपलब्धता टाइमस्टैम्प उस निर्णय के समय से बाद का न हो। फिर उस पुनर्निर्मित स्नैपशॉट से अपने फ़ीचर निकालें।

आपकी पाँच सत्रों की होल्डिंग अवधि इस हिसाब-किताब को वैकल्पिक नहीं बनाती। इससे आपको प्रवेश का समय सावधानी से चुनने की अधिक गुंजाइश मिलती है; संशोधनों तक पहले पहुँच नहीं मिलती।

पुराने शोध में, हो सकता है कि आपके पास सार्वजनिक रिलीज़ के समय का प्रमाण हो, लेकिन आपको डेटा मिलने का कोई रिकॉर्ड न हो। इस अंतर को स्पष्ट रखें। आप दस्तावेज़ित प्रकाशन टाइमस्टैम्प के बाद एक तय देरी मानकर पहुँच का मॉडल बना सकते हैं। उस धारणा को ऐतिहासिक डिलीवरी का मापा हुआ समय नहीं बता सकते।

आपको समय क्षेत्र की जानकारी वाला टाइमस्टैम्प भी चाहिए। रिलीज़ का दस्तावेज़ित स्थानीय समय रखें और उसे सही ढंग से बदलें; न्यूयॉर्क के लिए स्थिर UTC ऑफ़सेट, डेलाइट सेविंग के बदलावों के दौरान गलत पड़ेगा। अपने भविष्य के लिए यह छोटी-सी सुविधा कर दें। सितंबर वाले आपको मार्च वाले आपकी date_actual_final2 नाम की कॉलम का मतलब न समझना पड़े।

आपके रोलिंग फ़ीचर को पूरा विंटेज चाहिए

मान लें कि आप स्थिर सीमा की जगह यह नियम रखते हैं: “पेरोल वृद्धि पिछले बारह महीनों के औसत से अधिक है।” अब आपको उस निर्णय के समय तक के पिछले अवलोकन चाहिए, जिनमें तब तक प्रकाशित संशोधन भी शामिल हों।

हर महीने की पहली रिलीज़ को हमेशा इस्तेमाल करने से एक अलग फ़ीचर बनता है। अगर आप शुरुआती घोषणाओं का इतिहास चाहते हैं, तो यह एक वैध डिज़ाइन हो सकता है। लेकिन इससे किसी खास सुबह दिख रहा आर्थिक इतिहास दोबारा नहीं बनता, क्योंकि उस सुबह की जानकारी में पहले के महीनों के संशोधन पहले से शामिल हो सकते हैं।

अगर आप रोज़गार स्तरों से मासिक पेरोल बदलाव निकालते हैं, तो अंतर निकालने से पहले संबंधित विंटेज के लिए स्तरों की श्रृंखला फिर से बनाएँ। नए जारी स्तर को पिछले महीने के पुराने विंटेज वाले स्तर के साथ मिलाने से ऐसा बदलाव बन सकता है जो किसी प्रकाशित स्नैपशॉट में था ही नहीं।

इसलिए आपको तय करना होगा कि आपके फ़ीचर का मतलब क्या है: शुरुआती घोषणाएँ, उपलब्ध नवीनतम आर्थिक तस्वीर या स्वयं संशोधन। “पेरोल वृद्धि” से बहुत कुछ अनिर्णीत रह जाता है।

दस साल दोबारा चलाने से पहले एक रिलीज़ ठीक करें

आप शुरुआत ALFRED से कर सकते हैं, जो कई आर्थिक डेटा श्रृंखलाओं का विंटेज इतिहास उपलब्ध कराता है। अपनी खास डेटा श्रृंखला और अवधि के लिए कवरेज जाँचें। सिर्फ़ विंटेज की तारीख से उसी दिन के भीतर उपलब्धता साबित नहीं होती; उसी दिन के संकेत में इस्तेमाल करने से पहले इसे दस्तावेज़ित रिलीज़ समय से जोड़ें।

पहली जाँच के लिए एक रिलीज़ चुनें और उसे हाथ से फिर से बनाएँ:

1. संग्रहित रिलीज़ ढूँढ़ें और उसका प्रकाशन टाइमस्टैम्प, संदर्भ माह और शुरुआती मान दर्ज करें।
2. प्रवेश से पहले आपकी रणनीति को जो इनपुट स्नैपशॉट मिला होता, उसे फिर से बनाएँ।
3. संकेत की गणना हाथ से करें और अपने रीप्ले से उसकी तुलना करें।
4. डेटा स्टोर में बाद का संशोधन जोड़ें और जाँचें कि पहले का निर्णय अपरिवर्तित रहे।

यह आखिरी जाँच स्वचालित शोध पाइपलाइन में खास तौर पर उपयोगी है। शोध एजेंट को फ़ीचर मानों के साथ स्नैपशॉट की कटऑफ़ और चुने गए विंटेज पहचानकर्ता दें। आपको इतना प्रमाण चाहिए कि डेटाबेस बढ़ने के बाद भी किसी कारोबार को एक खास रिलीज़ तक खोजा जा सके।

उस एक निर्णय को सफलतापूर्वक दोहराने के बाद, पूरा इतिहास फिर चलाएँ और रिटर्न की तुलना से पहले संकेतों में मतभेद देखें। गिनें कि सुधार से कितने प्रवेश बने, हटे या खिसके। सिर्फ़ पहले और बाद के Sharpe से ज़्यादा जानकारी आपको इन बदले हुए निर्णयों से मिलेगी।

आपका फ़रवरी का कारोबार फ़रवरी की जानकारी पर खरा उतरना चाहिए। अप्रैल का संशोधन अप्रैल में ही रहने दें।