Trading Stratejisi Backtesting Metodolojisi

Stingray backtest’leri sınırları açık tek bir soruyu yanıtlamak için tasarlanır: Belirli ve typed bir market rule, açıklanmış bir tarihsel zaman aralığında nasıl davrandı? Sonuç, bir signal’ı değerlendirmek için kullanılan replay artifact’idir; tahmin veya eksiksiz portfolio simulation değildir.

Bu metodoloji replay başlamadan önce nelerin sabitlendiğini, historical data’nın nasıl değerlendirildiğini, fire ve forward return’lerin nasıl sayıldığını ve hangi sınırlamaların görünür kalması gerektiğini açıklar. Güncel örneklerde crypto market’ler sık görünür çünkü venue, funding, order book ve onchain data daha yüksek gözlemlenebilirliğe sahiptir. Güvenilir veri ve settlement activity programmable rails’e taşındıkça aynı yöntem diğer market’lere de uygulanabilir.

Kısa metodoloji özeti

Soru	Yöntem	Artifact içindeki kanıt
Ne test edildi?	Replay öncesinde typed rule, market, source, interval, window ve cooldown sabitlenir.	Rule definition ve replay metadata
Veri kullanılabilir miydi?	Her source resolve edilir, timestamp’leri korunur, gap veya kırpılmış aralıklar açıklanır.	Coverage notes ve source metadata
Rule ne zaman fire etti?	Historical sample’lar sırayla değerlendirilir; raw truth, distinct event ve cooldown-filtered notification ayrılır.	Fire set’leri, count’lar ve event row’ları
Sonrasında ne oldu?	Her eligible fire sonrasında belirtilen horizon’lardaki fiyat değişimi ölçülür.	Sample size ile forward returns
Sonuç denetlenebilir mi?	Artifact yeniden üretilebilir tutulur; varsayımlar, desteklenmeyen input’lar ve eksik observation’lar açıklanır.	Semantic version, diagnostics ve limitations
İnceleme sonrasında ne olur?	Execution kararından önce rule reject, refine veya monitor edilir.	Notify, preview-confirm ve opt-in activation path

1. Replay öncesinde rule’u sabitleyin

Faydalı bir backtest, incelenebilir bir rule ile başlar. Stingray historical evaluation başlamadan önce plain-English thesis’i typed definition’a resolve eder. Definition şunları açıkça belirtmelidir:

• Market, symbol ve venue veya data source
• Tüm condition ve threshold’lar
• Evaluation interval ve historical window
• Cooldown veya deduplication policy
• Yorumlama için kullanılacak direction ve forward-return horizon’ları

Replay daha temiz bir sonuç üretmek için rule’u sessizce değiştirmemelidir. İstenen source mevcut değilse, bir time parameter historical interval ile uyumsuzsa veya definition gerçeğe sadık biçimde değerlendirilemiyorsa doğru sonuç açık bir limitation veya rejection’dır.

Sonucu gördükten sonra threshold değiştirmek yeni bir rule yaratır. Değiştirilen rule, önceki kanıtın üzerine yazmak yerine yeni bir replay almalıdır.

2. Data source ve zamanı doğru resolve edin

Her condition replay-safe bir source contract gerektirir. Price, funding, open interest, event ve news input’larının clock ve coverage özellikleri farklıdır. Replay kullanılan source’u kaydeder ve observation’ları timestamp sırasıyla değerlendirir.

Event veya news data için ilgili zaman, bilginin sisteme gerçekten ulaşabildiği andır. Event’e daha sonra eklenen daha erken bir timestamp’i kullanmak, o anda henüz gözlemlenemeyen bilgiyi geçmiş teste taşır.

Artifact şunları açıklamalıdır:

• İstenen ve etkili date range
• Native veya selected interval
• Eksik internal segment’ler ve kırpılmış edge’ler
• Sampled, aggregated veya unavailable source’lar
• Mevcut history’nin rule’u değerlendirmek için yeterli olup olmadığı

