Yayıncılar ve Reklam Ağları İçin Header Bidding: Yönetilen Wrapper, Açık Kaynaklı Prebid veya Kendi Katmanınız

Header bidding, bir yayıncının reklam sunucusu neyi göstereceğine karar vermeden önce çok sayıda reklam alıcısından aynı anda fiyat istemesini sağlar. Böylece bütün alıcılar aynı alan için rekabet eder. Buna ulaşmanın üç yolu var. Biri yönetilen wrapper'dır: bir sağlayıcının kodun ve ayarlarının barındırılan sürümü. Bir diğeri, kendi ekibinizin işlettiği ücretsiz, açık kaynaklı Prebid yazılımıdır. Üçüncüsü kendi yazdığınız bir katmandır. Aralarındaki fark çoğunlukla bakımı kimin yaptığında ve ham açık artırma verisini kimin görebildiğinde toplanır.

Header bidding ne yapar?

Bir sayfada reklam için bir alan olduğunda, sayfadaki küçük bir kod parçası birkaç teklif verene teklif isteği gönderir. Teklif isteği, hangi alanın hangi sayfada satışta olduğunu bildirir. Prebid.org bunun için ücretsiz, açık kaynaklı bir yazılım yayımlıyor. Olağan kurulumu şöyle anlatıyor: “Prebid, reklam sunucusu çağrılmadan önce teklifleri toplar ve nihai kararı reklam sunucusu verir.” Teklif verenler arz tarafı platformları (SSP), talep tarafı platformları ve reklam borsalarıdır; her biri bir fiyat döndürür. Kod en iyi fiyatları reklam sunucusuna iletir, o da bunları doğrudan anlaşmalarınızla karşılaştırır. Bu makalede alıntılanan bütün sayfalar 10 Kasım 2026'da okundu.

Wrapper, bu kodun etrafındaki kaptır: alıcı listesi, yanıtlar için süre sınırı, fiyat kuralları ve reklam sunucusuyla bağlantı. Prebid.org, yazılımının bu türdeki en yaygın kullanılan wrapper olduğunu söylüyor. Ayrıca Prebid'in “tam teşekküllü bir teklif kitaplığı olarak da kullanılabileceğini”, kazananı sayfada seçtiğini ve herhangi bir reklam sunucusunun diğer talep kaynakları gibi ona teklif verebileceğini ekliyor.

Header bidding gelirde neyi değiştirir?

Her alanı aynı anda daha fazla alıcı gördüğü için kazanan fiyat yükselebilir. Kazancın büyüklüğü trafiğinize, formatlarınıza ve hangi alıcıların kitlenizi istediğine bağlıdır. Prebid, isteklerin paralel gittiğini söylüyor: “İstekler, tek tek değil, bütün teklif verenlere aynı anda gönderilir.”

Bunun bir bedeli var. Prebid'in sayfası şöyle diyor: “Reklam sunumunu geciktirirseniz, sayfadan çok çabuk çıkan kullanıcılardan gelen gösterimleri kaybedebilirsiniz.” Daha az teklif veren, daha hızlı bir açık artırma demektir, “ama daha az talep ortağı, en iyi teklifi yakalamak için daha az şans demektir de.” Bin sayfa görüntüleme başına geliri (sayfa RPM) ve sayfa hızını birlikte ölçün.

İstemci taraflı mı, sunucu taraflı mı; sayfa hızına ne olur?

İstemci taraflı bir açık artırmada teklif isteklerini ziyaretçinin tarayıcısı gönderir. Bunu, “tarayıcıda çalışan bir JavaScript kitaplığı” olan Prebid.js yapar. Sunucu taraflı bir açık artırmada tarayıcı bir sunucuya tek bir istek gönderir, alıcılara o sunucu sorar. Prebid'in sunucu ürünü Prebid Server'dır. Prebid.org, yükü bir sunucuya devretmenin “tarayıcıdan istemci tarafında çalıştırmaktan daha hızlı olabileceğini” ve ikisinin karışımının da mümkün olduğunu söylüyor. Kendi sayfalarınızda “teklif veren sayısını, zaman aşımı değerlerini ve istemci ile sunucu seçimini” test etmenizi öneriyor.

