Kendi SSP'niz: Prebid Server ya da Kiralık Bir SSP Ne Zaman Yeterli ve Kim Geliştirebilir

SSP, yani arz tarafı platformu, bir yayıncının reklam alanını aynı anda birçok alıcıya sunan ve satılan alan için yayıncıya ödeme yapan yazılımdır. Reklam alanını yalnızca kendi sitelerinde ya da uygulamalarında satan bir yayıncının nadiren kendi SSP'sini geliştirmesi gerekir. Böyle bir yayıncı mevcut SSP'ler üzerinden satış yapabilir ve açık kaynaklı bir program olan Prebid Server ile bu SSP'ler arasında kendi açık artırmasını yürütebilir. Kendi SSP'niz, işiniz başka yayıncıların reklam alanını satmaksa anlamlıdır. O durumda bile, hacminiz kiralık SSP'nin ücretlerini çok yüksek hâle getirene ya da yayıncılarınız onun yapamadığı bir şeye ihtiyaç duyana kadar kiralık bir SSP yeterli olabilir. Geliştirmeye karar verirseniz, kodu size teslim eden ve SSP'yi şirketinizin alan adı ve adıyla kuran bir firmayla çalışın.

SSP bir yayıncı için ne yapar?

Bir yayıncının sayfası ya da uygulaması, doldurulacak bir alanı olduğunda her seferinde bir reklam isteği gönderir. SSP bu isteği, reklamverenlerin reklam alanı satın almak için kullandığı yazılımlar olan talep tarafı platformlarına (DSP) yönelik bid request'lere dönüştürür. Onların tekliflerini toplar, kazananı seçer ve satışı kaydeder; böylece yayıncıya daha sonra ödeme yapabilir. Yayıncı SSP'de kurallar da belirler: örneğin kabul ettiği en düşük fiyat, yani taban fiyat (floor), ve reddettiği reklam türleri.

Her açık artırmanın bir süre sınırı vardır. Dijital reklamcılık için teknik standartlar yazan kâr amacı gütmeyen bir kuruluş olan IAB Tech Lab, bid request'ler için bir standart olan OpenRTB'yi yayımlar. 23 Ekim 2026'da okunan 2.6 sürümü, tmax alanını “zaman aşımını önlemek için, internet gecikmesi dahil, exchange'in tekliflerin alınması için tanıdığı milisaniye cinsinden azami süre” olarak tanımlıyor. Daha geç gelen bir teklif hiç teklif verilmemiş sayılır.

SSP parayı da yönetir. Gösterilen reklamları sayar ve alıcılara fatura eder, ardından her yayıncıya payını öder. Bu sayımlar bir alıcının sayımlarıyla uyuşmadığında, faturalar gönderilmeden önce birinin nedenini bulması gerekir.

Prebid Server bir yayıncı için yeterli mi?

Prebid Server, yalnızca kendi reklam alanını satan bir yayıncı için, yayıncının ekibi ya da bir barındırma sağlayıcısı onu işletiyorsa yeterli olabilir. Header bidding için geliştirilmiştir. Header bidding'de yayıncı, reklam sunucusu hangi reklamın gösterileceğine karar vermeden önce birkaç SSP'den ve ad exchange'den aynı anda teklif ister. Ad exchange de reklam alanı için açık artırmaları büyük ölçüde bir SSP gibi yürütür.

Prebid.org'un aynı gün okunan genel bakış sayfası şöyle diyor: “Prebid Server, sunucudan sunucuya header bidding için açık kaynaklı bir çözümdür.” Sayfaya göre “230+ sunucu tarafı teklif adaptörü” var; bunlar SSP'ler ve exchange'ler gibi teklif kaynaklarına hazır bağlantılardır.

Aynı sayfaya göre Prebid Server gelen her isteği kontrol eder, gizlilik kurallarını uygular ve teklif adaptörlerini çağırır. Adaptörler yanıt verdiğinde ya da “zaman aşımı süresi dolduğunda”, yanıtını isteği gönderen tarafa, örneğin bir web sayfasına ya da uygulamaya geri gönderir.

Prebid Server ile yayıncı, açık artırmayı çalıştığı SSP'ler ve exchange'ler arasında yürütür ve bunu genellikle DSP'lerle kendi sözleşmeleri olmadan yapar. Her SSP sattığı reklam alanı için yayıncıya ödeme yapmaya devam eder ve DSP bağlantılarının çoğu SSP'lerde kalır.