Temiz görünen bir headline number eksik coverage’ı düzeltemez. Gap’ler replay’i geçerli segment’lere bölüyorsa bu sınırlar görünür kalmalı, uydurma observation’larla doldurulmamalıdır.

3. Fire saymadan önce indicator warmup uygulayın

Indicator ve stateful condition’ların anlamlı hale gelmesi için history gerekir. Moving average, RSI, sequence veya cross condition dataset’in ilk satırından itibaren adil biçimde değerlendirilemez.

Source ve rule gerektirdiğinde Stingray visible evaluation window öncesindeki observation’ları warmup için kullanır. Warmup data indicator ve edge state’i hazırlar; ancak warmup fire’ları kullanıcıya sunulan kanıta dahil edilmez. Artifact warmup boundary’yi kaydeder, böylece ilk visible fire başlatılmamış bir indicator’dan kaynaklanmaz.

Evaluation granularity de rule ile uyumlu olmalıdır. Beş dakikalık bir condition hourly sample’lardan dürüstçe yeniden oluşturulamaz. Historical interval rule’daki en küçük time parameter’dan daha kabaysa replay false precision göstermek yerine açıkça başarısız olmalıdır.

4. Truthy sample ile actionable fire’ı ayırın

Bir condition art arda birçok sample boyunca true kalabilir. Her true row’u bağımsız signal saymak kanıtı büyütür ve tek bir market episode’un tüm sonucu domine etmesine yol açabilir.

Güncel replay artifact’leri üç view’u ayırır:

• Raw: Tüm rule’un true olduğu her evaluated sample. Diagnostic amaçlıdır.
• Primary: Tüm rule’un false durumdan true duruma geçtiği noktalar. Condition’a ayrı giriş event’lerini temsil eder.
• After cooldown: Yapılandırılmış notification cooldown uygulandıktan sonra kalan primary fire’lar. Live alert behavior’a en yakın view budur.

Cooldown operational control’dür; suppressed fire’ların ekonomik olarak önemsiz olduğu anlamına gelmez. Üç view’u birlikte görmek, rule’un distinct event bulup bulmadığını veya uzun süre true kalıp kalmadığını gösterir.

Ayrı bir primary set sunmadan yalnızca raw ve cooldown-filtered sonuçları gösteren legacy signal replay’lerde de aynı yorum geçerlidir. Rule açıkça farklı tanımlamadıkça kümelenmiş row’lar tek bir market episode olarak ele alınmalıdır.

5. Forward returns ölçün, ancak P&L’e dönüştürmeyin

Forward returns, eligible fire sonrasında 1 saat, 4 saat veya 24 saat gibi belirtilen horizon’lardaki fiyat değişimini yüzde olarak gösterir. Yanıtladığı soru şudur: “Bu condition görüldükten sonra fiyat genellikle ne yaptı?”

Artifact açıkça modellemedikçe bu eksiksiz bir trading strategy değildir. Standard signal replay şunları varsaymaz:

• Gerçek entry veya exit execution
• Position size veya leverage
• Fee, spread, slippage veya market impact
• Stop-loss veya take-profit behavior
• Portfolio constraint veya capital allocation

Her summary arkasındaki observation sayısını göstermelidir. Uzun bir benzer sample cluster’ı diğer tüm episode’ları bastırmamalı; distinct event’ler adil ağırlık almalıdır. Average, median, positive share ve distribution shape’i birlikte okumak tek bir headline statistic’ten daha yararlıdır.

Future data yalnızca fire belirlendikten sonra okunur. Forward data bir outcome measurement’tır ve historical trigger decision için input değildir.

6. Tek replay artifact’i içinde tutarlılığı koruyun

Replay saklanan input’lardan yeniden üretilebilir olmalıdır: rule version, source contract, market identity, interval, window, cooldown ve replay-semantics version.

Mümkün olduğunda chart range değişikliği aynı artifact’in başka bir window’unu okumalıdır. Rule sessizce yeniden çalıştırılıp farklı count’lar üretmemelidir. Chart, fire table, summary metric ve selected-event detail aynı fire set ve visible window’u kullanmalıdır.

