Düzeltmek, Yönetilen Servise Geçmek ya da Yeniden Kurmak: Reklam Olay Pipeline'ınız Zirvede Olay Kaybettiğinde Her Yolun Maliyeti

Reklam olay pipeline'ınız zirve trafikte gösterim ve tıklama kaybediyorsa, üç çıkış yolu var. Sızdıran bölümleri düzeltebilir, olayları taşıyan ve saklayan sunucuları (çoğu zaman Kafka ve ClickHouse) yönetilen bir servise taşıyabilir ya da pipeline'ı dışarıdan bir firmayla yeniden kurabilirsiniz. Seçtiğiniz yol, kimi işe alacağınızı da belirler. Düzeltme için ekibinizin içinde çalışan mühendisler gerekir; yeniden kurulum içinse bütün bir pipeline'ı teslim edip devredebilecek bir firma gerekir. Seçmeden önce atribüsyon raporlarınızla bidder loglarınız arasındaki farka yıllık bir fiyat biçin. Ardından her yolu maliyetine, elinizde kalan kontrole ve fatura kestiğiniz rakamların ne kadar sürede yeniden doğru hâle geleceğine göre karşılaştırın.

Atribüsyon raporlarımızla bidder logları arasındaki fark bize neye mal oluyor?

Maliyetin büyük kısmı faturalarda görünür, bu yüzden işe onlardan başlayın. Bir ay seçin ve üç sayıyı yan yana koyun: reklamverenlere faturaladığınız gösterimler, her exchange'in size faturaladığı gösterimler ve bidder'ınızın logladığı kazanımlar.

Neyin parasını ödeyeceğinize exchange karar verir. Exchange'lerin ve bidder'ların reklamları gerçek zamanlı alıp satmak için kullandığı IAB Tech Lab standardı OpenRTB 2.6'ya göre exchange, faturalama bildirimini “kazanan bir teklif, exchange'e özgü iş politikasına göre faturalanabilir hâle geldiğinde” gönderir. Her exchange size kendi politikasına göre ve kendi kayıtlarından fatura keser; reklamverenlerinize ise sizin raporlarınızdan fatura kesilir. Pipeline'ınızın kaybettiği her gösterimin parası ödenmiş, ama hiç faturalanmamıştır. İki kez sayılan bir gösterim iki kez faturalanır ve reklamverenin kendi sayımı uyuşmadığında bunu bir alacak dekontuyla geri ödersiniz.

Kimsenin gerçek verisini değil, yuvarlak rakamları ele alalım. Bir platform ayda 500 milyon gösterim satın alıyor ve bunları reklamverenlere bin gösterim başına 2 dolardan yeniden satıyor. Gösterim olaylarının %3'ünü kaybederse 15 milyon gösterim faturalanmadan kalır; bu da mükerrer kayıtlar ve alacak dekontları hesaba katılmadan ayda 30.000 dolar, yılda 360.000 dolar eder.

Fiyatını biçmesi daha zor iki maliyet daha var. Biri, ekibinizin her ay reklamverenlere ve exchange'lere farkları açıklamak için harcadığı saatler. Diğeri, eksik veriye dayanarak verilen teklifler. İkisini de toplamın yanına not edin.

Yıllık toplam, kabaca bir yolun en fazla ne kadara mal olması gerektiğini gösterir. Ortadan kaldırdığı farktan daha pahalıya gelen bir yolun başka bir gerekçesi olmalıdır; örneğin mevcut pipeline'ın kaldıramayacağı bir trafik büyümesi.

Yolların fiyatını çıkarmadan önce farkı bölün. Bidder loglarıyla uyuşmayan raporlar üzerine yazı, yeniden sayımı anlatıyor: bidder loglarınızdaki her kazanım, raporlarınızdaki bir gösterimle açık artırma kimliği, yani her exchange'in bir açık artırmaya bastığı kimlik üzerinden eşleştirilir. Yeniden sayım, farkın ne kadarının kaybolan olaylardan, ne kadarının iki tarafın farklı kurallarla saymasından geldiğini gösterir. Farklı kurallar, tek bir kural setinde anlaşıp bu seti hangi pipeline'ı çalıştırıyorsanız orada uygulayarak düzeltilir. Yönetilen bir servis ya da yeni bir pipeline sayım kurallarını değiştirmez.