Genel bakış sayfası iki yaygın senaryoyu anlatıyor: “Teknik bilgisi güçlü yayıncılar” ve “Yönetilen hizmet sağlayıcıları: diğer herkes için”. Sayfa şöyle diyor: “Açık kaynak topluluğu tarafından sağlanan yapılandırma araçları yoktur.” Ayrıca Prebid Server kurulumunun “Prebid.js kadar kolay olmaktan çok uzak olduğu” konusunda uyarıyor; Prebid.js, Prebid'in ziyaretçinin tarayıcısında çalışan header bidding kodudur.

GitHub'daki, aynı gün okunan prebid-server kodu, açık kaynaklı bir lisans olan Apache License 2.0 ile yayımlanıyor. Bu lisans, ticari amaçlar dahil herkesin kodu kullanmasına ve değiştirmesine izin verir. Bir yayıncı kodu kendi sunucularında çalıştırabilir ya da onu barındıran bir sağlayıcıyı kullanabilir. Genel bakış sayfası, barındırma sağlayıcılarının ayrıca “kayıtlı istekleri (stored requests) yönetmek için araçlar sunduğunu” söylüyor.

Ne zaman kendi SSP'mizi geliştirmeliyiz?

Kendi SSP'niz, başka yayıncılar adına reklam alanı satan bir işe uyar. Reklam ağları, uygulama gelirleştirme şirketleri ve alanlarını birlikte satan yayıncı grupları buna örnektir. Bu şirketler için açık artırma ve ondan alınan ücretler ürünün kendisidir; kiralık yazılım ise ikisinde de yapılabilecek değişiklikleri sınırlar.

Kiralık bir SSP her istek ya da her satış için ücret alıyorsa ve hacminiz büyümeye devam ediyorsa da geliştirmek mantıklı olabilir. Üçüncü bir neden, yayıncılarınızın ihtiyaç duyduğu ama denediğiniz kiralık ürünlerin hiçbirinin desteklemediği bir açık artırma kuralı ya da reklam formatıdır.

Bir SSP, DSP'ler bid request'lerini almayı kabul edene kadar hiçbir şey kazanmaz ve her DSP bağlantısı ayrı bir entegrasyon, test ve sözleşme demektir. Geliştirmeye başlamadan önce hangi DSP'lerin SSP'nize bağlanmayı kabul ettiğini ve lansmanda hangi yayıncıların reklam alanlarını getireceğini yazın.

SSP kiralamak bize ne kazandırır ve tedarikçide ne kalır?

Kiralamak, yazılımı tedarikçinin işletmesi ve sizin onu bir sözleşmeyle, bazen kendi markanız altında kullanmanız demektir. Bir reklam sunucusu tedarikçisi olan Epom, SSP modülünü reklam sunucusu planlarına ek olarak satıyor. Aynı gün okunan fiyatlandırma sayfası planları ayda 250 dolardan başlatıyor ve “SSP module” için “1000 ext.reqs başına 0,001 dolar” fiyatını veriyor. Modül, “özel DSP uç noktalarını bağlamanıza” olanak tanıyor. Bir başka ek olan ayda 250 dolarlık “White-label solution” ise “varsayılanlar yerine şirketinizin adını, logosunu ve alan adını kullanmanızı” sağlıyor.

Üzerinde sizin markanız olan kiralık bir ürün yine de tedarikçiye aittir. Aynı gün okunan Epom Server Şartlar ve Koşulları (Epom Server Terms and Conditions) şöyle diyor: “Bu Sözleşme bir satış teşkil etmez ve Yazılım üzerinde hiçbir mülkiyet hakkı devretmez.” Aynı koşullara göre müşteri, yazılımı kullanmasından doğan kullanım bilgileri ve trafik örüntüleri olan “Hesap Verileri”nin sahibidir ve “tüm Hesap Verileri, sözleşmenin yenilenmemesi ya da daha erken feshedilmesinden itibaren otuz (30) gün içinde Yazılımdan silinecektir”. Sözleşme sona ermeden önce verilerinizi dışa aktarmayı planlayın.

Diğer tedarikçiler sözleşmelerini farklı yazar; bu yüzden fiyatları karşılaştırmadan önce mülkiyet bölümünü okuyun. İstek başına fiyatlar, tedarikçinin neyi istek olarak saydığına bağlıdır ve Epom'un sayfası “ext.reqs” ifadesini tanımlamıyor. Bu tanımı yazılı olarak isteyin ve yayıncılarınızın, reklam alanlarının satıcısı olarak hangi alan adını listeleyeceğini sorun.

Reklam alanını kimin sattığını alıcılara hangi dosyalar söyler?