Prebid.org, sunucu taraflı teklif vermenin “JavaScript yerleştirebileceğiniz HTML başlık bölümlerinin bulunmadığı, mobil uygulamalar ve Accelerated Mobile Pages (AMP) siteleri gibi ortamlarda zorunlu” olduğunu söylüyor. Uygulama trafiğinde bu, tercihin bir kısmını belirler.

Yönetilen bir wrapper neleri kapsar?

Yönetilen wrapper, bir sağlayıcının header bidding kurulumunu sizin için kurduğu, barındırdığı ve güncel tuttuğu bir hizmettir. Prebid.org, mühendisi olmayan yayıncıların “Prebid'i sizin için entegre edip bakımını yapabilecek yönetilen hizmet şirketlerini” kullanabileceğini söylüyor ve bunları listeliyor. Dizininde Adapex, Aditude, AdPushup, Assertive Yield, Freestar, Livewrapped, Magnite, Media.net, Microsoft Monetize, PubMatic, Setupad ve başkaları yer alıyor.

Kapsam sağlayıcıdan sağlayıcıya değişir. Magnite, hizmet olarak sunduğu Prebid'in büyük yayıncıların “özel header bidding uygulamalarını kod yazmadan devreye almasını ve yönetmesini” sağladığını söylüyor. Bu, Magnite'ın kendi iddiasıdır. Bunların bir karışımını bekleyin ve hangilerinin fiyata dahil olduğunu sorun:

• Güncel tutulan wrapper kodu, alıcı listesi ve süre sınırı, ayrıca reklam sunucusu kurulumu
• Ayarları geliştirici olmadan değiştirmek için bir ekran ve raporlar
• Onay bağlantısı ve sunucu taraflı açık artırma istiyorsanız barındırılan bir Prebid Server

Yönetilen bir wrapper ile nelerden vazgeçersiniz?

Bedeller para, kontrol ve veri başlıklarında toplanır; bir sözleşme bunların her birini kısıtlayabilir.

• Para. Yönetilen hizmetler aylık ücret, gelirden pay, sağlayıcının kendi talebiyle birlikte sunulan paket içinde bir marj ya da bunların karışımını isteyebilir. Burada okunan sağlayıcı sayfalarında fiyat yer almıyor; bu yüzden tam formülü ve gelirin her kesinti düşüldükten sonraki net tutar olarak raporlanmasını isteyin.
• Kontrol. Hangi alıcıların ekleneceğine, açık artırmanın nasıl ayarlanacağına ve hangi güncellemenin yayına gireceğine sağlayıcı karar verebilir. Ayarları geçersiz kılıp kılamayacağınızı ve değişikliklerin kaydının tutulup tutulmadığını sorun.
• Veri. Birçok rapor tek tek açık artırmaları değil, toplamları gösterir. Bir sağlayıcıyı denetlemek için her açık artırmanın kaydına ihtiyacınız var: kime soruldu, kim yanıt verdi, hangi fiyatla ve ne kadar hızlı. Bunu alıp alamayacağınızı, hangi biçimde ve ne kadar süreyle alacağınızı sorun.

Talep de satan bir sağlayıcının kendi alıcısını kayırması için bir nedeni vardır. Kendi alıcısına diğerleri gibi davranıldığını nasıl gösterdiğini sorun ve cevabı yazılı alın.

Prebid'i kendiniz işletmek neyi gerektirir?

Yazılımın lisans bedeli yok: Prebid.org “Prebid, kullanmak isteyen herkes için ücretsizdir” diyor. Bedelini personel zamanıyla ödersiniz:

