Header Bidding Nedir? Prebid ve Açık Artırma Temelleri

Bir sayfadaki her reklam gösterimi aslında küçük bir satıştır: bir ziyaretçi sayfaya gelir, boş bir reklam alanı vardır ve birileri bu alanı almak için fiyat verir. Yayıncı açısından asıl soru, bu satışta kimin, hangi sırayla ve hangi kurallarla teklif verebildiğidir. Header bidding ve Prebid, bu sorunun modern yanıtlarından biridir. Kavramlar ilk bakışta kısaltma yığını gibi görünür: SSP, DSP, ad exchange, adapter, floor, timeout. Oysa arkadaki fikir basittir ve birkaç ilkeyle kavranabilir.

Bu rehber site sahibi, yayıncı ve reklam operasyonu çalışanı için yazıldı. Önce açık artırmanın temel kavramlarını ve eski waterfall düzenini anlatır, ardından header bidding'in akışını, Prebid'in bileşenlerini, zaman aşımı ve fiyat tabanı gibi ayarların mantığını ele alır. Sonra istemci ve sunucu tarafı seçimini, sayfa hızı ile CLS maliyetini, ads.txt ilişkisini ve ölçüm düzenini işler. Teknik ayrıntılar Prebid.org ve web.dev belgelerine dayanır; belgede görmediğimiz sürüm numarası, ayar değeri ya da performans rakamı vermiyoruz. Hiçbir bölüm belirli bir gelir artışı, gecikme süresi ya da ideal teklif veren sayısı vaat etmez. Örnekler kurgusaldır ve rakam içermez.

Açık Artırmanın Yayıncı İçin Anlamı: Temel Kavramlar

Programatik reklamda alım satım, insanların telefonla pazarlık yaptığı bir süreç değil, milisaniyeler içinde çalışan otomatik bir açık artırmadır. Bu otomasyonun içindeki rolleri tanımadan Prebid'in neyi çözdüğünü anlamak zordur. Aşağıdaki tanımlar genel sektör bilgisidir; her platformun terimleri küçük farklarla kullanabileceğini akılda tutun.

Taraflar ve roller

• Yayıncı: Reklam alanına sahip olan site ya da uygulama. Hangi alanın, hangi koşullarla satılacağına yayıncı karar verir.
• Reklam sunucusu (ad server): Yayıncının reklam alanlarını, kampanyalarını ve hangi reklamın hangi alanda gösterileceğini yöneten sistem. Google Ad Manager bu sınıftaki yaygın araçlardan biridir.
• SSP (arz tarafı platformu): Yayıncının envanterini alıcılara açan ve teklif toplayan platform.
• DSP (talep tarafı platformu): Reklamverenin adına hangi gösterime ne kadar teklif verileceğine karar veren platform.
• Ad exchange: SSP ve DSP'lerin teklif ve gösterim değiş tokuşu yaptığı pazar yeri.
• Teklif veren (bidder): Prebid bağlamında açık artırmaya teklif gönderen talep kaynağı; bir SSP, DSP ya da exchange olabilir.

Bu rollerin hepsini aynı yayıncı tek başına görmek zorunda değildir. Küçük bir site için tipik kurulum, bir reklam sunucusu ve birkaç talep kaynağından ibarettir. Büyüdükçe talep kaynakları artar, kuralların yönetimi önem kazanır ve ölçüm ayrıntılaşır.

Gösterim, fiyat ve kazanan

Her gösterim fırsatında temel akış şöyle işler: sayfa bir reklam alanı için istek gönderir, talep kaynakları teklif verir, en yüksek geçerli teklif kazanır ve kazanan reklam sayfada gösterilir. Teklifin birimi genellikle bin gösterim başına maliyettir (CPM). Hangi teklifin "geçerli" sayıldığını belirleyen şey yayıncının koyduğu kurallardır: alt fiyat sınırı, izin verilen reklam boyutları, engellenen reklamverenler ve zaman sınırı. Bu kuralların büyük bölümü bu yazının ilerleyen bölümlerinde ele alınıyor.

Doğrudan satış ile programatik satış arasındaki ayrım için direkt reklam ile programatik reklam farkı yazısına bakabilirsiniz; orada satış modellerinin karşılaştırması yapılıyor. Burada odak, programatik tarafın içindeki teknik düzen: tekliflerin nasıl toplandığı ve kimin son kararı verdiği.

Neden "açık artırma" gerçek bir açık artırmadır?

Açık artırma kelimesi mecaz değildir. Bir gösterim için birden fazla alıcı eş zamanlı olarak fiyat verir ve kural koyucu olarak yayıncı yalnızca belirli koşulları sağlayan teklifleri kabul eder. Rekabet ne kadar gerçekse, fiyat keşfi o kadar sağlıklı olur; ancak her ek talep kaynağı hem teknik yük hem de yönetim maliyeti getirir. Header bidding konusundaki bütün tasarım kararları aslında bu iki ucun dengelenmesidir: daha fazla rekabet ile daha az gecikme.

