İsteği İşleme

Google, uygulamanıza teklif isteği gönderdiğinde gerçek zamanlı bir 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.

İsteği ayrıştır

Google, teklif isteğini HTTP POST isteğinin ikili yükü olarak eklenen serileştirilmiş bir protokol arabelleği olarak gönderir. 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ının bir örneğine ayrıştırmalısınız. BidRequest, referans verileri sayfasından edinebileceğiniz realtime-bidding.proto politikasında tanımlanmıştır. BidRequest için oluşturulan sınıfta ParseFromString() yöntemini kullanarak mesajı ayrıştırabilirsiniz. Örneğin, aşağıdaki C++ kodu bir dizede 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 edindikten sonra bu öğeyle bir nesne olarak çalışabilir, ihtiyacınız olan alanları çıkarıp yorumlayabilirsiniz. Örneğin, C++ için:

for (int i = 0; i < bid_request.adslot_size(); ++i) {
  const BidRequest_AdSlot& adslot = bid_request.adslot(i);
  // Decide what to bid on adslot.
}

BidRequest ile gönderilen bazı bilgiler (ör. Google Kullanıcı Kimliği, dil veya coğrafi konum) her zaman kullanılamayabilir. Belirli bir gösterim için bilinmeyen bilgileri kullanan ön hedefleme reklam gruplarınız varsa bu reklam grupları eşleşmez. Ön hedefleme koşulları için eksik bilgilerin önemli olmadığı durumlarda teklif istekleri, eksik bilgilerle gönderilir.

Ön hedefleme reklam grubuyla ilgili bilgiler, her bir AdSlot için MatchingAdData grubunda mevcuttur. Bu değer, Google'ın teklif isteğini göndermesini isteyen ön hedefleme reklam grubunun ilk eşleşen reklam grubu kimliğini içerir. Bu kimlik, yanıtınızın gösterim için açık artırmayı kazanması durumunda ücretlendirilen reklam grubu ve kampanyanın kimliğini belirtir. Bazı durumlarda, BidResponse.AdSlot içinde ilişkilendirme için billing_id öğesini açıkça belirtmeniz gerekir. Örneğin, BidRequest.AdSlot birden fazla matching_ad_data içeriyorsa. Teklifin içeriğiyle ilgili kısıtlamalar hakkında daha fazla bilgi için realtime-bidding.proto inceleyin.

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 URL'si makroları

Bazı BidRequest alanları, isteğe bağlı olarak HTTP POST isteğinde kullanılan URL'ye eklenebilir. Örneğin, istekteki bir değeri kullanarak birden fazla arka uç üzerinden yük dengeleme yapan hafif bir ön uç kullanıyorsanız bu özellik faydalı olacaktır. Yeni makrolarla ilgili destek istemek için teknik hesap yöneticinize başvurun.

MakroAçıklama
%%GOOGLE_USER_ID%%

BidRequest öğesinden google_user_id ile değiştirilir. Örneğin, teklif veren URL'si

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
, istek zamanında
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
gibi bir URL ile değiştirilecektir.

Google Kullanıcı Kimliği bilinmiyorsa boş dize değiştirilir ve şuna benzer bir sonuç elde edilir:

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

BidRequest has_mobile() çağrılırken 1 veya 0 ile değiştirilir.
%%HAS_VIDEO%%

BidRequest öğesi has_video() çağrılırken 1 (true) veya 0 (false) ile değiştirilir.
%%HOSTED_MATCH_DATA%%

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

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

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

Mobil uygulama işlemleri, şuna benzeyen URL'leri bildirir:

mbappgewtimrzgyytanjyg4888888.com

Dizenin kalın karakterlerle (gewtimrzgyytanjyg4888888) yazılan kısmının kodunu çözmek için base 32 kod çözücü kullanın.

Online kod çözücü kullanabilirsiniz ancak harfleri büyük yazıp sondaki 8'leri = değerleriyle değiştirmeniz gerekir.

Bu değerin kodu çözüldüğünde: 

GEWTIMRZGYYTANJYG4======
şu şekilde sonuçlanır: 
1-429610587
429610587 dizesi, iFunny iOS uygulamasının uygulama kimliğidir.

Bir örnek daha verelim. Raporlanan URL: 

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

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

