Dijital Açık Hava Ekran Ağı İçin Programatik Satış: Bir DOOH SSP'si Üzerinden Satmak, White-Label Bir Altyapı Kullanmak ya da Kendinizinkini Geliştirmek

Programatik satış, reklam alanınızı yazılımın satması demektir. Bir reklam alanı her satışa çıktığında, reklamverenlerin satın alma sistemleri otomatik bir açık artırmada ona teklif verir. Bir dijital açık hava (DOOH) ağının alışveriş merkezleri, istasyonlar, spor salonları ve ofisler gibi yerlerde ekranları vardır. Ağ bu ekranları, birçok ağın ekranlarını alıcılara sunan bir DOOH arz tarafı platformu (SSP) üzerinden programatik olarak satabilir. Bir tedarikçinin yazılımını kendi markasıyla da işletebilir (white-label altyapı) ya da kendi platformunu geliştirebilir. Seçim, satışın ne kadarını kontrol etmek istediğinize ve teknolojiyi her gün kimin işleteceğine bağlıdır.

Bir ekran ağı programatik satış yaptığında ne değişir?

Bazı alıcılar, satış ekibinizle kampanya rezervasyonu yapmak yerine yazılım üzerinden tek tek oynatımlara teklif vermeye başlar. Doğrudan satışta bu ekip bir reklamverenle tarihler, ekranlar ve fiyat üzerinde anlaşır. Ardından biri reklamları, her ekranın neyi ne zaman oynatacağına karar veren yazılım olan içerik yönetim sisteminize (CMS) yükler.

Programatik teklifler, reklamverenlerin ve ajansların reklam satın almak için kullandığı sistem olan talep tarafı platformundan (DSP) gelir. Alıcı ve satıcı sistemleri bu teklifleri genellikle ortak bir mesaj formatı olan OpenRTB üzerinden alıp verir. Dijital reklamcılık için teknik standartlar yazan IAB Tech Lab bu formatı güncel tutar ve Kasım 2022'de OpenRTB 2.6'ya ekran desteği ekledi.

Bu yazı, bu spesifikasyona ve IAB Tech Lab'in onun için hazırladığı uygulama notlarına dayanıyor. Ayrıca ortak bir mekân türleri listesi olan OpenOOH mekân taksonomisinden ve Media Rating Council'in (MRC) açık hava ölçümüne ilişkin standartlarından yararlanıyor. Tüm kaynaklara 4 Kasım 2026'da erişildi.

İşe CMS'inizle ya da her ekranı çalıştıran cihaz veya yazılım olan oynatıcınızla başlayın. Döngü (loop), belirli uzunlukta, sürekli tekrar oynatılan bir içerik ve reklam dizisidir. Ekranlarınız bir döngüyle çalışıyorsa, döngüdeki alanların bir kısmı programatik için boş kalmalıdır. Oynatıcının bu alanlar için reklamları çekmesi ve neyin oynatıldığını bildirmesi gerekir. Hiçbir reklam gelmediğinde ise gösterecek başka bir şeye ihtiyacı vardır.

Açık artırma, oynatımdan epey önce gerçekleşebilir. IAB Tech Lab'in notları, çoğu ekranın yoğun saatlerde kesilebilen mobil ağlar üzerinden bağlandığını açıklıyor. Bu yüzden bazı ekran ağları reklamları önceden çeker. Notlarda şöyle deniyor: “Sektörde şu anda kabul gören, ‘teklif onayı’ndan ‘yayın’a kadar geçen süre 1 ila 2 saate kadar çıkabilir.”

Ekrandaki tek bir oynatım nasıl birçok gösterime dönüşür?

DSP'lerden teklif istemeye yarayan mesaj olan her bid request, o oynatımın kaç gösterim değerinde olduğunu belirtir. Bir web sitesinde gösterim, bir kişiye gösterilen bir reklamdır. IAB Tech Lab'in notlarına göre ekrandaki bir oynatım ise “gösterilen reklamın yakınında bulunan herkes tarafından görülebilir”.