Alıcılar teklif vermeden önce reklam alanının nereden geldiğini kontrol eder. Bir yayıncı, alanını satmaya yetkili her sistemi kendi web sitesindeki ads.txt adlı bir dosyada listeler. Uygulamalar bunun tamamlayıcısı olan app-ads.txt dosyasını kullanır. Aynı gün okunan ads.txt spesifikasyonunun 1.1 sürümü, her satırın ilk alanını “bidder'ların bağlandığı SSP, Exchange, Header Wrapper vb. sistemin kanonik alan adı” olarak tanımlıyor.

Bir ads.txt satırının üçüncü alanı, yayıncının o sistemle doğrudan çalışıp çalışmadığını gösterir. Spesifikasyona göre “DIRECT”, yayıncının satırda adı geçen “hesabı doğrudan kontrol ettiği” anlamına gelir. Spesifikasyon bunun “genellikle yayıncı ile reklam sistemi arasında doğrudan bir ticari sözleşme anlamına geldiğini” de ekliyor.

SSP, alanını sattığı her satıcının adını veren sellers.json adlı bir dosya yayımlar. Temmuz 2019 tarihli ve aynı gün okunan sellers.json spesifikasyonunun 1.0 sürümü şöyle diyor: “Reklam sistemleri sellers.json dosyasını kök alan adlarında ve gerektiğinde alt alan adlarında yayımlamalıdır.”

Dosya her satıcıyı listelemek zorundadır: “Gizli olsalar bile tüm satıcılar dahil edilmelidir.” Her satıcı kimliği tek bir şirketi temsil eder. Spesifikasyonun ifadesiyle, “Her seller_id, o seller_id ile işlem gören envanter için ödeme alan yalnızca tek bir kuruluşa karşılık gelmelidir.”

SSP'nin alan adı bid request'lerde de görünebilir. OpenRTB 2.6, her bid request'te bir SupplyChain nesnesi bulunmasını önerir: bu nesne, reklam alanının satışında yer alan ve bu süreçte ödeme alan şirketlerin listesidir ve eksik olarak işaretlenebilir. Nesnenin asi alanı, bir ads.txt satırının ilk alanıyla aynı sözcüklerle tanımlanır: bidder'ların bağlandığı sistemin alan adı.

AB'deki kişilere gösterilen reklam alanı için dikkate alınması gereken bir çerçeve daha var. Bir reklam sektörü kuruluşu olan IAB Europe, Şeffaflık ve Rıza Çerçevesi'ni (Transparency and Consent Framework, TCF) yürütüyor; bu çerçeve, her kişinin rıza gibi gizlilik tercihlerini yayıncının sitesinden ya da uygulamasından reklam teknolojisi şirketlerine iletir. IAB Europe, TCF'yi “gönüllü bir standart” olarak tanımlıyor. Aynı gün okunan tedarikçiler (vendors) sayfası, tedarikçilerin “reklam sunucuları, ölçüm sağlayıcıları, reklam ajansları, DSP'ler, SSP'ler ve daha fazlası olabileceğini” söylüyor. Sayfa şunu da ekliyor: “Tedarikçilerin TCF'ye katılmak için kayıt olması gerekir.”

SSP geliştirildiğinde nelerin sahibi biz olmalıyız?

Yukarıdaki her dosya ve kayıt bir alan adını ya da bir şirketi gösterir. Aşağıdaki her kalemin sonunda şirketinizde kaldığından emin olun:

• Yayıncılarınızın ads.txt satırlarında ve asi alanında görünen, şirketiniz adına kayıtlı alan adı
• Bu alan adındaki sellers.json dosyası ve dosyada listelenen satıcı kimlikleri
• Her DSP ile yapılan ve geliştirici firmanın değil, şirketinizin imzaladığı sözleşmeler
• SSP'niz TCF'ye katılıyorsa, şirketiniz adına yapılmış bir TCF tedarikçi kaydı
• Şirketiniz adına açılmış kod depoları, derleme betikleri ve bulut hesapları
• Loglar ve raporlar; bunları dışa aktarmanın test edilmiş bir yoluyla birlikte

Sonradan değiştirilmesi genellikle en zor kalem alan adıdır. Yeni bir alan adı, her yayıncının ads.txt dosyasında yeni bir satır demektir. Bir yayıncı bu satırı ekleyene kadar, ads.txt dosyasını kontrol eden alıcılar o yayıncının alanının SSP'niz üzerinden yapılan satışlarını yetkisiz sayabilir.