Waterfall Düzeni ve Neden Değişti

Header bidding'i anlamak için önce onun yerine geçmeye çalıştığı düzene bakmak gerekir. Aşağıda anlatılan waterfall işleyişi genel sektör bilgisidir ve her uygulamada ayrıntıları farklılaşabilir.

Sıralı çağrı mantığı

Waterfall düzeninde yayıncı, talep kaynaklarını bir öncelik sırasına dizer. Reklam sunucusu önce ilk kaynağa sorar. Kaynak belirlenen fiyat düzeyinin üstünde bir reklam sunamazsa ya da boş dönerse ikinciye geçilir, sonra üçüncüye ve böyle sürer. Sıra çoğunlukla geçmiş ortalama gelire bakılarak elle belirlenir. Sistem basittir ve uzun süre iş görmüştür.

Sıralamanın doğurduğu sorunlar

• Rekabetin eksik kalması: Üst sıradaki kaynak belirlenen eşiği geçince alt sıradakiler hiç teklif veremez. Daha yüksek verecek bir alıcı varsa bile sıraya hiç ulaşamayabilir.
• Elle bakım yükü: Sıra ve fiyat düzeyleri güncel kalmazsa gelir kaybı olur; ayarları sürekli gözden geçirmek operasyon emeği ister.
• Sıralı gecikme: Her adım bir bekleme anlamına gelir; arka arkaya gelen boş yanıtlar sayfada reklamın geç görünmesine yol açabilir.
• Veri görünürlüğünün zayıflığı: Hangi talep kaynağının gerçekte ne kadar teklif verdiğini görmek zorlaşır.

Bu sınırlar, tüm talep kaynaklarının aynı anda ve eşit koşullarda teklif verdiği bir düzen fikrini doğurdu. Header bidding de bu fikrin pratik uygulamasıdır. Ancak yeni düzen sorunsuz değildir: eşzamanlı çağrılar tarayıcıda iş yükü yaratır ve sayfa hızıyla ilgili yeni bir maliyet doğurur. Bu maliyeti ileride ayrı bir bölümde ele alıyoruz.

Header Bidding Akışı Adım Adım

Prebid belgeleri Prebid'i, ücretsiz ve açık kaynaklı bir header bidding çözümü olarak tanıtır. Aynı sayfa iki çalışma biçimini ayırt eder: header bidding kitaplığı olarak Prebid, reklam sunucusu çağrılmadan önce teklifleri toplar ve son kararı reklam sunucusu verir. Tam açık artırma kitaplığı olarak ise reklam sunucusu da dâhil bütün talep kaynakları Prebid'e teklif verir ve kazananı Prebid seçer. Bu ikilemi sonraki bölümlerde ayrıntılandırıyoruz; kaynak olarak Prebid genel bakış belgesi (yeni sekmede açılır) esas alınmıştır.

Tipik bir sayfa yüklemesinde sıra

1. Ziyaretçi sayfayı açar; yayıncı kodu hangi reklam alanlarının bulunduğunu ve her biri için hangi reklam boyutlarının kabul edildiğini tanımlar.
2. Prebid, seçilen talep kaynaklarına teklif isteklerini aynı anda gönderir; Prebid belgelerinin ifadesiyle istekler sırayla değil eş zamanlı gider.
3. Her talep kaynağı belirlenen süre içinde yanıt verir. Süre sınırı uygulanır; süresinde yanıt vermeyen talep kaynağı açık artırmaya dâhil edilmez.
4. Yayıncı kuralları (alt fiyat sınırı gibi) geçerli tekliflerin ayıklanmasında uygulanır.
5. Sonuç, kullanılan moda göre ya reklam sunucusuna anahtar-değer olarak iletilir ya da Prebid kazananı doğrudan seçer.
6. Seçilen reklam sayfada gösterilir ve gösterim ile gelir kayıtları oluşur.

Eş zamanlılığın getirdiği fark

Waterfall'da kaynaklar tek tek sorulurken burada hepsi aynı anda sorulur. Bu, rekabeti artırır; çünkü hiçbir alıcı sıranın sonunda kalmaz. Aynı zamanda sayfa için ek bir iş yükü de yaratır: her kaynak ek bir ağ isteği ve işlem demektir. Prebid belgeleri bu nedenle yayıncılara teklif veren sayısı, zaman aşımı ve istemci ile sunucu dağılımını A/B testleriyle sınamalarını önerir. Kesin bir sayı önermiyoruz: doğru sayı, sayfanızın yapısına, ziyaretçi bağlantılarına ve talep kaynaklarınızın hızına göre değişir.

