İsteği İşleme

Google, uygulamanıza bir teklif isteği gönderdiğinde gerçek zamanlı teklif etkileşimi başlar. Bu kılavuzda, uygulamanızı teklif isteğini işleyecek şekilde 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 bir OpenRTB `BidRequest` içindeki anlaşmalar arasında gezinme 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 verirken 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ıyla 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.

Hesabınız için yapılandırılan sınıflandırmadaki kategorilerle doldurulan BidRequest.bcat alanını inceleyerek bir gösterim için engellenen kategorileri 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": {
    ...
  }
}

Bağlamsal kategorileri belirleme

Teklif istekleri, bir gösterimin gerçekleştiği web sitesini veya uygulamayı açıklayan bağlamsal kategori alanları içerebilir. Bu alanlar da reklam kategorisi sınıflandırmalarını kullanır ancak reklam öğesiyle ilgili kısıtlamalar yerine gösterimin bağlamını temsil eder. Bu alanlar, BidRequest.bcat alanı ile aynı sınıflandırmayı kullanmayabilir. Google veya yayıncı bu içerik kategorilerini sağlayabilir. İçeriğe dayalı kategorileri kullanmak gösterim değerlendirmenizi, içeriğe dayalı hedeflemenizi ve marka güvenliğinizi iyileştirebilir.

Google tarafından algılanan içeriğe dayalı kategoriler

Google, site, uygulama veya sayfa için algılanan IAB içerik kategorileriyle aşağıdaki alanları doldurur:

Alan Açıklama
BidRequest.site.cat Siteyi açıklayan içerik kategorisi kimlikleri dizisi.
BidRequest.site.pagecat Sitenin mevcut sayfasını veya görünümünü açıklayan içerik kategorisi kimlikleri dizisi.
BidRequest.app.cat Uygulamayı açıklayan içerik kategorisi kimlikleri dizisi.
BidRequest.app.pagecat Uygulamanın mevcut sayfasını veya görünümünü açıklayan içerik kategorisi kimlikleri dizisi.

Belirli bir teklif isteği için bu alanlarda kullanılan tam sınıflandırmayı BidRequest.site.cattax veya BidRequest.app.cattax alanlarında bulabilirsiniz. İçeriğe dayalı kategori alanları, yayıncı tercihleri veya yasal düzenlemelerle ilgili endişeler nedeniyle her zaman doldurulmayabilir. Daha fazla bilgi için Google Ad Manager'da OpenRTB içeriğe dayalı kategorileri bölümünü inceleyin.

Yayıncı tarafından sağlanan sinyaller

Teklif istekleri, Google tarafından algılanan içeriğe dayalı kategorilerin yanı sıra gösterimin bağlamını da açıklayan, yayıncı tarafından sağlanan sinyaller de içerebilir. Google tarafından algılanan içeriğe dayalı kategorilerin aksine, bu sinyaller yalnızca yayıncı tarafından sağlandığında doldurulur. Bu sinyaller, content.data.segment ve content.genre gibi BidRequest.site.content ve BidRequest.app.content nesnelerinde gönderilir. content.data.segment girişleri için kullanılan taksonomi content.data.ext.segtax içinde raporlanır. Daha fazla bilgi için Gerçek Zamanlı Teklif Verme (GZT) için yayıncı tarafından sağlanan sinyaller (PPS) bölümüne bakın.

Sözlük dosyaları

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

Teklif veren URL makroları

İsteğe bağlı olarak, BidRequest bazı bilgiler makrolar kullanılarak teklif verme 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, istek sırasında teklif veren URL'si http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%, 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 ve sonuç şuna benzer:

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

Teklif isteğinin bir mobil cihazdan geldiğini belirtmek için 1, aksi takdirde 0 ile değiştirildi. Bu, BidRequest.device.devicetype değerine göre belirlenir. 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.
%%IS_CTV%%

Teklif isteğinin bir bağlı TV cihazından geldiğini belirtmek için 1, aksi takdirde 0 ile değiştirildi. Bu, BidRequest.device.devicetype değerine dayanır. Protobuf için bağlı TV cihazları CONNECTED_TV, CONNECTED_DEVICE veya SET_TOP_BOX'dir. Bunlar, JSON için 3, 6 veya 7 tam sayı değerlerine karşılık gelir.
%%HOSTED_MATCH_DATA%%

BidRequest.user.buyeruid değerine dayalı bir değerle değiştirildi.

%%MOBILE_IS_APP%%

Teklif isteğinin mobil uygulama envanteri için olduğunu belirtmek üzere 1 ile, aksi takdirde 0 ile değiştirilir. 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 bildirir:

mbappgewtimrzgyytanjyg4888888.com

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

