İsteği İşleme

Google, uygulamanıza bir teklif isteği gönderdiğinde gerçek zamanlı teklif verme etkileşimi başlar. Bu kılavuzda, teklif isteğini işlemek için uygulamanızı nasıl kodlayacağınız açıklanmaktadır.

Ayrıştırma isteği

Google, OpenRTB JSON veya Protobuf biçimlerinde serileştirilmiş bir teklif isteğini HTTP POST isteğinin yükü olarak eklenmiş şekilde gönderir. Alınan biçim, uç noktanızın yapılandırmasına bağlıdır. Örnek için Örnek teklif isteği bölümüne bakın.

Serileştirilmiş BidRequest değerini almak için bu isteği ayrıştırmanız gerekir. Protobuf biçimini kullanıyorsanız openrtb.proto ve openrtb-adx.proto dosyalarını referans verileri sayfasından indirmeniz ve BidRequest mesajını ayrıştırmak için kullanılabilecek bir kitaplık oluşturmak üzere kullanmanız gerekir. Örneğin, aşağıdaki C++ kodu, bir dizede POST yükü verilmiş bir isteği ayrıştırır: 

string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
  // Process the request.
}

BidRequest elde ettikten sonra bunu bir nesne olarak kullanabilir, ihtiyacınız olan alanları ayıklayıp yorumlayabilirsiniz. Örneğin, C++'ta OpenRTB `BidRequest` içindeki fırsatları yinelemek aşağıdaki gibi görünebilir:

for (const BidRequest::Imp::Pmp::Deal& deal : pmp.deals()) {
  DoSomething(deal.id(), deal.wseat());
}

Faturalandırma kimlikleri

Bir yayıncının reklam envanteri, ön hedefleme yapılandırmalarınızdan biri veya daha fazlası tarafından hedeflendiğinde teklif isteği alırsınız. BidRequest.imp.ext.billing_id alanı, uygun alıcıların faturalandırma kimlikleri ve alakalı ön hedefleme yapılandırmalarıyla doldurulur. Ayrıca, anlaşma envanteri için BidRequest.imp.pmp.deal.ext.billing_id kullanarak ilgili alıcılarla ilişkili faturalandırma kimliklerini bulabilirsiniz. Teklif verilirken yalnızca teklif isteğine dahil edilen alıcıların faturalandırma kimlikleri belirtilebilir.

Teklif isteğinde birden fazla faturalandırma kimliği varsa teklifinizi ilişkilendirmek istediğiniz alıcının faturalandırma kimliğini BidResponse.seatbid.bid.ext.billing_id alanı ile belirtmeniz gerekir.

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

Engellenen kategorileri belirleme

Teklif verdiğinizde, dahil edilen reklam öğesinde yayıncının engellediği kategoriler algılanmamış olmalıdır. Aksi takdirde teklif, açık artırmadan filtrelenir.

Bir gösterim için engellenen kategorileri, hesabınız için yapılandırılan taksonomideki kategorilerle doldurulan BidRequest.bcat alanını inceleyerek bulabilirsiniz.

Aşağıdaki örnekte, yapılandırılmış bir reklam kategorisi sınıflandırmasına göre engellenen kategoriler gösterilmektedir:

IAB İçerik Sınıflandırması 1.0

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

Sözlük dosyaları

Teklif isteğinde, referans verileri sayfasında bulunan sözlük dosyalarında tanımlanan tanımlayıcılar kullanılır.

Teklif veren URL makroları

İsteğe bağlı olarak, BidRequest öğesindeki bazı bilgiler makrolar kullanılarak teklif uç noktası URL'lerine eklenebilir. Bir veya daha fazla makro içeren bir uç nokta URL'si yapılandırırsanız bu bilgiler teklif isteğinde mevcutsa makrolar genişletilir. Örneğin, BidRequest içindeki bilgilere göre yük dengeleme yapmak istiyorsanız bu özellikten yararlanabilirsiniz. Yeni makrolar için destek isteğinde bulunmak üzere hesap yöneticinizle iletişime geçin.