Kurgusal örnek: Bir tarif sitesinin sayfa akışı

Kurgusal örnek: bir tarif sitesinde her tarif sayfasında iki reklam alanı bulunuyor. Site üç talep kaynağını Prebid'e bağlıyor ve her sayfa açıldığında üçüne aynı anda istek gönderiliyor. Bir kaynak yavaş yanıt verirse belirlenen süre dolunca açık artırmadan çıkarılıyor ve diğer iki kaynağın teklifleriyle devam ediliyor. Sitenin ekibi sonradan hangi kaynağın sık sık süreyi aştığına bakıyor ve onu daha az kritik bir alana taşımayı değerlendiriyor. Örnekte gerçek bir şirket ya da ölçüm yok; yalnızca karar mantığı gösterilmek isteniyor.

Prebid Ailesi: Prebid.js, Prebid Server ve Adapter

Prebid tek bir dosya değildir; birbirini tamamlayan bileşenlerden oluşan bir ailedir. Prebid genel bakış sayfası bu bileşenleri şöyle sıralar: tarayıcıda çalışan Prebid.js, sunucu tarafı seçenek olan Prebid Server ve mobil uygulamalar için Prebid Mobile. Bunların yanında talep kaynaklarını Prebid'e bağlayan adapter'lar ve analitik, kimlik, fiyat tabanı gibi işleri üstlenen modüller vardır.

Prebid.js

Prebid.js, tarayıcıda çalışan bir JavaScript kitaplığıdır ve paketin çekirdek ürünüdür; belgeye göre görüntülü, video ve yerel reklam biçimlerini destekler. Yayıncı yalnızca ihtiyaç duyduğu adapter ve modülleri içeren bir paket oluşturur. Bu yaklaşım, gereksiz kodu dışarıda tutmak ve sayfa yükünü sınırlamak için önemlidir; çünkü her adapter ek kod demektir.

Adapter nedir?

Adapter, Prebid ile bir talep kaynağı arasındaki çeviri katmanıdır. Prebid belgeleri, bid adapter'larının Prebid'i SSP, DSP ve exchange gibi teklif verenlere bağladığını anlatır. Yayıncı bir talep kaynağını eklemek istediğinde ilgili adapter'ı pakete katar, kaynağın istediği parametreleri (örneğin yayıncıya ait kimlik ya da yerleşim bilgisi) reklam birimine tanımlar. Parametrelerin adı ve biçimi her adapter'a göre değişir; ilgili belge sayfasından kontrol edilmelidir.

Prebid Mobile ve diğer modüller

Prebid Mobile, iOS ve Android uygulamalarında header bidding'i mümkün kılan SDK'lardır ve Prebid Server ile çalışır. Modüller arasında analitik, kimlik ve fiyat tabanı gibi alanlar bulunur. Her modül paketi büyüttüğü için yalnızca gerçekten kullanılacak olanlar eklenmelidir. Bu ilke aşağıdaki sayfa hızı bölümünde yeniden karşımıza çıkacak.

Tablodaki özet Prebid genel bakış belgesinden derlenmiştir. Ayrıntılı kurulum için Prebid.org dokümantasyonu esas alınmalı; sürümler ve modül adları hızla değiştiği için burada sürüm numarası vermiyoruz.

Zaman Aşımı, Fiyat Tabanı ve Fiyat Kovaları

Açık artırmanın kalitesini belirleyen birkaç temel ayar vardır. Bu bölümde yalnızca kavramları ve Prebid belgelerinde adı geçen ayarları ele alıyoruz; önerilen değer vermiyoruz çünkü doğru değer sitenize göre değişir.

Zaman aşımı: ne kadar beklenir?

Teklif toplama bir bekleme süresiyle sınırlanır. Prebid.js ayar sayfası genel bir bidder zaman aşımı ayarını (bidderTimeout) tanımlar ve bir uyarı ekler: zaman aşımı beklenenden geç tetiklenebilir, dolayısıyla bazı teklifler açık artırmaya geç katılabilir. Bu ayrıntı pratikte önemlidir: ayarladığınız süre, sayfada gerçekten yaşanan sürenin kesin bir üst sınırı değil, hedefidir. Kısa süre gecikmeyi azaltır ama yavaş yanıt veren alıcıları dışarıda bırakır; uzun süre rekabeti artırabilir ama reklamın geç görünmesine neden olur. Dengeyi yayıncının kendi verisi belirler.