Her yol parasal olarak neye mal olur?

Düzeltme ve yeniden kurulum çoğunlukla proje olarak ödenir. Yönetilen bir servis ise kullandığınız sürece her ay bir fatura ekler.

Yerinde düzeltmenin maliyeti mühendislik zamanıdır; bu zaman ya kendi mühendislerinizden ya da ekibinizin içinde çalışan dışarıdan mühendislerden gelir. Yeni bir abonelik yoktur. İkinci bir düzeltme turu planlayın, çünkü düzeltmelerden sonraki ilk yoğun dönem çoğu zaman yetişemeyen bir sonraki bölümü ortaya çıkarır.

Yönetilen bir servis her ay fatura keser ve faturanın bir kısmı olayların gigabaytı başına fiyatlandığı için trafiğinizi takip eder. Sağlayıcının sunucuları dışındaki her şeyi yine sizin mühendisleriniz işletir. Amazon MSK Serverless, AWS'nin Kafka için sunduğu yönetilen servisin seçeneklerinden biridir; Kafka, olayları toplama ile veritabanı arasında tutan kuyruktur. 14 Ekim 2026'da okunan fiyatlandırma sayfası, her küme (servisin her ayrı kurulumu) ve her partition (kuyruğun bir dilimi) için saatlik bir ücret listeliyor. Buna kuyruğa yazılan ve kuyruktan okunan her gigabayt için bir ücret ile depolama için bir ücret ekleniyor. Dolayısıyla aynı olayları okuyan her ek program, örneğin bidder loglarınıza karşı günlük bir yeniden sayım, faturayı büyütür.

Yönetilen yolun fiyatını gelecek yılın en yoğun ayında beklediğiniz trafiğe göre çıkarın ve bu trafiği sağlayıcının sınırlarıyla karşılaştırın. Örneğin bir MSK Serverless kümesi, 14 Ekim 2026'da okunan kota sayfasına göre saniyede 200 megabaytın üzerindeki yazmaları yavaşlatır.

Yeniden kurulumun parasının çoğu projenin kendisine gider. Buna eski ve yeni pipeline'ların yan yana çalıştığı ayları ve kendi ekibinizin işi incelemek ve kabul etmek için harcadığı saatleri ekleyin. Devir tesliminden sonra yeni pipeline'ı birinin işletmesi gerekir ve sözleşme bunun kim olduğunu belirtmelidir. Teklifleri kalem kalem yan yana koyabilmek için her firmadan aynı kapsamı, paralel çalışma dahil, yazılı olarak fiyatlandırmasını isteyin.

Her yol elimizde ne kadar kontrol bırakır?

Yönetilen bir servis, takviminizden başlayarak kontrolün bir kısmını elinizden alır. MSK sürüm destek politikasına göre, destek bitiş tarihi geçmiş bir Kafka sürümünde hâlâ çalışan bir küme “önerilen Kafka sürümüne otomatik olarak yükseltilir”. Politika şunu da ekliyor: “Yükseltmeden önce herhangi bir bildirim almazsınız.” Kendi yükseltmelerinizi bu tarihlerden önce planlayın ya da sağlayıcının zamanlamasını kabul edin. İleride ayrılmak başlı başına bir taşıma işidir. Veriler başka yerde işlettiğiniz sistemlere kopyalanır ve onları yazan ya da okuyan her program yeni sisteme geçirilir.

Yerinde düzeltme, pipeline'ın tüm kontrolünü sizde bırakır. Düzeltmelerin nasıl çalıştığını onları yapan kişiler bilir; bu yüzden bu kişilerin bir kısmı sözleşmeyle dışarıdan çalışıyorsa, ayrılmadan önce her düzeltme için yazılı bir not isteyin.

Yeniden kurulumda kontrolünüz, sözleşmenin size verdiği kadardır. Sözleşme, kodun şirketinize ait olduğunu ve işin başından itibaren şirketinizin hesaplarında tutulacağını söylemelidir. Tasarım belgeleri kodla birlikte gelmeli, yanlarında da runbook'lar, yani her alarmın nasıl ele alınacağını anlatan yazılı talimatlar olmalıdır. Mühendisleriniz de dışarıdaki firma hâlâ projedeyken yeni pipeline'ın alarmlarına yanıt vermeye başlamalıdır.

