14 September 2026 · data

Backtest makro Anda memperdagangkan laporan ketenagakerjaan yang direvisi

Backtest makro Anda memperdagangkan laporan ketenagakerjaan yang direvisi

Kepada perancang strategi filter payroll,

Anda membuat aturan sederhana: setelah laporan ketenagakerjaan AS dirilis, strategi Anda menahan ETF ekuitas selama lima sesi jika pertumbuhan payroll bulanan melebihi 175,000. Jika tidak, strategi tetap memegang kas. Anda menjadwalkan entry setelah pasar ekuitas dibuka, memasukkan biaya trading, dan mempertahankan ambang batas yang tetap. Lalu Anda mengunduh seri payroll historis dan menggunakannya untuk merekonstruksi setiap sinyal.

Masalah yang tersisa adalah data unduhan itu. Seri ekonomi historis dapat memuat estimasi revisi yang belum tersedia pada tanggal ketika strategi Anda konon melakukan trading. Untuk menguji sinyal makro secara jujur, Anda perlu menggunakan versi yang tersedia pada setiap waktu pengambilan keputusan. Memajukan entry satu bar tidak akan memperbaiki angka yang baru diterbitkan dua bulan kemudian.

Observasi Januari Anda punya beberapa tanggal rilis

Perhatikan riwayat rilis rekaan ini. Tanggal dan perubahan payroll berikut menggambarkan mekanismenya; ini bukan hasil ekonomi yang dilaporkan.

RilisBulan acuanPerubahan payroll yang dilaporkanAturan Anda pada rilis tersebut
7 Februari, 08:30 ETJanuari+150,000Tetap memegang kas
7 Maret, 08:30 ETJanuari, direvisi+185,000Tidak mengubah keputusan Februari
4 April, 08:30 ETJanuari, direvisi lagi+210,000Tidak mengubah keputusan Februari

Jika data unduhan Anda menampilkan Januari sebagai +210,000, simulasi Anda akan masuk ke ETF pada Februari. Aturan yang sebenarnya akan tetap memegang kas. Semua harga, timestamp order, dan komisi bisa benar, tetapi seluruh transaksi itu tetap fiktif.

Jangan berasumsi bahwa kontaminasi ini pasti memperbaiki kinerja. Revisi bisa menghasilkan transaksi yang untung, transaksi yang rugi, atau menghapus salah satunya. Masalahnya adalah simulasi Anda menjawab pertanyaan yang tidak mungkin diajukan strategi Anda saat itu.

Dan Januari hanyalah periode yang diukur. Itu bukan tanggal ketika Anda mengetahui hasil pengukurannya. Baris berlabel 1 Januari tidak berarti Anda boleh memperdagangkannya pada 1 Januari.

Catat riwayat ketersediaan setiap nilai

Tabel riset Anda membutuhkan lebih dari sekadar bulan dan angka. Simpan periode acuan, nilai, timestamp rilis, ID vintage, dan sumbernya. Untuk pengumpulan yang berkelanjutan, catat juga kapan sistem Anda menerima rilis tersebut. Pertahankan versi lama alih-alih menimpa nilainya.

Pada setiap timestamp keputusan, pilih versi terbaru yang memenuhi syarat dari tiap observasi, dengan timestamp ketersediaan tidak lebih dari waktu keputusan tersebut. Lalu hitung fitur dari snapshot yang direkonstruksi itu.

Aturan pengambilan data Anda: batasi dulu catatan hanya pada data yang sudah tersedia, lalu pilih versi yang sesuai, baru hitung sinyal. Menghitung fitur dari riwayat revisi saat ini lalu menggeser hasilnya ke waktu sebelumnya tetap membocorkan informasi.

Periode kepemilikan selama lima sesi tidak membuat pencatatan ini boleh diabaikan. Periode itu memberi Anda lebih banyak ruang untuk memilih waktu entry yang konservatif; tetapi tidak memberi Anda akses dini ke revisi.

