Veri sağlığı kapısı: bozuk veriyle reklam kararı vermemek

Salı sabahı 09:40. Performans ekibinden biri panele bakıyor: yaz kampanyasının ROAS değeri 0,4 görünüyor, kuralın eşiği ise 1,0. Kural doğru kurulmuş, koşul doğru yazılmış, aksiyon doğru seçilmiş; kampanya duruyor. Öğleden sonra platformun dönüşüm kayıtları geç akıyor ve aynı kampanyanın o güne ait getirisi eşiğin iki katına çıkıyor. Kural hata yapmadı. Kuralı besleyen tablo o saatte on dokuz saat eskiydi ve dönüşümlerin bir kısmı henüz yazılmamıştı. Buradaki rakamlar örnek, ama tablo tanıdık: durdurulan şey kötü bir kampanya değil, yarım bir tablodan okunmuş bir cümleydi.

Bu yazı, o cümlenin hiç okunmamasını sağlayan mekanizmayı anlatıyor. Önce reklam verisinin tam olarak nerede bozulduğunu ayırıyoruz. Sonra bir veri sağlığı kapısının neyi doğrulaması gerektiğini tazelik, kapsam ve para birimi başlıkları altında tek tek açıyoruz. Ardından kapı kapalıyken kuralın nasıl davranması gerektiğine, kuralı açmadan önce hangi sınamalardan geçireceğinize ve bütün bunu haftalık bir rutine nasıl çevireceğinize geçiyoruz. En sonda sık sorulan sorular var.

Reklam verisi tam olarak nerede bozulur?

“Veri bozuk” cümlesi tek başına hiçbir işe yaramaz, çünkü bozulma tek bir yerde olmaz. Reklam kararına giden sayı, en az dört durak geçer: platformun kendi raporlama katmanı, sizin tarafınıza akan senkron, kaydın CRM ile eşleşmesi ve son olarak kuralın okuduğu özet tablo. Her durağın kendine has bir arıza biçimi vardır ve bunlar birbirine hiç benzemez. Aynı panelde “dün 12 satış” yazarken kuralın 7 satış görmesi, çoğu zaman bu duraklardan birinin geride kalmasıdır.

En sık görülen bozulma, kampanya ile kayıt arasındaki bağın kopmasıdır. Reklamdan gelen ziyaretçi formu doldurur, kayıt CRM'e düşer, ama hangi kampanyadan geldiği yazılmamıştır. Bu durumda platform tarafı “dönüşüm var” der, gelir tarafı sessiz kalır ve gerçek getiri olduğundan düşük görünür. Bağın nerede koptuğunu görmek için etiketleme düzenini baştan kurmak gerekir; kampanya etiketlerini tek bir şemaya oturtmak bu işin en sıkıcı ama en getirili adımıdır.

İkinci sık arıza, senkronun tamamen durmasıdır. Erişim izni süresi dolar, hesap sahibi değişir ya da reklam hesabı platform tarafında kısıtlanır; panel eski veriyi göstermeye devam ettiği için hiçbir şey yanlış görünmez. Bu sessiz kesintiyi fark etmenin yolu, verinin kendisine değil verinin yaşına bakmaktır. Hesabın tamamen kapandığı durumlarda ise sorun daha görünürdür ama çözümü daha uzundur; hesap kısıtlaması yaşandığında izlenecek adımlar ayrı bir konu başlığıdır.

• Gecikmeli dönüşüm: Atıf penceresi kapanmadan bakılan ROAS her zaman gerçeğinden düşüktür.
• Kısmi gün: Bugünün verisi henüz tamamlanmamışken günlük eşiğe sokulur.
• Para birimi karışması: Hesap bir birimde, eşik başka bir birimde tanımlıdır.
• Zaman dilimi kayması: Platformun günü ile raporun günü aynı saatte başlamaz.
• Duplike kayıt: Aynı dönüşüm hem platformdan hem CRM'den sayılır.

Veri sağlığı kapısı neyi doğrular, neyi doğrulamaz?