Aşağıda, uygulama adını almayla ilgili bir örnek verilmiştir. Bildirilen URL aşağıdaki gibidir: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
Bu değerin kodunun çözülmesi: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
şunu sağlar: 
air.com.hypah.io.slither
Sonuç, slither.io Android uygulamasına eşittir.

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'ın isteklerine benzer. Open Bidding müşterilerine az sayıda ek alan sunulur. Mevcut birkaç alanın alternatif kullanımları olabilir. Bunlardan bazıları:

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 eğik çizgiyle ayrılmış reklam birimi hiyerarşisini içerir.

Örneğin, 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 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 satıcıları bildirme

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

BidRequest öğesini anlamak ve BidResponse öğenizi oluşturmak için teknoloji tedarikçi firmaları bildirmeyle ilgili iki farklı seçeneği bilmeniz gerekir:

  1. Bazı tedarikçi firmaların beyan edilmesi gerekmez. Bu tedarikçiler Authorized Buyers Yardımı'nda listelenir.
  2. Diğer tedarikçiler, yalnızca hem BidRequest hem de BidResponse içinde beyan edilmeleri halinde katılabilirler:
    • BidRequest bölümündeki allowed_vendor_type alanı, satıcının hangi tedarikçi firmalara izin verdiğini belirtir. BidRequest öğesinin allowed_vendor_type alanında gönderilecek tedarikçiler Vendors.txt sözlük dosyasında listelenir.
    • BidResponse'deki vendor_type alanı, alıcının izin verilen tedarikçi firmalardan hangilerini kullanmayı amaçladığını belirtir.

Örnek teklif isteği

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

Google

OpenRTB JSON

OpenRTB Protokol Arabelleği

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

Yeniden pazarlama

Authorized Buyers, bir mobil uygulamadan gelen teklif isteklerine bir mobil reklam kimliği iletir. Mobil reklam kimliği bir iOS IDFA veya Android reklam kimliği olabilir. Bu kimlik, Authorized Buyers tarafından yönetilen JavaScript etiketindeki %%EXTRA_TAG_DATA%% makrosu üzerinden gönderilir.

%%ADVERTISING_IDENTIFIER%% makrosu, alıcıların gösterim oluşturmada iOS IDFA'yı veya Android'in Reklam Kimliğini almalarını sağlar. %%EXTRA_TAG_DATA%% gibi şifrelenmiş bir protokol arabelleği MobileAdvertisingId döndürür:

message MobileAdvertisingId {
  optional bytes advertising_id = 1;
  optional int32 user_id_type = 2;
}

user_id_type, enum AdxMobileIdType öğesinde tanımlanan değerlerden biridir:

enum AdxMobileIdType {
  MOBILE_ID_UNKNOWN = 0,
  IDFA = 1,
  ANDROID_ID = 2,
};

Gösterim oluşturma sırasında topladığınız reklam kimliklerini kullanarak mobil reklam kimliklerinden kullanıcı listeleri oluşturabilirsiniz. Bu kullanıcı listeleri sizin sunucunuzda veya bizim sunucularımızda tutulabilir. Google'ın sunucularında kullanıcı listeleri oluşturmak için toplu yükleme tesisimizi kullanabilirsiniz.

Mobil reklamcılık kimliği bir kullanıcı listesiyle eşleştiğinde, yeniden pazarlama yapmak için bu kimliği kullanabilirsiniz.

Gerçek zamanlı 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.

Teklif yanıtı geri bildirimi, hem AdX Protocol hem de OpenRTB için sonraki teklif isteğinde desteklenir. OpenRTB için BidRequestExt içinde gönderilir.

Teklif Yanıtı Geri Bildirimi'nde gönderilen varsayılan alanlara ek olarak, BidResponse içinde döndürülen bir event_notification_token kullanarak teklif yanıtında (AdX Proto veya OpenRTB) ö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 reklam öğesiyle ilişkili ve yalnızca teklif veren tarafından bilinen meta veriler. Ayrıntılar için RTB için OpenRTB Uzantılar Protokol Tamponu ve AdX için AdX Proto bölümüne bakın.

Authorized Buyers teklif verene teklif isteği gönderdiğinde teklif veren, BidResponse ile yanıt verir. Teklif veren gerçek zamanlı geri bildirimi etkinleştirdiyse sonraki bir teklif isteğinde Authorized Buyers, aşağıda gösterildiği gibi bir BidResponseFeedback mesajıyla yanıtla ilgili geri bildirim gönderir:

