Reklam kuralını açmadan backtest etmek

Salı sabahı 09.15. Performans pazarlamacısı üç haftadır aklında olan kuralı nihayet yazmış: "ROAS son 7 günde 1,0'ın altına düşerse kampanyayı durdur." Kaydet düğmesinin hemen yanında ikinci bir düğme duruyor: bu kural son 28 günde ne yapardı? Tıklıyor. Ekrandaki sonuç, kuralı yazarken kafasındaki resimden epey farklı: kural 46 kez tetiklenirdi, 12 kampanyanın 9'una en az bir kez dokunurdu ve durduracakları arasında ay boyunca en çok ciro getiren yeniden pazarlama kampanyası da var. Nedeni basit: o kampanyanın ROAS'ı pazartesi sabahları düzenli olarak 0,8'e iniyor, çarşamba öğleden sonra 2,4'e çıkıyor. Buradaki sayılar örnektir. Değişmeyen tarafı şu: kural açık olsaydı, kimsenin ekrana bakmadığı bir pazartesi sabahı hesabın en iyi kampanyası kapanmış olurdu.

Aşağıda backtest'i bir güven tazeleme ritüeli olarak değil, bir kuralın kapsamını ve kör noktalarını ölçen bir alet olarak ele alıyoruz. Önce backtest'in neyi kanıtladığını neyi kanıtlayamayacağından ayırıyoruz. Sonra eşik sayısının nereden geldiğini, 28 günlük pencerenin neyi gizlediğini ve geri besleme sorununu — kuralın geçmişi kendi eliyle değiştirmesini — konuşuyoruz. Ardından simülasyonun backtest'ten ayrıldığı yeri, guardrail'lerin tetiklenme sayısını nasıl kırptığını, çıkan sayıyı okumanın karar tablosunu, sadece göster modunun bıraktığı boşluğu nasıl kapattığını ve kural açıldıktan sonra hangi kanıtın toplandığını görüyoruz. En sonda bir kuralı ne zaman emekliye ayıracağınız var.

Backtest neyi kanıtlar, neyi kanıtlamaz?

Backtest tek bir soruyu yanıtlar: bu kural, elimdeki geçmiş veriye uygulansaydı kaç kez ve hangi kampanyalarda tetiklenirdi? Reklam Otomasyonu'nun "Açmadan önce backtest" ekranı tam olarak bunu döker — son 28 gün, tetiklenme sayısı, eşleşen kampanyaların adı, hiçbir şeye dokunmadan. Bu bilgi küçük görünür ama iki büyük hatayı daha ilk dakikada yakalar: kuralın hiç çalışmayacak kadar dar olması ve hesabın yarısını süpürecek kadar geniş olması.

Kanıtlayamadığı şey ise sonuçtur. Backtest size "bu kural açık olsaydı ROAS şu kadar artardı" demez, diyemez. Çünkü kural o kampanyayı 12 Mart'ta durdursaydı, 13–28 Mart arasındaki veriler hiç oluşmayacaktı; elinizdeki geçmiş, kuralın müdahale etmediği bir geçmiştir. Bu ayrımı baştan yapmak, backtest'e taşıyamayacağı bir yük bindirmenizi engeller. Aynı mantığı yazılım tarafında da kuruyoruz: bir otomasyonu canlıya almadan önce geçmiş girdilerle koşturmak, davranışını görmenin en ucuz yolu; bir AI ajanını yayına almadan test etmenin mantığı da aynı yerden çıkıyor.

Pratik sonuç: backtest bir performans tahmini değil, bir kapsam ölçümüdür. "Kaç kampanyaya, ne sıklıkla, hangilerine dokunacağım" sorusunun cevabı. Kuralı bu gözle okuduğunuzda ekrandaki 46 sayısı bir vaat değil, bir uyarıdır.

Eşik sayısını gerçekten nereden buluyorsunuz?

