DSP ya da SSP'nizde İnternete Bağlı TV: Neler Değişir, Neyi Kendiniz Geliştirmelisiniz

İnternete bağlı TV (CTV) reklamları, internete bağlı televizyonlarda, genellikle bir streaming uygulamasının içinde birkaç reklamdan oluşan bir reklam arasında oynatılan video reklamlardır. Web ve uygulama banner'ları için kurulmuş bir DSP ya da SSP'nin bu reklamları işleyebilmesi için dört yerde değişmesi gerekir. Bid request tek bir reklam alanı yerine bütün bir reklam arasını tarif eder. Reklam, video dosyalarına işaret eden bir XML belgesi olan VAST yanıtı olarak gelir. Birçok TV uygulaması reklamları bir tarayıcının yaptığı gibi isteyip izleyemez; bu yüzden reklamı yayın akışına bir stitching servisi yerleştirir. Ardından reklam isteklerini, çoğu zaman da izleme çağrılarını TV adına bu servis gönderir; dolayısıyla cihazları tanımlama ve gösterimleri sayma biçiminizi değiştirmeniz gerekir. Reklam aralarına teklif verme ve VAST desteği, kendi platformunuzda geliştirmeye değer. Stitching ise yayıncıya ya da bu iş için kurulmuş bir servise aittir.

İnternete bağlı TV reklamlarını farklı kılan nedir?

Bir web sitesinde reklam isteği genellikle tek bir alan için tek bir reklam ister; tarayıcı o reklamı yükler ve gösterimi bildirir. TV'de ise izleyici bir streaming uygulamasında bir program izler ve reklamlar, geleneksel televizyon yayınında olduğu gibi reklam aralarında gelir. OpenRTB teklif verme protokolünü güncel tutan kuruluş IAB Tech Lab, böyle bir reklam arasına ad pod (reklam kuşağı) adını verir: “bir video ya da ses içeriği akışı içinde art arda oynatılan” bir ya da daha fazla reklam.

IAB Tech Lab'in OpenRTB 2.6 spesifikasyonu, 2.6 sürümünü “CTV işlemleri için Ad Pod'ları getiren” sürüm olarak tanımlar. Bu yazı, bu spesifikasyona ve IAB Tech Lab'in onun için hazırladığı uygulama notlarına dayanıyor; ikisi de buradaki diğer kaynaklar gibi 2 Kasım 2026'da okundu.

Reklam arası bid request'te nasıl gelir?

OpenRTB 2.6'da bir reklam arası, bid request'te bir ya da daha fazla gösterim nesnesi (impression object) olarak gelir; aynı podid değerini paylaşan gösterim nesneleri aynı reklam arasına aittir. Uygulama notları üç tür reklam arası tanımlar:

• Yapılandırılmış (structured): satıcı alanların sayısını, sırasını ve her birinin süresini önceden belirler; her alan ayrı bir gösterim nesnesidir
• Dinamik (dynamic): satıcı toplam süreyi ve azami reklam sayısını belirler, ancak reklamların sayısını ya da her birinin süresini belirlemez; reklam arasının tamamı tek bir gösterim nesnesi olarak gelebilir
• Hibrit (hybrid): reklam arasının bir kısmı sabit, bir kısmı dinamiktir

Banner platformlarının çoğu şu alanları okumak zorunda hiç kalmadı:

• poddur, yani reklamverenlerin dinamik bir reklam arasında doldurabileceği toplam saniye sayısı, ve maxseq, yani bu reklam arasının alabileceği en fazla reklam sayısı
• rqddurs, yani kesin reklam sürelerinin listesi. Spesifikasyona göre bu alan, “kesin olmayan reklam sürelerinin istenmeyen ‘yayın boşluğuna’ yol açacağı” canlı TV için tasarlanmıştır
• slotinpod, yani satıcının ilk ya da son alanı garanti edip edemeyeceğini belirten alan, ve podseq, yani reklam arasının programdaki konumu
• mincpmpersec, yani reklam arasının dinamik kısmı için reklam süresinin saniyesi başına taban fiyat

Her teklif, reklamının süresini dur alanında belirtir. Uygulama notları ayrıca alıcıların “pod'un nihai olarak satıcı tarafından oluşturulmasını beklemesi gerektiğini” söyler. Tek bir reklam arası için birkaç teklif gönderirseniz satıcı bunlardan hiçbirini kullanmamaktan hepsini kullanmaya kadar istediği sayıda teklifi kullanabilir ve onları diğer alıcıların reklamlarıyla karıştırabilir.