Aynı ayar sayfası zaman aşımıyla ilişkili başka ayarlardan da söz eder; örneğin tekliflerin geçerlilik süresinden kesilen bir tampon (ttlBuffer) ve açık artırma zaman aşımına uğradığında Prebid'in istekleri sonlandırmasını engelleyen bir seçenek (disableAjaxTimeout). Bu ayarların ne zaman değiştirilmesi gerektiği genel kural değil, test konusudur. Prebid.js ayar belgesi (yeni sekmede açılır) bütün seçeneklerin güncel tanımını verir.

Fiyat tabanı: en düşük kabul edilen teklif

Fiyat tabanı (floor), bir teklifin kabul edilebilmesi için geçmesi gereken alt sınırdır. Prebid Fiyat Tabanı modülü belgesi bir floor'u her Prebid açık artırması için bir teklifin karşılaması gereken en düşük CPM fiyatı olarak tanımlar. Modül, yayıncının kendi fiyat tabanlarını belirlemesine ya da bir floor sağlayıcısıyla çalışmasına imkân tanıyan açık kaynaklı bir çerçevedir.

• Kurallar üç yerden gelebilir: uzaktan çekilen dinamik veri, ayar paketi (setConfig) ya da reklam birimi. Her açık artırmada yalnızca tek bir konumdaki kurallar kullanılır ve öncelik sırası dinamik, setConfig, reklam birimi şeklindedir.
• Kurallar reklam birimi, GPT slot adı, medya türü, reklam boyutu ve alan adı gibi boyutlara göre eşleşebilir; özel boyutlar da desteklenir.
• enforceJS ayarı, eşleşen fiyat tabanını aşmayan tekliflerin bastırılıp bastırılmayacağını belirler.
• floorMin en düşük tabanı belirler; modül floorMin ile eşleşen kural değerinden büyük olanı kullanır.
• skipRate, fiyat tabanı mantığını rastgele atlayarak tabanlı ve tabansız açık artırmaların karşılaştırılmasına imkân verir.

Fiyat tabanı konusunda belge, uzak veri kullanıldığında bir bekleme ayarı (auctionDelay) olduğunu ve uzak istek başarısız olursa ya da geç dönerse paket düzeyindeki verinin yedek olarak kullanılabileceğini anlatır. Ayrıntılar için Fiyat Tabanı modülü belgesi (yeni sekmede açılır) okunmalıdır. Yüksek bir taban reklamın hiç dolmamasına, düşük bir taban değerli alanın ucuza satılmasına yol açabilir; hangi düzeyin doğru olduğunu yalnızca kendi verinizle sınayabilirsiniz. Doluluk oranı ve eCPM gibi metriklerin nasıl okunacağı için RPM, eCPM ve doluluk oranı yazısı yardımcı olur.

Fiyat kovaları ve hb_pb

Reklam sunucusuyla çalışırken teklif fiyatları anahtar-değer olarak iletilir. Prebid.js ayar belgesi, fiyat kovası ayarının (priceGranularity) hb_pb anahtar kelimesi için kullanılan fiyat kovası inceliğini tanımladığını yazar. Belgede low, medium, high, auto, dense gibi standart değerlerin yanı sıra özel bir yapılandırma nesnesi de bulunur. Kovalar inceldikçe fiyat çözünürlüğü artar, ama reklam sunucusunda yönetilecek kalem sayısı da artabilir. Bu nedenle ince kova her zaman daha iyi değildir; operasyon yükü ile fiyat hassasiyeti arasında bir denge vardır.

Reklam Sunucusunun Rolü: Son Kararı Kim Verir?

Header bidding'de en çok karıştırılan nokta, açık artırmayı kimin kazandığıdır. Prebid belgeleri iki ayrı modu net biçimde anlatır; hangi modun seçildiği gelir operasyonunu ve ekip işbölümünü değiştirir. Aşağıdaki anlatım Prebid reklam operasyonu başlangıç belgesine (yeni sekmede açılır) dayanır.

Header bidding modu: karar reklam sunucusunda

Bu modda Prebid, reklam sunucusu çağrılmadan önce teklifleri toplar ve son kararı reklam sunucusu verir. Belgeye göre reklam sunucusu hedefleme bilgisini okur ve eşleşen kalemleri arar; reklam operasyonu ekibi bu kalemlerin var olduğundan ve doğru yapılandırıldığından emin olmalıdır. Pratik anlamı şudur: Prebid'in teklifi, reklam sunucusundaki diğer kampanyalarla rekabet eder ve hangisinin kazanacağını reklam sunucusunun kuralları belirler. Doğrudan satılmış kampanyalar, anlaşmalı teslimat hedefleri ve diğer talep kaynakları da aynı karara girer.

Tam açık artırma modu: karar Prebid'de