Bu sayı gösterim çarpanıdır (impression multiplier), yani her oynatım için sayılan kitledir. OpenRTB 2.6 onu şöyle tanımlar: “Bu öğe satın alınırsa gerçekleşmiş sayılacak faturalanabilir olayların miktarı.” Sade bir dille söylersek, alıcının parasını ödediği şey budur.

Çarpan, gece sakin bir ekranda olabileceği gibi, birin altında da olabilir. Notlara göre “kesirli değerler (ör. her reklam yayını başına 0,32 gösterim) yaygındır”. Notlar ayrıca bu sayının saatten saate değişebileceğini ya da “gerçek zamanlı sensör verilerinden” gelebileceğini ekliyor.

Fiyatlar CPM, yani bin gösterim başına fiyat olarak kalır. Notlar bir piyasa fiyatı değil, bir hesap örneği veriyor: 2,50 dolarlık bir CPM teklifi 30,3 gösterim değerindeki bir oynatımı kazanırsa fatura 0,07575 dolar tutar. Notlar ayrıca ondalıklarla çarpmanın “‘alım tarafı’ ve ‘satış tarafı’ ondalık basamakları kestiğinde tutarsızlıklara yol açabileceği” konusunda uyarıyor. İlk kampanyadan önce yuvarlama konusunda her SSP ve alıcıyla anlaşın.

Kitle rakamı nereden gelir?

Bid request, bu rakamı kimin sağladığını da belirtebilir. IAB Tech Lab'in AdCOM spesifikasyonu üç kaynak sayar: bir ölçüm sağlayıcısı, yayıncı (siz) ya da exchange (SSP).

Alıcılar bu rakamın neyi ölçtüğünü soracaktır. MRC, medya ölçümünü denetleyen ve akredite eden ABD'li bir sektör kuruluşudur. MRC'nin nihai sürümü Aralık 2025 tarihli olan açık hava standartları, bir konumdaki trafikten reklamı görmüş olması muhtemel kitleye uzanan bir merdiven tanımlar. Her basamak yeni koşullar ekler ve standartlar, “Brüt Gösterimlerin (Gross Impressions) en yüksek potansiyel kitle tahminini yansıttığını” belirtir.

Bir reklamın oynatıldığını nasıl kanıtlarız?

Oynatım kanıtı (proof of play), ekranın oynatıcısının tuttuğu ve hangi reklamın hangi ekranda ne zaman oynatıldığını gösteren bir logdur. MRC standartları şöyle der: “Brüt Gösterimlerin ya da Kitle tahminlerinin raporlanmasını desteklemek için güçlü bir oynatım kanıtı (proof-of-play, PoP) bulunmalıdır”.

Dijital ekranlar için standartlar, lansmandan önce test edilmesi ve “periyodik olarak izlenmesi” koşuluyla oynatıcı etkinliğini kaydeden teknolojiyi kabul eder. Standartlar ayrıca satıcının bir reklamın yayınlandığına dair kanıtını, örneğin oynatım loglarını da ele alır. Standartlara göre bu kanıtın neleri içereceği “reklam kampanyası başlatılmadan önce alıcı ve satıcı tarafından kararlaştırılmalıdır”.

OpenRTB'de, alıcıya bir gösterimin faturalanabileceğini bildiren mesaj olan bir faturalama bildirimi bulunur. Farklı bir mesaj olan kazanma bildirimi ise yalnızca bir teklifin kazandığını söyler. IAB Tech Lab'in notları, bu ikisinin ayrı tutulmasını ve faturalama bildiriminin “kreatif ekranda görüntülendiğinde ve gösterim[ler] faturalanabilir olduğunda” gönderilmesini güçlü bir şekilde önerir. Kreatif, reklam dosyasının kendisidir.