Çoğu kural yanlış yazıldığı için değil, yanlış eşikle yazıldığı için işe yaramaz. "ROAS 1,0'ın altındaysa durdur" cümlesindeki 1,0 nereden geldi? Genellikle bir toplantıda söylenmiş yuvarlak bir sayıdır; hesabın gerçek dağılımıyla ilgisi yoktur. Hesabınızın medyan ROAS'ı 0,9 ise 1,0 eşiği kampanyaların yarısını durdurur; medyan 3,2 ise aynı eşik yıl boyunca hiç tetiklenmez ve kural bir süs olarak açık kalır.

Bu yüzden eşiği tahminle değil dağılımla seçmek gerekir. "Eşiği veriden seçin" ekranı metriğin kampanyalarınız arasındaki dağılımını gösterir, medyanı tek tıkla eşik yapmanıza izin verir ve o eşikte kaç kampanyanın yakalandığını yazar. Karar sırası tersine döner: önce "kaç kampanyaya dokunmak istiyorum" diye sorarsınız, sonra o sayıyı veren eşiği alırsınız. Alt çeyrekten eşik almak seçici bir kural üretir; medyan daha geniş bir tarama yapar.

Eşik seçerken hangi metriğin gürültülü olduğunu da hesaba katın. Günlük harcama görece kararlıdır, ROAS küçük dönüşüm hacimlerinde zıplar, CPL tek bir formla ikiye katlanabilir. Gürültülü metrikte dar eşik, kuralın her hafta farklı kampanyayı yakalaması demektir. Benzer bir kalibrasyon problemini satış tarafında da yaşarsınız; lead puanlama modelini kalibre etmek de eşiğin gerçeği yansıtıp yansıtmadığını sormakla başlar.

28 günlük pencere size neyi göstermez?

Backtest penceresi sabit: son 28 gün. Bu pencere gündelik dalgalanmayı ve hafta içi–hafta sonu ritmini yakalamak için yeterlidir; mevsimselliği yakalamak için değildir. İçinde bir kampanya lansmanı, bir indirim dönemi ya da bir stok tükenmesi varsa, backtest o dönemin kurallarını öğrenir ve size normal ayların resmini vermez. Tersi de geçerli: pencere tamamen sakin bir aya denk geldiyse, kural yoğun dönemde ne yapacağını göstermeden onay almış olur.

Pencerenin ikinci sınırı veri kalitesidir. Kural kurulmadan önce veri sağlığı kapısı senkron tazeliğini, 28 günlük veri kapsamını ve hesap para birimini doğrular; eksik ya da bayat veriyle kural kaydedilmez. Bu kontrol backtest'in okuduğu tabanı korur, ama atıf tarafındaki karışıklığı çözmez: dönüşümler yanlış kampanyaya yazılıyorsa backtest de yanlış kampanyayı işaretler. Bu yüzden kural yazmadan önce UTM parametreleriyle kampanya takibinin düzgün kurulmuş olması, backtest'in okuduğu her satırın anlamlı olmasını sağlar.

Üçüncüsü, öğrenme fazı. Platform yeni bir kampanyayı öğrenirken metrikler dengesizdir; o günlerde tetiklenen bir kural, kampanyayı olgunlaşmadan öldürür. Guardrail tarafında öğrenme fazındaki hedefleri atlama seçeneği tam da bunun içindir ve backtest'i bu seçenek açıkken bir kez daha koşturmak, kaç tetiklenmenin aslında öğrenme gürültüsü olduğunu gösterir.

Kural geçmişi değiştirir: geri besleme sorunu

Backtest'in en sinsi tarafı burasıdır. Bir aksiyon uygulandığında sonraki günlerin verisi başkalaşır. Durdurulan kampanya harcamaz, veri üretmez, dolayısıyla kuralın onu ikinci kez durdurma ihtimali de yoktur. Backtest ise geçmişi olduğu gibi okur ve aynı kampanyayı beş kez daha durdurulmuş sayar. Bu, tetiklenme sayısını sistematik olarak şişirir.