Bu modda Prebid karar katmanıdır ve reklam sunucusu, varsa, Prebid açık artırmasına başka bir talep kaynağı gibi katılır. Belge, bu modda Prebid teklifleri için fiyat kovası kalemlerine gerek olmadığını belirtir; bunun yerine reklam sunucusunun kendi kampanyaları (rezervasyon önceliği, sponsorluk, ev kampanyaları) yapılandırılır. Mühendislik tarafında bu davranış reklam sunucusu adapter'ı için bir ayarla açılır. İki mod arasındaki seçim, ekibin altyapısına, mevcut kampanya düzenine ve raporlama ihtiyacına bağlıdır.

Hangi modu seçmeli?

Seçim bir doğru-yanlış sorusu değil, iş modeli sorusudur. Reklam sunucunuzda yoğun bir doğrudan satış operasyonu varsa karar mekanizmasını orada bırakmak doğal olabilir. Tamamen programatik çalışan ve karar mantığını tek yerde toplamak isteyen bir yayıncı ise tam açık artırma modunu değerlendirebilir. Her iki durumda da geçişi küçük bir trafik dilimiyle sınamak ve sonuçları aynı metriklerle karşılaştırmak mantıklıdır.

Google Ad Manager gibi bir reklam sunucusunun kendi içinde sunduğu açık artırma ürünleri ve kalem kuralları farklı bir konudur; bunların güncel koşulları için doğrudan Google Ad Manager Yardım belgelerine bakın, çünkü ürün adları ve ayarlar sık değişir.

İstemci Tarafı mı, Sunucu Tarafı mı?

Prebid iki yerde çalışabilir: ziyaretçinin tarayıcısında (istemci tarafı) ve bir sunucuda (sunucu tarafı). Prebid genel bakış sayfası Prebid Server'ı, açık artırmaların bir kısmını ya da tamamını tarayıcıdan çıkaran, böylece istemci yükünü ve gecikmeyi azaltmayı hedefleyen sunucu tarafı seçenek olarak anlatır. Aynı sayfa, HTML başlığının bulunmadığı ortamlarda (mobil uygulamalar ve AMP sayfaları gibi) sunucu tarafının gerekli olduğunu da belirtir.

Sunucu tarafının sağladıkları

Prebid Server genel bakış belgesi, Prebid Server'ı sunucudan sunucuya header bidding için açık kaynaklı bir çözüm (yeni sekmede açılır) olarak tanıtır. Gelen reklam isteklerini denetler ve zenginleştirir, sunucu tarafı adapter'lara gönderir ve yanıtı oluşturur. Belge ayrıca mobil uygulamalar, AMP, Prebid.js ile sunucu tarafı web, bağlı TV, dijital açık hava ve ses gibi kullanım alanlarını sayar ve bidder'lara istek göndermeden önce gizlilik düzenlemelerinin uygulanabildiğini yazar.

Sunucu tarafının bedeli

Aynı belge dürüst bir uyarı da içerir: Prebid Server bir sunucudur, çalışacağı yer ölçeklenebilir, dağıtık ve hızlı olmalıdır; kurulumu Prebid.js kadar kolay değildir; topluluk tarafından sağlanan yapılandırma araçları yoktur. Yani sunucu tarafı, tarayıcı yükünü azaltsa da operasyon yükünü artırabilir. Birçok yayıncı bu nedenle Prebid.org üyelerinden birinin barındırdığı bir hizmeti tercih eder; belge bu tür hizmetlerin var olduğunu söyler. Bir hizmet seçerken sözleşmeyi, veri akışını ve raporlamayı kendi şartlarınıza göre değerlendirin; bu rehber belirli bir sağlayıcıyı önermez.

Karma yaklaşım

İstemci ve sunucu tarafı birbirini dışlamaz. Bazı talep kaynakları tarayıcıda, bazıları sunucuda çalıştırılabilir. Bir yayıncı için mantıklı başlangıç, mevcut kurulumu ölçmek, yavaş ya da ağır kaynakları belirlemek ve yalnızca onları sunucuya taşımayı denemektir. Taşıdıktan sonra gelir ve gecikme birlikte izlenmelidir; çünkü sunucu tarafında kullanıcı eşleştirme gibi konular farklı davranabilir. Belge bu konuyu genel bakışta ayrıntılandırmaz ve ayrı bir çerez eşleştirme sayfasına yönlendirir; bu nedenle burada iddia ileri sürmüyoruz. Ayrıntıları ilgili Prebid belgesinden kontrol edin.

Karma kurulumda sorumlulukların net olması gerekir. Hangi talep kaynağının nerede çalıştığını, hangi ayarın hangi katmanda tanımlandığını ve hangi raporun hangi kaynaktan geldiğini bir tabloda tutun. Kayıt yoksa, bir gelir düşüşü yaşandığında nedenin tarayıcı tarafı mı, sunucu tarafı mı olduğunu ayırmak güçleşir.