Her teklifle birlikte reklamverenin alan adını (adomain) ve kreatifin kimliğini (crid) gönderin. Spesifikasyon ikisini de “reklam kalitesi kontrolleri ya da yayıncı kısıtlamalarının uygulanması için” kullanılan öznitelikler arasında sayar.

Bir DSP için reklam araları teklif mantığını değiştirir. Banner için çalışan bir bidder gösterimleri tek tek fiyatlandırır. CTV bidder'ı ise reklamlarından hangilerinin reklam arasında kalan süreye sığdığını seçmek ve onları saniye başına fiyatlandırmak zorundadır; satıcının bunlardan hangilerini tutacağını da kontrol edemez.

VAST yanıtının neleri içermesi gerekir?

Video reklamlar, IAB Tech Lab'in “dijital video oynatıcılara reklam sunmak için evrensel bir XML şeması” olarak tanımladığı VAST ile teslim edilir. IAB Tech Lab'in en son Temmuz 2024'te güncellenen VAST sayfası, Aralık 2022 tarihli VAST 4.3'ü en yeni sürüm olarak gösteriyor. IAB Tech Lab'in GitHub'daki VAST 4.x deposunda VAST 4.4 de bulunuyor; oradaki bir proje sorumlusunun notu bu sürümün 22 Temmuz 2026'da yayımlandığını belirtiyor. VAST 4.4, duraklatma (pause) ve ekran koruyucu reklamları gibi CTV formatları ekliyor. Aşağıdaki alıntılar VAST 4.3'ten alınmıştır.

IAB Tech Lab, Temmuz 2024'te ayrıca VAST 4'ün kreatif kimliğini ve mezzanine dosyasını daha eski VAST 2 ve 3'e taşıyan bir CTV eki (addendum) yayımladı. Ek, bu önceki sürümlerin “bugün hâlâ pazara hâkim olduğunu” söylüyor.

TV'de VAST'ın iki parçası en çok önem taşır:

• Bir mezzanine dosyası, yani yayıncının sistemlerinin her ekran için ayrı bir sürüm ürettiği “ham, yüksek kaliteli video dosyası”. VAST 4.3'e göre mezzanine dosyası “reklamın akışa eklendiği (ad-stitched) uygulamalarda zorunludur” ve bir stitching servisi mezzanine dosyası olmayan bir yanıtı reddedebilir
• Bir UniversalAdId, yani kreatifle birlikte sistemden sisteme taşınan bir tanımlayıcı. VAST 4.3 bunu, programın içinde oynatılan türden reklamlar olan lineer reklamlar için zorunlu tutar; CTV eki ise onu VAST 2 ve 3'e bir uzantı olarak ekler. Stitching servisleri, bir kreatifi daha önce dönüştürüp dönüştürmediklerini anlamak için onu kullanır

VAST 4.3'ün tarif ettiği stitching sürecinde, servisin daha önce hiç görmediği bir kreatifin oynatılabilmesi için önce dönüştürülmesi gerekir; bu yüzden reklam arasında onun yerine başka bir reklam oynatılır. VAST 4.3, bir mezzanine dosyasının ilk indirilmesinin “birkaç saat sürebileceğini” belirtir. AWS, reklamları akışlara yerleştiren bulut servisi MediaTailor için aynı kuralı anlatıyor: “Bir reklam henüz içerikle eşleşecek şekilde dönüştürülmediyse (transcode edilmediyse), MediaTailor onu eklemeyi atlar”; reklam ise bir sonraki istek için hazırlanır.

Bu yüzden yeni bir kreatif, her stitching servisinde ilk oynatılma fırsatlarını kaçırabilir. VAST 4.3'e göre herhangi bir şekilde değiştirilen bir kreatif yeni bir tanımlayıcı almalıdır. Kreatifin kendisi değişmediği sürece tanımlayıcıyı değiştirmeyin; böylece her stitching servisi onu yalnızca bir kez dönüştürür.

VAST 4.3 doğrulama kodu için Open Measurement'ı (OMID) önerir ve “VPAID kullanılmamasını güçlü bir şekilde” tavsiye eder; VPAID, video reklamın içinde kod çalıştırmanın eski yoludur. VAST 4.3, etkileşimli reklamlar için VPAID'in yerine SIMID'i gösterir. Etkileşimli kodu video dosyasından ayrı tutar; böylece bir stitching servisiyle çalışan oynatıcılar kodu çalıştıramadıklarında da videoyu oynatabilir. Her TV kreatifinin düz bir video olarak çalıştığından emin olun.

Reklamı akışa bir sunucu yerleştirdiğinde ne değişir?