• Güncellemeler. Prebid.org şöyle diyor: “En az altı ayda bir yükseltme yapmanızı öneriyoruz.” Sürümler “hata düzeltmeleri, performans iyileştirmeleri, yeni özellikler ve daha iyi mevzuat desteği” getirir; her alıcı, onunla konuşan küçük bir modül olan bir adaptör üzerinden bağlanır.
• Derleme ve test. Alıcı ve analitik modüllerini Prebid.js dosyanızda seçer, yeniden derler ve her sürümden önce gerçek sayfalarda, birkaç tarayıcıda test edersiniz.
• Raporlama. Prebid.org “birçok analitik adaptör eklentisi” listeliyor. Birini seçer, bağlar ve nelerin saklanacağına karar verirsiniz. Açık artırma düzeyindeki kayıtlar buradan gelir.
• Reklam sunucusu kurulumu. Satır öğeleri, yani reklam sunucusunun her fiyat düzeyi için tuttuğu kayıtlar ile fiyat kuralları kodun gönderdiğiyle eşleşmelidir; yoksa gelir sessizce sızar.
• Kullanıyorsanız sunucu taraflı barındırma. Prebid'in barındırma kılavuzu şöyle diyor: “Prebid Server, anahtar teslim bir çözüm değildir.” Şunu da ekliyor: “En az üç ayda bir güncelleme olup olmadığını kontrol etmeyi taahhüt etmeniz gerekir. Neredeyse her hafta yeni sürümler çıkıyor.” Prebid'in sunucuya genel bakışı da kurulumunun “Prebid.js kadar kolay olmadığı” uyarısını yapıyor.

Orta yol, sahibi olduğunuz hesaplar altında Prebid'i kurması ve bakımını yapması için bir firma tutmaktır. Kod da veri de sizde kalır.

Onay ve gizlilik kuralları nerede devreye girer?

Her teklif isteği bir kişiye dair bilgi taşıyabilir; bu nedenle gizlilik kurallarının geçerli olduğu yerlerde her yol ziyaretçinin tercihini kaydetmeli ve alıcılara iletmelidir.

AB'de onay kaydı genellikle IAB Europe'un Şeffaflık ve Onay Çerçevesi (TCF) dizesidir. Bunu, ziyaretçilere soran açılır pencere olan onay yönetim platformu (CMP) üretir. IAB Europe'un sayfası, TCF v2.3'ün Nisan 2025'te yayına girdiğini ve “TCF katılımcılarının TCF v2.3'ü benimsemek için 28 Şubat 2026'ya kadar süresi olduğunu” söylüyor. IAB Europe'un 16 Temmuz 2026 tarihli duyurusu, CMP'lere yeni TCF v2.4 bildirimlerini web'de uygulamaları için 23 Ekim 2026'ya kadar süre veriyor. Uygulamalar ve bağlı TV için tarih 23 Şubat 2027. AB Adalet Divanı'nın C-604/22 sayılı davada 7 Mart 2024 tarihli kararına ilişkin basın bildirisi, dizenin “tanımlanabilir bir kullanıcıya ilişkin bilgiler içerdiğini ve bu nedenle GDPR anlamında kişisel veri oluşturduğunu” söylüyor. Dize, bir IP adresi gibi bir tanımlayıcıyla ilişkilendirildiğinde bu bilginin kullanıcıyı belirlemeyi mümkün kılabileceğini de ekliyor. Günlüklerinizde bunu kişisel veri olarak ele alın. Google Ad Manager için Google'ın yardım sayfası şöyle diyor: “AEA ve Birleşik Krallık'taki kullanıcılara kişiselleştirilmiş reklam sunarken TCF ile entegre, sertifikalı bir CMP gereklidir.”

ABD'de kurallar eyaletten eyalete değişir. California Başsavcılığı'nın sayfası “GPC dahil olmak üzere, kişisel bilgilerinin satışını veya paylaşımını reddetme hakkını” listeliyor. GPC, Global Privacy Control'dür: bazı tarayıcılarda bulunan ya da bir tarayıcı eklentisiyle gelen, bir siteye kişinin verisini satmayı veya paylaşmayı bırakmasını söyleyen bir ayardır. Prebid'in onay sinyallerini CMP'den okuyup alıcılara ileten modülleri var; IAB'nin Global Privacy Platform'u için olan modül de bunlardan biri. Bunların sınırı, Prebid'in ifadesiyle şöyle: “Mevzuat gereksinimlerini karşılamak için oluşturulan Prebid işlevleri, her tarafın kendi yasal yükümlülüklerini belirleme ve geçerli tüm yasalara uyma sorumluluğunun yerini tutmaz.”

Yönetilen bir wrapper ile açık artırma verisinin veri sorumlusunun kim olduğunu ve veri işleme şartlarını kimin imzaladığını sorun.

Kimlik ve çerezler header bidding'i nasıl etkiler?