Online bir kod çözücü kullanabilirsiniz ancak harfleri büyük harfe dönüştürmeniz ve sondaki 8 değerlerini = değerleriyle değiştirmeniz gerekir.

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

GEWTIMRZGYYTANJYG4======
 sonuçları: 
1-429610587
 429610587 dizesi, iOS uygulaması iFunny'nin uygulama kimliğidir.

Bir başka örneğe bakalım. Bildirilen URL: 

mbappgewtgmjug4ytmmrtgm888888.com
 Bu değerin kodunu çözme: 
GEWTGMJUG4YTMMRTGM======
 sonuçlanır: 
1-314716233
 Sonuç 314716233, iOS uygulaması TextNow'un uygulama kimliğidir.

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

Uygulama adını alma örneğini aşağıda bulabilirsiniz. Bildirilen URL şu şekildedir: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Bu değerin kodunu çözme: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 sonuçları: 
air.com.hypah.io.slither
 Sonuç, Android uygulaması slither.io ile eşdeğerdir.

Open Bidding alanları

Open Bidding'e katılan exchange ve ağ teklif verenlerine gönderilen teklif istekleri, standart gerçek zamanlı teklif vermeye katılan Authorized Buyers'a gönderilenlere benzer. Open Bidding müşterileri az sayıda ek alan alır ve mevcut birkaç alanın alternatif kullanımları olabilir. Bu politikalardan bazıları:

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

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

Örneğin, bu ifade aşağıdaki gibi bir biçimlendirmeyle 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çileri bildirme

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

BidRequest anlamak ve BidResponse oluşturmak için teknoloji tedarikçilerini beyan etmeyle ilgili iki farklı olasılığı bilmeniz gerekir:

  1. Bazı tedarikçilerin bildirilmesi gerekmez. Bu tedarikçiler Ad Manager Sertifikalı Harici Tedarikçiler listesinde yer alır.
  2. Diğer tedarikçiler yalnızca BidRequest içinde beyan edilmişlerse katılabilir:
    • 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 tedarikçiler, vendors.txt sözlük dosyasında listelenir.

Örnek teklif isteği

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

OpenRTB Protobuf

OpenRTB JSON

Teklif isteğini gerçek bir istekteki POST yükünden alacağınız gibi ikili forma dönüştürmek için aşağıdakileri yapabilirsiniz (C++ dilinde). 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
  }
}

Anında geri bildirim

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

Anında geri bildirim, daha önce verdiğiniz bir veya daha fazla teklifin sonucuna göre BidRequest.ext.bid_feedback 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. Anında geri bildirimi etkinleştirmek için hesap yöneticinizle iletişime geçin.

Teklif Yanıtı Geri Bildirimi'nde 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 taktiği temsil eden yeni bir hedefleme kimliği veya teklif kimliği ya da reklam öğesiyle ilişkili, yalnızca teklif veren tarafından bilinen meta veriler. Ayrıntılar için OpenRTB Uzantıları Protokol Arabelleği dosyasına bakın.

Authorized Buyers, bir teklif verene teklif isteği gönderdiğinde teklif veren BidResponse ile yanıt verir. Teklif veren, anlık geri bildirimi etkinleştirdiyse Authorized Buyers, sonraki teklif isteğinde BidFeedback mesajıyla yanıta ilişkin geri bildirim 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 alanıdır. Kodun anlamını creative-status-codes.txt dosyasında bulabilirsiniz. Teklifi kazanırsanız fiyat geri bildirimi özelliğini devre dışı bırakabileceğinizi unutmayın. Daha fazla bilgi için Kapsam dışında kalmayı seçme başlıklı makaleyi inceleyin.

Anında geri bildirim, teklif isteği kimliğini ve aşağıdakilerden birini içerir:

Açık artırma sonucu Anında geri bildirim
Alıcı teklif göndermedi. Hiç.
Alıcı, açık artırmaya ulaşmadan önce filtrelenen bir teklif gönderdi. Reklam öğesi durum kodu (creative-status-codes.txt).
Alıcı bir 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.