MakroAçıklama
%%GOOGLE_USER_ID%%

BidRequest.user.id içinde bulunan Google kullanıcı kimliğiyle değiştirildi. Örneğin, teklif veren URL'si http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%, istek sırasında http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl gibi bir URL ile değiştirilir.

Google kullanıcı kimliği bilinmiyorsa boş dize kullanılır. Sonuç,

http://google.bidder.com/path?gid=
%%HAS_MOBILE%%

Teklif isteğinin bir mobil cihazdan geldiğini belirtmek için 1 ile, aksi takdirde 0 ile değiştirildi. Bu, BidRequest.device.devicetype değerine dayanır. Mobil cihazlar HIGHEND_PHONE (4) veya Tablet (5) ile gösterilir.
%%HAS_VIDEO%%

Teklif isteğinin video envanteri içerdiğini belirtmek için 1, aksi takdirde 0 ile değiştirildi. Bu, teklif isteğinde BidRequest.imp.video değerinin doldurulup doldurulmadığına bağlıdır.
%%HOSTED_MATCH_DATA%%

BidRequest.user.buyeruid temel alınarak belirlenen bir değerle değiştirilir.

%%MOBILE_IS_APP%%

Teklif isteğinin mobil uygulama envanteri için olduğunu belirtmek üzere 1 ile, aksi takdirde 0 ile değiştirildi. Bu, BidRequest.app alanının doldurulup doldurulmadığına bağlıdır.

İşlem URL'sinden mobil uygulama kimliğini bulma

Mobil uygulama işlemleri, aşağıdaki gibi görünen URL'leri raporlar:

mbappgewtimrzgyytanjyg4888888.com

Dizenin kalın yazılmış kısmını (gewtimrzgyytanjyg4888888) çözmek için 32 tabanlı kod çözücü kullanın.

Online bir kod çözücü kullanabilirsiniz ancak harfleri büyük yazmanız ve sondaki 8 karakterlerini = değerleriyle değiştirmeniz gerekir.

Bu değeri çözdüğümüzde: 

GEWTIMRZGYYTANJYG4======
 sonucunu verir: 
1-429610587
 429610587 dizesi, iOS uygulaması iFunny'nin uygulama kimliğidir.

Başka bir örnek gösterelim. Bildirilen URL: 

mbappgewtgmjug4ytmmrtgm888888.com
 Bu değerin kodu çözüldüğünde: 
GEWTGMJUG4YTMMRTGM======
 sonucunu verir: 
1-314716233
 Sonuç 314716233, iOS uygulaması TextNow'ın uygulama kimliğidir.

İşlem URL'sinden mobil uygulama adını bulma

Uygulama adını alma örneğini burada görebilirsiniz. Bildirilen URL şu şekildedir: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Bu değerin kodu çözüldüğünde: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 sonucunu verir: 
air.com.hypah.io.slither
 Sonuç, Android uygulaması slither.io ile eşleşiyor.

Open Bidding alanları

Open Bidding'e katılan exchange ve ağ teklif verenlere gönderilen teklif istekleri, standart gerçek zamanlı teklif verme işlemine katılan Authorized Buyers'ın teklif isteklerine benzer. Open Bidding müşterileri, az sayıda ek alan alacak ve mevcut alanlardan bazıları alternatif kullanımlara sahip olabilecek. Bu politikalara şunlar dahildir:

OpenRTB Ayrıntılar
BidRequest.imp.ext.dfp_ad_unit_code

Yayıncının Ad Manager ağ kodunu ve ardından reklam birimi hiyerarşisini içerir. Reklam birimi hiyerarşisi, eğik çizgilerle ayrılır.