Bütçe kurallarında etki ters yöne çalışır. "ROAS hedefin üstündeyse bütçeyi artır" kuralı geçmişte uygulansaydı, artan bütçe muhtemelen CPM'i yükseltir ve ROAS'ı bir miktar geri çekerdi; backtest bu tepkiyi göremez, çünkü elindeki veri düşük bütçeyle üretilmiştir. Yani backtest yükseltme kurallarında iyimser, durdurma kurallarında ise abartılı çıkar.

Doğru okuma şudur: tetiklenme sayısını bir tahmin değil, bir üst sınır olarak alın. "En kötü ihtimalle bu kural şu kadar kampanyaya dokunabilir" cümlesi backtest'in verebileceği en dürüst cümledir. Kaç kez tetikleneceğinden çok, hangi kampanyaların listede olduğuna bakın; adları tanıdıksa ve orada olmamaları gerekiyorsa, sorun kuralın kendisindedir.

Simülasyon backtest'ten ne zaman daha faydalıdır?

Backtest "geçmişte olurdu" sorusuna, simülasyon "şu değerlerde ne olur" sorusuna bakar. "Kendi sayılarınızla simülasyon" ekranında örnek metrikleri elle girersiniz: ROAS 0,7, harcama 1.400, frekans 4,2. Koşul eşleşiyor mu, guardrail bütçe değişimini nasıl kırpıyor, aksiyon hangi değerle uygulanacaktı — hepsi görünür, hiçbir şey uygulanmaz.

Bu ayrım üç durumda kritiktir. Birincisi, yeni açılmış bir kampanyada geçmiş yoktur; backtest boş döner ama simülasyon kuralın mantığını yine de sınar. İkincisi, uç değerleri elle denemek istersiniz: ROAS tam eşikteyken ne olur, harcama sıfırken koşul çöker mi. Üçüncüsü, düşük hacimli hesaplarda 28 gün istatistiksel olarak zaten yetersizdir; LinkedIn Ads ile B2B reklamcılıkta aylık dönüşüm sayısı çift haneyi zor bulduğu için backtest'in ürettiği örüntü tesadüfle karışabilir.

Pratik sıra: kuralı düz bir cümleyle anlatıp koşul → aksiyon taslağını çıkarttıktan sonra önce simülasyonla mantığı doğrulayın, sonra backtest ile kapsamı ölçün. Tersi sırada koştuğunuzda, yanlış yazılmış bir koşulun tetiklenme sayısını tartışmakla vakit kaybedersiniz.

Guardrail'ler tetiklenme sayısını nasıl kırpar?

Bir kural tek başına çalışmaz. Minimum veri penceresi, bütçe-değişim sınırları, aksiyonlar arası bekleme, günlük bütçe tabanı ve öğrenme fazı koruması, kural iş görmeden önce uygulanır. Backtest'i bu ayarlar açıkken koşturmak, sayının ciddi biçimde düşmesine yol açar: aynı kampanyaya art arda dokunmayı engelleyen bekleme süresi tek başına tekrarlı tetiklenmelerin çoğunu eler.

Bu yüzden backtest'i iki kez okumak işe yarar. Guardrail'siz sayı kuralın ham kapsamını, guardrail'li sayı gerçek davranışını verir. Aradaki fark büyükse — örneğin 46'dan 11'e düşüyorsa — kuralınız aslında guardrail'lerin yönettiği bir kuraldır ve eşiği biraz gevşetmeniz, kuralı daha okunur hale getirir.

Guardrail mantığının reklam tarafındaki kardeşi negatif listelerdir: ikisi de "bu iş yapılmasın" diyerek bütçeyi korur. Negatif anahtar kelimelerle reklam bütçesini yakmayı durdurmak harcamanın girişini kapatır; guardrail ise otomasyonun çıkışını sınırlar. Bir hesapta ikisi de yoksa, kural motoru açmadan önce bu iki katmanı kurmak backtest'ten daha çok kazandırır.

Kaç tetiklenme sağlıklı bir sayıdır?

Backtest sonucunu okurken tek bir doğru sayı yoktur, ama sayının hangi aralıkta olduğuna göre atılacak adım oldukça nettir. Aşağıdaki tablo 28 günlük pencere ve orta ölçekli bir hesap (10–30 aktif kampanya) varsayımıyla yazıldı; kendi hesabınızda kampanya sayısına göre ölçekleyin.