Uygulama gösterimi ve 83 reklam öğesi durum kodu için uygulama yayıncısı bir uyumlulaştırma şelalesi kullanıyor olabilir. Bu nedenle, kazanan teklif, yayıncının geri verilen gösterim şelale zincirindeki diğer taleplerle rekabet eder. 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ülen anında 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 anlık 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 bir fiyattır ve beklenen doluluk oranına göre ağırlıklandırılı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 düzende gösterilmiştir:
    \[C_1, C_2, …, C_n\]
  • Aşağıda, uyumlulaştırma zincirindeki BGBM'ler için karşılık gelen doluluk oranları gösterilmektedir:
    \[f_1, f_2, …, f_n\]
  • Aşağıda, verilen doluluk oranına göre uyumlulaştırma zinciri öğesinden \(i\)beklenen BGBM'yi ve 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\}\)
  • Kazanan nihai uyumlulaştırma zinciri şu şekilde olacaktır:
    \[\{C_1, C_2, …, C_K, W\}\]
    Burada \(W\) kazanan teklif, \(C_K > W >= C_{K+1}\)
  • Açılış fiyatı veya taban fiyat \(F\)ile gösterilir.
  • İkinci en yüksek teklif \(R\)olarak gösterilir.
Açık artırmayı 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ıkla \(\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 örneği

Bir yayıncının hem gerçek zamanlı teklif verme hem de SDK uyumlulaştırma zinciri kullandığını varsayalım:

SDK Uyumlulaştırma Zinciri Beklenen BGBM Doluluk Oranı
1. ağ \(C_1 = $3.00\) \(f_1 = 5\%\)
2. ağ \(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\%\)

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

RTB Açık Artırması BGBM
Açık Artırma Kazananı (W) 1,00 ABD doları
Açık artırmada ikinci olan (R) 0,05 ABD doları
Açılış Fiyatı / Taban Fiyat (F) 0 ABD doları
Açık artırmayı kazanan teklif

Aşağıda, kazanan 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 Olasılık
\(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		 Olasılık
\(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 Olasılık
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Olasılık
\(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 düzleştirme

Teklif düzleştirme, tek bir karmaşık BidRequest işlenerek uygulamanıza gönderilen birden fazla teklif isteğine dönüştürülmesini 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 düzleştirme ile her biçim, uygun faturalandırma kimlikleri gibi özelliklerin istekte belirtilen biçimle alakalı olduğu ayrı bir teklif isteğinde gönderilir.

Aşağıdaki biçimleri içeren teklif istekleri, ayrı teklif istekleri olarak düzleştirilir:

  • Banner
  • Video
  • Ses
  • Yerel biçim

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

Aşağıda, reklam biçimi düzleştirme olmadan basitleştirilmiş bir OpenRTB JSON teklif isteği örneği, eşdeğer bir düzleştirilmiş istek grubuyla karşılaştırmalı olarak gösterilmektedir:

Önceden düzleştirme

Düzleştirme sonrası

Fırsatlar

Belirli bir teklif veren için reklam fırsatı, herkesin katılabileceği açık artırmanın yanı sıra çeşitli anlaşma türleri için geçerli olabilir. Anlaşmalar için teklif düzleştirme sayesinde, herkesin katılabileceği açık artırma için bir teklif isteği ve her sabit fiyatlı anlaşma türü için bir teklif isteği gönderilir. Uygulamada, reklam kısıtlamaları açık artırmalar ve sabit fiyatlı fırsat türleri arasında farklılık gösterebilir. Örneğin, hem herkesin katılabileceği açık artırmada hem de sabit fiyatlı fırsatta kullanılabilen belirli bir 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, herkesin katılabileceği açık artırma ve sabit fiyatlı fırsat için 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 (true VEYA false)
Düzleştirilmemiş orijinal istek 15 true
Düzleştirilmiş 1. istek: Atlanamayan 15 false
Düzleştirilmiş istek #2: Atlanabilir 60 true

Atlanabilir video süresi teklif isteği düzleş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ürenin 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ürelere sahip hem atlanabilir hem de atlanamayan video reklamlara izin verdiğinde skip, true olarak ayarlanır ve maxduration, atlanabilir ve atlanamayan reklam kısıtlamaları arasında daha kısa olan süreye ayarlanır.

Video bölümleri

Birden fazla reklam fırsatı içeren bir video kapsülü için teklif istekleri, her teklif isteği bu kapsüldeki tek bir reklam fırsatı için olacak şekilde düzleştirilir. 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 sunan üçüncü taraf satıcıları belirtmenize olanak tanır.

Bir yayıncının teklif isteğinde Açık Ölçüm'ü destekleyip desteklemediğini, reklam fırsatının Publisher-excludable creative attributes (Yayıncı tarafından hariç tutulabilen reklam öğesi özellikleri) bölümünde 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ş reklamı videosu

OpenRTB Protobuf

OpenRTB JSON

Uygulama içi doğal

OpenRTB Protobuf

OpenRTB JSON

Web videosu

OpenRTB Protobuf

OpenRTB JSON

Exchange teklif vereni için mobil web banner'ı

OpenRTB Protobuf

OpenRTB JSON

Çok formatlı doğal ve video reklamlar

OpenRTB Protobuf

OpenRTB JSON