message BidResponseFeedback {
  // The unique id from BidRequest.id
  optional bytes request_id = 1;

  // The index of the BidResponse_Ad if there was more than one. The index
  // starts at zero for the first creative.
  optional int32 creative_index = 2;

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

  // 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 int64 cpm_micros = 4;

  // The minimum bid value necessary to have won the auction, in micros of
  // 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 int64 minimum_bid_to_win = 7;

  // 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 micros 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 BidResponseFeedback object.
  optional int64 server_side_component_minimum_bid_to_win = 16;

  // 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 = 15 [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 micros of your account currency.
  optional int64 sampled_mediation_cpm_ahead_of_auction_winner = 10;

  // Event notification token that was included in the bid response.
  optional bytes event_notification_token = 5;

  // Buyer creative ID that was included in the bid response.
  optional string buyer_creative_id = 6;

  // 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 BidResponseFeedback message. Google will send separate
  // BidResponseFeedback 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 feedback_type = 17;

  // 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 buyer_origin = 18;

  // 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 interest_group_buyer_status_code = 19;
}

Bu mesajda, işaretlemeniz gereken ilk alan bid_response_feedback.creative_status_code. Kodu, creative-status-codes.txt içinde bulabilirsiniz. Teklifi kazanırsanız fiyat geri bildirimini devre dışı bırakabilirsiniz. Daha fazla bilgi için Devre dışı bırakma bölümüne bakın.

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öndermemiştir. Hiç.
Alıcı, açık artırmaya ulaşmadan önce filtrelenmiş bir teklif göndermiştir. Reklam öğesi durum kodu (creative-status-codes.txt).
Alıcı teklif verdi 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. Temizlenen fiyat ve reklam öğesi durum kodu 1.

Uygulama yayıncısı, bir uygulama gösterimi ve 83 reklam öğesi durum kodu için 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 edebilirdi. 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üldüğü gibi gerçek zamanlı geri bildirime bir örnek verilmiştir:

Google

OpenRTB JSON

OpenRTB Protokol Arabelleği

İ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 filtrelenmemişse minimum_bid_to_win ve sampled_mediation_cpm_ahead_of_auction_winner alanlarını da içeren gerçek zamanlı geri bildirimler alırsınız. Bu sinyaller, gösterimi kazanmak için teklifinizin ne kadar yüksek veya düşük olabileceğine ilişkin teklif mantığınıza bilgi sağlamak amacıyla kullanılabilir.

  • minimum_bid_to_win: Gerçek zamanlı teklif açık artırmasını kazanmak için verilebilecek minimum tekliftir. Açık artırmayı kazanmış olsanız bile bu, kazanmayı sürdürürken verebileceğiniz en düşük teklif olacaktır. Açık artırmayı kaybettiyseniz, kazanan teklif bu olur.
  • sampled_mediation_cpm_ahead_of_auction_winner: Uyumlulaştırma zincirinde başka ağlar varsa bu alanın değeri, beklenen doluluk oranına göre ağırlıklı olarak açık artırmanın kazananından daha yüksek olan uygun uyumlulaştırma ağlarından birinden alınan örnek bir teklifi temsil eden fiyat olur. Uyumlulaştırma zincirindeki ağlardan hiçbirinin doldurması beklenmiyorsa veya yayıncı SDK uyumlulaştırmasını 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 amacıyla kullanılan hesaplamaları açıklamak için önce 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, belirtilen doluluk oranına göre beklenen BGBM'yi ve uyumlulaştırma zinciri öğesinden \(i\)olasılığını belirlemek için kullanılan bir işlev gösterilmektedir:
    \(X_i = \{C_i\) olasılıkla \(f_i\); \(0\) olasılıkla \(1 - f_i\}\)
  • Kazanan son uyumlulaştırma zinciri şöyle 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, \(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ı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ı kaybedenlere ilişkin 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 aşağıdaki gibi 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ı
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\%\)
Ağ 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