Sayfa Hızı, CLS ve Kullanıcı Deneyimi Maliyeti

Header bidding gelir fırsatı yaratır ama sayfaya yük bindirir. Bu yükü görmezden gelen bir kurulum, ziyaretçi deneyimini bozarak uzun vadede reklam gelirini de olumsuz etkileyebilir. Reklamların Core Web Vitals ile dengesi konusunu ayrı bir yazıda ele aldık: reklam ve Core Web Vitals dengesi. Burada header bidding'e özgü noktaları sıralıyoruz.

Ek betik ve ağ yükü

Her adapter, pakete ek kod ekler; her talep kaynağı ek ağ isteği demektir. Bu etkinin büyüklüğü sayfadan sayfaya değişir ve genel bir rakamla anlatılamaz. Yayıncı için doğru yöntem, adapter eklemeden önce ve sonra aynı sayfayı aynı koşullarda ölçmektir. Kullanılmayan adapter ve modülleri paketten çıkarmak, en basit kazançlardan biridir.

Layout shift: reklam kutusu için yer ayırmak

Reklamlar çoğunlukla sayfa yüklendikten sonra gelir. Teklif toplama bitene kadar kutu boşsa ve yer ayrılmamışsa, reklam geldiğinde içerik aşağı kayar. web.dev düzen kayması rehberi, ziyaretlerin en az yüzde 75'inde CLS değerinin 0,1 ya da daha düşük olmasını hedef gösterir ve 0,25'in üzerini zayıf sayar. CLS optimizasyon rehberi (yeni sekmede açılır) reklamlar ve gömülü içerikler için şunları önerir:

• min-height kuralıyla ya da duyarlı reklamlar için aspect-ratio ile yer ayırmak.
• Reklam boyutları değişiyorsa, olası en küçük boyutu ayırmak; böylece sonradan büyüme daha az kayma yaratır.
• Reklam yüklenmediğinde yer tutucuyu korumak; ayrılan alanı çökertmek de kayma yaratabilir.
• Ekran boyutuna göre yer tutucu boyutlarını medya sorgularıyla ayarlamak.
• Geç yüklenen içeriği görünür alanın daha aşağısına yerleştirmek.

Bu öneriler header bidding için çok önemlidir; çünkü açık artırmada hangi boyutta reklamın geleceği, teklif toplama bitene kadar bilinmeyebilir. Alan için olası en küçük boyutu rezerve etmek, kaymayı sınırlamanın mantıklı yoludur. Kayma ayrıca sayfanın yaşam süresi boyunca ölçülür; rehber, yükleme sonrası kaymaların da sayılabileceğini ve alan verisinin de izlenmesi gerektiğini söyler. Yani yalnızca laboratuvar testine güvenmeyin.

Yer ayırmanın gelir maliyeti

Yer ayırmanın bir bedeli olabilir: boş kalan alan, ziyaretçi için dolu bir alandan daha az değerlidir ve düzen tasarımını sınırlar. Yayıncı bu dengeyi bilinçli kurmalıdır. Örneğin içerik akışının ortasındaki bir alan için daha esnek, sayfa üstündeki bir alan için daha sıkı kurallar seçilebilir. Hangi alanın ne kadar gelir getirdiğini kendi verinizden görmeden bu kararı tahminle vermeyin.

Gecikmenin azaltılması için sıralı düşünce

1. Önce ölçün: sayfa hızı ve CLS değerlerini mevcut kurulumla kaydedin.
2. Gereksiz adapter ve modülleri çıkarın.
3. Reklam alanları için yer ayırın.
4. Zaman aşımı ve teklif veren sayısını tek tek değiştirip etkisini izleyin.
5. Gerekirse yavaş kaynakları sunucu tarafına taşıyın.

Bu liste bir öncelik önerisidir; hiçbir adım garantili bir iyileşme sunmaz. Her değişiklikten sonra aynı ölçümü tekrarlayın.

ads.txt ve Satıcı Şeffaflığı

Programatik reklamda alıcılar, bir envanteri kimin satmaya yetkili olduğunu bilmek ister. ads.txt bu amaçla yaratılmış basit bir mekanizmadır. IAB Tech Lab sayfası, ads.txt'nin yetkili dijital satıcılar anlamına geldiğini ve yayıncıların envanterini satmaya yetkili şirketleri herkese açık biçimde listelemesi için basit, esnek ve güvenli bir yöntem olduğunu yazar. Amaç, programatik reklam ekosisteminde şeffaflığı artırmaktır; herkese açık bir yetkili satıcı kaydı, kötü niyetli kişilerin sahte envanter satarak kazanç sağlamasını zorlaştırır.

Header bidding ile ilişkisi

