İsteği İşleme

Gerçek zamanlı teklif etkileşimi, Google'ın en iyi yoludur. Bu kılavuzda, teklif isteğini işlemek için uygulamanızı nasıl kodlayacağınız açıklanmaktadır.

Protobuf Ayrıştırma isteği

Google, teklif isteğini HTTP POST isteğinin ikili yükü. Content-Type application/octet-stream olarak ayarlandı. Örnek için Örnek teklif isteği bölümüne bakın.

Bu isteği BidRequest mesajı örneğine ayırmanız gerekir. Seçtiğiniz protokole bağlı olarak BidRequest, referans verileri sayfasından edinilebilen openrtb.proto veya desteği sonlandırılmış realtime-bidding.proto içinde tanımlanır. BidRequest için oluşturulan sınıftaki ParseFromString() yöntemini kullanarak mesajı ayrıştırabilirsiniz. Örneğin, aşağıdaki C++ kodu bir isteği ayrıştırır dizede bir POST yükü verildi: 

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, OpenRTB "BidRequest"teki anlaşmalarla C++ yinelemesi şöyle görünebilir: şu:

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. tüm uygun alıcıların faturalandırma kimlikleriyle doldurulur ve ilgili ön hedefleme yapılandırmaları için kullanılabilir. 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. Yalnızca şu faturalandırma kimlikleri: Teklif isteğine dahil edilen alıcılar teklif verirken 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.

Google GZT protokolü teklif URL'si makroları

İsteğe bağlı olarak, BidRequest'ün bazı alanları HTTP POST isteğinde kullanılan URL'ye eklenebilir. Bu, örneğin Bir değer kullanarak birden fazla arka uç üzerinde yük dengeleyen hafif bir ön uç . Yeni makrolar için destek istemek üzere teknik hesap yöneticinizle iletişime geçin.

MakroAçıklama
%%GOOGLE_USER_ID%%

Şununla değiştirildi: google_user_id BidRequest arasında. Örneğin, teklif veren URL'si 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
. gibi bir metinle değiştirilir. 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
adresine e-posta gönderebilirsiniz.

Google User-ID bilinmiyorsa boş dize, ile benzer sonuç

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

BidRequest'nin has_mobile() numarası aranırken 1 veya 0 ile değiştirilir.
%%HAS_VIDEO%%

1 (doğru) veya 0 (yanlış) ile değiştirilir BidRequest adlı kişinin has_video() numarası aranıyor.
%%HOSTED_MATCH_DATA%%

BidRequest kaynağındaki hosted_match_data alanının değeriyle değiştirilir.
%%MOBILE_IS_APP%%

BidRequest öğesinin mobile.is_app alanındaki 1 (doğru) veya 0 (yanlış) ile değiştirilir.

İş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 harflerle yazılmış bölümünün kodunu çözmek için base-32 kod çözücü kullanın (gewtimrzgyytanjyg4888888).

Bu sorunu çözmek için kod çözücü ile aynıdır, ancak harflerin büyük yazılması ve sondaki harflerin yerine = değerlerine sahip 8 öğeleri.

Bu değerin kodunu çözdüğümüzde: 

GEWTIMRZGYYTANJYG4======
aşağıdaki sonucu elde ederiz: 
1-429610587
429610587 dizesi, iOS uygulaması iFunny'ın uygulama kimliğidir.

Başka bir örnek verelim. Bildirilen URL: 

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

İş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 çözdüğümüzde: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
sonuç olarak: 
air.com.hypah.io.slither
slither.io Android uygulamasına ulaşılır.

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 Authorized Buyers Ayrıntılar
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].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.

Örnek olarak bu, şuna benzer bir biçimlendirmeyle görünür: /1234/cruises/mars
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

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

Değerlerin, BidRequest.user.data[].name şuna ayarlandığında yayıncı görünür: “Publisher Passed”.

İ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 Authorized Buyers'a katılım için Google'ın onayladığı tedarikçi firmalar etkileşimlere 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çilerin beyan edilmesi gerekmez; listelenen tüm tedarikçiler Ad Manager Sertifikalı Harici Tedarikçiler.
  2. Diğer tedarikçiler yalnızca BidRequest:
    • 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 satıcılar, vendors.txt sözlük dosyasında listelenir.

Örnek teklif isteği

Aşağıdaki örnekler kullanıcılar tarafından okunabilen Protobuf ve JSON istekleri.

OpenRTB Protobuf