Backtest sonucu	Muhtemel neden	Sonraki adım
0 tetiklenme	Eşik dağılımın tamamen dışında	Dağılıma dönün, medyandan eşik alın
1–5 tetiklenme	Dar ve seçici kural	Doğrudan onay moduna alın
6–20 tetiklenme	Makul kapsam	Bir hafta sadece göster, sonra onay
20+ tetiklenme, az kampanya	Aynı kampanyalarda salınım	Aksiyonlar arası beklemeyi uzatın
Kampanyaların çoğu listede	Eşik çok gevşek veya metrik yanlış	Kuralı ikiye bölün, kapsamı daraltın

Tablodaki son satır en sık görülenidir ve genellikle kuralın çok şey yapmaya çalışmasından kaynaklanır. "Düşük ROAS'ı durdur" ile "formsuz harcamayı kes" aynı cümleye sıkıştırıldığında, kural iki farklı sorunu tek eşikle çözmeye çalışır ve ikisinde de kabalaşır.

Sadece göster modu backtest'in boşluğunu nasıl doldurur?

Backtest geçmişe, sadece göster modu geleceğe bakar. Her kural üç özerklik seviyesinden birinde çalışır: sadece göster, onayımla, otomatik. İlk seviyede kural kampanyalarınızı gerçek zamanlı değerlendirir, kaç kampanya bakıldı, kaçı eşleşti ve ne değişirdi bilgisini üretir; hesabınıza tek bir değer yazılmaz. Önizleme asla yazmaz ilkesi bu modun tamamını kapsar.

İki aracın yakaladığı hata türleri farklıdır. Backtest kuralın mantık hatalarını gösterir; sadece göster modu, veri akışındaki ve zamanlamadaki sorunları ortaya çıkarır — senkronun gecikmesi, gün sonunda metriklerin oturması, kuralın her saat yerine yalnız belirli gün ve saatlerde koşması gerektiği. Bir hafta sadece göster modunda biriken karar listesini okumak, backtest'in 28 günlük tablosundan daha ikna edicidir, çünkü listedeki her satırın bugünkü hesapta karşılığı vardır.

Onay modu bir sonraki basamaktır: eşleşmeler onay kuyruğuna düşer, nedeni ve uygulanacak tam değişikliği görür, siz onaylamadan kampanyaya dokunulmaz. Birden fazla platformda çalışıyorsanız bu kuyruk aynı zamanda ortak bir dil olur; Meta, Google, TikTok ve LinkedIn'i tek panelde yönetmek ile aynı mantığı otomasyon kararlarına taşır.

Kural açıldıktan sonra hangi kanıtı topluyorsunuz?

Kural otomatiğe geçtiği anda backtest'in işi biter, ölçüm başlar. Uygulanan her aksiyonun öncesi ve sonrası eşit pencerelerle karşılaştırılır; bu karşılaştırma gözlemseldir ve nedensellik iddia etmez. Yani "kural sayesinde ROAS arttı" cümlesini kurmaz, "bu aksiyondan önceki 7 gün ile sonraki 7 gün şöyleydi" der. Farkı korumak önemlidir, çünkü aynı hafta devreye giren yeni bir görsel ya da sezon etkisi tabloyu tek başına açıklayabilir; bu yüzden kreatif testlerini kendi sisteminde yürütmek otomasyon ölçümünü de temizler.

Riski küçültmenin ikinci yolu kademeli açıştır: kuralı önce kampanyaların küçük bir kısmında çalıştırıp etkiyi kıyaslar, sonra tümüne ölçeklersiniz. Yanlış giderse tek bir kararı ya da koşunun tamamını 24 saat içinde tersine çevirebilir, bütçeyi önceki değerine döndürebilirsiniz. Bu geri alma penceresi, backtest'te göremediğiniz her şeyin maliyetini bir güne indirir.

