İsteği İşleme

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

İsteği ayrıştırma

Google, bir HTTP POST isteğinin yükü olarak OpenRTB JSON veya Protobuf biçimlerinde serileştirilmiş bir teklif isteği 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'ü almak için bu isteği ayrıştırmanız gerekir. Protobuf biçimini kullanıyorsanız Referans verileri sayfasından openrtb.proto ve openrtb-adx.proto dosyalarını indirip BidRequest iletisini ayrıştırmak için kullanılabilecek bir kitaplık oluşturmak üzere bu dosyaları kullanmanız gerekir. Örneğin, aşağıdaki C++ kodu, bir dizedeki POST yükü verilen 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'yi aldıktan sonra, ihtiyacınız olan alanları ayıklayıp yorumlayarak bir nesne olarak kullanabilirsiniz. Örneğin, C++'ta bir OpenRTB "BidRequest"indeki fırsatlar arasında iterasyon yapmak 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, uygun tüm alıcıların faturalandırma kimlikleriyle 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ıyla 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ğine birden fazla faturalandırma kimliği dahil edilmişse teklifinizi ilişkilendirmek istediğiniz alıcının faturalandırma kimliğini BidResponse.seatbid.bid.ext.billing_id alanıyla belirtmeniz gerekir.

Sözlük dosyaları

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

Teklif veren URL makroları

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

MakroAçıklama
%%GOOGLE_USER_ID%%

BidRequest.user.id bölümünde bulunan Google kullanıcı kimliğiyle değiştirilir. Ö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 ve

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

Teklif isteğinin mobil cihazdan geldiğini belirtmek için 1 ile değiştirilir. Aksi takdirde 0 ile değiştirilir. 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 ile değiştirilir. Aksi takdirde 0 ile değiştirilir. Bu, BidRequest.imp.video değerinin teklif isteğinde doldurulup doldurulmadığına bağlıdır.
%%HOSTED_MATCH_DATA%%

BidRequest.user.buyeruid değerine göre bir değerle değiştirilir.

%%MOBILE_IS_APP%%

Teklif isteğinin mobil uygulama envanteri için olduğunu belirtmek üzere 1 ile değiştirilir. Aksi takdirde 0 ile değiştirilir. Bu, BidRequest.app değerinin 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ış (gewtimrzgyytanjyg4888888) kısmının kodunu çözmek için 32'lik taban kod çözücü kullanın.

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

Bu değerin kodunu çözelim: 

GEWTIMRZGYYTANJYG4======
 sonuçlanır: 
1-429610587
 429610587 dizesi, iOS uygulaması iFunny için uygulama kimliğidir.

Başka bir örnek verelim. Bildirilen URL: 

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

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

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

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Bu değerin kodunu çözme: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 sonuçlanır: 
air.com.hypah.io.slither
 Sonuç, slither.io adlı Android uygulamasına karşılık gelir.

Open Bidding alanları

Open Bidding'e katılan exchange ve ağ teklif verenlere gönderilen teklif istekleri, standart gerçek zamanlı teklif vermeye katılan Authorized Buyers'ın isteklerine benzer. Open Bidding müşterilerine az sayıda ek alan sunulur ve mevcut alanların birkaçının alternatif kullanımları olabilir. Bu politikalar aşağıdakileri içerir:

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 eğik çizgilerle ayrılmış şekilde içerir.

Örneğin, bu şuna benzer bir biçimlendirmeyle görünür: /1234/cruises/mars.
BidRequest.user.data.segment

Yayıncıdan exchange teklif verene 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 sunma gibi hizmetler sunan teknoloji tedarikçileri, 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 denetlediği tedarikçi firmalara izin verilir.

BidRequest'ü anlamak ve BidResponse'unuzu oluşturmak için teknoloji tedarikçi firmalarını bildirmeyle ilgili iki farklı seçeneği bilmeniz gerekir:

  1. Bazı tedarikçi firmaların bildirilmesi gerekmez. Bu tedarikçi firmalar Ad Manager Onaylı Harici Tedarikçiler bölümünde listelenir.
  2. Diğer tedarikçiler yalnızca BidRequest içinde tanımlanmışsa katılabilir:
    • BidRequest alanındaki BidRequest.imp.ext.allowed_vendor_type alanı, satıcının hangi tedarikçilere izin verdiğini belirtir. allowed_vendor_type içinde gönderilecek tedarikçi firmalar, vendors.txt sözlük dosyasında listelenir.