OpenRTB JSON

Google (Kullanımdan kaldırıldı)

Teklif isteğini ikili forma dönüştürmek için (ör. POST yüküyle ilgili işlem yapmak istiyorsanız aşağıdaki işlemi (C++ ürününde) yapabilirsiniz. Not, ancak bu, OpenRTB JSON için geçerli değildir.

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

Authorized Buyers gerçek zamanlı geri bildirim özelliğini de kullanabilir exchange'ler ve ağlar olarak tanımlanır.

Teklif yanıtı geri bildirimi, her ikisi için de sonraki teklif isteğinde desteklenir OpenRTB ve kullanımdan kaldırılan Google GZT protokolü. OpenRTB için BidRequest.ext.bid_feedback olarak gönderilir.

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. İlgili içeriği oluşturmak için kullanılan event_notification_token, yalnızca bir reklamveren oluşturabilirsiniz. Örneğin: yeni bir hedefleme kimliği veya yeni bir taktiği veya reklam öğesiyle ilişkili meta verileri temsil eden teklif kimliği bilgi sahibi olmanız gerekir. Ayrıntılar için OpenRTB veya desteği sonlandırılan Google RTB protokolü için OpenRTB Extensions Protocol Buffer'a bakın.

Authorized Buyers teklif verene teklif isteği gönderdiğinde teklif veren yanıt verir BidResponse ile. 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;

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

  // The minimum bid value necessary to have 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 did not
  // 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 teklif vermeyi devre dışı bırakabileceğinizi unutmayın. değerlendirebiliriz. Daha fazla bilgi için bkz. Nasıl yapılır? devre dışı bırakabilirsiniz.

Gerçek zamanlı geri bildirim, teklif isteği kimliğini ve takip etmek için:

Açık artırma sonucu Gerçek zamanlı geri bildirim
Alıcı teklif göndermedi. Hiç.
Alıcı, ulaşmadan önce filtrelenen bir teklif gönderdi açık artırmadır. 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ırma için) dahil edilir.
Alıcı, açık artırmayı kazanan bir teklif göndermiştir. Temizlenen fiyat ve reklam öğesi durum kodu 1.

Bir uygulama gösterimi ve 83 reklam öğesi durum kodu için, uyumlulaştırma şelalesi kullanıyor olabilir ve dolayısıyla kazanan teklifin, yayıncının hesabındaki diğer taleple rekabet edebileceği geri verilen gösterim şelale zinciri. Teklif verirken sampled_mediation_cpm_ahead_of_auction_winner'yi nasıl kullanacağınızı öğrenin.

Örnek

Aşağıda, desteklenen bir program kapsamında gerçek zamanlı bir geri bildirim örneği verilmiştir: protokoller:

OpenRTB Protobuf

OpenRTB JSON

Google (Kullanımdan kaldırıldı)

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

İlk fiyat açık artırmasında teklif verdikten sonra, geri bildirim alırsınız. minimum_bid_to_win ve dahil olmak üzere geri bildirimler Teklif, sampled_mediation_cpm_ahead_of_auction_winner açık artırmadan filtrelenmedi. Bu sinyaller, daha yüksek veya daha düşük olabileceğine ilişkin bir teklif mantığı gösterimi kazanır.

  • minimum_bid_to_win: Olası minimum teklif gerçek zamanlı teklif açık artırmasını kazanmak için yerleştirilir. Açık artırmayı siz kazandıysanız, bu en düşük teklif olabilir. 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. Bu ayardaki ağlardan hiçbiri için uyumlulaştırma zincirinin doldurması bekleniyorsa veya yayıncı SDK kullanmıyorsa uyumlulaştırma.

İşleyiş şekli

