Memproses Permintaan

Interaksi bidding real-time dimulai saat Google mengirimkan permintaan bid ke aplikasi Anda. Panduan ini menjelaskan cara mengodekan aplikasi Anda untuk memproses permintaan bid.

Uraikan permintaan

Google mengirimkan permintaan bid sebagai penyangga protokol serial yang dilampirkan sebagai payload biner dari permintaan POST HTTP. Content-Type disetel ke application/octet-stream. Lihat Contoh permintaan bid untuk mengetahui contohnya.

Anda harus mengurai permintaan ini menjadi instance BidRequest untuk membuat pesan email baru. BidRequest ditentukan di realtime-bidding.proto, yang dapat diperoleh dari halaman data referensi. Anda dapat mengurai pesan menggunakan metode ParseFromString() di class yang dihasilkan untuk BidRequest. Misalnya, kode C++ berikut mengurai permintaan diberi payload POST dalam string: 

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

Setelah memiliki BidRequest, Anda dapat menggunakannya sebagai mengekstrak dan menafsirkan kolom yang Anda butuhkan. Misalnya, di C++:

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

Beberapa informasi yang dikirim di BidRequest, seperti Pengguna Google ID, bahasa, atau lokasi geografis tidak selalu tersedia. Jika Anda memiliki grup iklan pra-penargetan yang menggunakan informasi yang tidak diketahui untuk grup iklan tertentu tayangan iklan, maka grup iklan tersebut tidak akan sesuai. Dalam kasus di mana informasi ini tidak penting untuk kondisi pra-penargetan, permintaan bid dikirim dengan informasi yang dihilangkan.

Informasi tentang grup iklan pra-penargetan tersedia di Grup MatchingAdData untuk setiap AdSlot. Isinya adalah ID grup iklan pertama yang cocok untuk grup iklan pra-penargetan yang meminta Google untuk mengirimkan permintaan bid, yaitu grup iklan dan kampanye yang dikenai biaya jika respons Anda memenangkan lelang untuk tayangan. Di bawah tertentu ini, Anda harus secara eksplisit menentukan billing_id untuk atribusi di BidResponse.AdSlot, misalnya, saat BidRequest.AdSlot memiliki lebih dari satu matching_ad_data. Untuk informasi selengkapnya tentang batasan konten bid, lihat realtime-bidding.proto.

File kamus

Permintaan bid menggunakan ID yang ditentukan dalam file kamus, yang yang tersedia di data referensi kami.

Makro URL bid

Secara opsional, beberapa kolom BidRequest dapat disisipkan ke dalam URL yang digunakan dalam permintaan POST HTTP. Hal ini berguna, misalnya, jika Anda menggunakan frontend ringan yang melakukan load balancing pada beberapa backend menggunakan nilai dari permintaan. Hubungi manajer akun teknis Anda untuk meminta dukungan terkait makro baru.

MacroDeskripsi
%%GOOGLE_USER_ID%%

Diganti dengan google_user_id dari BidRequest. Misalnya, URL bidder 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
 akan diganti dengan sesuatu seperti 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
 sesuai waktu permintaan.

Jika User-ID Google tidak diketahui, string kosong akan diganti dengan hasil mirip dengan

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

Diganti dengan 1 atau 0 saat menelepon has_mobile() BidRequest.
%%HAS_VIDEO%%

Diganti dengan 1 (benar) atau 0 (salah) saat memanggil has_video() BidRequest.
%%HOSTED_MATCH_DATA%%

Diganti dengan nilai kolom hosted_match_data dari BidRequest.
%%MOBILE_IS_APP%%

Diganti dengan 1 (benar) atau 0 (salah) dari kolom mobile.is_app BidRequest.

Menemukan ID aplikasi seluler dari URL transaksi

Transaksi aplikasi seluler akan melaporkan URL yang terlihat seperti ini:

mbappgewtimrzgyytanjyg4888888.com

Menggunakan dekoder base-32 untuk mendekode bagian string yang dicetak tebal (gewtimrzgyytanjyg4888888).

Anda dapat menggunakan properti online decoder, tetapi Anda harus menggunakan huruf besar dan mengganti di akhir 8 dengan nilai =.

Jadi dengan mendekode nilai ini: 

GEWTIMRZGYYTANJYG4======
 menghasilkan: 
