Reklam Raporları Neden Bidder Loglarıyla Uyuşmuyor ve Pipeline'ı Kim Yeniden Kurabilir

Reklam raporları bidder loglarıyla bir türlü uyuşmuyorsa, aynı farkın arkasında iki sorun olabilir. Ya olay (event) denen gösterim ve tıklama kayıtları raporlara giderken, çoğu zaman zirve trafikte kaybolur ya da her taraf onları kendi kurallarıyla sayar. Exchange'in her açık artırmaya verdiği kodlar olan açık artırma kimlikleri üzerinden yapılan bir yeniden sayım, bu ikisini birbirinden ayırır. Bu sayımı kimseyle anlaşmadan önce yapın, çünkü yeni bir pipeline tek başına yalnızca ilk sorunu çözer.

Reklam raporlarının bidder loglarıyla uyuşmaması ne anlama gelir?

Bidder loglarınız, bidder'ınızın katıldığı her açık artırmayı, verdiği her teklifi ve kazandığı her açık artırmayı kaydeder. Raporlarınız ise tarayıcılardan ve uygulamalardan gelen gösterimler ve tıklamalar gibi daha sonra ulaşan olaylardan oluşturulur. Aradaki farkın nedeni şu ikisinden biri ya da her ikisidir:

• Kaybolan olaylar. Gösterim ya da tıklama gerçekleşti, ama olayı raporlara hiç ulaşmadı. Zirve trafikte büyüyen bir fark, pipeline'da kaldıramadığını düşüren bir bölüme işaret eder
• Farklı kurallar. İki taraf günü farklı saat dilimlerinde kapatıyor ya da geç gelen bir olayı başka bir saate yazıyor olabilir. Taraflardan biri yeniden gönderimden sonra bir olayı iki kez sayabilir ya da bidder'ın yine de saydığı bot trafiğini ayıklayabilir. Atıf da kendi kurallarını ekler; örneğin bir tıklamadan ne kadar sonra gelen bir dönüşümün hâlâ sayılacağı gibi

Her iki durumda da bu fark para kaybettirir. Reklamverenlere raporlarınıza göre fatura kesiyorsanız, kaybolan gösterimler için eksik, iki kez sayılanlar için fazla fatura kesersiniz; her exchange ise size genellikle kendi sayımına göre fatura keser. Bu olaylardan öğrenen bir bidder da tekliflerini yanlış rakamlara göre belirler.

Kaybolan olayları farklı kurallarla sayılan olaylardan nasıl ayırt edebiliriz?

İki tarafı olay olay eşleştirin. IAB Tech Lab'in gerçek zamanlı teklif verme protokolü OpenRTB, her açık artırmaya exchange'in atadığı bir teklif isteği kimliği (bid request ID), istekteki her gösterime de kendi kimliğini verir. Bidder'ınız exchange'den bu kimlikleri, kazandığınızda gönderdiği bildirime ve reklamın kendisine yazmasını isteyebilir. Böylece her gösterim olayı bidder loglarınızdakiyle aynı kimlikleri taşır.

Kimliklerin hiçbiri tek başına yeterli değildir. OpenRTB 2.6'ya göre her exchange kendi istek kimliklerini belirler; dolayısıyla iki exchange'in aynı kimliği kullanmasını engelleyen hiçbir şey yoktur. Gösterim kimliği yalnızca kendi isteğinin içinde benzersizdir ve genellikle 1'den başlar. Bu yüzden üç değeri birlikte eşleştirin: exchange, istek kimliği ve gösterim kimliği.

Ardından yeniden sayımı yapın:

• Yoğun bir günün her saati için bidder loglarındaki kazanımları ve raporlarınızdaki gösterimleri, ikisini de UTC'ye göre ve bu üç parçalı anahtarla eşleştirerek sayın
• Ertesi gün yeniden sayın. Fark küçülürse, bir kısmı geç gelen olaylardan kaynaklanıyordur
• Hâlâ eksik olan kazanımların payı en yoğun saatlerde artıyorsa, pipeline zirvede olay kaybediyordur. Saatten saate benzer kalan bir pay beklenen bir durumdur, çünkü bazı kazanımlar hiçbir zaman gösterime dönüşmez
• Geri kalanını sınıflandırın. Her tarafta farklı bir saate düşen bir olay, iki tarafın farklı saat dilimleri ya da kesim saatleri kullandığı anlamına gelir. Çift sayım genellikle bir yeniden denemeden kaynaklanır. Bir olay yalnızca nihai raporda eksikse, onu bot filtrelemesi gibi bir filtre çıkarmıştır