Fatura kestiğimiz rakamları en kısa sürede hangi yol düzeltir?

Yerinde düzeltme bir sonraki zirvede, pipeline'ın her adımındaki saatlik sayılar öncesi ve sonrasıyla karşılaştırılarak kontrol edilebilir. Yönetilen bir servise geçiş daha uzun sürer, çünkü veriler kopyalanır, olayları yazan ya da okuyan her program yeni sisteme geçirilir ve iki sistem, sayıları birbirini tutana kadar yan yana çalışır. Sağlayıcının sunucuları dışındaki sızıntıların yine de düzeltilmesi gerekir; örneğin tarayıcılardan ve uygulamalardan olayları alan program olan toplayıcıda. En uzun süren yol yeniden kurulumdur. Bidder loglarıyla uyuşmayan raporlar üzerine yazının açıkladığı gibi, fatura kestiğiniz raporlar yeni pipeline'a geçmeden önce iki pipeline da en az bir tam faturalama dönemi boyunca aynı olaylarla çalışır.

Kendi verilerimizden yola çıkarak bir yolu nasıl seçeriz?

Seçimin büyük kısmını dört yanıt belirler. İlk üçü zaten tuttuğunuz kayıtlardan gelir, dördüncüsü bir test gerektirebilir.

• Farkın ne kadarı kaybolan olaylar, ne kadarı sayım kuralları? Bu ayrımı yeniden sayım verir
• Zirvede olaylar hangi adımlarda kayboluyor? Toplayıcıdan veritabanına kadar her adımdaki saatlik sayılar, sayının nerede düştüğünü gösterir
• Mühendislerinizin pipeline'a harcadığı saatler geçen çeyrekte nereye gitti? Ticket'ları ve alarmları, sunucuları ayakta tutmaya harcanan zaman ve sayım ya da veri sorunlarını düzeltmeye harcanan zaman olarak ayırın
• Pipeline'ın on iki ay sonra hangi trafiği taşıması gerekiyor? Kendi trafiğinizden kaydedilmiş bir günü bu hızda yeniden gönderin ve pipeline'ın dayanıp dayanmadığına bakın

Yan yana konduğunda üç yol şöyle görünür.

• Yerinde düzeltme. Mühendislik saatleri, tam kontrol ve bir sonraki zirvede kontrol edebileceğiniz sonuçlar
• Yönetilen servis. Trafiği takip eden aylık bir fatura, sağlayıcının takvimine göre yapılan yükseltmeler ve bir taşıma işinin ardından gelen sonuçlar
• Dışarıdan bir firmayla yeniden kurulum. Bir proje artı aylarca süren paralel çalışma, sözleşme yoluyla kontrol ve en az bir tam faturalama döneminin ardından gelen sonuçlar

Yolları karşılaştırmak için her biri için önümüzdeki on iki aydaki maliyetini ve farkın aylık fiyatının, o yol farkı kapatana kadar geçecek ay sayısıyla çarpımını toplayın. Toplamları yalnızca gerçekten bulduğunuz kayıpları ortadan kaldırabilecek yollar arasında karşılaştırın. Olaylar veritabanına ulaşmadan kayboluyorsa yönetilen bir veritabanı işe yaramaz. Fark, iki tarafın günü farklı saatlerde kapatmasından geliyorsa yeniden kurulum işe yaramaz.

Yolları birleştirebilir miyiz?

Çoğu zaman en ucuz plan, üç yolu belirli bir sırayla birleştirir. Önce sayım kurallarında anlaşın, çünkü bu kurallar altta ne çalışırsa çalışsın geçerlidir. Ardından yerini gösterebildiğiniz sızıntıları düzeltin. Sunucular ve tasarımla ilgili kararı en sona, birkaç haftalık temiz saatlik sayılar geriye ne kaldığını gösterdiğinde bırakın.