Kanıtın kalitesini asıl belirleyen ise hangi geliri ölçtüğünüzdür. Platformun dönüşüm değeri yerine CRM'de kazanılan fırsat gelirini ölçen gerçek ROAS, kohortlar olgunlaşmadan zarar kararı verilmesini engeller. Bu bağı kurmak reklam harcamasını CRM geliriyle eşleştirmeyi gerektirir; aksi halde kural, satışa hiç dönüşmeyen ucuz dönüşümleri ödüllendirir.

Aynı veri hattı ters yöne de akar. CRM'de kazanan segmentleri biliyorsanız, bu müşteri listelerini reklam platformlarına taşıyarak kuralların üzerinde çalıştığı kitleyi baştan iyileştirirsiniz; iyi kitlede kurulan bir eşik, kötü kitlede kurulan bir eşikten daha uzun ömürlü olur.

Bir kuralı ne zaman emekliye ayırmalısınız?

Kurallar birikir. Altı ay sonra hesapta kimsenin hatırlamadığı, birbirini iptal eden kurallar olur: biri bütçeyi açarken diğeri kısar. Aynı kapsamda çakışan kural çiftleri işaretlenir ve tek ekrandan çözülür; ayrıca kuralların koşma sırasını siz belirlersiniz, böylece hangisinin önce davranacağı tesadüfe kalmaz. Sessiz kalan kurallar da ayrı bir iş yükü: bir kural üst üste sonuç üretmezse pazarlama yetkililerine bildirim gider, bozuk otomasyon sessizce beklemez.

Emeklilik kararı için basit bir ritim işe yarar: her çeyrekte aktif kuralları yeniden backtest edin. Hesabın dağılımı değişmiştir, eski eşik ya artık hiç tetiklenmiyordur ya da hesabın yarısını yakalıyordur. Kural yazıldığı gün doğru olabilir; üç ay sonra doğru kalması için aynı ölçümü tekrarlamak gerekir. Hesap yapısı değiştiğinde — kampanyalar birleştirildiğinde, yeni bir hesap açıldığında ya da reklam hesabı askıya alınıp yeniden kurulduğunda — eski kuralların kapsamı sessizce kayar ve yeniden ölçülmesi şarttır.

Bütün bu düzenin üstünde duran şey ana şalterdir: otomasyon varsayılan olarak kapalı gelir, siz bilerek açana kadar hiçbir reklam değişmez ve kapatmak kurallarınızı silmez. Kuralı açmadan önce backtest, simülasyon ve sadece göster adımlarını sırayla geçirmek isterseniz, Rocketly hesabınızı açıp ilk kuralınızı hiçbir kampanyaya dokunmadan sınayabilirsiniz.

Sıkça sorulan sorular

Backtest hesabımdaki kampanyalara zarar verir mi?

Hayır. Backtest yalnızca geçmiş veriyi okur ve kuralın ne yapacağını raporlar; bağlı hesaba hiçbir değer yazılmaz. Aynı şey sadece göster modu ve simülasyon için de geçerlidir.

Backtest 0 tetiklenme verdiyse kuralı açmalı mıyım?

Açabilirsiniz ama önce eşiği kontrol edin. Sıfır sonuç genellikle eşiğin dağılımın dışında kalmasından gelir; nadiren de kuralın gerçekten çok istisnai bir durum için yazılmış olmasından. İkinci durumdaysa kuralı açmak zararsızdır, çünkü zaten seyrek çalışacaktır.

28 günden uzun bir pencereye bakabilir miyim?

Backtest penceresi son 28 gündür. Daha uzun bir dönemi merak ediyorsanız pratik yol, kuralı sadece göster modunda birkaç hafta çalıştırıp biriken karar listesini okumaktır; bu, ileriye doğru genişleyen bir pencere sağlar.

Backtest sonucu ile gerçek sonuç neden farklı çıkıyor?

Çünkü kural uygulandığında sonraki günlerin verisi değişir. Durdurulan kampanya veri üretmez, artırılan bütçe maliyeti etkiler. Backtest bu geri beslemeyi modelleyemez; bu yüzden tetiklenme sayısını bir üst sınır olarak okumak doğru yaklaşımdır.