Birçok TV uygulaması reklamları bir tarayıcının yaptığı gibi isteyip izleyemez. VAST 4.3, sunucu tarafında reklam ekleme (server-side ad insertion, SSAI) ya da ad stitching adı verilen alternatifi tarif eder. Uygulama yayın akışını bir stitching servisinden ister, servis reklamları reklam sunucusundan ister ve reklamlar içeriğe yerleştirilir; böylece izleyici “tek bir kesintisiz akış” alır.

OpenRTB 2.6, stitching ve izleme işlerinin ne kadarının bir sunucuda gerçekleştiğini belirtmek için gösterim nesnesine bir ssai alanı ekler. Alanın değerleri “tamamen istemci tarafı” ile “tamamen sunucu tarafı” arasında değişir. Aradaki durumda video sunucuda akışa yerleştirilir, izleme pikselleri ise cihaz tarafından tetiklenir. Varsayılan değer olan 0, durumun bilinmediği anlamına gelir; dolayısıyla bu alanı içermeyen bir istek size hiçbir yönde bilgi vermez.

Reklam istekleri ve izleme çağrıları bir sunucudan geldiğinde, birçok izleyici tek bir IP adresini paylaşıyormuş gibi görünür. VAST 4.3 şu uyarıyı yapar: “İzleme bilgisi alan bir reklam sunucusu için raporlar geçersiz trafiğe benzer görünür.” VAST 4.3'e göre stitching sağlayıcıları, izleme istekleriyle birlikte cihazın IP adresini ve user agent'ını X-Device-IP ve X-Device-User-Agent adlı iki başlıkta göndermek zorundadır ve bu değerler orijinal reklam isteğindekilerle eşleşmelidir.

Bu, platformunuz için şu anlama gelir:

• Trafik bir stitching servisi üzerinden geldiğinde cihaz bilgilerini bu başlıklardan ve bid request'ten alın. Bu durumda size bağlanan IP adresi stitching servisine aittir; bu yüzden onu cihaz için kullanmayın
• X-Device başlıkları olmadan gelen her türlü sunucu tarafı trafiği satıcıya sorun
• Satıcının, yayıncının app-ads.txt dosyasında listelendiğini kontrol edin. IAB Tech Lab'in spesifikasyonu ads.txt'yi “internete bağlı televizyon uygulama mağazalarındaki” uygulamalara genişletir
• Frekans sınırlarını ve kitleleri cihaz kimliklerine dayandırın. VAST 4.3, bir stitching servisinin “çerezlere erişemediğini” belirtir. OpenRTB 2.6'da ifa alanı, cihazın işletim sisteminden gelmesi beklenen bir reklam kimliği taşır; lmt alanı ise izlemenin ne zaman sınırlanması gerektiğini belirtir

Gösterimler nasıl sayılır ve faturalanır?

OpenRTB'nin uygulama notları faturalanabilir olayları saymanın yollarını karşılaştırır. Ses ve video için VAST gösterim (impression) olayını önerir. Banner'lar için iyi çalışan faturalama bildirimi URL'si (burl) ise “ses/video için önerilmez”.

Notlar ayrıca bidder'lara açık artırma ile faturalama bildirimi arasındaki gecikmeyi izlemelerini tavsiye eder; çünkü harcama hedefleri, frekans sınırları ve bütçe dağıtımı (pacing) buna bağlıdır. Notların makul gecikmeler tablosunda, sunucu tarafı stitching kullanılan ses ya da video satırında “Çok Uzun veya Bilinmiyor” yazar.

Satıcı exp alanıyla istekte açık artırma ile gösterim arasında kaç saniye geçebileceğini, alıcı ise teklifte kaç saniye beklemeye razı olduğunu belirtir. İki değer de tavsiye niteliğindedir. Notlar, bidder'ları tekliflerindeki exp süresinden sonra gelen bir faturalama bildiriminin faturalanmayacağını varsaymamaları konusunda uyarır; çünkü bu, exchange ile yapılan sözleşmenin konusudur.

Sunucu tarafı stitching, sayım kurallarını değiştirmedi. VAST 4.3, Media Rating Council (MRC) ile birlikte geliştirilen IAB ölçüm yönergelerinden alıntı yapar: “Ölçüm Yönergeleri, reklam sayımının istemci tarafından başlatılan bir yaklaşım kullanmasını şart koşar”. Aynı pasaj, sunucuda sayıma “istemci tarafı olaylara ve ölçüm kaynaklarına dayalı olarak başlatıldığı sürece” izin verir. Bir sunucunun kendi başına başlattığı sayımı ise reddeder; çünkü bu sayım “kullanıcının reklamı fiilen görmesine en uzak” olanıdır. Bir sunucu reklamı akışa yerleştirdiğinde gösterim sayımını hangi olayın başlattığını her satıcıya sorun.