Olaylarınız açık artırma kimliği taşımıyorsa, ilk düzeltme onları eklemektir; çünkü onlar olmadan yeniden sayım yalnızca toplamları karşılaştırabilir. Yukarıda bağlantısı verilen reklam ölçümlemesi üzerine teknik yazı, zaman damgalarını ve geç gelen olayları ayrıntılı olarak ele alıyor.

Zirve trafikte olaylar nerede kayboluyor?

Kafka ve ClickHouse üzerine kurulmuş bir pipeline düşünün. Bir toplayıcı (collector) her olayı tarayıcıdan ya da uygulamadan alır ve bir mesaj kuyruğu olan Kafka'ya yazar. Bir yükleyici (loader) Kafka'dan okur ve olayları paketler hâlinde, raporlarınızın arkasındaki analitik veritabanı ClickHouse'a yazar. Zirve anında olaylar her adımda kaybolabilir:

• Toplayıcı aşırı yüklenir. Reddettiği ya da çok geç yanıtladığı istekler, tarayıcı ya da uygulama onları yeniden göndermedikçe kaybolur. Olay Kafka'ya ulaşmadan “alındı” yanıtı veren bir toplayıcı, çöktüğünde elinde tuttuğu her şeyi de kaybeder
• Kafka olayları yeterince hızlı alamaz. Kafka'nın dokümantasyonu, olaylar iletilebileceklerinden daha hızlı geldiğinde ne olduğunu anlatır. Kafka'ya yazan kod belirli bir süre bekler, sonra bir hatayla vazgeçer. Bu hatayı görmezden gelen bir toplayıcı olayı iz bırakmadan kaybeder
• Yeniden denemeler mükerrer kayıt üretir. Kafka'da, kendi yeniden denemelerinin ikinci bir kopya yazmasını engelleyen bir ayar vardır. Kafka'nın Java istemcisi bu ayarı varsayılan olarak açar; diğer dillerdeki istemci kütüphaneleri kendi varsayılanlarını belirler ve bazıları kapalı bırakır. Bu ayar, kodunuzun ürettiği mükerrerleri yakalamaz; örneğin yeniden başlatmadan sonra tekrar gönderilen bir paketi ya da iki kez tetiklenen bir pikseli
• Toplu yüklemeler bütün hâlinde başarısız olur. ClickHouse'un dokümantasyonu olayların büyük paketler hâlinde yüklenmesini önerir. Yükleme modlarından birinde tek bir hatalı satır, paketin tamamının reddedilmesine yol açar. Vazgeçen bir yükleyici paketteki tüm olayları kaybeder; paketi değiştirmeden yeniden gönderen bir yükleyici ise aynı hatalı satıra yeniden takılır. Bu yüzden hatalı satırların ayrılması ve sayılması gerekir. Bir yazma işlemi zaman aşımına uğradığında ve verinin yazılıp yazılmadığını kimse bilmediğinde, birebir aynı paketi yeniden göndermek ancak tablo tekrar gelen paketleri atacak şekilde ayarlanmışsa güvenlidir; kendi sunucularınızda çalışan temel bir ClickHouse tablosu bunu varsayılan olarak yapmaz

Mühendislerinizden, kötü geçen bir günün en yoğun saatine ait şu kayıtları isteyin:

• Yük dengeleyicideki ve toplayıcıdaki hatalar ve zaman aşımları, ayrıca toplayıcının loglarında Kafka'ya yapılan başarısız yazma işlemleri
• Consumer lag, yani yükleyicilerin ne kadar geride kaldığı, ve Kafka'nın veriyi sakladığı süreden uzun bekledikleri için okunmadan sildiği olaylar
• ClickHouse'a yapılan başarısız yazma işlemleri ve bunların hata mesajları
• Her adımda saat başına sayım: toplayıcının aldığı, Kafka'ya yazılan, yükleyicinin okuduğu ve ClickHouse'a kaydedilen olaylar