Ekranlarımızı programatik olarak satmanın üç yolu nedir?

• Bir DOOH SSP'si üzerinden satmak. CMS'inizi ya da oynatıcılarınızı SSP'ye bağlar, ekranlarınızı ve kitle rakamlarınızı sisteme yüklersiniz. SSP bunları birlikte çalıştığı DSP'lere sunar, açık artırmayı yürütür ve kendi ücretini düştükten sonra kalanı size öder.
• White-label bir altyapı kullanmak. Bir tedarikçi, reklam sunucusunu ve DSP'lere satış yapan yazılımını size lisanslar. Reklam sunucusu, hangi reklamın oynatılacağını seçen ve onu sayan sistemdir. Platform sizin markanızı taşır, kodun bakımını ise tedarikçi yapar.
• Kendi platformunuzu geliştirmek. Reklam sunucusunu, DSP'lere bağlantıyı ve raporları ekibiniz ya da anlaştığınız bir firma geliştirir. Kodun ve içindeki her kuralın sahibi sizsiniz ve sistemi siz işletirsiniz.

Bu yolları birleştirebilirsiniz: örneğin doğrudan kampanyalar için kendi reklam sunucunuzu işletebilir, boşta kalan oynatımları ise SSP'ler üzerinden satabilirsiniz.

Bir DOOH SSP'si üzerinden satmak ne zaman yeterlidir?

Şunların çoğu geçerliyse bir SSP kullanın:

• Teknolojiye para harcamadan önce programatik alıcıların ekranlarınız için ödeme yapıp yapmayacağını öğrenmek istiyorsunuz
• CMS'iniz ya da oynatıcılarınız zaten o SSP ile çalışıyor ya da SSP bunları bağlamanıza yardım edecek
• Programatik, satış ekibinizin satmadığı alanları dolduracak
• Bir reklam platformunu gece gündüz işletecek mühendisleriniz yok

Bunun bedelini kontrolle ödersiniz. Alıcılar ekranlarınızı SSP'nin pazar yerinde diğer ağların yanında bulur; fiyatlar ve anlaşmalar da onun yazılımının izin verdiği şekilde işler.

White-label bir altyapı ne zaman mantıklıdır?

Şu durumlarda white-label bir altyapı seçin:

• Ajanslar bir pazar yerinden değil, sizin markanızdan ve satış ekibinizden satın almalı
• Fiyatlar, anlaşmalar ve hangi reklamın hangi mekânda oynatılabileceği konusunda kendi kurallarınızı istiyorsunuz
• Kampanyaları yürütecek bir ekip kurabiliyorsunuz, ama reklam yazılımı yazıp işletecek bir ekip kuramıyorsunuz

Kod kiralıktır. Yeni özellikler tedarikçinin takvimine göre gelir ve lisans ücretleri hacminizle birlikte artabilir. Ayrılırsanız ekranları, anlaşmaları ve alıcı hesaplarını başka bir yerde yeniden kurmanız gerekebilir.

Kendi platformumuzu geliştirmeye ne zaman değer?

Geliştirmek şu durumlarda karşılığını verir:

• Programatik gelirinizin büyük bir payını oluşturuyor ve ücretler, kendi sisteminizi işletecek bir ekibe ödeme yapmaktan daha pahalıya geliyor
• Ekranlarınız, görüştüğünüz tedarikçilerin destekleyemediği kurallara ihtiyaç duyuyor; örneğin bir istasyonda tren saatlerine göre değişen reklamlar
• Başka ağların ekranlarını da satıyorsunuz; dolayısıyla platform sattığınız şeyin bir parçası
• Mekânlarınızdan gelen kitle verileri kendi sistemlerinizde kalmalı