Olası değerleri belirlemek için kullanılan hesaplamaları açıklamak amacıyla minimum_bid_to_win ve sampled_mediation_cpm_ahead_of_auction_winner için öncelikle şunları tanımlar:

  • 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, beklenen BGBM'yi ve BGBM'yi belirlemek için kullanılan bir işlev verilmiştir. belirtilen dolguya göre \(i\)uyumlulaştırma zinciri öğesinden olasılık oran:
    \(X_i = \{C_i\) olasılık \(f_i\); \(0\) olasılık \(1 - f_i\}\)
  • Kazanan nihai uyumlulaştırma zinciri şu şekilde olacaktır:
    \[\{C_1, C_2, …, C_K, W\}\]
    kazanan teklif \(W\) buradadır 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ırmanın 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 ile \(\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 vermeyi hem de bir SDK uyumlulaştırma zincirini kullandığı şöyle olur:

SDK Uyumlulaştırma Zinciri Beklenen BGBM Doluluk Oranı
Ağ 1 \(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 İkincisi (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, bir dönüşüm için değerlerin ve olasılıkların minimum_bid_to_win ve sampled_mediation_cpm_ahead_of_auction_winner, kaybeden teklifler.

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 birleştirildiğinde, hangi teklif isteklerini orijinalin bir parçasıdır, çünkü BidRequest.ext.google_query_id alanı boş bırakılamaz.

Teklif birleştirme varsayılan olarak etkindir, ancak hesabınızla iletişime geçebilirsiniz yöneticisine de başvurabilirsiniz.

Reklam biçimleri

Bazı reklam fırsatları birden fazla biçimi kabul edebilir. Teklif birleştirmede ise her biçimi, uygun gibi özelliklerin gösterildiği ayrı bir teklif isteğinde gönderilir faturalandırma kimlikleri istekte belirtilen biçimle alakalıdır.

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

  • Banner
  • Video
  • Ses
  • Yerel biçim

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

Aşağıda, reklam içermeyen basitleştirilmiş bir OpenRTB JSON teklif isteğini gösteren örnek verilmiştir bir eşdeğer düzleştirilmiş istek grubuna kıyasla biçim birleştirme:

Önceden düzleştirme

Post-Düz

Fırsatlar

Belirli bir teklif veren için reklam fırsatı, çeşitli anlaşmalarda geçerli olabilir reklam türlerini listeledik. Anlaşmalar için teklif birleştirme özelliğiyle, tek bir teklif herkesin katılabileceği açık artırma için ve her sabit fiyat türü için bir istek gönderilir fırsatınız olur. Uygulamada, reklam kısıtlamaları açık artırmalar ile sabit fiyatlar arasında farklılık gösterebilir belirli bir video reklam fırsatı için geçerli olan teklif türlerini hem herkesin katılabileceği açık artırma hem de sabit fiyatlı anlaşmada Maksimum reklam süresi ve reklamın ayarlanıp yayınlanmayacağı gibi kısıtlamaların atlanabilir reklamlara izin verilir ve bu reklamlar 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.

Maksimum atlanabilir video süresi

Google'ın protokolü ve OpenRTB uygulaması, video süresi ve atlanabilirlik için aşağıdaki alanları destekler:

Süre Atlanabilir süre Atlanabilirlik
Google protokolü max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration Yok skip

Bu, Google protokolünde ayrıntılı bir atlanabilir ve atlanabilir olmayan süre bulunabilirken OpenRTB uygulamasında yalnızca tek bir maksimum süre değeri olduğu anlamına gelir.

Teklif birleştirmeden önce OpenRTB'nin maxduration değeri Google protokolünün max_ad_duration değerinden düşük olanı ve skippable_max_ad_duration alanları için geçerlidir. Bu davranış artık bu değerler farklı olduğunda iki ayrı teklif isteği gönderecek şekilde değiştirildi: biri atlanabilir fırsatlar için maxduration'yi, diğeri ise atlanamayan fırsatları temsil ediyor.

Aşağıdaki örneklerde, bir Google protokolü isteğinin nasıl çevrildiği gösterilmektedir OpenRTB'ye teklif birleştirme işleminden önce ve sonra. Eşdeğer Google protokolü isteğinin max_ad_duration değeri 15, skippable_max_ad_duration değeri ise 60'tır.

Ö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 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'ya uygundur.
  • Teklif veren hesabında etkin OpenRTB uç noktaları olmalıdır.

Teknik hesap yöneticinizle iletişime geçerek bu tür bir düzleştirmeyi devre dışı bırakabilirsiniz.

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 battrBanner veya Video ö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 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

Google (Kullanımdan kaldırıldı)

Uygulama geçiş reklamı

OpenRTB Protobuf

OpenRTB JSON

Google (Kullanımdan kaldırıldı)

Uygulama geçiş reklamı videosu

OpenRTB Protobuf

Google (Kullanımdan kaldırıldı)

Uygulama yerel

OpenRTB Protobuf

OpenRTB JSON

Google (Kullanımdan kaldırıldı)

Web videosu

Google (Kullanımdan kaldırıldı)

Exchange teklif vereni için mobil web banner'ı

OpenRTB Protobuf