Ваш макробектест торгував за переглянутим звітом про зайнятість

Вітаю, розробнику стратегії на основі фільтра за зайнятістю!

Ви створили просте правило: після звіту США про зайнятість стратегія тримає ETF на акції протягом 5 торгових сесій, якщо приріст зайнятості за місяць перевищує 175,000. Інакше вона залишається в грошах. Ви запланували вхід після відкриття фондового ринку, врахували торгові витрати й зафіксували поріг. Потім завантажили історичний ряд зайнятості й використали його, щоб відтворити кожен сигнал.

Залишилася проблема із завантаженими даними. Історичний економічний ряд може містити переглянуті оцінки, яких не було на момент, коли ваша стратегія нібито торгувала. Щоб чесно бектестувати макросигнал, потрібна версія, доступна на час кожного рішення. Перенесення входу на 1 бар уперед не виправить використання цифри, опублікованої 2 місяці потому.

Ваше січневе спостереження має кілька днів народження

Розгляньмо вигадану історію публікацій. Ці дати й зміни зайнятості лише ілюструють механіку; це не фактичні економічні результати.

Якщо у вашому завантаженні за січень стоїть +210,000, під час відтворення стратегія купить ETF у лютому. Насправді за вашим правилом вона залишилася б у грошах. Усі ціни, часові мітки ордерів і комісії можуть бути правильними, але вся ця угода — вигадана.

Не можна припускати, що таке забруднення даних завжди покращує результати. Перегляди можуть створити прибуткові чи збиткові угоди або прибрати ті чи інші з них. Проблема в тому, що симуляція відповідає на запитання, яке ваша стратегія не могла поставити на той момент.

А січень — це лише період, який вимірюють. Це не дата, коли ви дізналися результат вимірювання. Рядок із позначкою «1 січня» не дає вам права торгувати за ним 1 січня.

Збережіть історію доступності кожного значення

У дослідницькій таблиці потрібно зберігати не лише місяць і число. Записуйте звітний період, значення, часову мітку публікації, ідентифікатор версії даних і джерело. Для постійного збору даних також фіксуйте, коли ваша система отримала публікацію. Зберігайте старі версії, а не перезаписуйте їхні значення.

На момент ухвалення рішення виберіть найновішу допустиму версію кожного спостереження, час доступності якої не пізніший за час цього рішення. Потім обчисліть ознаки на основі відновленого знімка даних.

Період утримання позиції протягом 5 сесій не робить цей облік необов’язковим. Він дає більше свободи вибрати обережний час входу, але не забезпечує завчасного доступу до переглядів.

Для давніших досліджень у вас можуть бути підтвердження часу публічної публікації, але не запис часу отримання даних вашою системою. Чітко розрізняйте ці моменти. Ви можете змоделювати доступ після документально підтвердженої публікації із зазначеною затримкою. Але не можна називати таке припущення виміряним часом історичної доставки.

Також потрібна часова мітка з часовим поясом. Зберігайте задокументований місцевий час публікації та правильно конвертуйте його: незмінне зміщення UTC для Нью-Йорка не працюватиме під час переходів на літній час. Подбайте про себе в майбутньому. Вам, вересневому собі, не доведеться розшифровувати стовпець березневого себе з назвою date_actual_final2.

Для ковзних ознак потрібна вся історія версій

Уявімо, що замість фіксованого порога ви використовуєте правило «приріст зайнятості перевищує середнє за попередні 12 місяців». Тепер потрібні попередні спостереження в тому вигляді, у якому вони існували на момент рішення, зокрема з усіма переглядами, опублікованими до цього часу.

Якщо назавжди брати першу публікацію за кожен місяць, це визначатиме іншу ознаку. Такий підхід може бути цілком доречним, якщо вам потрібна саме історія первинних оголошень. Але він не відтворить економічну історію, доступну конкретного ранку, адже на той час набір інформації міг уже містити перегляди за попередні місяці.

Якщо ви обчислюєте щомісячну зміну зайнятості на основі рівнів зайнятості, спершу відновіть ряд рівнів для відповідної версії даних, а вже потім обчислюйте різницю. Поєднання щойно опублікованого рівня зі значенням за попередній місяць з давнішої версії може створити зміну, якої не було в жодному опублікованому знімку даних.

Тож треба чітко визначити, що означає ваша ознака: первинні оголошення, найновіша доступна картина економіки чи самі перегляди. Назва «приріст зайнятості» залишає надто багато запитань без відповіді.

Виправте одну публікацію, перш ніж перераховувати 10 років

Почати можна з ALFRED: там є історії версій для багатьох економічних рядів. Перевірте, чи доступні саме потрібний ряд і період. Сама дата версії не підтверджує доступність даних протягом дня. Для сигналу того ж дня потрібен документально підтверджений час публікації.

Для першої перевірки виберіть одну публікацію й відновіть дані вручну:

1. Знайдіть архівовану публікацію та зафіксуйте час оприлюднення, звітний місяць і початкове значення.
2. Відновіть знімок даних, який стратегія отримала б перед входом.
3. Обчисліть сигнал вручну й порівняйте його з результатом відтворення.
4. Додайте до сховища даних пізніший перегляд і перевірте, що попереднє рішення не змінилося.

Остання перевірка особливо корисна в автоматизованому дослідницькому конвеєрі. Передавайте своєму дослідницькому агенту граничний час знімка даних і вибрані ідентифікатори версій разом зі значеннями ознак. Потрібно мати достатньо даних, щоб відстежити угоду до конкретної публікації, навіть коли базове сховище даних розростеться.

Коли відтворите це одне рішення, перезапустіть історичну симуляцію й порівняйте розбіжності сигналів, перш ніж порівнювати дохідність. Порахуйте входи, які виправлення додало, прибрало або перенесло. Зміни в рішеннях розкажуть більше, ніж одне порівняння Sharpe до і після.

Ваша лютнева угода має спиратися на інформацію, доступну в лютому. Залиште квітневий перегляд у квітні.