Örneğin, bu ifade şu biçimlendirmeye benzer şekilde görünür: /1234/cruises/mars.
BidRequest.user.data.segment

Yayıncıdan exchange teklif verenine gönderilen yinelenen anahtar/değer çiftleri.

BidRequest.user.data.name, “Publisher Passed” olarak ayarlandığında değerlerin yayıncı tarafından gönderilen anahtar/değer çiftleri olduğunu belirleyebilirsiniz.

İzin verilen tedarikçi firmaları bildirme

Araştırma, yeniden pazarlama ve reklam yayınlama gibi hizmetler sağlayan teknoloji tedarikçileri, alıcılar ve satıcılar arasındaki etkileşimde rol oynayabilir. Yalnızca Google'ın Authorized Buyers etkileşimlerine katılım için incelediği sağlayıcılara izin verilir.

BidRequest anlamak ve BidResponse oluşturmak için teknoloji tedarikçilerini bildirme konusunda iki farklı olasılık olduğunu bilmeniz gerekir:

  1. Bazı tedarikçilerin bildirilmesi gerekmez. Bu tedarikçiler Ad Manager Onaylı Harici Tedarikçiler listesinde yer alır.
  2. Diğer sağlayıcılar yalnızca BidRequest:
    • BidRequest alanında, BidRequest.imp.ext.allowed_vendor_type alanı satıcının izin verdiği tedarikçileri belirtir. allowed_vendor_type içinde gönderilecek satıcılar, vendors.txt sözlük dosyasında listelenir.

Örnek teklif isteği

Aşağıdaki örnekler, Protobuf ve JSON isteklerinin insan tarafından okunabilir örneklerini temsil etmektedir.

OpenRTB Protobuf

OpenRTB JSON