Bir kapı, adı üstünde, geçişi durduran şeydir. Reklam Otomasyonu tarafındaki veri sağlığı kapısı üç şeyi doğrulamadan bir kuralın kurulmasına izin vermez: senkron tazeliği, 28 günlük veri kapsamı ve hesap para birimi. Bu üçü mekanik kontrollerdir; yorum gerektirmez, tartışmaya açık değildir ve kuralın mantığından bağımsız olarak her hesapta aynı şekilde işler. Eski veriden karar çıkmaması bu yüzden bir tavsiye değil, bir ön koşuldur.

Kapının yapmadığı şeyi de net söylemek gerekir. Kapı, seçtiğiniz metriğin doğru metrik olup olmadığını bilmez. CPA'yı eşik yapmışsınız ama işin gerçek kısıtı CPL'se, veri kusursuz olsa bile karar yanlış olur. Aynı şekilde kapı, farklı platformların aynı metriği farklı tanımlamasını da düzeltmez; bir platformda “dönüşüm” tıklama sonrası yedi gün, diğerinde bir gün olabilir. Bu farkları görünür kılmak kampanyaları tek panelde toplayan bir kurulumun işidir, kapının değil.

Kapı ile guardrail'i de karıştırmamak gerekir. Kapı, kuralın çalışıp çalışmayacağına karar verir. Guardrail ise kural çalıştıktan sonra ne kadar değişebileceğini sınırlar: bütçe-değişim sınırları, aksiyonlar arası bekleme, günlük bütçe tabanı ve öğrenme fazındaki hedefleri atlama gibi. İkisi arka arkaya durur. Kapı “bu veriyle karar verilmez” der, guardrail “bu veriyle bile karar verilecekse şu kadarına kadar” der.

Senkron tazeliği: veri kaç saat geç kalırsa karar bozulur?

Tazelik eşiği, kararın geri alınabilirliğine göre değişir. Bir uyarı göndermek için altı saatlik gecikme sorun değildir; bütçeyi yarıya indirmek için aynı gecikme fazladır. Pratikte işleyen ayrım şudur: aksiyon ne kadar sert ve ne kadar zor geri alınıyorsa, tazelik eşiği o kadar dar olmalıdır. Bütçeyi yüzde on artırmak ile kampanyayı durdurmak aynı veri yaşını hak etmez.

Aşağıdaki tablo, bir hesapta tartışmayı kapatan türden bir çerçevedir. Eşik değerleri örnektir; sizin hesabınızdaki senkron sıklığına ve atıf penceresine göre değişir. Önemli olan sayılar değil, her kontrolün bir sahibi ve kapı kapandığında net bir davranışı olmasıdır.

Kontrol	Neye bakar	Örnek eşik	Kapı kapalıysa
Senkron tazeliği	Son başarılı veri çekimi	6 saatten eski değil	Kural koşmaz, gerekçe loglanır
Veri kapsamı	Kesintisiz gün sayısı	28 günün tamamı dolu	Kural taslakta kalır
Para birimi	Hesap birimi ile eşik birimi	Birebir aynı	Bütçe aksiyonu bloke edilir
Zaman dilimi	Hesap ile raporun gün sınırı	Aynı saatte başlar	Günlük eşik devre dışı
Dönüşüm olgunluğu	Atıf penceresi kapandı mı	Son 3 gün hesaba katılmaz	Durdurma onaya düşer

Tazeliğin bir de sessiz hali vardır: senkron çalışır, veri gelir, ama gelen veri hep aynıdır. Bu durumda kural her saat koşar, hiçbir şey eşleşmez ve kimse bir şey fark etmez. Reklam Otomasyonu'ndaki sessiz kuralı bildir davranışı tam da buna karşılık gelir; bir kural üst üste sonuç üretmiyorsa pazarlama yetkililerine bildirim gider. Bozuk otomasyonun en tehlikeli biçimi yanlış karar vermesi değil, hiç karar vermeden açık görünmesidir.

Kaç günlük veri bir durdurma kararına yeter?