Neyi kendiniz geliştirmelisiniz, ortaklar neyi zaten üstleniyor?

Bir CTV kurulumunun bazı kısımları yayıncıya ya da yayıncılar için geliştirilmiş servislere aittir. Stitching'in kendisi bunlardan biridir. Örneğin MediaTailor izleyicinin bilgilerini reklam karar sunucusuna gönderir, seçilen reklamları reklam sunucusunun yanıtında alır ve onları akışa yerleştirir. Video dosyalarını her yayıncının formatına dönüştürmek de aynı işin parçasıdır.

Diğer kısımlar platformunuzun ne kazanacağını belirler ve bunlar kendiniz geliştirmeye değer:

• DSP için: bir reklam arasına hangi reklamların sığdığını seçmek ve onları saniye başına fiyatlandırmak
• DSP için: faturalama bildirimleri geç geldiğinde bütçe dağıtımını (pacing) yönetmek
• DSP için: kreatifleri bir mezzanine dosyasıyla ve yalnızca kreatif değiştiğinde değişen bir kreatif kimliğiyle sunmak; bu kimlik VAST 4'ün UniversalAdId öğesinde ya da CTV ekinin VAST 2 ve 3 için tanımladığı uzantıda yer alır
• SSP için: her reklam arasını birkaç alıcının tekliflerinden oluşturmak ve yayıncının hangi reklamverenlerin yer alabileceğine dair kurallarını uygulamak
• SSP için: pod alanlarını ve ssai değerini her alıcıya iletmek
• Her ikisi için: cihaz bilgilerini X-Device başlıklarından okumak ve geçersiz sunucu tarafı trafiği filtrelemek
• Her ikisi için: gösterimleri alıcıların ve denetçilerin kabul edeceği şekilde saymak

Reklamverenlerinin CTV isteyip istemediğini yalnızca test etmek isteyen bir DSP, hâlihazırda CTV satan bir ya da iki SSP ile başlayabilir ve önce yapılandırılmış reklam aralarına teklif verebilir. Bu SSP'lere CTV arzlarının ne kadarının dinamik reklam araları olarak geldiğini sorun; çünkü uygulama notları satıcıları mümkün olduğunda dinamik pod'lar sunmaya teşvik eder. Kesin reklam süreleri gerektiren canlı TV, ilk kampanyalar reklamverenlerin bunu istediğini gösterene kadar bekleyebilir.

CTV gelirinizin kalıcı bir payı hâline geldiğinde yukarıdaki listedeki her şeyi geliştirin. TV yayıncılarıyla kendi anlaşmalarınızı yapıyorsanız ya da bir ortağın reklam aralarını işleme biçimi hangi tekliflerinizin yayına gireceğini sürekli belirliyorsa da aynısı geçerlidir.

Platformumuza CTV ekleyen bir firmaya neler sormalıyız?

• Sistem hangi OpenRTB 2.6 pod alanlarını okuyacak ve dinamik bir reklam arası için reklamları nasıl seçiyor?
• Sistem teklifleri saniye başına nasıl fiyatlandırıyor ve mincpmpersec'e uyuyor mu?
• Kreatiflerimiz hangi VAST sürümlerini kullanacak ve mezzanine dosyaları nereden geliyor?
• Kreatiflerimiz kayıtlı UniversalAdId'ler mi taşıyacak, yoksa varsayılan “unknown” değerini mi?
• Sistem sunucu tarafı trafiği nasıl ele alıyor ve cihazın IP adresini ve user agent'ını nereden alıyor?
• Gösterimler her satıcı için nasıl sayılıyor?
• Faturalama bildirimleri çok geç geldiğinde bütçe dağıtımı (pacing) nasıl doğru tutuluyor?
• İlk olarak hangi ortaklarla test yapacağız ve hangi özellikler bekleyebilir?

amBrain nerede devreye girer?

AdTech'te amBrain; DSP geliştirme, real-time bidding platformları ve ad exchange mühendisliği üzerinde çalışıyor. Hizmet listesindeki satırlardan ikisi şöyle: “amBrain, yayıncılar için arz tarafı platformları (SSP) geliştirir.” ve “amBrain reklam sunucuları geliştirir: hedefleme, frekans sınırlama ve raporlama.” 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.”

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 platforma internete bağlı TV eklediğini söylemez; RTBBidder hakkında hiçbir rakam, amBrain'e ait fiyat ya da takvim de vermez. IAB Tech Lab ve AWS kendi belgelerinden alıntılanmıştır ve yazı amBrain ile bu ikisinden herhangi biri arasında bir ilişki iddia etmez. amBrain kısa listenizdeyse, ona da diğer her firmaya sorduğunuz soruların aynısını sorun.