IAB Tech Lab, ajanlar arası reklam satın alma için OpenProposal taslağını içeren AAMP 3.0'ı yayınladı

Ne yayınlandı

22 Eylül 2026'da IAB Tech Lab, satıcı ajanlarının reklam ürünlerini makine tarafından okunabilir biçimde nasıl tanımlayacağına ve alıcı ajanların bu tanımları bir kampanya brifine göre nasıl puanlayacağına dair taslak bir spesifikasyon olan OpenProposal ile birlikte AAMP 3.0'ı yayınladı. Sürüme değinen bir dev.to gönderisine göre taslak üzerindeki kamu yorum süreci 22 Ekim 2026'ya kadar sürecek.

Aynı gönderi, IAB Australia'nın aynı hafta bir satıcı sandbox'ı açtığını ve katılımcıların gerçek harcamanın açıkça hariç tutulduğu sentetik verilerle keşif ve teklif akışlarını prova edebildiğini de bildiriyor.

Standartlaştırılan sorun

Gerekçe, gönderinin çerçevelendirdiği gibi ölçek: insan bir medya ekibi bir avuç RFP yanıtını değerlendirebilirken, binlerce yanıtla karşılaşan otomatik bir alıcı, her satıcı envanteri aynı şekilde kodlamadıkça hiçbir şeyi sıralayamaz. OpenProposal bu paylaşılan kodlamayı tanımlıyor ve onu Tech Lab'ın halihazırda sürdürdüğü altyapıya — AdCOM, OpenDirect ve Deals API — bağlıyor.

Taslak planlama aşamasını kapsıyor. Bir alıcı ajan bir brifle yola çıkar — kanal, coğrafya, bütçe aralığı, format sınırları, muhtemelen içerik taksonomisinin bir bölümü — ve satıcı ajanlar alıcının uygunluğa göre puanladığı yapılandırılmış ürün tanımlarıyla yanıt verir. AAMP 2.x altında yürütme zaten programatik garanti, tercihli anlaşmalar, private marketplace satırları ve açık exchange'i kapsıyor; hepsi paylaşılan alıcı ve satıcı SDK'ları üzerinden erişilebilir.

Eksik tutamak

Gönderinin en keskin eleştirisi karşılaştırmadan bir adım sonrasına işaret ediyor. Kabul edilen yol programatik olduğunda, yürütme hâlâ halihazırda çalışan hangi exchange'deyse oradaki bir OpenRTB bid request ve yanıtından ibaret. Bu mesaj çifti hangi teklifin kazandığını tanımlayan hiçbir şey içermiyor: bir teklif tanımlayıcısı yok, puanlama sırasında kullanılan brif sürümüne bir işaretçi yok ve istekteki video nesnesinin karşılaştırmanın dayandığı süre ve yerleşim semantiğini koruduğunu garanti eden hiçbir şey yok.

Yazar bunu komşu protokollerle karşılaştırıyor. AdCP her mesajın içinde bir sürüm üzerinde anlaşıyor ve uyuşmazlıkta tipli bir hata gösteriyor; AAMP 2.3 fiyat duyarlı yollara güven doğrulaması ekledi; buna karşılık OpenRTB güncelliğini yitirmiş snapshot'ını mesajın kendisi içinde değil hâlâ onboarding evrakında sabitliyor.

Somut bir başarısızlık senaryosu: video süresi

Gönderi bu boşluğu bağlı TV örneğiyle açıklıyor. OpenRTB 2.6, saniye cinsinden tam olarak kabul edilebilir sürelerden oluşan ve eski minduration ile maxduration aralığıyla birleştirilemeyen bir dizi olan rqddurs'ı getirdi; spor ve haber podları buna bağımlı çünkü 30 saniyelik bir yuvada 29 saniyelik bir spot yuvayı boş bırakır.

15 ve 30 saniyelik yerleşimler isteyen bir brif düşünün. Teklif karşılaştırması bir satıcı ürününü AdCOM yerleşim semantiği altında tam olarak bu sürelerde puanlar. Ancak alıcı ajan açık artırma çağrısını hâlâ 5 ile 60 saniye arası bir süre aralığı taşıyan bir şablondan oluşturursa, bir DSP meşru biçimde 6, 12 veya 45 saniyelik kreatifler döndürebilir — her biri brifin ve teklifin üzerinde anlaştığını ihlal ederken, aşağı akıştaki çeyrek ve pod mantığı hâlâ daha sıkı sözleşmeyi varsayar. Gönderinin önerdiği düzeltme, aralığı tam kabul edilen kümeyle — 15 ve 30 değerli rqddurs ile — değiştirmek ve aralık alanlarını tamamen bırakmaktır.

Açık artırma adımının doğrulanması

Gönderi ayrıca IAB Tech Lab'den bağımsız ve hiçbir spesifikasyon tarafından zorunlu tutulmayan bir bid request ve yanıt doğrulayıcısı olan rtblint'i anlatıyor. Daha geniş dersi şudur: OpenProposal yanıtını bir şemaya göre doğrulamak, iletilen impression nesnesi ayrı yazılmışsa hiçbir işe yaramaz. Yazar, doğrulamayı exchange'in gerçekte çalıştırdığı OpenRTB snapshot sürümüne sabitlemeyi, AdCOM yerleşim alanlarını (plcmt gibi) planlama sırasında puanlananlarla karşılaştırmayı ve VAST'a çözümlenen satırlar için ise ortaya çıkan tag'i özel VAST inceleme araçlarından geçirmeyi öneriyor.

Neden önemli

OpenProposal, medya satın almanın daha önce insanların teklifleri okumasını gerektiren kısmını otomatikleştiriyor ve bilinçli olarak açık artırma sınırında duruyor. Sonraki bir revizyon kabul edilen teklifle bid request arasında bir köprü eklemedikçe, planlama ve yürütme iki ayrı sözleşme olarak kalır ve karşılaştırma sırasında üzerinde anlaşılan kısıtlar açık artırma adımında sessizce kaybolabilir. 22 Ekim'de kapanan yorum penceresi bu köprüyü savunmak için doğal bir andır. Böyle bir köprü var olana dek, ajan pipeline'ları kuran ekipler iletilen her bid request'i, onu seçen tekliften ayrı bir sözleşme olarak kendi doğrulamasından geçirmelidir.