1-429610587
 String 429610587 adalah ID aplikasi untuk aplikasi iOS iFunny.

Contoh lainnya, URL yang dilaporkan adalah: 

mbappgewtgmjug4ytmmrtgm888888.com
 Decoding nilai ini: 
GEWTGMJUG4YTMMRTGM======
 menghasilkan: 
1-314716233
 Hasil 314716233 adalah ID aplikasi untuk aplikasi iOS TextNow.

Menemukan nama aplikasi seluler dari URL transaksi

Berikut adalah contoh cara mendapatkan nama aplikasi. URL yang dilaporkan adalah sebagai berikut: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Decoding nilai ini: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 menghasilkan: 
air.com.hypah.io.slither
 Hasilnya sama dengan aplikasi Android slither.io.

Kolom Bidding Terbuka

Permintaan bid dikirim ke bidder bursa dan jaringan yang berpartisipasi dalam Bidding serupa dengan Authorized Buyers yang berpartisipasi dalam bidding real-time. Pelanggan Bidding Terbuka akan menerima sejumlah kecil tambahan, dan beberapa {i>field<i} yang ada mungkin memiliki penggunaan alternatif. Ini meliputi hal berikut:

OpenRTB Authorized Buyers Detail
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

Berisi kode jaringan Ad Manager penayang yang diikuti dengan iklan hierarki unit, yang dipisahkan oleh garis miring ke depan.

Sebagai contoh, ini akan muncul dengan pemformatan yang mirip dengan: /1234/cruises/mars.
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

Pasangan nilai kunci berulang yang dikirim dari penayang ke bidder bursa.

Anda dapat menentukan bahwa nilainya adalah pasangan nilai kunci yang dikirim oleh penayang jika BidRequest.user.data[].name ditetapkan ke “Publisher Passed”.

Mendeklarasikan vendor yang diizinkan

Vendor teknologi yang menyediakan layanan seperti penelitian, pemasaran ulang, dan penayangan iklan dapat berperan dalam interaksi antara pembeli dan penjual. Hanya vendor yang telah diperiksa Google untuk berpartisipasi dalam Authorized Buyers interaksi yang diizinkan.

Untuk memahami BidRequest dan membuat BidResponse, Anda harus mengetahui dua perbedaan kemungkinan untuk mendeklarasikan vendor teknologi:

  1. Beberapa vendor tidak perlu diumumkan; vendor tersebut tercantum di Bantuan Authorized Buyers.
  2. Vendor lain hanya dapat berpartisipasi jika dinyatakan dalam kedua BidRequest dan BidResponse:
    • Di BidRequest, allowed_vendor_type menentukan vendor mana yang diizinkan oleh penjual. Vendor yang akan dikirim dalam kolom allowed_vendor_type dari BidRequest adalah tercantum di dalam Vendors.txt file kamus.
    • Di BidResponse, kolom vendor_type menentukan vendor mana yang ingin digunakan oleh pembeli.

Contoh permintaan bid

Contoh berikut menampilkan contoh Protobuf yang dapat dibaca manusia dan Permintaan JSON.

Google

JSON OpenRTB

Buffering protokol OpenRTB

Untuk mengonversi permintaan bid ke dalam bentuk biner, seperti yang akan Anda dapatkan dari POST dalam permintaan nyata, Anda dapat melakukan hal berikut (di C++). Catatan: namun, hal ini tidak berlaku untuk OpenRTB JSON.

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
  }
}

Pemasaran Ulang

Authorized Buyers meneruskan ID iklan seluler dalam permintaan bid dari aplikasi seluler. ID periklanan seluler dapat berupa IDFA iOS atau ID iklan Android, yang dikirim melalui Makro %%EXTRA_TAG_DATA%% di tag JavaScript yang dikelola oleh Authorized Buyers.

Makro %%ADVERTISING_IDENTIFIER%% memungkinkan pembeli menerima IDFA iOS atau ID Iklan Android pada rendering tayangan. Metode ini mengembalikan buffer proto terenkripsi MobileAdvertisingId seperti %%EXTRA_TAG_DATA%%:

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

user_id_type adalah salah satu nilai yang ditentukan dalam enum AdxMobileIdType:

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