İşin büyük kısmını son kayıt görür. Zirvede bir adımın sayısı düşerken bir önceki adımınki sabit kalıyorsa, olaylar bu iki adım arasında kaybolmuştur.

Pipeline'ı düzeltmeli miyiz, yönetilen bir servise mi geçmeliyiz, yoksa yeniden mi kurmalıyız?

Mevcut pipeline'ı düzeltin:

• Ne zaman uygun: yeniden sayım çoğunlukla farklı kurallara ya da adını koyabildiğiniz birkaç sızıntıya işaret ediyorsa ve pipeline düzeltmelerden sonra en yoğun saatinize yetişebiliyorsa
• Ödediğiniz bedel: mühendislik süresi ve daha büyük bir zirvenin bir sonraki zayıf noktayı ortaya çıkarma riski
• Kodun sahibi: siz; bilgi de mühendislerinizde kalır

Sunucuları sağlayıcının işlettiği, Kafka için Amazon MSK ya da ClickHouse için ClickHouse Cloud gibi yönetilen bir servise geçin:

• Ne zaman uygun: mühendisleriniz sayım mantığından çok Kafka ve ClickHouse sunucularını ayakta tutmaya zaman harcıyorsa ve kayıplar bu sunucuların zirvede kapasitesinin yetmemesinden kaynaklanıyorsa
• Ödediğiniz bedel: trafiğinizle birlikte büyüyen aylık bir fatura. 7 Ekim 2026'da okunan fiyatlandırma sayfalarına göre iki servis de işlem gücü ve depolama için ücret alıyor; ClickHouse Cloud ise dışarı veri aktarımını ve kendi veri alım servisini ayrıca listeliyor. En yoğun ayınızın faturasını ve ileride başka bir yere taşınmanın maliyetini tahmin edin
• Çözmedikleri: hâlâ sizin işlettiğiniz toplayıcı ve yükleyici, mükerrer kayıtlar, geç gelen olaylar ve bidder loglarınızla mutabakat. Servis kendisine gönderdiğinizi saklar, bidder'ınızın ne saydığından haberi yoktur
• Kodun sahibi: siz; servis ise sağlayıcının koşullarıyla çalışır

Pipeline'ı yeniden kurun:

• Ne zaman uygun: yeniden sayım birkaç adımda kayıp gösteriyorsa ya da tasarım trafiğinizle birlikte büyüyemiyorsa. Eksik açık artırma kimlikleri, ancak onları eklemek her adımı değiştirmek anlamına geliyorsa sizi yeniden kuruluma iter
• Ödediğiniz bedel: üç yol arasında en fazla mühendislik işi, ayrıca eski ve yeni pipeline'ların yan yana çalıştığı bir dönem

Hangi firmalar Kafka ve ClickHouse üzerinde bir reklam olayı pipeline'ını yeniden kurabilir?

Bu işi iki tür firma yapar ve bu yazı ikisini de sıralamıyor. Reklam teknolojisi mühendislik firmaları bidder, exchange ve reklam sunucusu kurar; bu yüzden açık artırma kimliklerinin nereden geldiğini bilirler, ama sizin hacminizde bir olay pipeline'ı işletip işletmediklerini sorun. Veri mühendisliği firmaları birçok sektör için olay pipeline'ı kurar, ama her zaman reklam teknolojisi için değil. Onlara OpenRTB ile çalışıp çalışmadıklarını ve bir exchange ile sayım mutabakatı yapıp yapmadıklarını sorun.

Bir firmayla anlaşmadan önce neler sormalıyız?

Listenizdeki her firmaya aynı beş soruyu sorun.

Mükerrer kayıtları nasıl temizliyorsunuz? İyi bir yanıt, her olaya oluşturulduğu anda, herhangi bir yeniden denemeden önce verilen ve açık artırma kimlikleri ile olay türünden türetilen bir kimlikten söz eder. Pipeline mükerrerleri iki kez temizler: bir kez olayları kaydederken, bir kez de raporlar onları okurken. İkinci geçiş önemlidir, çünkü ClickHouse mükerrerleri arka planda, önceden planlayamayacağınız zamanlarda temizler. Dokümantasyonu bunun “mükerrer kayıt olmamasını garanti etmediğini” söylüyor.