Alıcılar tanıdıkları bir ziyaretçi için daha fazla ödeyebilir. Prebid'in User ID modülü, sayfasında “header bidding'in değerini artırmanın önemli bir yolu” diye anılan, ortak takma adlı kimlikler kurar. Kimlik modüllerini siz seçersiniz; ziyaretçilere yapılacak bildirim konusunda hukuki danışmanlık alın.

Sunucu taraflı açık artırmalar bir adım ekler. Prebid Server kılavuzu “Birçok teklif veren, kendine özgü kullanıcı kimliklerini çerezler üzerinden takip eder” ve bu çerezlerin “Prebid Server alan adı altında birleştirilmesi gerekir” diyor. Buna çerez eşitleme denir ve yalnızca “gizlilik düzenlemeleri izin veriyorsa” çalışır. Eşitleme olmadığında alıcı ziyaretçiyi tanımayabilir.

Google, 22 Nisan 2025'te “Chrome'da kullanıcılara üçüncü taraf çerezleri konusunda seçenek sunan mevcut yaklaşımımızı koruyacağımızı ve üçüncü taraf çerezleri için yeni, bağımsız bir istem sunmayacağımızı” yazdı. 17 Ekim 2025'te Google, tarayıcı tabanlı iki reklam hedefleme aracı olan Topics ve Protected Audience'ın da aralarında bulunduğu “aşağıdaki Privacy Sandbox teknolojilerini kullanımdan kaldıracağını” söyledi. Çerez sayfaları hâlâ çerezlerin “tarayıcı tasarımı, Enterprise politikası ya da kullanıcı tercihiyle engellenebileceğini” belirtiyor. Chrome'un, kararlı sürümü 8 Eylül 2026 için planlanan 153 sürümüne ait sürüm notları hâlâ Chrome'un “üçüncü taraf çerezlerine yönelik mevcut yaklaşımın korunacağı” duyurusuna atıf yapıyor. Bu makale için bulunan hiçbir sonraki Google açıklaması bunu değiştirmiyor.

Dolayısıyla çerezler bazı ziyaretçilerde çalışır, bazılarında çalışmaz. Her seçeneğin çerezi olmayan ziyaretçilerde nasıl performans gösterdiğini sorun.

Seçenekleri kontrollü bir testle nasıl karşılaştırırsınız?

Vaat edilen artış, sağlayıcının umududur. Assertive Yield'in dizin sayfası, “mevcut para kazanma çözümlerini yüzde 20'den fazla aşan, ziyaretçi gelirinde dikkat çekici bir artış” gösterdiğini söylüyor. Bu, kendi iddiasıdır ve sizin sayfalarınız hakkında hiçbir şey söylemez.

• Trafiği mevcut kurulumunuzla yenisi arasında rastgele bölün. İkisini aynı sayfalarda, bütün haftalar boyunca aynı anda çalıştırın; trafik azsa daha uzun.
• Önce soruyu sabitleyin: her grup için bin sayfa görüntüleme başına gelir, her ücret düşüldükten sonra, yanında sayfa hızı ve çıkış oranıyla. Başlamadan önce süreye ve başarı çizgisine karar verin.
• Rakamları yalnızca sağlayıcının panosundan değil, kendi reklam sunucunuzdan ve kayıtlarınızdan alın.
• Zor durumları da dahil edin: yavaş bağlantılar, onayı reddeden ziyaretçiler, uygulamalar ve AB trafiği.

Kendi katmanınızı geliştirmek ne zaman haklı olur?

Nadiren, üstelik genellikle sıfırdan değil. Prebid.org, sitesindeki kodun ve belgelerin “Apache Lisansı altında yayımlandığını” söylüyor; dolayısıyla bir firma Prebid'in üzerine inşa edebilir. Şunlardan herhangi biri özel bir çalışmayı haklı çıkarabilir:

• Bir reklam ağı ya da SSP işletiyorsunuz ve açık artırmanın kendisi sizin ürününüz; taban fiyatlar, anlaşmalar ya da hangi alıcıların hangi alanı gördüğü konusunda kendi kurallarınız var.
• Sözleşmeler ya da veri kuralları, her açık artırma kaydının sizin sistemlerinizde kalmasını gerektiriyor.
• Envanteriniz alışılmadık: Prebid'in iyi kapsamadığı ekranlar ya da uygulama formatları gibi.
• Sizin hacminizde sağlayıcı ücretleri, kendi kodunuzun bakımını yapan bir ekipten daha pahalıya geliyor.