Bu sorunun tek bir doğru cevabı yok, ama yanlış cevapları çok net: “dün kötüydü” bir cevap değildir. Bir kampanyanın gerçekten kötü olduğunu söyleyebilmek için, o kampanyanın normal dalgalanmasını görmüş olmanız gerekir. Günlük harcaması düşük bir kampanyada üç günlük veri istatistiksel olarak neredeyse hiçbir şey söylemez; günde yüzlerce dönüşüm alan bir kampanyada aynı üç gün fazlasıyla yeterlidir. Karar penceresi, takvimden değil hacimden çıkar.

Bu yüzden minimum veri penceresi bir guardrail olarak tanımlanır ve hesap düzeyi politikada asgari veri günü olarak sabitlenir; hiçbir kural bu sınırı kendi başına gevşetemez. Kurala “son 7 gün” yazıp geçmek yerine, o 7 günün kaç dönüşüm içerdiğini sormak gerekir. Örnek sayılarla düşünmenin mantığı, aslında bir karşılaştırma testinde örneklem büyüklüğü sorma alışkanlığıyla aynıdır; iki seçenek arasında karar vermenin veri mantığı burada da geçerlidir.

Bir de öğrenme fazı meselesi var. Algoritmik kampanyalar açıldıktan sonra bir süre kararsız davranır; bu dönemde ölçülen ROAS, kampanyanın olgun performansını temsil etmez. Guardrail tarafında öğrenme fazındaki hedefleri atlamak bu yüzden vardır. Otomasyona ne zaman güveneceğinizi belirlerken bu dönemi ayrı tutmak şart; algoritmanın kendi optimizasyonuna ne zaman alan bırakılacağı ayrı bir karar setidir ve kural motoruyla çakışmaması gerekir.

Para birimi ve zaman dilimi uyuşmazlığı bütçe kararını nasıl saptırır?

Para birimi hatası sessizdir ve tam olarak bu yüzden pahalıdır. Hesap bir birimde faturalanırken eşiği başka bir birimde yazdıysanız, kural yanlış bir sayıyla karşılaştırma yapar ve sonuç makul görünür. “CPA 40'ın üstünde ise bütçeyi kıs” kuralı, hesap birimi ile eşik birimi ayrıştığında ya hiç tetiklenmez ya da her gün tetiklenir. İkisi de bir arıza sinyali değil, normal bir grafik gibi görünür.

Zaman dilimi kayması daha ince bir hatadır. Platformun günü ile sizin raporunuzun günü farklı saatte başlıyorsa, günlük harcama eşiği hep yarım bir günü ölçer. Ay sonu bütçe hedefi takibinde bu kayma birikir: ideal, gerçek ve tahmini harcama arasındaki sapma her gün biraz büyür ve ayın son haftasında ani bir frenle karşılaşırsınız. Harcamanın nereye gittiğini terim düzeyinde görmek, bu tür sapmaların gerçek kaynağını bulmayı kolaylaştırır; alakasız aramalara giden bütçeyi kesmek çoğu hesapta ilk düzeltmedir.

Bu iki kontrolün ortak özelliği, kurulum anında bir kez doğrulanıp sonra unutulabilecek olmasıdır. Reklam Otomasyonu'ndaki veri sağlığı kapısı hesap para birimini kural kurulmadan önce doğruladığı için, bu hata sınıfı kuralın ömrü boyunca değil kurulum ekranında yakalanır. Kural yazarken bir saniyelik sürtünme, üç hafta sonra yanlış kısılmış bir bütçeye tercih edilir.

Dönüşüm gecikmesi varken ROAS'a bakmak neden erken?

Uzun satış döngüsü olan işlerde platformun raporladığı dönüşüm değeri ile kasaya giren para arasında haftalar olabilir. Reklam bugün bir form getirir, satış ekibi iki hafta sonra görüşür, fırsat üçüncü haftada kazanılır. Bu düzende bugünün ROAS'ına bakıp durdurma kararı vermek, filmin ilk on dakikasında sonucu yazmaya benzer. Sorun kuralın hızında değil, ölçülen şeyin henüz oluşmamış olmasındadır.