Teklif isteğini, gerçek bir istekteki POST yükünden alacağınız gibi ikili biçime dönüştürmek için aşağıdakileri yapabilirsiniz (C++'da). Ancak bunun OpenRTB JSON için geçerli olmadığını unutmayın.

string text_format_example = /* example from above */;
BidRequest bid_request;
if (TextFormat::ParseFromString(text_format_example, &bid_request)) {
  string post_payload;
  if (bid_request.SerializeToString(&post_payload)) {
    // post_payload is a binary serialization of the protocol buffer
  }
}

Anlık geri bildirim

Gerçek zamanlı geri bildirim, Authorized Buyers'ın yanı sıra Open Bidding'i kullanan exchange'ler ve ağlar tarafından da kullanılabilir.

Anlık geri bildirim, daha önce verdiğiniz bir veya daha fazla teklifin sonucuna göre BidRequest.ext.bid_feedback alanını doldurur ve teklifin açık artırmayı kazanıp kazanmadığı ya da açık artırmayı kazanmak için gereken minimum teklif gibi ayrıntıları bulmak için kullanılabilir. Anlık geri bildirim özelliğini etkinleştirmek için hesap yöneticinizle iletişime geçin.

Teklif yanıtı geri bildiriminde gönderilen varsayılan alanlara ek olarak, BidResponse.seatbid.bid.ext.event_notification_token alanını kullanarak teklif yanıtında özel veriler de gönderebilirsiniz. event_notification_token, yalnızca teklif veren tarafından bilinen ve hata ayıklamaya yardımcı olabilecek rastgele verilerdir. Örneğin: yeni bir hedefleme kimliği veya yeni bir taktiği temsil eden teklif kimliği ya da yalnızca teklif veren tarafından bilinen, reklam öğesiyle ilişkili meta veriler. Ayrıntılar için OpenRTB Uzantıları Protokol Arabellek dosyasına bakın.

Authorized Buyers bir teklif verene teklif isteği gönderdiğinde teklif veren BidResponse ile yanıt verir. Teklif verenin gerçek zamanlı geri bildirimi etkinse Authorized Buyers, sonraki teklif isteğinde yanıta ilişkin geri bildirimi BidFeedback mesajıyla gönderir:

message BidFeedback {
  // The unique id from BidRequest.id.
  optional string request_id = 1;

  // The status code for the ad. See creative-status-codes.txt in the
  // technical documentation for a list of ids.
  optional int32 creative_status_code = 2;

  // Deprecated. This field is not populated and will be removed after March,
  // 2025. If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional double price = 3 [deprecated = true];

  // The minimum bid value necessary to have won the auction, in your account
  // currency. If your bid won the auction, this is the second highest bid
  // that was not filtered (including the floor price). If your bid didn't win
  // the auction, this is the winning candidate's bid. This field will only be
  // populated if your bid participated in a first-price auction, and will not
  // be populated if your bid was filtered prior to the auction.
  optional double minimum_bid_to_win = 6;

  // Billable event rate multiplier that was applied to this bid during
  // ranking. The adjustment reflects the likelihood that your bid would
  // generate a billable event (namely, the ad renders successfully) if it won
  // the auction, relative to the probability that other bids generate a
  // billable event if they won the auction. This adjustment can be larger or
  // smaller than 1. This affects the final ranking in the auction only; in
  // particular, this multiplier does not affect the payment or whether the
  // bid clears any floor price.
  optional float billable_event_rate_bid_adjustment = 13 [default = 1];

  // When a publisher uses an RTB auction and waterfall-based SDK mediation on
  // the same query, the winner of the real-time auction must also compete in
  // a mediation waterfall (which is ordered by price) to win the impression.
  // If the bid participated in the auction and there was no waterfall, the
  // value of this field is 0. If the bid participated in the auction and
  // there was a waterfall, the value of this field is a price representing a
  // sample bid from the eligible mediation networks that were higher than the
  // auction winner, weighted by expected fill rate. This field can be used
  // in conjunction with minimum_bid_to_win to train bidding models. The CPM
  // is in your account currency.
  optional double sampled_mediation_cpm_ahead_of_auction_winner = 8;

  message EventNotificationToken {
    // The contents of the token.
    optional string payload = 1;
  }

  // The token included in the corresponding bid.
  optional EventNotificationToken event_notification_token = 4;

  // The creative ID included in the corresponding bid.
  optional string buyer_creative_id = 5;
}

Bu mesajda kontrol etmeniz gereken ilk alan bid_feedback.creative_status_code'dır. Kodun anlamını creative-status-codes.txt dosyasında bulabilirsiniz. Teklifi kazanırsanız fiyat geri bildirimini devre dışı bırakabileceğinizi unutmayın. Daha fazla bilgi için Nasıl devre dışı bırakılır? başlıklı makaleyi inceleyin.

Gerçek zamanlı geri bildirimde teklif isteği kimliği ve aşağıdakilerden biri yer alır:

Açık artırma sonucu Anlık geri bildirim
Alıcı teklif göndermedi. Hiç.
Alıcı, açık artırmaya ulaşmadan önce filtrelenen bir teklif gönderdi. Reklam öğesi durumu kodu (creative-status-codes.txt).
Alıcı teklif gönderdi ancak açık artırmayı kaybetti. Reklam öğesi durum kodu 79 (açık artırmada daha yüksek teklif verildi).
Alıcı, açık artırmayı kazanan bir teklif gönderdi. Temizleme fiyatı ve reklam öğesi durum kodu 1.

83 reklam öğesi durum koduna sahip bir uygulama gösterimi için uygulama yayıncısı, uyumlulaştırma şelalesi kullanıyor olabilir. Bu nedenle, kazanan teklif, yayıncının geri gönderme şelalesi zincirindeki diğer taleple rekabet etmiş olabilir. Teklif verirken sampled_mediation_cpm_ahead_of_auction_winner özelliğini nasıl kullanacağınızı öğrenin.

Örnek

Aşağıda, desteklenen protokollerde görünen anlık geri bildirim örneği verilmiştir:

OpenRTB Protobuf

OpenRTB JSON

İlk fiyat açık artırmaları için teklif modeli oluşturma

İlk fiyat açık artırmasında teklif verdikten sonra, teklif açık artırmadan filtrelenmediyse minimum_bid_to_win ve sampled_mediation_cpm_ahead_of_auction_winner alanlarını içeren gerçek zamanlı geri bildirim alırsınız. Bu sinyaller, gösterimi kazanmak için teklifinizin ne kadar daha yüksek veya düşük olabileceği konusunda teklif verme mantığınızı bilgilendirmek için kullanılabilir.

  • minimum_bid_to_win: Gerçek zamanlı teklif açık artırmasını kazanmak için verilebilecek minimum teklif. Açık artırmayı kazandıysanız bu değer, kazanmaya devam ederken verebileceğiniz en düşük teklif olur. Açık artırmayı kaybettiyseniz bu, kazanan teklif olur.
  • sampled_mediation_cpm_ahead_of_auction_winner: Uyumlulaştırma zincirinde başka ağlar varsa bu alanın değeri, açık artırma kazananından daha yüksek olan uygun uyumlulaştırma ağlarından birinin örnek teklifini temsil eden ve beklenen doluluk oranına göre ağırlıklandırılmış bir fiyattır. Uyumlulaştırma zincirindeki ağlardan hiçbirinin doldurması beklenmiyorsa veya yayıncı SDK uyumlulaştırması kullanmıyorsa bu değer 0 olarak ayarlanır.

İşleyiş şekli

minimum_bid_to_win ve sampled_mediation_cpm_ahead_of_auction_winner için olası değerleri belirlemek üzere kullanılan hesaplamaları açıklamak için öncelikle aşağıdakileri tanımlamamız gerekir:

  • Aşağıda, uyumlulaştırma zincirindeki BGBM'ler azalan sırada gösterilmektedir:
    \[C_1, C_2, …, C_n\]
  • Aşağıda, aracılık zincirindeki BGBM'ler için karşılık gelen doldurma oranları gösterilmektedir:
    \[f_1, f_2, …, f_n\]
  • Aşağıda, verilen doldurma oranına göre, beklenen BGBM'yi ve bunun aracılık zinciri öğesinden \(i\)elde edilme olasılığını belirlemek için kullanılan bir işlev verilmiştir:
    \(X_i = \{C_i\) olasılığıyla \(f_i\); \(0\) olasılığıyla \(1 - f_i\}\)
  • Son kazanan uyumlulaştırma zinciri şu şekilde olacaktır:
    \[\{C_1, C_2, …, C_K, W\}\]
    Burada \(W\) kazanan teklif ve \(C_K > W >= C_{K+1}\)
  • Açılış fiyatı veya taban fiyat \(F\)olarak gösterilir.
  • İkinci en yüksek teklif \(R\)ile gösterilir.
Açık artırma kazananı için hesaplamalar
Alan Hesaplama
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) olasılığıyla \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
\(1 <= i <= K\)için.
Açık artırmayı kaybeden için hesaplamalar
Alan Hesaplama
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