Header bidding'de birden fazla talep kaynağı envanterinize erişir. Her birinin sizi temsil etme yetkisi olmalıdır ve bu yetki ads.txt aracılığıyla alıcılara görünür kılınır. Yeni bir talep kaynağı eklediğinizde onun ads.txt kaydını da güncellemek, işlemin parçasıdır. Kayıt eksikse alıcı o satıcıdan gelen teklifi tanıyamayabilir. Bu bir işleyiş bilgisidir; hangi alıcının dosyayı zorunlu tuttuğu kendi sözleşmenize bağlıdır.

Kurulum adımları, dosyanın nerede durması gerektiği ve satır yapısı için ads.txt kurulum rehberi yazısına bakın. IAB Tech Lab sayfasının sürüm geçmişi OWNERDOMAIN, MANAGERDOMAIN, INVENTORYDOMAIN, SUBDOMAIN ve CONTACT gibi değişkenleri de sayar; hangisinin sizin için gerekli olduğunu IAB Tech Lab ads.txt sayfası (yeni sekmede açılır) ve güncel şartname üzerinden kontrol edin.

Şeffaflığın pratik kontrol listesi

• Her aktif talep kaynağının ads.txt'de karşılığı var mı?
• Artık kullanılmayan kaynakların kayıtları temizlendi mi?
• Satıcı kimlikleri kaynaktan alınan değerle birebir uyuşuyor mu?
• Dosya herkese açık biçimde erişilebilir ve güncel mi?

Kayıtların düzenli gözden geçirilmesi, bir talep kaynağını eklemek kadar önemlidir. Eski kayıtlar karışıklığa yol açar.

Ölçüm ve Test Düzeni

Header bidding kurulumunu yönetmenin en güvenilir yolu, değişiklikleri küçük adımlarla yapıp her adımı ölçmektir. Prebid belgelerinin kendisi de teklif veren sayısı, zaman aşımı ve istemci/sunucu dağılımının A/B testleriyle sınanmasını önerir. Kurulumu bu önerinin üzerine kurabilirsiniz.

Hangi metriklere bakılır?

• Gelir metrikleri: sayfa başına gelir (RPM), eCPM ve doluluk oranı; bu metriklerin tanımları yukarıda anılan gelir metrikleri yazısında bulunur.
• Teklif davranışı: hangi talep kaynağı ne sıklıkla teklif veriyor, ne sıklıkla süreyi aşıyor, ne sıklıkla kazanıyor.
• Sayfa deneyimi: CLS ve diğer Core Web Vitals değerleri, mümkünse alan verisinden.
• Teknik sağlık: boş kalan reklam alanları, hata ve yanıt vermeyen kaynaklar.

A/B test mantığı

Bir ayarı değiştirirken trafiği ikiye bölmek, değişikliğin etkisini yalnızca zamana bağlı dalgalanmalardan ayırmanın yoludur. Fiyat Tabanı modülü bu yaklaşımı destekleyen skipRate ve model etiketleri (modelVersion, modelTimestamp) gibi seçenekler sunar. Genel kural olarak aynı anda yalnızca tek bir değişkeni değiştirin; aksi halde sonucu neye bağlayacağınızı bilemezsiniz.

Test süresi, trafik hacmi ve mevsim etkisine göre değişir. Hafta içi ile hafta sonu davranışının farklı olduğu bir sitede testin birkaç günle sınırlanması yanıltıcı olabilir. Kesin bir süre önermiyoruz; ancak testi, karşılaştırdığınız gruplar benzer koşullardan geçecek kadar uzun tutun.

Kurgusal örnek: Zaman aşımı denemesi

Kurgusal örnek: bir haber sitesi, mevcut zaman aşımını kısaltmayı düşünüyor. Trafiğin bir kısmında yeni değeri deniyor, kalan kısımda eskisini koruyor. İki grubu aynı hafta içinde karşılaştırıyor: reklam alanı doluluğu, sayfa başına gelir ve CLS. Sonuçlar karışıksa, yani gecikme azalırken gelir de düşüyorsa, ekip kararı yalnızca tek bir metrikle vermiyor; hangi alanın daha değerli olduğuna bakıyor. Burada hiçbir rakam yok ve hiçbir sonuç gerçek bir siteye ait değildir.

Kayıt tutma

Her değişiklik için tarih, değişen ayar, beklenen etki ve gözlenen sonuç yazılmalıdır. Bu kayıt, bir ay sonra gelirde dalgalanma olduğunda en değerli kaynağınız olur. Ekip değişse bile, yapılan denemeler kaybolmaz.

Sık Yapılan Hatalar

