سازندهٔ راهبردِ فیلتر حقوق‌بگیری،
یک قاعدهٔ ساده ساخته‌اید: پس از گزارش اشتغال آمریکا، اگر رشد ماهانهٔ حقوق‌بگیران از 175,000 بیشتر باشد، راهبردتان به‌مدت 5 جلسهٔ معاملاتی یک ETF سهامی نگه می‌دارد؛ در غیر این صورت، نقد می‌ماند. ورود را پس از بازشدن بازار سهام برنامه‌ریزی کرده‌اید، هزینه‌های معامله را لحاظ کرده‌اید و آستانه را ثابت نگه داشته‌اید. بعد هم یک مجموعهٔ تاریخی از حقوق‌بگیران دانلود کرده‌اید و از آن برای بازسازی همهٔ سیگنال‌ها استفاده کرده‌اید.
مشکل باقی‌مانده در همان دادهٔ دانلودشده است. یک مجموعهٔ اقتصادی تاریخی ممکن است برآوردهای بازبینی‌شده‌ای داشته باشد که در تاریخ‌هایی که گویا راهبردتان معامله کرده، هنوز در دسترس نبوده‌اند. برای اینکه سیگنال کلان را صادقانه بک‌تست کنید، به نسخه‌ای نیاز دارید که در هر زمان تصمیم‌گیری در دسترس بوده است. جلو بردن زمان ورود به‌اندازهٔ 1 کندل، عددی را که 2 ماه بعد منتشر شده اصلاح نمی‌کند.
مشاهدهٔ ژانویهٔ شما چند بار متولد می‌شود
این تاریخچهٔ انتشارِ ساختگی را ببینید. تاریخ‌ها و تغییرات حقوق‌بگیران سازوکار را نشان می‌دهند؛ این‌ها نتایج اقتصادیِ گزارش‌شده نیستند.
| انتشار | ماه مرجع | تغییر گزارش‌شدهٔ حقوق‌بگیران | قاعدهٔ شما در زمان انتشار |
|---|---|---|---|
| 7 فوریه، 08:30 ET | ژانویه | +150,000 | نقد می‌ماند |
| 7 مارس، 08:30 ET | ژانویه، بازبینی‌شده | +185,000 | تصمیم فوریه را بازنویسی نمی‌کند |
| 4 آوریل، 08:30 ET | ژانویه، بازبینی‌شده برای بار دوم | +210,000 | تصمیم فوریه را بازنویسی نمی‌کند |
اگر دادهٔ دانلودشدهٔ شما ژانویه را +210,000 نشان دهد، بازپخش شما در فوریه وارد ETF می‌شود. قاعدهٔ واقعی‌تان باید نقد می‌ماند. ممکن است همهٔ قیمت‌ها، زمان‌مهر سفارش‌ها و کارمزدها درست باشند، اما کل آن معامله ساختگی باشد.
نمی‌توانید فرض کنید این آلودگی عملکرد را بهتر می‌کند. بازبینی‌ها ممکن است معامله‌های سودآور یا زیان‌ده بسازند یا هرکدام را حذف کنند. ایراد این است که شبیه‌سازی‌تان به پرسشی پاسخ می‌دهد که راهبردتان در آن زمان نمی‌توانسته مطرح کند.
تازه ژانویه فقط دوره‌ای است که اندازه‌گیری می‌شود؛ تاریخِ آگاه‌شدن از آن اندازه‌گیری نیست. ردیفی با برچسب 1 ژانویه به شما اجازه نمی‌دهد در 1 ژانویه بر اساس آن معامله کنید.
برای هر مقدار، تاریخچهٔ در دسترس‌بودن نگه دارید
جدول پژوهشی‌تان به چیزی بیشتر از یک ماه و یک عدد نیاز دارد. دورهٔ مرجع، مقدار، زمان‌مهر انتشار، شناسهٔ نسخه و منبع را نگه دارید. اگر داده را پیوسته گردآوری می‌کنید، زمان دریافت انتشار توسط سیستم‌تان را هم ثبت کنید. نسخه‌های قدیمی را حفظ کنید و مقدارشان را درجا به‌روزرسانی نکنید.
در زمان هر تصمیم، تازه‌ترین نسخهٔ مجاز از هر مشاهده را انتخاب کنید که زمان‌مهر در دسترس‌بودنش دیرتر از زمان آن تصمیم نباشد. سپس ویژگی‌هایتان را از آن نمای بازسازی‌شده محاسبه کنید.
قاعدهٔ بازیابی شما: اول رکوردها را به آنچه در دسترس بوده محدود کنید، بعد نسخه‌های مربوط را انتخاب کنید و سپس سیگنال را محاسبه کنید. محاسبهٔ ویژگی‌ها بر اساس تاریخچهٔ بازبینی‌شدهٔ امروز و جابه‌جاکردن نتیجه به زمانی پیش‌تر، نشت اطلاعات را حفظ می‌کند.
دورهٔ نگهداری 5 جلسه‌ای، این ثبت و نگهداری را اختیاری نمی‌کند. فقط فضای بیشتری برای انتخاب زمان ورودِ محافظه‌کارانه در اختیارتان می‌گذارد؛ دسترسی زودهنگام به بازبینی‌ها نمی‌دهد.
برای پژوهش‌های قدیمی‌تر، شاید مدرکی از زمان انتشار عمومی داشته باشید، اما سابقه‌ای از زمان دریافت خودتان در اختیار نباشد. این تفاوت را روشن نگه دارید. می‌توانید با ذکر یک تأخیر مشخص، دسترسی را پس از زمان انتشار مستندشده مدل کنید؛ اما نمی‌توانید این فرض را دریافت تاریخیِ اندازه‌گیری‌شده بنامید.
به زمان‌مهری هم نیاز دارید که منطقهٔ زمانی را در نظر بگیرد. زمان محلیِ مستندشدهٔ انتشار را ذخیره و درست تبدیل کنید؛ اختلاف ثابت UTC برای نیویورک با تغییر ساعت تابستانی از کار می‌افتد. این لطف کوچک را در حق خودِ آینده‌تان بکنید. شما در سپتامبر نباید مجبور شوید ستونی به نام date_actual_final2 را که خودتان در مارس ساخته‌اید رمزگشایی کنید.
ویژگی‌های متحرک شما به کل نسخهٔ داده نیاز دارند
فرض کنید آستانهٔ ثابت را با «رشد حقوق‌بگیران از میانگین 12 ماه گذشته بیشتر باشد» عوض می‌کنید. حالا به مشاهدات پیشین همان‌طور که در زمان تصمیم وجود داشتند نیاز دارید؛ از جمله بازبینی‌هایی که تا آن زمان منتشر شده بودند.
استفادهٔ همیشگی از نخستین انتشار هر ماه، ویژگی متفاوتی تعریف می‌کند. اگر صریحاً تاریخچهٔ اطلاعیه‌های اولیه را می‌خواهید، این طراحی می‌تواند معتبر باشد. اما تاریخچهٔ اقتصادیِ قابل مشاهده در یک صبح مشخص را بازسازی نمی‌کند، چون مجموعهٔ اطلاعات آن صبح ممکن است از قبل بازبینی ماه‌های گذشته را هم شامل شده باشد.
اگر تغییر ماهانهٔ حقوق‌بگیران را از سطح اشتغال به دست می‌آورید، پیش از محاسبهٔ تفاضل، سری سطح را برای نسخهٔ مربوط بازسازی کنید. ترکیب سطحی که همین حالا منتشر شده با سطح ماه قبل از نسخه‌ای قدیمی‌تر می‌تواند تغییری بسازد که در هیچ نمای منتشرشده‌ای وجود نداشته است.
پس باید مشخص کنید ویژگی‌تان چه معنایی دارد: اطلاعیه‌های اولیه، تازه‌ترین تصویر اقتصادیِ در دسترس، یا خودِ بازبینی‌ها. عبارت «رشد حقوق‌بگیران» چیزهای زیادی را نامشخص می‌گذارد.
پیش از بازاجرای 10 سال داده، یک انتشار را اصلاح کنید
می‌توانید از ALFRED شروع کنید که تاریخچهٔ نسخه‌ها را برای بسیاری از سری‌های اقتصادی ارائه می‌دهد. پوشش سری و دورهٔ دقیق خودتان را بررسی کنید. تاریخ یک نسخه به‌تنهایی زمان در دسترس‌بودن در طول روز را ثابت نمی‌کند؛ اگر برای سیگنال همان روز از آن استفاده می‌کنید، زمان انتشارِ مستندشده را هم کنار آن بگذارید.
برای نخستین بررسی، یک انتشار را انتخاب و با دست بازسازی کنید:
- نسخهٔ بایگانی‌شدهٔ انتشار را پیدا کنید و زمان‌مهر انتشار، ماه مرجع و مقدار اولیه را ثبت کنید.
- نمای ورودی‌ای را بازسازی کنید که راهبردتان پیش از ورود دریافت می‌کرد.
- سیگنال را دستی محاسبه و با بازپخش خود مقایسه کنید.
- یک بازبینی بعدی را به مخزن داده اضافه کنید و مطمئن شوید تصمیم قبلی بدون تغییر می‌ماند.
این بررسی آخر در یک خط لولهٔ پژوهشی خودکار به‌ویژه مفید است. نقطهٔ برش نمای داده و شناسه‌های نسخهٔ انتخاب‌شده را همراه مقادیر ویژگی‌ها در اختیار عامل پژوهشی‌تان بگذارید. باید شواهد کافی داشته باشید تا بتوانید یک معامله را به انتشار مشخصی ردیابی کنید، حتی پس از آنکه پایگاه دادهٔ زیرین بزرگ‌تر شده است.
وقتی آن تصمیم را بازتولید کردید، تاریخچه را دوباره اجرا کنید و پیش از مقایسهٔ بازده‌ها، اختلاف سیگنال‌ها را بسنجید. تعداد ورودهایی را بشمارید که با اصلاح ایجاد، حذف یا جابه‌جا شده‌اند. از این تصمیم‌های تغییریافته بیشتر از یک Sharpe قبل‌و‌بعدِ تنها یاد می‌گیرید.
معاملهٔ فوریهٔ شما باید با اطلاعات فوریه دوام بیاورد. بازبینی آوریل را در آوریل نگه دارید.
← همهٔ مطالب