Anda dapat membuat daftar pengguna dari ID periklanan seluler menggunakan ID iklan yang telah Anda kumpulkan selama rendering tayangan. Daftar pengguna ini dapat dikelola di server Anda atau kami. Untuk membuat daftar pengguna di server Google, Anda dapat menggunakan fasilitas upload massal kami.

Jika ID periklanan seluler cocok dengan daftar pengguna, Anda dapat menggunakannya untuk menjalankan pemasaran ulang.

Masukan real-time

Masukan real-time juga tersedia untuk Authorized Buyers sebagai bursa dan jaringan menggunakan Bidding Terbuka.

Masukan respons bid didukung pada permintaan bid berikutnya untuk Protokol AdX dan OpenRTB. Untuk OpenRTB, dikirimkan dalam BidRequestExt.

Selain kolom default yang dikirim di Masukan Respons Bid, Anda dapat juga mengirimkan data kustom dalam respons bid (baik Proto AdX atau OpenRTB) menggunakan event_notification_token yang ditampilkan di BidResponse. event_notification_token adalah data arbitrer yang hanya diketahui oleh bidder yang mungkin membantu proses debug, contoh: ID penargetan atau ID bidding baru yang mewakili taktik baru, atau metadata yang terkait dengan materi iklan yang hanya diketahui oleh bidder. Untuk mengetahui detailnya, lihat OpenRTB Buffering Protokol Ekstensi untuk RTB dan AdX Proto untuk AdX.

Saat Authorized Buyers mengirimkan permintaan bid kepada bidder, bidder akan membalas dengan BidResponse. Jika bidder mengaktifkan masukan real-time, Dalam permintaan bid berikutnya, Authorized Buyers akan mengirimkan masukan tentang dalam pesan BidResponseFeedback, seperti yang ditunjukkan di bawah ini:

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

Dari pesan ini, isian pertama yang harus Anda periksa adalah bid_response_feedback.creative_status_code; Anda dapat menemukan kode artinya dalam status-materi-codes.txt. Perhatikan bahwa jika memenangkan bid, Anda dapat memilih untuk tidak ikut dari masukan harga. Untuk informasi selengkapnya, lihat Cara ketidakikutsertaan.

Masukan real-time mencakup ID permintaan bid dan salah satu berikut ini:

Hasil lelang Masukan real-time
Pembeli tidak mengajukan bid. Tidak ada.
Pembeli mengajukan bid yang difilter sebelum mencapai lelang. Kode status materi iklan (creative-status-codes.txt).
Pembeli mengajukan bid, tetapi kalah dalam lelang. Kode status materi iklan 79 (outbid di lelang).
Pembeli mengajukan bid yang memenangkan lelang. Harga kliring dan kode status materi iklan 1.

Untuk tayangan aplikasi dan kode status materi iklan 83, penayang aplikasi mungkin menggunakan waterfall mediasi, sehingga bid yang menang akan bersaing dengan permintaan lain di rantai waterfall passback. Pelajari cara menggunakan sampled_mediation_cpm_ahead_of_auction_winner saat bidding.

Contoh

Berikut contoh masukan real-time seperti yang terlihat dalam laporan protokol:

Google

JSON OpenRTB

Buffering protokol OpenRTB

Membuat model bidding untuk lelang harga pertama

Setelah menempatkan bid dalam lelang harga pertama, Anda akan menerima bid secara real-time masukan yang meliputi minimum_bid_to_win dan sampled_mediation_cpm_ahead_of_auction_winner kolom jika bid tidak difilter dari lelang. Sinyal ini dapat digunakan untuk menginformasikan logika bidding terkait seberapa tinggi atau rendah bid Anda agar memenangkan tayangan.

  • minimum_bid_to_win: Bid minimum yang seharusnya ditempatkan untuk memenangkan lelang bidding real-time. Jika Anda memenangkan lelang, ini akan menjadi bid terendah yang bisa Anda ajukan sambil tetap menang. Jika Anda kehilangan lelang ini, maka bid ini akan menjadi bid yang menang.
  • sampled_mediation_cpm_ahead_of_auction_winner: Jika ada jaringan lain dalam rantai mediasi, dalam bidang ini adalah harga yang mewakili contoh tawaran dari salah satu jaringan mediasi yang memenuhi syarat dan lebih tinggi dari pemenang lelang, dengan rasio pengisian yang diharapkan. Ini akan diatur ke 0 jika tidak ada jaringan dalam rantai mediasi diharapkan terisi, atau jika penayang tidak menggunakan SDK mediasi.