Çözüm, ölçüyü platformun dönüşüm değerinden gelir tarafına taşımaktır. Reklam Otomasyonu'ndaki CRM'den gerçek ROAS yaklaşımı tam olarak bunu yapar: platformun kendi dönüşüm değeri yerine satış sürecinde kazanılan fırsat gelirini ölçer ve kohortlar olgunlaşmadan zarar kararı verilmesini engeller. Bu ölçünün kurulabilmesi için harcama ile gelirin aynı kimlikle eşleşmesi gerekir; reklam harcamasını CRM gelirine bağlayan döngüyü kurmak bu bölümün önkoşuludur.

Aynı veri hijyeni, reklam tarafına geri beslediğiniz listeler için de geçerlidir. Kirli e-posta alanları, eksik ülke bilgisi veya kopyalanmış kayıtlar hedef kitleyi olduğundan küçük ya da yanlış gösterir. CRM kayıtlarından hedef kitle oluştururken eşleşme oranı düşüyorsa, sorun genellikle platformda değil kaynak tablodadır. Kapı, dışarı çıkan veriyi de içeri giren veri kadar ciddiye almanız gerektiğini hatırlatır.

Kapı kapalıyken kural ne yapmalı?

Kapının kapanması bir hata mesajı değildir; bir karardır ve o kararın da bir davranışı olması gerekir. Üç makul seçenek vardır: kuralı hiç koşturmamak, kuralı koşturup aksiyonu onaya düşürmek, ya da yalnızca uyarı göndermek. Yanlış olan dördüncü seçenek, kapıyı görmezden gelip aksiyonu uygulamaktır. Hangi seçeneğin doğru olduğu, aksiyonun sertliğine bağlıdır.

Sert aksiyonlar için insan kararı en ucuz sigortadır. Bir kampanyayı durdurmak, bütçeyi ikiye katlamak ya da bir hedef kitleyi kapatmak, veri şüpheliyken otomatik uygulanmamalıdır. Onay kuyruğu bu yüzden vardır: eşleşme düşer, nedeni ve uygulanacak tam değişiklik görünür, siz onaylamadan kampanyaya dokunulmaz. Aynı mantığın süreç tarafındaki karşılığı da tanıdıktır; otomatik akışa bir insan onayı eklemek hız kaybı değil, geri dönülmez adımın önündeki fren mesafesidir.

Yumuşak aksiyonlar için ise durmak gereksiz bir maliyettir. Uyarı göndermek, bütçeyi yüzde beş kırpmak veya bir kampanyayı işaretlemek, veri biraz eski olsa bile makul kalır. Buradaki asıl kural şudur: kapı kapalıyken uygulanan her aksiyonun geri alınabilir olması gerekir. Uygulanmış bir kararı ya da koşunun tamamını 24 saat içinde tersine çevirebiliyorsanız, kapının kapalı olduğu bir günde bile hareket etmenin maliyeti sınırlıdır.

Kapıyı açmadan önce kuralı nasıl sınarsınız?

Bir kuralın veriyle nasıl davranacağını tahmin etmek yerine ölçmek mümkün. Backtest, kuralın son 28 günde kaç kez ve hangi kampanyalarda tetikleneceğini hiçbir şeye dokunmadan gösterir. Burada bakacağınız şey sadece tetiklenme sayısı değil, tetiklenme dağılımıdır. Kural 28 günde iki kez çalışıyorsa muhtemelen eşik çok dar; her gün her kampanyada çalışıyorsa muhtemelen kural bir eşik değil bir politika yazmıştır.

İkinci sınama, kendi sayılarınızla simülasyon. Örnek metrikleri elle girip koşulun eşleşip eşleşmediğini ve guardrail'in değişimi nasıl kırptığını görürsünüz; bu adımda hesaba hiçbir şey yazılmaz. Üçüncüsü, eşiği tahminle değil veriden seçmek: metriğin kampanyalarınız arasındaki dağılımına bakıp medyanı tek tıkla eşik yapabilir ve kaç kampanyanın yakalandığını okuyabilirsiniz. Aynı disiplin kreatif tarafında da işler; hangi görselin neden kazandığını sistemli test etmek eşik tartışmasını görüş meselesi olmaktan çıkarır.