Örnek teklif isteği

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

OpenRTB Protobuf

OpenRTB JSON

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

Gerçek zamanlı geri bildirim

Gerçek zamanlı geri bildirim, Authorized Buyers'ın yanı sıra Open Bidding kullanan exchange'ler ve ağlar tarafından 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ığı veya açık artırmayı kazanmak için gereken minimum teklif gibi ayrıntıları bulmak için kullanılabilir. Gerçek zamanlı 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 verenin bildiği ve hata ayıklama işlemine yardımcı olabilecek rastgele verilerdir. Örneğin: yeni bir taktiği temsil eden yeni bir hedefleme kimliği veya teklif verme kimliği ya da yalnızca teklif verenin bildiği, 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 bir teklif isteğinde yanıtla ilgili geri bildirimi BidFeedback mesajında 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;

  // The minimum bid value necessary to have won the server-side component of
  // the overall auction given that there was also an interest group bidding
  // component to the overall auction which ran using the Protected Audience
  // API. The value is expressed in CPM of the buyer account currency. The
  // minimum bid to win for the overall auction, including bids from the
  // server-side and the on-device interest group components, is populated in
  // the minimum_bid_to_win field of the same BidFeedback object.
  optional double sscminbidtowin = 14;

  // 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;

  // Possible types of bid response feedback objects.
  enum FeedbackType {
    FEEDBACK_TYPE_UNSPECIFIED = 0;

    // Feedback for a bid that was submitted on a bid response.
    BID_FEEDBACK = 1;

    // Feedback for an interest group buyer submitted on a bid response to
    // particpate in an interest group bidding component of the auction run
    // using the Protected Audience API.
    INTEREST_GROUP_BUYER_FEEDBACK = 2;
  }

  // The type of the BidFeedback message. Google will send separate
  // BidFeedback objects for:
  // a) Each bid submitted on a bid response
  // b) Each buyer submitted on a bid response to particpate in an interest
  // group bidding component of the auction run using the Protected Audience
  // API.
  optional FeedbackType feedbacktype = 15;

  // Origin of an interest group buyer that was included in the bid response.
  // This field is populated only for feedback where a bidder opted in an
  // interest group buyer to participate in the interest group bidding
  // component of the overall auction run using the Protected Audience API.
  // To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
  // To learn more about interest group bidding and the Protected Audience
  // API, see
  // https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
  optional string buyerorigin = 16;

  // The status code for the submitted interest group buyer. This field is
  // only populated in the feedback for an interest group buyer that a bidder
  // requested to enter into the interest group auction through the bid
  // response. Individual creative status codes of bids submitted by the buyer
  // in the on-device interest group auction are not available. See
  // https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
  // for a list of interest group buyer status codes.
  optional int32 igbuyerstatus = 17;
}

Bu mesajda kontrol etmeniz gereken ilk alan bid_feedback.creative_status_code'tü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 Kapsam dışında kalmayı seçme başlıklı makaleyi inceleyin.

Gerçek zamanlı geri bildirim, teklif isteği kimliğini ve aşağıdakilerden birini içerir:

Açık artırma sonucu Gerçek zamanlı 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ı teklif gönderdi ancak açık artırmayı kaybetti. Reklam öğesi durum kodu 79 (açık artırmada tekliften daha yüksek teklif verildi).
Alıcı, açık artırmayı kazanan bir teklif göndermiştir. Açık artırma fiyatı ve reklam öğesi durum kodu 1.

Bir 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 gönderme şelalesi zincirindeki diğer taleple rekabet etmiş olabilir. Teklif verirken sampled_mediation_cpm_ahead_of_auction_winner'yi nasıl kullanacağınızı öğrenin.

Örnek

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

OpenRTB Protobuf

OpenRTB JSON

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