GZT açık artırmasının sonucu olarak aşağıdaki sonucu 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ı
Rezerv Fiyatı / Taban (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 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, minimum_bid_to_win ve sampled_mediation_cpm_ahead_of_auction_winner değerlerinin ve olasılıkların kaybedilen teklifler için 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ğine dönüştürülmesini tanımlar. Aynı kimlikleri (Authorized Buyers RTB Protokolü'nde BidRequest.google_query_id veya OpenRTB protokolünde BidRequestExt.google_query_id) korudukları için birleştirme işleminden sonra hangi teklif isteklerinin ilişkilendirildiğini belirleyebilirsiniz.

Reklam biçimleri

Bazı reklam fırsatları birden fazla biçimi kabul edebilir. Teklif birleş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, farklı teklif istekleri olarak birleştirilecek:

  • Banner
  • Video
  • Ses
  • Yerel biçim

Reklam biçimi birleştirme örneği

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

Önceden Düzülmüş

Düzleme Sonrası

Fırsatlar

Belirli bir teklif veren için reklam fırsatı, herkesin katılabileceği açık artırmaya ek olarak çeşitli anlaşma türleri için geçerli olabilir. Anlaşmalar için teklif birleştirmeyle, herkesin katılabileceği açık artırma için bir teklif isteği ve her bir sabit fiyatlı anlaşma türü için bir teklif isteği gönderilir. Pratikte 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 herkesin katılabileceği açık artırmada hem de sabit fiyatlı bir anlaşmada kullanılabilen belirli bir video reklam fırsatında teklif veren, maksimum reklam süresi ve atlanabilir reklamlara izin verilip verilmeyeceği gibi kısıtlamaların farklı olabileceği durumlarda her biri için ayrı teklif istekleri alır. Sonuç olarak, reklam fırsatına uygulanan birleştirme işlemi, açılış açık artırması ve sabit fiyatlı anlaşma için reklam kısıtlamalarını daha kolay ayırt etmenizi sağlar.

Maksimum atlanabilir video süresi

Google'ın protokolü ve OpenRTB uygulaması, video süresi ve atlanabilirliği 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ünün ayrıntılı bir atlanabilir ve atlanamayan süresi olabileceği, OpenRTB uygulamasının yalnızca tek bir maksimum süre değerine sahip olduğu anlamına gelir.

Teklif birleştirme işleminden önce OpenRTB'nin maxduration değeri, Google protokolünün max_ad_duration ve skippable_max_ad_duration alanlarının alt kısmına ayarlanır. Bu davranış artık bu değerler farklı olduğunda iki ayrı teklif isteği gönderilecek şekilde değiştirilmiştir: Biri atlanabilir için maxduration, diğeri atlanamayan fırsatlar için.

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

Örnek max_ad_duration skip (doğru VEYA yanlış)
Birleştirmeden 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, yalnızca aşağıdaki koşullar karşılandığında gerçekleşir:

  • İstek videoya izin veriyor.
  • Hem atlamalı hem de atlanamayan videolara izin verilir. İlgili 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.
  • Teklif veren hesabında etkin OpenRTB uç noktaları var.

Teknik hesap yöneticinizle iletişime geçerek bu tür birleştirme işleminin kapsamı dışında kalmayı seçebilirsiniz.

Video kapsülleri

Birden fazla reklam fırsatı içeren video kapsülü için teklif istekleri, her teklif isteği söz konusu kapsüldeki bağımsız bir reklam fırsatına yönelik olacak şekilde birleştirilir. Bu, belirli bir kapsül için birden fazla reklam fırsatına teklif vermenizi sağlar.

Open Measurement

Open Measurement, mobil uygulama ortamlarına yayınlanan reklamlar için bağımsız ölçüm ve doğrulama hizmetleri sağlayan üçüncü taraf tedarikçi firmaları belirtmenizi sağlar.

Bir yayıncının, reklam fırsatının Yayıncı tarafından hariç tutulabilir reklam öğesi özelliklerinde bulunan OmsdkType: OMSDK 1.0 özelliğini hariç tutup tutmadığını kontrol ederek teklif isteğinde Open Measurement'ı destekleyip desteklemediğini belirleyebilirsiniz. Authorized Buyers protokolü için BidRequest.adslot[].excluded_attribute değerinin altında yer alır. OpenRTB protokolü için bu, biçime bağlı olarak Banner veya Video için battr özelliğinin altında bulunur.

Open Measurement sinyalleri içeren teklif isteklerini nasıl yorumlayacağınız 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'ı

Google

OpenRTB JSON

OpenRTB Protokol Arabelleği

Uygulama geçiş reklamı

Google

OpenRTB JSON

OpenRTB Protokol Arabelleği

Uygulama geçiş videosu

Google

OpenRTB Protokol Arabelleği

Uygulama yerel

Google

OpenRTB JSON

OpenRTB Protokol Arabelleği

Web videosu

Google

Exchange teklif vereni için mobil web banner'ı

OpenRTB Protokol Arabelleği