Yeniden kurulum, kendi sunucularınızı işletmek anlamına gelmek zorunda değildir. Yeni bir pipeline, yönetilen bir kuyruk ve yönetilen bir analitik veritabanı üzerinde durabilir; bazı sağlayıcılar yükleyiciyi, yani olayları kuyruktan veritabanına yazan adımı da işletir. ClickHouse veritabanının barındırılan sürümü olan ClickHouse Cloud, bunun için ClickPipes'ı sunar. Dokümantasyonu ClickPipes'ı “yönetilen bir entegrasyon platformu” olarak tanımlar ve kaynakları arasında Kafka ile AWS MSK'yı sayar. Bu durumda dışarıdaki firma, platformunuza özgü olanı kurar: örneğin sayım kurallarını ve bidder loglarınıza karşı günlük yeniden sayımı; buna ek olarak toplayıcıyı ve yönetilen bir seçeneğin uymadığı her yerde bir yükleyiciyi.

Dışarıdan bir firmanın teklifi neyi göstermeli?

Bir firma hangi yolu önerirse önersin, teklifi kendi verilerinizle doğrulanabilir olmalıdır. Yola uyan kontrolleri isteyin.

• En yoğun saatinize ait her adımdaki sayılar; firmanın önerdiği her düzeltmeden önce ve sonra
• Gelecek yılın trafiğiyle en yoğun ayınızın faturası, sizin işletmeye devam edeceğiniz parçalar ve sağlayıcıdan nasıl ayrılacağınız
• Bidder loglarınıza karşı, üzerinde anlaşılmış bir fark sınırı içinde kalan günlük bir yeniden sayıma bağlı ödemeler; paralel çalışmanın süresi ve mühendislerinizin alarmları devralacağı tarihle birlikte

amBrain reklam olay pipeline'ları geliştiriyor mu?

amBrain, reklam teknolojisi için olay analitiği pipeline'ları geliştirir: gösterim ve tıklama olaylarının toplanması, işlenmesi ve raporlanması. AdTech'te ayrıca DSP geliştirme, real-time bidding platformları ve ad exchange mühendisliği üzerinde çalışıyor; RTBBidder ise amBrain'in bir müşteri için geliştirdiği bir talep tarafı platformudur.

amBrain; trading ve reklam teknolojisi alanlarındaki yavaş sistemleri teşhis eder: çalışan platform uçtan uca ölçülür ve rapor, sürenin nereye gittiğini açıkça gösterir.

amBrain 2019'dan bu yana yazılım geliştiriyor. Üç formatta çalışıyor: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler. Mülkiyet konusundaki satırı ise şöyle: “Müşteri, yeniden kullanılabilir bileşenlerimiz dışında ürünün ve kodun tam mülkiyetini elinde tutar.”

Buradaki hiçbir şey bir müşterinin pipeline'ını anlatmaz. Amazon MSK, Kafka, ClickHouse ve ClickPipes yaygın örnekler olarak anılıyor; amBrain bunları kullandığını ya da bir pipeline'ı yönetilen bir servise taşıdığını iddia etmiyor. Yazı amBrain'e ait fiyat ya da takvim vermez ve yukarıdaki dolar rakamları kurgusal bir örnektir.

amBrain ile görüşürseniz, işe farkınızın yıllık fiyatıyla ve en yoğun gününüzün saatlik sayılarıyla başlayın.

Reklam olay pipeline'ını düzeltme ya da yeniden kurma üzerine sık sorulan sorular

• Yeniden kurmaya karar vermeden önce düzeltmeleri ne kadar süre denemeliyiz? Düzeltmelerden sonraki ilk zirve boyunca; düşüş yalnızca bir sonraki adıma kaydıysa ikinci bir tur boyunca da. Sayı zaten düzelttiğiniz bir adımda yeniden düşüyorsa ya da ikinci tur bir sonraki zirvede yeni bir düşüş bırakıyorsa, düzeltmeler trafiğinize yetişemiyor demektir. Yeniden kurulum işte o zaman masaya gelmelidir
• Pipeline'ı yeniden kuran firma sonrasında onu işletebilir mi? Sözleşme alarmlara kimin ve ne kadar hızlı yanıt vereceğini belirtiyorsa bu ayarlanabilir. Yine de kendi mühendislerinizi alarm nöbet çizelgesinde tutun; böylece sözleşme sona erdiğinde pipeline'ı bilen kimsenin kalmadığı bir durum oluşmaz