İlk fiyat açık artırmasında teklif verdikten sonra, teklif açık artırmadan filtrelenmemişse 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 mantığınıza bilgi vermek için kullanılabilir.

  • minimum_bid_to_win: Gerçek zamanlı teklif açık artırmasını kazanmak için yerleştirilebilecek minimum teklif. Açık artırmayı kazandıysanız bu, kazanırken verebilecek en düşük tekliftir. Açık artırmayı kaybettiyseniz kazanan teklif budur.
  • sampled_mediation_cpm_ahead_of_auction_winner: Uyumlulaştırma zincirinde başka ağlar varsa bu alanın değeri, uygun uyumlulaştırma ağlarından birinde açık artırma kazananından daha yüksek olan ve beklenen doluluk oranına göre ağırlıklandırılmış bir örnek teklifi temsil eden bir fiyattır. Uyumlulaştırma zincirindeki ağların hiçbirinin doldurulmasının beklenmediği veya yayıncının SDK uyumlulaştırmasını kullanmadığı durumlarda 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 amacıyla 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österilmektedir:
    \[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 doldurma 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\) with probability \(f_i\); \(0\) with probability \(1 - f_i\}\)
  • Kazanan nihai uyumlulaştırma zinciri şu şekilde olacaktır:
    \[\{C_1, C_2, …, C_K, W\}\]
    Burada \(W\) kazanan tekliftir ve \(C_K > W >= C_{K+1}\)
  • Açılış fiyatı veya taban, \(F\)olarak gösterilir.
  • İkinci teklif \(R\)olarak 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ık \(\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ırması 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\%\)

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ı (K) 1,00 ABD doları
Açık Artırma İKİNCİSİ (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 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, kaybeden 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 düzleştirme, tek bir karmaşık BidRequest öğesinin 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 orijinalin 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 özelliğiyle 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, farklı teklif isteklerine 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 grubuna kıyasla reklam biçimi düzleştirmesi içermeyen basitleştirilmiş bir OpenRTB JSON teklif isteği gösterilmektedir:

Önceden düzleştirme

Düzleştirme sonrası

Fırsatlar

Belirli bir teklif veren için bir reklam fırsatı, herkesin katılabileceği açık artırmaya ek olarak çeşitli anlaşma türleri için de geçerli olabilir. Anlaşmalar için teklif düzleştirme özelliğiyle, herkese açık 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ırma ve sabit fiyatlı anlaşma türleri arasında farklılık gösterebilir. Örneğin, hem açık artırma hem de sabit fiyatlı anlaşma için kullanılabilen belirli bir video reklam fırsatı için teklif veren, her biri için farklı teklif istekleri alır. Bu istekler, maksimum reklam süresi ve atlanabilir reklamlara izin verilip verilmediği gibi kısıtlamalarda farklılık gösterebilir. Sonuç olarak, reklam fırsatına uygulanan düzleştirme, herkesin katılabileceği açık artırma ve sabit fiyatlı anlaşma için reklam kısıtlamalarını daha kolay anlamanıza olanak tanır.

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ştirmeyi kullanır.

Aşağıda, atlanamayan reklamın maksimum süresi 15 ve atlanabilir reklamın maksimum süresi 60 olduğunda video envanterin 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
Birleştirilmiş istek #1: Atlanamayan 15 false
Birleş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:

  • İstekte videoya izin veriliyor.
  • Hem atlanabilir hem de atlanamayan videolara izin verilir ve bu iki videonun maksimum süreleri 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 veriyorsa skip, true olarak ayarlanır ve maxduration, atlanabilir ve atlanamayan reklam kısıtlamaları arasında hangisi daha kısaysa o süreye ayarlanır.

Video kapsülleri

Birden fazla reklam fırsatı içeren bir video kapsülüne yönelik teklif istekleri birleştirilir. Böylece her teklif isteği, ilgili kapsüldeki tek bir reklam fırsatı için olur. Bu sayede belirli bir kapsül için birden fazla reklam fırsatı için teklif verebilirsiniz.

Open Measurement

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

Bir yayıncının, teklif isteğinde Open Measurement'ı destekleyip desteklemediğini belirlemek için 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 edebilirsiniz. Bu, biçime bağlı olarak Banner veya Video için battrözelliğinin altında bulunur.

Open Measurement sinyalleri içeren teklif isteklerinin nasıl yorumlanacağı hakkında daha fazla bilgi için Open Measurement SDK'sı Yardım Merkezi makalesine bakın.

Ö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 yerel

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

OpenRTB Protobuf

OpenRTB JSON