Untuk riset lama, Anda mungkin memiliki bukti waktu rilis publik, tetapi tidak memiliki catatan waktu penerimaan Anda sendiri. Tegaskan perbedaan itu. Anda dapat memodelkan akses setelah timestamp publikasi yang terdokumentasi dengan jeda yang dinyatakan. Namun, asumsi itu tidak bisa disebut sebagai catatan pengiriman historis yang terukur.

Anda juga sebaiknya menggunakan timestamp yang memperhitungkan zona waktu. Simpan waktu lokal rilis sebagaimana didokumentasikan dan konversikan dengan benar; offset UTC tetap untuk New York akan keliru saat perubahan waktu musim panas. Beri kebaikan kecil itu kepada diri Anda di masa depan. Anda yang di bulan September seharusnya tidak perlu menebak-nebak arti kolom Anda di bulan Maret yang bernama date_actual_final2.

Fitur rolling Anda membutuhkan seluruh vintage

Misalnya, Anda mengganti ambang batas tetap dengan “pertumbuhan payroll melebihi rata-rata dua belas bulan sebelumnya.” Kini Anda membutuhkan observasi terdahulu sebagaimana tercatat pada waktu keputusan itu, termasuk revisi yang sudah diterbitkan saat itu.

Menggunakan rilis pertama setiap bulan untuk selamanya menghasilkan fitur yang berbeda. Desain itu bisa sah jika Anda memang secara eksplisit ingin menggunakan riwayat pengumuman awal. Namun, desain tersebut tidak merekonstruksi riwayat ekonomi yang terlihat pada pagi tertentu, karena informasi yang tersedia pagi itu mungkin sudah mencakup revisi bulan-bulan sebelumnya.

Jika Anda menghitung perubahan payroll bulanan dari tingkat ketenagakerjaan, rekonstruksi seri tingkat tersebut untuk vintage yang relevan sebelum menghitung selisihnya. Mencampur tingkat yang baru dirilis dengan tingkat bulan sebelumnya dari vintage lama dapat menghasilkan perubahan yang tidak pernah tercantum dalam snapshot yang dipublikasikan.

Jadi, Anda perlu menetapkan arti fitur Anda: pengumuman awal, gambaran ekonomi terbaru yang tersedia, atau revisi itu sendiri. Istilah “pertumbuhan payroll” masih menyisakan terlalu banyak hal yang belum diputuskan.

Perbaiki satu rilis sebelum menjalankan ulang data sepuluh tahun

Anda bisa mulai dari ALFRED, yang menyediakan riwayat vintage untuk banyak seri ekonomi. Periksa cakupannya untuk seri dan periode yang tepat. Tanggal vintage saja tidak membuktikan ketersediaan intraday; padukan dengan waktu rilis yang terdokumentasi sebelum menggunakannya untuk sinyal pada hari yang sama.

Untuk audit pertama, pilih satu rilis dan rekonstruksi secara manual:

  1. Temukan rilis arsip dan catat timestamp publikasi, bulan acuan, serta nilai awalnya.
  2. Susun ulang snapshot input yang akan diterima strategi Anda sebelum entry.
  3. Hitung sinyal secara manual dan bandingkan dengan simulasi Anda.
  4. Tambahkan revisi berikutnya ke penyimpanan data dan pastikan keputusan sebelumnya tidak berubah.

Pemeriksaan terakhir itu sangat berguna dalam pipeline riset otomatis. Berikan kepada agen riset Anda batas waktu snapshot dan ID vintage yang dipilih, beserta nilai fiturnya. Anda membutuhkan bukti yang cukup untuk menelusuri suatu transaksi kembali ke rilis tertentu, bahkan setelah basis data yang mendasarinya bertambah besar.

Setelah satu keputusan berhasil direproduksi, jalankan ulang riwayat dan bandingkan perbedaan sinyal sebelum membandingkan imbal hasil. Hitung entry yang ditambahkan, dihapus, atau digeser akibat perbaikan itu. Anda akan belajar lebih banyak dari keputusan yang berubah tersebut daripada dari satu angka Sharpe sebelum dan sesudah.

Transaksi Februari Anda harus bertahan hanya dengan informasi yang tersedia pada Februari. Biarkan revisi April tetap di April.

data point-in-timedata makroekonomibias look-aheadbacktesting
← Semua artikel