Bu yolda her DSP'nin, kendi alıcıları ekranlarınızı görebilmeden önce, genellikle platformunuza bağlanmayı kabul etmesi ve bid request'lerinizi test etmesi gerekir. Birinin sistemi izlemesi ve raporları alıcılarla mutabık kılması gerekir. OpenRTB de değişmeye devam ediyor: IAB Tech Lab, ekran desteğini eklediğinden bu yana 2.6 sürümü için yedi güncelleme yayımladı. Ekibinizde bu işi üstlenecek kimse yoksa, bir SSP ya da white-label bir altyapıyla başlayın.

Hangi yolu seçersek seçelim, ekibimize hangi işler kalır?

Şunları ekibiniz belirler ve güncel tutar:

• Ekran ve mekân verileri: her ekran için bir kimlik, konum, boyut, çalışma saatleri ve mekân türü. Mekân taksonomisi, bir spor salonunun her alıcı için aynı anlama gelmesini sağlayan ortak bir mekân türleri listesidir. OpenRTB 2.6, istek başka bir taksonomi belirtmedikçe OpenOOH Venue Taxonomy'yi esas alır. Bu taksonomi mekânları “Perakende” ve ardından “Perakende / Alışveriş Merkezleri” gibi düzeylere ayırır.
• Kitle tahminleri ve kaynakları: rakamınızın MRC merdiveninin hangi basamağını ölçtüğü, onu kimin ölçtüğü ve ne sıklıkla değiştiği
• Kreatif onayı ve içerik kuralları: IAB Tech Lab'in notlarına göre büyük ticari ağlardaki reklamların “elle önceden onaylanması gerekir”; bazı durumlarda bu onayı mekânların mülk sahipleri de verir. Notlar, “halka açık bir yerde binlerce kişiye” gösterilen tek bir kötü reklamın ağın “reklam yayınlama sözleşmesini/iznini” riske attığı konusunda uyarıyor. Her mekân sahibinin neye izin verdiğini yazılı bir liste hâlinde tutun.
• Oynatım logları ve mutabakat: bir SSP bu logları toplasa bile kendi oynatım kanıtı (proof-of-play) loglarınızı tutun. Ekranlar çevrimdışı kalır ve ondalıklar farklı yuvarlanır; bu yüzden birinin her ay loglarınızı her alıcının raporuyla karşılaştırması gerekir.
• Taban fiyatlar ve doğrudan anlaşmalar: taban fiyat, kabul ettiğiniz en düşük tekliftir ve tekliflerin kendisi gibi CPM olarak belirlenir. Özel pazar yeri (private marketplace) anlaşması, yalnızca davet ettiğiniz alıcıların katılabildiği bir açık artırmadır. Bid request bunu deal ID adı verilen bir kodla işaretler. Doğrudan bir kampanya ile programatik bir teklif aynı alanı istediğinde hangisinin kazanacağına karar verin.

Bir SSP ya da white-label tedarikçisiyle imzalamadan önce neleri kontrol etmeliyiz?

• Yüklediğimiz ekran listesinin, mekân verilerinin ve kitle rakamlarının sahibi kim ve bunları istediğimiz zaman dışa aktarabilir miyiz?
• Her bid request'e kimin kitle rakamı giriyor ve bu rakamın kaynağı nasıl işaretleniyor?
• Her satıştan kendinize ne kadar pay ayırıyorsunuz ve raporlarımız hem brüt hem de net tutarı gösteriyor mu?
• Bugün hangi DSP'ler bağlı ve bunlardan hangileri son üç ayda DOOH oynatımı satın aldı?
• Doğrudan kampanya satmaya devam edip aynı anda başka SSP'leri de kullanabilir miyiz?
• Her kreatifi kim onaylıyor ve bir reklamı yalnızca tek bir mekân için engelleyebilir miyiz?
• Ayrıldığımızda ne olur: bildirim süresi ne kadar ve hangi anlaşmaları, hesapları, logları ve raporları yanımızda götürebiliriz?

Kodun, verilerin ve alıcı ilişkilerinin sahibi kim?