Geliştirici firmadan, sizin mülkiyetiniz dışında kalan kendi kodunun ya da üçüncü taraf kodunun her parçasını, her parçanın lisansıyla birlikte saymasını isteyin. SSP'nin içindeki Prebid Server gibi açık kaynaklı kodlar kendi lisanslarını korur. Özel bir ekibin nasıl kontrol edileceğini ve kodun nasıl sizde kalacağını anlatan yazı, sözleşme ifadelerini genel olarak ele alıyor.

SSP'mizi geliştirmeyi teklif eden bir firmayı nasıl kontrol ederiz?

Herhangi bir reklam teknolojisi tedarikçisi için genel kontroller, DSP ya da ad exchange geliştirme, lisanslama veya kiralama hakkındaki yazıda yer alıyor. SSP geliştirmek altı soru daha doğurur:

• Geliştirdiğiniz hangi SSP ya da exchange bugün canlıda? Hangi DSP'ler onun üzerinden satın alıyor?
• Sisteminizin gönderdiği, SupplyChain nesnesi doldurulmuş bir bid request'i bize gösterebilir misiniz?
• Bir teklif tmax'tan sonra gelirse ne olur ve bir yayıncı kaç teklifin geç kaldığını nasıl görür?
• Herhangi bir fatura kesilmeden önce gösterilen reklam sayınızı her DSP'nin sayısıyla nasıl eşleştiriyorsunuz?
• Yeni bir yayıncıyı sellers.json dosyasına kim ekliyor ve değişiklik ne kadar sürüyor?
• Devir teslimden sonra hangi bileşenler sizde kalıyor?

Bir SSP işletmiş bir firma, bu soruların çoğunu dosya, log ve rapor göstererek yanıtlayabilir. Bir gizlilik sözleşmesi bir müşterinin adının açıklanmasını engelliyorsa, firmadan bunun yerine o müşteriyle bir görüşme ayarlamasını isteyin.

En çok zamanı sayımla ilgili sorulara ayırın, çünkü yayıncılara SSP'nin rakamlarına göre ödeme yapılır. Reklam raporlarının neden bidder loglarıyla uyuşmadığını anlatan yazı, iki ayrı sayımın nerelerde birbirinden ayrıldığını açıklıyor.

SSP geliştirmek ya da kiralamak ne kadara mal olur?

Geliştirme, ilk sürüm için tek seferlik bir maliyetle başlar: açık artırma, yayıncı ve DSP bağlantıları, yukarıdaki dosyalar, raporlama ve ödemeler. Lansmandan sonra işletme maliyetleri sunucuları, ağ trafiğini, izlemeyi, nöbet tutan kişileri ve yıllık TCF tedarikçi ücreti gibi ücretleri kapsar.

Bir SSP'nin ağ trafiği, reklam isteği sayısıyla olduğu kadar DSP sayısıyla da büyür. SSP her reklam isteği için davet ettiği her DSP'ye ayrı bir bid request gönderir; bu yüzden her yeni DSP istek, trafik ve sunucu ekler.

Kiralama, bu maliyetlerin çoğunu Epom'un plan ücreti ve 1.000 “ext.reqs” başına fiyatı gibi tedarikçi ücretlerine dönüştürür. İki seçeneği iki yıl sonra beklediğiniz hacimle karşılaştırın. Ayrılmanın maliyetini de hesaba katın; örneğin alan adı tedarikçiye aitse her yayıncıda yeni ads.txt satırları gerekir.

amBrain nerede devreye girer?

amBrain'in hizmet listesinde şu satır yer alıyor: “amBrain, yayıncılar için arz tarafı platformları (SSP) geliştirir.” AdTech'te amBrain ayrıca DSP geliştirme, real-time bidding platformları ve ad exchange mühendisliği üzerinde çalışıyor. RTBBidder, amBrain'in bir müşteri için geliştirdiği bir talep tarafı platformudur.

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.” amBrain kısa listenizdeyse, ona da diğer her firmaya yönelttiğiniz soruların aynısını yöneltin; hangi yeniden kullanılabilir bileşenleri kastettiğini de sorun.

Bu yazı bir vaka çalışması değildir ve hiçbir müşteri çalışmasını anlatmaz. RTBBidder'ın adı yalnızca amBrain'in geliştirdiği bir DSP olarak geçer ve yazı onun hakkında hiçbir rakam vermez.

Prebid.org, IAB Tech Lab, IAB Europe ve Epom kendi sayfalarından alınmış örnekler olarak geçiyor ve yazı amBrain ile bunların herhangi biri arasında bir ilişki iddia etmez. Yazı amBrain'e ait fiyat ya da takvim vermez. Hukuki tavsiye de değildir: rıza ve veri kuralları ülkeden ülkeye değişir; bu yüzden bunları bir avukatla kontrol edin.