Cara kerjanya

Untuk menjelaskan kalkulasi yang digunakan dalam menentukan nilai yang mungkin untuk minimum_bid_to_win dan sampled_mediation_cpm_ahead_of_auction_winner, kita harus terlebih dahulu tentukan hal berikut:

  • Berikut adalah CPM di rantai mediasi dalam urutan menurun:
    \[C_1, C_2, …, C_n\]
  • Berikut ini menunjukkan rasio pengisian yang sesuai untuk CPM dalam rantai mediasi:
    \[f_1, f_2, …, f_n\]
  • Berikut ini adalah fungsi yang digunakan untuk menentukan CPM yang diharapkan dan probabilitas dari elemen rantai mediasi \(i\), berdasarkan isian yang diberikan tarif:
    \(X_i = \{C_i\) dengan probabilitas \(f_i\); \(0\) dengan probabilitas \(1 - f_i\}\)
  • Rantai mediasi pemenang terakhir adalah:
    \[\{C_1, C_2, …, C_K, W\}\]
    dengan \(W\) adalah bid pemenang, dan \(C_K > W >= C_{K+1}\)
  • Harga minimum, atau harga minimum, dilambangkan sebagai \(F\).
  • Bid kedua dinyatakan sebagai \(R\).
Penghitungan untuk pemenang lelang
Kolom Penghitungan
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) dengan probabilitas \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Untuk \(1 <= i <= K\).
Penghitungan untuk pecundang lelang
Kolom Penghitungan
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

Contoh dengan rantai mediasi sederhana

Asumsikan penayang menggunakan bidding real-time dan rantai mediasi SDK sebagai berikut ini:

Rantai Mediasi SDK CPM yang diharapkan Rasio Pengisian
Jaringan 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
Jaringan 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
Jaringan 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
Jaringan 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Asumsikan hal berikut sebagai hasil lelang RTB:

Lelang RTB CPM
Pemenang Lelang (M) $1,00
Runner-UP Lelang (R) $0,05
Harga Reservasi / Harga Minimum (F) $0
Bid yang memenangkan lelang

Berikut ini adalah contoh bagaimana nilai dan probabilitas untuk minimum_bid_to_win dan sampled_mediation_cpm_ahead_of_auction_winner dihitung untuk bid yang menang.

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\%\)
Bid yang kalah dalam lelang

Berikut ini adalah contoh bagaimana nilai dan probabilitas untuk minimum_bid_to_win dan sampled_mediation_cpm_ahead_of_auction_winner dihitung untuk bid yang kalah.

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\%\)

Perataan bid

Perataan bid menjelaskan pemrosesan satu kompleks BidRequest menjadi beberapa permintaan bid yang dikirim ke aplikasi. Karena menyimpan ID yang identik (BidRequest.google_query_id di Protokol RTB Authorized Buyers atau BidRequestExt.google_query_id di protokol OpenRTB) Anda bisa menentukan permintaan bid mana yang berkorelasi setelah diratakan.

Format iklan

Beberapa peluang iklan dapat menerima beberapa format. Dengan pemisahan bid, setiap dikirim dalam permintaan bid khusus dengan atribut seperti valid ID penagihan relevan dengan format yang ditentukan dalam permintaan.

Permintaan bid yang berisi format berikut akan disatukan menjadi permintaan bid yang berbeda:

  • Banner
  • Video
  • Audio
  • Native

Contoh perataan format iklan

Berikut adalah contoh yang menampilkan permintaan bid JSON OpenRTB yang sederhana tanpa iklan perataan dibandingkan dengan kumpulan setara permintaan yang disatukan:

Pra-ratakan

Pasca-rata

Promo

Peluang iklan untuk bidder tertentu dapat berlaku untuk berbagai transaksi selain lelang terbuka. Dengan pemisahan bid untuk transaksi, satu bid akan dikirim untuk lelang terbuka, dan satu untuk setiap jenis harga tetap transaksi. Dalam praktiknya, batasan iklan dapat berbeda antara lelang dan harga tetap jenis transaksi tertentu, misalnya, untuk peluang iklan video tertentu yang tersedia untuk baik lelang terbuka maupun transaksi harga tetap, bidder akan menerima permintaan bid untuk masing-masing dengan batasan seperti durasi iklan maksimum dan apakah iklan yang dapat dilewati yang diizinkan bisa berbeda. Akibatnya, perataan diterapkan pada iklan memungkinkan Anda lebih mudah mengenali batasan iklan untuk iklan lelang dan transaksi harga tetap.