Bir sağlayıcının raporu sizinkiyle uyuşmuyor diye geliştirmeyin; yeni bir sistem bir rakam kümesi daha ekler. Sıradan görüntülü reklamları olan tek bir sitede bir ücretten kurtulmak için de geliştirmeyin.

Bir sağlayıcıdan ayrılırsanız elinizde ne kalır?

Prebid'in dizinindeki birkaç sağlayıcı Prebid'in kendisi üzerine kuruludur. Örneğin Magnite, hizmetinin “Prebid.js, Prebid Mobile ve Prebid Server üzerinden” çalıştığını söylüyor; yani Prebid tabanlı kurulumlar arasında geçmek, kapalı bir sistemden ayrılmaktan daha küçük bir iş olmalı. Şunları yazılı olarak isteyin:

• Her SSP ve borsa ile kendi hesaplarınız; böylece alıcı ilişkileri ve ödemeler sizde kalır
• Wrapper'ın bütün yapılandırması okunabilir biçimde: alıcılar, süre sınırları, taban fiyatlar ve sayfa başına ayarlar
• Sözleşme süresi boyunca, kontrolünüzdeki bir depolama alanına aktarılmış, açık artırma düzeyinde kayıtlar
• Onay kayıtları, kullanıcı kimliği ayarları ve reklam sunucusu satır öğeleri; bunlar zaten sizin hesabınızda olmalı
• Bir ihbar süresi ve bir devir planı; sağlayıcının betiğini sayfalarınızdan kimin kaldıracağı da dahil

Bunu kuran bir firma size depoyu, derleme adımlarını ve test sayfalarını bırakmalıdır.

Bir sağlayıcıya ya da bunu geliştirecek bir firmaya ne sormalısınız?

• Tam olarak ne ücret alıyorsunuz ve bize raporladığınız gelir rakamından önce neler düşülüyor?
• Siz de talep satıyor musunuz ve bunun hangi teklifin kazanacağını etkilemesini nasıl önlüyorsunuz?
• Açık kaynaklı Prebid üzerine mi kurulu ve bugün hangi sürümdeyiz? Ne sıklıkla güncelliyorsunuz?
• Açık artırma düzeyindeki kayıtları dışa aktarabilir miyiz; hangi biçimde, hangi maliyetle ve ne kadar süre saklanıyor?
• AB ve ABD eyaletleri için hangi onay platformunu ve sinyalleri destekliyorsunuz?
• Çerezi olmayan bir ziyaretçide ve bir mobil uygulamada nasıl davranıyor?
• Trafiğimizde, rakamları kendi reklam sunucumuzdan alarak bir bölünmüş test yapacak mısınız?
• Ayrılırsak neyi elimizde tutarız, siz neyi teslim edersiniz?

amBrain nerede devreye girer?

Bu blogu amBrain yayımlıyor. Kendi sözleriyle: “amBrain, yayıncılar için arz tarafı platformları (SSP) geliştirir.” İkinci bir satır reklam olay verisiyle ilgili: “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ı.”

amBrain 2019'dan bu yana yazılım geliştiriyor. Müşterileriyle nasıl çalıştığı konusunda şöyle diyor: “Üç format: 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.” İmzalamadan önce bu bileşenlerin adlarıyla listesini isteyin.

Bu makale bir vaka çalışması değildir ve hiçbir müşteri işini anlatmaz. Yukarıdaki satırlar hiçbir müşterinin adını vermez ve buradaki hiçbir şey amBrain'in herhangi bir şirket için bir header bidding ürünü geliştirdiğini söylemez. Makale amBrain fiyatı ya da takvimi vermez ve andığı hiçbir sağlayıcıyla ilişki öne sürmez. Her dış kaynak kendi sayfasından alıntılanmıştır.

Bu da hukuki tavsiye değildir. İmzalamadan önce satıcı sözleşmelerini, veri işleme şartlarını ve onay kurulumunuzu bir avukata okutun. amBrain kısa listenizdeyse, ona da diğer firmalara sorduğunuz soruları sorun.