Basit bir uyumlulaştırma zinciri içeren örnek

Bir yayıncının hem gerçek zamanlı teklif vermeyi hem de SDK uyumlulaştırma zincirini aşağıdaki gibi kullandığını varsayalım:

SDK uyumlulaştırma zinciri Beklenen BGBM Doluluk Oranı
Ağ 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
Ağ 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
Ağ 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
Network 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

RTB açık artırmasının sonucu olarak aşağıdakileri varsayalım:

GZT Açık Artırması BGBM
Açık Artırma Kazananı (W) 1,00 ABD doları
Açık Artırma İkincisi (R) 0,05 ABD doları
Açılış fiyatı / taban fiyat (F) 0 ABD doları
Açık artırmayı kazanan teklif

Aşağıda, kazanılan bir teklif için minimum_bid_to_win ve sampled_mediation_cpm_ahead_of_auction_winner değerlerinin ve olasılıklarının nasıl hesaplandığına dair bir örnek verilmiştir.

minimum_bid_to_win Probability
\(max(F, R, C_3) = $0.50\) \(f_3 = 80\%\)
\(max(F, R, C_4) = $0.10\) \((1-f_3) \cdot f_4 = 17\%\)
\(max(F, R, 0) = $0.05\) \((1-f_3) \cdot (1-f_4) = 3\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probability
\(C_1 = $3.00\) \(f_1 \div (1-(1-f_1) \cdot (1-f_2)) =~ 10.5\%\)
\(C_2 = $2.00\) \(((1-f_1) \cdot f_2) \div (1-(1-f_1) \cdot (1-f_2)) =~ 89.5\%\)
Açık artırmayı kaybeden teklifler

Aşağıda, kaybedilen teklifler için minimum_bid_to_win ve sampled_mediation_cpm_ahead_of_auction_winner değerlerinin ve olasılıklarının nasıl hesaplandığına dair bir örnek verilmiştir.

minimum_bid_to_win Probability
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probability
\(C_1 = $3.00\) \(f_1 = 5\%\)
\(C_2 = $2.00\) \((1-f_1) \cdot f_2 =~ 42.8\%\)
\(0\) \((1-f_1) \cdot (1-f_2) =~ 52.2\%\)

Teklif birleştirme

Teklif birleştirme, tek bir karmaşık BidRequest öğesinin uygulamanıza gönderilen birden fazla teklif isteği olarak işlenmesini ifade eder. Bir teklif isteği düzleştirildiğinde, BidRequest.ext.google_query_id alanında aynı değere sahip oldukları için hangi teklif isteklerinin orijinal teklif isteğinin parçası olduğunu anlayabilirsiniz.

Teklif düzleştirme varsayılan olarak etkindir ancak devre dışı bırakmak isterseniz hesap yöneticinizle iletişime geçebilirsiniz.

Reklam biçimleri

Bazı reklam fırsatları birden fazla biçimi kabul edebilir. Teklif birleştirme ile her biçim, ayrı bir teklif isteğinde gönderilir. Bu teklif isteğinde, uygun faturalandırma kimlikleri gibi özellikler, istekte belirtilen biçimle alakalıdır.

Aşağıdaki biçimleri içeren teklif istekleri ayrı teklif istekleri halinde birleştirilir:

  • Banner
  • Video
  • Ses
  • Yerel biçim

Reklam biçimi düzleştirme örneği

Aşağıda, eşdeğer bir düzleştirilmiş istek grubuyla karşılaştırıldığında reklam biçimi düzleştirme içermeyen basitleştirilmiş bir OpenRTB JSON teklif isteğini gösteren bir örnek verilmiştir:

Önceden düzleştirme

Düzleştirme sonrası

Fırsatlar

Belirli bir teklif veren için reklam fırsatı, açık artırmaya ek olarak çeşitli anlaşma türleri için geçerli olabilir. Anlaşmalar için teklif düzleştirme özelliği kullanıldığında, açık artırma için bir teklif isteği, sabit fiyatlı anlaşmaların her türü için ise birer teklif isteği gönderilir. Uygulamada, reklam kısıtlamaları açık artırmalar ve sabit fiyatlı anlaşma türleri arasında farklılık gösterebilir. Örneğin, hem açık artırmada hem de sabit fiyatlı anlaşmada kullanılabilen belirli bir video reklam fırsatı için teklif veren, maksimum reklam süresi ve atlanabilir reklamlara izin verilip verilmediği gibi kısıtlamaların farklı olabileceği her biri için ayrı teklif istekleri alır. Sonuç olarak, reklam fırsatına uygulanan düzleştirme, açık artırma ve sabit fiyatlı anlaşmayla ilgili reklam kısıtlamalarını daha kolay ayırt etmenizi sağlar.

Atlanabilirlik ve Video Süresi

OpenRTB spesifikasyonunda, atlanabilir ve atlanamayan reklamların maksimum video sürelerini belirtmek için ayrı alanlar yoktur. Google'ın uygulaması, mevcut BidRequest.video.maxduration ve BidRequest.video.skip alanlarını kullanarak bunları ayırt etmek için teklif düzleştirme özelliğini kullanır.

Aşağıda, atlanamayan bir reklamın maksimum süresi 15 ve atlanabilir bir reklamın maksimum süresi 60 olduğunda video envanterinin nasıl düzleştirildiğine dair bir örnek verilmiştir.

Örnek max_ad_duration skip (doğru VEYA yanlış)
Düzleştirilmemiş orijinal istek 15 true
Birleştirilmiş istek #1: Atlanamayan 15 false
Birleştirilmiş istek #2: Atlanabilir 60 true

Atlanabilir video süresi teklif isteği birleştirme işlemi yalnızca aşağıdaki koşullar karşılandığında gerçekleşir:

  • İstek videoya izin veriyor.
  • Hem atlanabilir hem de atlanamayan videolara izin verilir ve ilgili iki maksimum süre değeri farklıdır.
  • Bu istek, Özel Açık Artırma veya Herkesin Katılabileceği Açık Artırma için uygundur.

Teknik hesap yöneticinizle iletişime geçerek bu tür bir düzleştirmeyi devre dışı bırakabilirsiniz. Devre dışı bırakıldığında ve yayıncı, atlanabilirliğe göre farklı maksimum sürelerle hem atlanabilir hem de atlanamayan video reklamlara izin verdiğinde skip, true olarak ayarlanır ve maxduration, atlanabilir ve atlanamayan reklam sınırlamaları arasında daha kısa olan süreye ayarlanır.

Video kapsülleri

Birden fazla reklam fırsatı içeren bir video kapsülü için teklif istekleri birleştirilir. Böylece her teklif isteği, söz konusu kapsüldeki ayrı bir reklam fırsatı için olur. Bu sayede, belirli bir kapsül için birden fazla reklam fırsatına teklif verebilirsiniz.

Open Measurement

Open Measurement, mobil uygulama ortamlarında yayınlanan reklamlar için bağımsız ölçüm ve doğrulama hizmetleri sağlayan üçüncü taraf tedarikçileri belirtmenize olanak tanır.

Bir yayıncının teklif isteğinde Açık Ölçüm'ü destekleyip desteklemediğini, reklam fırsatının yayıncı tarafından hariç tutulabilen reklam öğesi özelliklerinde bulunan OmsdkType: OMSDK 1.0 özelliğini hariç tutup tutmadığını kontrol ederek belirleyebilirsiniz. Bu, biçime bağlı olarak Banner veya Video için battr özelliği altında bulunur.

Open Measurement sinyalleri içeren teklif isteklerini yorumlama hakkında daha fazla bilgi için Open Measurement SDK Yardım Merkezi makalesini inceleyin.

Örnek teklif istekleri

Aşağıdaki bölümlerde, farklı reklam türleri için örnek teklif istekleri gösterilmektedir.

Uygulama banner'ı

OpenRTB Protobuf

OpenRTB JSON

Uygulama geçiş reklamı

OpenRTB Protobuf

OpenRTB JSON

Uygulama geçiş video reklamı

OpenRTB Protobuf

OpenRTB JSON

Uygulama yerel

OpenRTB Protobuf

OpenRTB JSON

Web videosu

OpenRTB Protobuf

OpenRTB JSON

Borsa teklif vereni için mobil web banner'ı

OpenRTB Protobuf

OpenRTB JSON

Çok formatlı doğal reklam ve video

OpenRTB Protobuf

OpenRTB JSON