Durasi video maksimum yang dapat dilewati

Implementasi protokol Google dan OpenRTB mendukung kolom berikut untuk durasi video dan dapat dilewati:

Durasi Durasi yang dapat dilewati Dapat dilewati
Protokol Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration t/a skip

Ini berarti bahwa meskipun protokol Google dapat memiliki dan tidak dapat dilewati, implementasi OpenRTB hanya memiliki satu nilai durasi maksimum.

Sebelum pemisahan bid, maxduration OpenRTB akan ditetapkan menjadi yang lebih rendah dari max_ad_duration protokol Google dan skippable_max_ad_duration kolom. Perilaku ini sekarang telah berubah menjadi mengirim dua permintaan bid terpisah saat nilai ini berbeda: satu permintaan mewakili maxduration untuk dapat dilewati dan satu lagi untuk tidak dapat dilewati peluang.

Contoh berikut menunjukkan bagaimana permintaan protokol Google menerjemahkan ke OpenRTB sebelum dan sesudah pemisahan bid. Protokol Google yang setara permintaan memiliki max_ad_duration sebesar 15 dan skippable_max_ad_duration dari 60.

Contoh max_ad_duration skip (benar ATAU salah)
Permintaan asli tanpa perataan 15 true
Permintaan merata #1: Tidak dapat dilewati 15 false
Permintaan merata #2: Dapat dilewati 60 true

Penyatuan permintaan bid durasi video yang dapat dilewati hanya akan terjadi jika ketentuan berikut terpenuhi:

  • Permintaan akan mengizinkan video.
  • Video yang dapat dilewati dan video yang tidak dapat dilewati diizinkan, dan masing-masing batasnya durasi yang berbeda nilainya.
  • Permintaan ini memenuhi syarat untuk Lelang Pribadi atau Lelang Terbuka.
  • Akun bidder memiliki endpoint OpenRTB yang aktif.

Anda dapat memilih untuk tidak mengikuti jenis perataan ini dengan menghubungi bagian teknis pengelola akun.

Pod video

Permintaan bid untuk pod video dengan beberapa peluang iklan disatukan, sehingga setiap permintaan bid ditujukan untuk peluang iklan individual dari pod tersebut. Dengan demikian, Anda dapat mengajukan bid pada beberapa peluang iklan untuk pod tertentu.

Pengukuran Terbuka

Pengukuran Terbuka memungkinkan Anda menentukan vendor pihak ketiga yang menyediakan layanan pengukuran dan verifikasi independen untuk iklan yang ditayangkan ke aplikasi seluler lingkungan fleksibel App Engine.

Anda dapat menentukan apakah penayang mendukung Pengukuran Terbuka dalam bid dengan memeriksa apakah peluang iklan mengecualikan atribut OmsdkType: OMSDK 1.0 yang ditemukan di Dapat dikecualikan penayang atribut materi iklan. Untuk protokol Authorized Buyers, ini adalah ditemukan di bawah BidRequest.adslot[].excluded_attribute. Untuk Protokol OpenRTB, yang akan ditemukan pada atribut battr untuk Banner atau Video, bergantung pada formatnya.

Untuk informasi selengkapnya tentang cara menafsirkan permintaan bid yang berisi permintaan bid Sinyal pengukuran, lihat Pengukuran Terbuka Artikel Pusat Bantuan SDK.

Contoh permintaan bid

Bagian berikut menunjukkan contoh permintaan bid untuk berbagai jenis iklan.

Banner aplikasi

Google

JSON OpenRTB

Buffering protokol OpenRTB

Interstisial aplikasi

Google

JSON OpenRTB

Buffering protokol OpenRTB

Video interstisial aplikasi

Google

Buffering protokol OpenRTB

Native aplikasi

Google

JSON OpenRTB

Buffering protokol OpenRTB

Video web

Google

Banner web seluler untuk bidder bursa

Buffering protokol OpenRTB