Source history veya replay semantics önemli biçimde değiştiğinde sonuç yeni bir version almalıdır. Reproducibility, gelecekte tüm data vendor’ların aynı history’yi döndüreceği anlamına gelmez. Belirli bir artifact’in varsayımlarının denetlenebilecek kadar açık olması anlamına gelir.

7. Sonucu hüküm değil kanıt olarak inceleyin

Replay’i şu sırayla okuyun:

1. Test edilen rule’un amaçladığınız rule olduğunu doğrulayın.
2. Return’lerden önce source coverage, interval ve warmup’ı kontrol edin.
3. Raw, primary ve after-cooldown count’ları karşılaştırın.
4. Clustering ve tam fire row’larını inceleyin.
5. Forward returns’ü sample size ve regime context ile okuyun.
6. Gerçekten değiştirilmiş hypothesis’i yeni bir rule olarak test edin.

Şu sorular yararlıdır:

• Fire’ların çoğu tek bir volatility veya liquidity regime içinde mi oluştu?
• Sonucu tek bir event veya küçük bir sample mı domine ediyor?
• Seçilen horizon thesis ile uyumlu mu?
• Başka bir venue, source veya interval yorumu değiştirir mi?
• Rule window incelenmeden önce mi seçildi, yoksa aynı window üzerinde tekrar tekrar tune mu edildi?

Bir rule’u aynı historical window üzerinde tekrar tekrar optimize etmek overfitting risk’ini artırır. Umut verici bir sonuç, monitoring evidence olarak ele alınmadan önce daha sonraki veya ayrı bir dönemde kontrol edilmelidir.

8. Backtest sonrasında trust ladder’ı izleyin

Bir backtest genellikle üç karardan birine yol açar:

• Reject: Rule noisy, rare, fragile, unsupported veya regime-dependent’tır.
• Refine: Tek bir açık varsayımı değiştirin ve yeni replay üretin.
• Monitor: Typed rule’u live alert olarak çalıştırın ve gözlemlenen behavior’ı historical artifact ile karşılaştırın.

Execution ayrı bir karardır. Stingray trust ladder notify first, desteklenen yerlerde preview-confirm ve yalnızca kullanıcı açıkça etkinleştirdiğinde opt-in execution şeklindedir. Positive historical average bu sırayı atlamaz.

Bilinen sınırlamalar

• Historical performance future result’ları tahmin etmez.
• Available history source, venue, asset ve event type’a göre değişir.
• Candle veya sampled data kesin intrabar event sırasını kanıtlayamaz.
• Forward returns signal sonrası outcome’u ölçer; gerçekleştirilebilir trade return değildir.
• Backtest structural change, delisting, liquidity constraint ve future market rule’ları kaçırabilir.
• Aynı window üzerinde çok sayıda test yapmak, tesadüfen iyi sonuç bulma ihtimalini artırır.
• Unsupported veya coverage’ı yetersiz input’lar sessizce yaklaşık hesaplanmamalı, reject edilmelidir.

Yayın kontrol listesi

Bir Stingray replay’i guide, example veya benchmark içinde kullanılmadan önce yayın şunları içermelidir:

• Tam thesis veya prompt
• Typed rule veya gerçeğe sadık okunabilir summary
• Market, venue, source, interval ve date window
• Coverage ve warmup notes
• Mevcutsa raw, primary ve after-cooldown count’ları
• Forward-return horizon’ları ve sample size’ları
• Fee, slippage, position sizing ve execution için açık exclusions
• Sonucun historical evidence olduğu, trading advice veya performance promise olmadığı ifadesi

Alanları tek tek yorumlamak için Backtest Kartı Nasıl Okunur? rehberine bakın. Yayınlanmış walkthrough’lar için Strateji Örnekleri sayfasını kullanın. Thesis’ten monitor aşamasına kadar geniş workflow için Stingray Nasıl Çalışır? sayfasını okuyun.