Geç gelen olayları nasıl ele alıyorsunuz? İyi bir yanıt, her olay türü için sayıların hâlâ değişebildiği belirli bir süreden ve bundan sonra kesinleştikleri bir noktadan söz eder. Daha geç gelen bir olay atılmamalı; yine de sayılmalı ve geç olarak işaretlenmelidir.

Rakamlarınızı bidder loglarımızla ve ortaklarımızın raporlarıyla nasıl karşılaştırıyorsunuz? Açık artırma kimlikleri üzerinden günlük bir yeniden sayım ve her fark için yazılı bir gerekçe arayın. Farkın hangi büyüklüğe ulaştığında birinin konuyu exchange'e taşıyacağında anlaşın.

Sistemi zirve yükümüzün üzerinde nasıl test edeceksiniz? Kaydedilmiş yoğun bir günü en yoğun saatinizden daha yüksek bir hızda yeniden oynatmalarını isteyin. Yeniden oynatma sırasında bir toplayıcıyı ve bir veritabanı sunucusunu kapatsınlar. Sonunda her olay ya kaydedilmiş ya da düşürülmüş olarak sayılmış olmalı.

Kodun sahibi kim olacak? Yazılı olarak sizin şirketiniz; kod da ilk günden sizin depolarınızda duracak. Firmanın elinde tuttuğu her şey, iş bittikten sonra onu kullanmanızı ve değiştirmenizi sağlayan bir lisansla birlikte adıyla listelenmeli.

Uyarı işaretleri nelerdir?

• Kimse yeniden sayım yapmadan ya da bidder loglarınızı açmadan yeniden kurulum öneriliyor
• Firma, yeni raporların bidder'la birebir uyuşacağını vaat ediyor
• Mükerrer kayıtlar konusundaki tek yanıt, her olayın “tam olarak bir kez” teslim edileceği vaadi; iki kez tetiklenen bir piksel gibi kendi kodunuzun ürettiği mükerrerler hakkında ise tek kelime yok
• Tek kanıt, sizin trafiğinizin yeniden oynatılması değil, uydurma olaylarla yapılmış bir yük testi

amBrain nerede devreye girer?

AdTech'te amBrain; DSP geliştirme, real-time bidding platformları ve ad exchange mühendisliği üzerinde çalışıyor. Bu işler arasında, amBrain'in bir müşteri için geliştirdiği talep tarafı platformu RTBBidder de var.

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üşteri, amBrain'in yeniden kullanılabilir bileşenleri dışında ürünün ve kodun tam mülkiyetini elinde tutar.

Bu yazı bir vaka çalışması değildir. Hiçbir müşterinin olay pipeline'ını anlatmaz; RTBBidder'ın adı yalnızca amBrain'in geliştirdiği bir DSP olarak geçer. Kafka ve ClickHouse burada amBrain'in projelerinin ya da kullandığı araçların tarifi olarak değil, örnek bir teknoloji yığını olarak yer alıyor. Yazı fiyat ya da takvim vermez.

Raporlarınız ile bidder loglarınız uyuşmuyorsa önce yeniden sayımı yapın. Sonra sonuçlarını ve aynı beş soruyu, amBrain dahil listenizdeki her firmaya götürün.

Sık sorulan sorular

• Raporlarımız ile bidder logları hiç yüzde 100 uyuşacak mı? Hayır. OpenRTB, exchange'in kazandığınızı bildiren mesajının “teslim edilmiş, görüntülenmiş ya da faturalanabilir bir reklamın göstergesi olmak zorunda olmadığını” söyler; bazı olaylar da bot trafiği olarak filtrelenir. Her bir kısmı için yazılı bir gerekçesi olan istikrarlı bir fark hedefleyin ve her ortakla hangi sayıma göre fatura keseceğinizde anlaşın
• Kafka ve ClickHouse kullanmak zorunda mıyız? Hayır. Başka kuyruklar ve analitik veritabanları da aynı işi görebilir; yeniden sayım ve beş soru hepsi için geçerlidir
• Yeni pipeline kurulurken eski raporları nasıl çalışır durumda tutarız? İki pipeline'a da aynı olayları verin ve her birini her gün bidder loglarıyla karşılaştırın. Fatura kesmekte kullandığınız raporları yeni pipeline'a en son, her farkın açıklandığı tam bir faturalama döneminin ardından geçirin