Sonra da kademeli açmak kalır. Kuralı önce kampanyaların küçük bir kısmında, sadece göster modunda çalıştırın; kararları okuyun, kapının kaç kez kapandığını sayın, sonra onay moduna geçin. Güven oluştuğunda otomatiğe alın. Bu sıralamanın amacı yavaşlamak değil, kuralın yanlış olduğu durumu ucuz keşfetmektir.

Veri sağlığını haftalık rutine nasıl çevirirsiniz?

Kapı otomatik çalışır ama kapının kapandığı günlerin okunması insan işidir. Haftada bir, on beş dakikalık bir bakış çoğu hesap için yeterli: hangi kurallar kaç kez engellendi, engelin sebebi tazelik miydi kapsam mıydı, hangi hesapta tekrar ediyor. Bu liste bir süre sonra kendini tekrar etmeye başlar ve tekrar eden her kalem düzeltilebilir bir kurulum hatasıdır.

İkinci rutin, aksiyon sonrası okuma. Uygulanan her aksiyonun öncesi ve sonrası eşit pencerelerle karşılaştırıldığında, kuralın işe yarayıp yaramadığı hakkında gözlemsel bir fikir edinirsiniz. Bu karşılaştırma nedensellik iddia etmez ve etmemelidir; aynı hafta içinde sezon, stok ve rekabet de değişmiştir. Yine de bir kural üst üste durdurduğu kampanyaların ardından hesap toplamında bir iyileşme görünmüyorsa, o kuralın eşiğini yeniden konuşmak gerekir.

Üçüncüsü, çakışma denetimi. Aynı kapsamda biri bütçeyi açarken diğerini kısan kural çiftleri işaretlendiğinde, bunlar tek ekranda çözülür. Kural sayısı arttıkça çakışma olasılığı doğrusal değil hızlı büyür; kuralların koşma sırasını bilinçli belirlemek de bu yüzden bir ayar değil bir tasarım kararıdır. Veri sağlığı kapısıyla birlikte kurallarınızı bu disiplinle işletmek istiyorsanız Rocketly hesabınızı açıp kuralı önce sadece göster modunda çalıştırabilirsiniz.

Sıkça sorulan sorular

Veri sağlığı kapısı kuralı tamamen durdurur mu?

Kapı, doğrulama tamamlanmadan kuralın kurulmasına izin vermez; senkron tazeliği, 28 günlük veri kapsamı ve hesap para birimi doğrulanmadan kural iş görmez. Kurulmuş bir kuralda kapı kapandığında ne olacağını ise siz belirlersiniz: koşmamak, onaya düşürmek veya yalnızca uyarı göndermek.

Eşikleri her hesap için ayrı mı ayarlamak gerekir?

Evet, çünkü tazelik ve kapsam ihtiyacı hesabın hacmine ve satış döngüsüne bağlıdır. Günde birkaç dönüşüm alan bir hesapta 28 günlük pencere zorunluyken, yüksek hacimli bir hesapta daha kısa pencereler de anlamlı olabilir. Hesap düzeyi politika bu sınırları tek yerde tutar.

Veri eskiyse kural neden hiç koşmasın, yaklaşık bir karar veremez mi?

Yaklaşık karar, geri alınabilir aksiyonlarda makuldür. Durdurma ve büyük bütçe değişimi gibi geri dönüşü pahalı aksiyonlarda ise yaklaşık karar, kayıp fırsatı sabit maliyete çevirir. Ayrım aksiyonun sertliğine göre yapılır, verinin ne kadar eski olduğuna göre değil.

Kapı açıksa veri doğru demek midir?

Hayır. Kapı mekanik kontrolleri geçirir: veri taze mi, kapsam tam mı, birim tutarlı mı. Metriğin doğru metrik olup olmadığını, atıf tanımının işinize uyup uymadığını ve kayıtların CRM'de doğru eşleştiğini kapı bilemez. O katman yine de sizin tasarım kararınızdır.