Bir SSP kendi platformunun ve DSP'lerle yaptığı sözleşmelerin sahibidir. Ekran ve kitle verileriniz sizin kalmalı ve sözleşme de bunu açıkça söylemelidir. Bir SSP içinde kurulan anlaşmaları ayrılırken yanınızda götüremeyebilirsiniz.

White-label bir tedarikçi kodun sahibidir, marka ise sizindir. Alıcı hesaplarının ve DSP bağlantılarının şirketinizin adına mı, yoksa tedarikçinin adına mı kayıtlı olduğunu kontrol edin.

Kendi platformunuzu geliştirirseniz kaynak kodun sahibi olabilir ve onu değiştirmesi için istediğiniz ekiple çalışabilirsiniz. Sistemi geliştiren firmadan, elinde tuttuğu parçaları ve bunları kullanmanızı sağlayan lisansı sözleşmede adıyla belirtmesini isteyin.

Ne seçerseniz seçin, verilerinizin yalnızca ekranlarınızı satmak için kullanılabileceğini ve logların ve raporların istediğiniz zaman dışa aktarılabileceğini yazılı hâle getirin.

Ekran platformumuzu geliştirecek bir firmaya neler sormalıyız?

• Platform CMS'imize ve oynatıcılarımıza nasıl bağlanacak ve hiçbir reklam zamanında gelmediğinde ekranda ne oynatılacak?
• Her bid request ekranın konumunu, mekân türünü, oynatım başına kitleyi ve bu rakamın kaynağını nasıl taşıyacak?
• Oynatım kanıtı nasıl kaydedilecek ve alıcıların raporlarıyla nasıl karşılaştırılacak?
• Alıcılar kreatifleri, IAB Tech Lab'in notlarında DOOH için “şiddetle tavsiye edilen” bir standart olarak anılan Ad Management API üzerinden onaya mı gönderecek?
• Taban fiyatlar ve özel pazar yeri (private marketplace) anlaşmaları her ekran, mekân ve saat için nasıl belirlenecek?
• İlk olarak hangi DSP'leri bağlayacaksınız ve onlarla görüşmeleri kim yürütecek?
• Bugün çalışan bir sistemde bunun işlediğini gösterebilir misiniz?

amBrain nerede devreye girer?

Bu blogu amBrain yayımlıyor. amBrain'in kendi ifadelerinden üçü, üçüncü yolu seçen bir ağın kurduğu sistemleri anlatıyor. Biri şöyle: “amBrain, yayıncılar için arz tarafı platformları (SSP) geliştirir.” Bir diğeri: “amBrain reklam sunucuları geliştirir: hedefleme, frekans sınırlama ve raporlama.” Üçüncüsü: “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ı.” Alım tarafındaki dördüncüsü ise şöyle: “RTBBidder, bir müşteri için geliştirdiğimiz talep tarafı platformu.”

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 yazı bir vaka çalışması değildir. RTBBidder'ın adını vermek dışında hiçbir müşteri çalışmasını anlatmaz. amBrain'in herhangi bir müşteri için bir DOOH platformu geliştirdiğini, bir ekran ağını bir SSP'ye bağladığını ya da kitle ölçümü yaptığını söylemez. amBrain'e ait fiyat ya da takvim de vermez. IAB Tech Lab'den, OpenOOH taksonomisinden ve MRC'den yapılan alıntılar bunların yayımlanmış belgelerinden alınmıştır ve yazı amBrain ile bunların herhangi biri arasında bir ilişki iddia etmez.

Hukuki tavsiye de değildir. İmzalamadan önce SSP, tedarikçi ve mekân sözleşmelerini bir avukata okutun. Kitle sayımlarınız kameralardan ya da başka sensörlerden geliyorsa, gizlilik hukukunun bunlara nasıl uygulandığını sorun. amBrain kısa listenizdeyse, ona da diğer her firmaya sorduğunuz soruların aynısını sorun.