• Çok sayıda talep kaynağını ölçmeden eklemek: Her kaynak yük getirir. Eklemeden önce ve sonra aynı sayfayı ölçün.
• Zaman aşımını "kesin süre" sanmak: Prebid.js belgesi zaman aşımının beklenenden geç tetiklenebileceğini yazar.
• Reklam alanı için yer ayırmamak: Geç gelen reklam içeriği kaydırır ve CLS'yi bozar.
• Fiyat tabanını tek seferde yükseltmek: Doluluk düşebilir; skipRate gibi araçlarla karşılaştırmalı test yapın.
• İki modu karıştırmak: Karar reklam sunucusunda mı Prebid'de mi olduğu net değilse raporlar çelişir.
• ads.txt'yi güncellememek: Yeni bir talep kaynağı eklenince kaydı da eklenmelidir.
• Kullanılmayan adapter'ları bırakmak: Gereksiz kod, sayfa yükünü artırır.
• Tek bir ölçüme bakmak: Yalnızca gelire ya da yalnızca hıza bakmak yanıltıcıdır.
• Sürüm ve ayar adlarını eski bir kaynaktan kopyalamak: Prebid hızla değişir; güncel dokümantasyonu kontrol edin.

Sıkça Sorulan Sorular

Header bidding nedir, kısaca?

Header bidding, yayıncının reklam alanı için birden fazla talep kaynağını aynı anda teklife davet ettiği ve teklifleri reklam sunucusuna gitmeden önce topladığı bir açık artırma yöntemidir. Prebid belgeleri bu modeli, tekliflerin reklam sunucusu çağrılmadan önce toplanması ve son kararın reklam sunucusunda verilmesi biçiminde anlatır. Eski sıralı waterfall düzeninde ise talep kaynakları teker teker denenirdi.

Prebid ile header bidding aynı şey mi?

Değil. Header bidding bir yöntemdir, Prebid ise bu yöntemi uygulamak için kullanılan açık kaynaklı bir çözümdür. Prebid.org belgeleri Prebid'i ücretsiz ve açık kaynaklı bir header bidding çözümü olarak tanıtır. Tarayıcıda çalışan Prebid.js, sunucu tarafı seçenek olan Prebid Server ve mobil uygulamalar için Prebid Mobile bu ailenin parçalarıdır.

İstemci tarafı mı, sunucu tarafı mı daha iyi?

Tek bir doğru yanıt yoktur. Sunucu tarafı seçenek tarayıcı yükünü ve gecikmeyi azaltmayı hedefler ama bir sunucu altyapısı ve işletim emeği ister. Prebid belgeleri teklif veren sayısını, zaman aşımını ve istemci ile sunucu dağılımını A/B testleriyle sınamayı önerir. Karar kendi sayfanızın ölçümlerine dayanmalıdır.

Header bidding sayfa hızını ve CLS'yi etkiler mi?

Etkileyebilir. Teklif toplama ek ağ istekleri ve ek betik çalışması demektir; reklam kutusu için yer ayrılmazsa reklam geç yüklendiğinde içerik kayabilir. web.dev, reklamlar için min-height ya da aspect-ratio ile yer ayırmayı ve reklam yüklenmediğinde yer tutucuyu korumayı önerir. Etkinin büyüklüğü sayfadan sayfaya değişir; kendi alan verinizle ölçün.

ads.txt header bidding için zorunlu mu?

Zorunlu olduğunu iddia etmiyoruz; IAB Tech Lab ads.txt'yi, yayıncıların envanterini satmaya yetkili şirketleri herkese açık biçimde listelemesi için basit bir yöntem olarak tanımlar ve amacı programatik ekosistemde şeffaflığı artırmaktır. Alıcıların yetkili satıcıları görmesini sağladığı için programatik satışta pratik bir güven işaretidir. Hangi alıcının dosyayı şart koştuğu kendi anlaşmalarınıza bağlıdır.

Sonuç

Header bidding, reklam alanını satarken birden fazla talep kaynağını eşit koşulda yarıştırma fikridir; Prebid de bu fikri açık kaynaklı bir araç takımıyla uygulanabilir kılar. Temel tasarım kararları birkaç soruya iner: teklifler nerede toplanacak (tarayıcıda mı, sunucuda mı), kararı kim verecek (reklam sunucusu mu, Prebid mi), ne kadar beklenecek, hangi alt fiyat uygulanacak ve bunun sayfa hızına ve düzen kaymasına bedeli ne olacak. Hiçbirinin evrensel doğru yanıtı yoktur. Doğru yaklaşım, küçük adımlarla değiştirmek, aynı metriklerle ölçmek ve ads.txt gibi şeffaflık kayıtlarını güncel tutmaktır.

Reklam alanı satmak ya da reklam vermek isteyenler için Akua Adforce'ta reklam alanlarını inceleyebilirsiniz; kapsam ve koşullar ilgili sayfada yazılıdır.