Memproses Permintaan

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

Urai permintaan

Google mengirimkan permintaan bid yang diserialisasi dalam format JSON OpenRTB atau Protobuf, yang dilampirkan sebagai payload permintaan POST HTTP. Format yang diterima bergantung pada konfigurasi endpoint Anda. Lihat Contoh permintaan bid sebagai contoh.

Anda harus mengurai permintaan ini untuk menerima BidRequest yang diserialisasi. Jika Anda menggunakan format Protobuf, Anda harus mendownload openrtb.proto dan openrtb-adx.proto dari halaman data referensi, lalu menggunakannya untuk membuat library yang dapat digunakan untuk mengurai pesan BidRequest. Misalnya, kode C++ berikut mengurai permintaan yang 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 objek, mengekstrak dan menafsirkan kolom yang Anda butuhkan. Misalnya, di C++, mengulangi penawaran dalam `BidRequest` OpenRTB dapat terlihat seperti berikut:

for (const BidRequest::Imp::Pmp::Deal& deal : pmp.deals()) {
  DoSomething(deal.id(), deal.wseat());
}

ID Penagihan

Anda menerima permintaan bid saat inventaris iklan penayang ditargetkan oleh satu atau beberapa konfigurasi prapenargetan. BidRequest.imp.ext.billing_id akan diisi dengan ID penagihan pembeli yang memenuhi syarat dan konfigurasi prapenargetan yang relevan. Selain itu, untuk inventaris transaksi, Anda dapat menemukan ID penagihan yang terkait dengan pembeli yang relevan menggunakan BidRequest.imp.pmp.deal.ext.billing_id. Hanya ID penagihan pembeli yang disertakan dalam permintaan bid yang dapat ditentukan saat mengajukan bid.

Jika beberapa ID penagihan disertakan dalam permintaan bid, Anda harus menentukan ID penagihan pembeli yang ingin Anda atribusikan bid-nya dengan kolom BidResponse.seatbid.bid.ext.billing_id.

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

Menentukan kategori yang diblokir

Saat Anda mengajukan bid, materi iklan yang disertakan tidak boleh memiliki kategori terdeteksi yang diblokir oleh penayang. Jika tidak, bid akan difilter dari lelang.

Anda dapat menemukan kategori yang diblokir untuk tayangan iklan dengan meninjau kolom BidRequest.bcat, yang diisi dengan kategori dalam taksonomi yang dikonfigurasi untuk akun Anda.

Contoh berikut menunjukkan kategori yang diblokir berdasarkan taksonomi kategori iklan yang dikonfigurasi:

Taksonomi Konten IAB 1.0

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

Menentukan kategori kontekstual

Permintaan bid dapat menyertakan kolom kategori kontekstual yang menjelaskan situs atau aplikasi tempat terjadinya tayangan iklan. Kolom ini juga menggunakan taksonomi kategori iklan, tetapi mewakili konteks tayangan iklan, bukan batasan pada materi iklan. Kolom ini mungkin tidak menggunakan taksonomi yang sama dengan kolom BidRequest.bcat. Google atau penayang dapat menyediakan kategori kontekstual ini. Menggunakan kategori kontekstual dapat meningkatkan evaluasi tayangan, penargetan kontekstual, dan keamanan merek Anda.

Kategori kontekstual yang terdeteksi Google

Google mengisi kolom berikut dengan kategori konten IAB yang terdeteksi untuk situs, aplikasi, atau halaman:

Kolom Deskripsi
BidRequest.site.cat Array ID kategori konten yang mendeskripsikan situs.
BidRequest.site.pagecat Array ID kategori konten yang menjelaskan halaman atau tampilan situs saat ini.
BidRequest.app.cat Array ID kategori konten yang mendeskripsikan aplikasi.
BidRequest.app.pagecat Array ID kategori konten yang menjelaskan halaman atau tampilan aplikasi saat ini.

Anda dapat menemukan taksonomi persis yang digunakan untuk kolom ini untuk permintaan bid tertentu di kolom BidRequest.site.cattax atau BidRequest.app.cattax. Kolom kategori kontekstual mungkin tidak selalu diisi karena preferensi penayang atau masalah peraturan. Untuk informasi selengkapnya, lihat Kategori kontekstual OpenRTB di Google Ad Manager.

Sinyal yang diberikan penayang

Selain kategori kontekstual yang terdeteksi Google, permintaan bid juga dapat berisi sinyal yang diberikan penayang, yang juga menjelaskan konteks tayangan iklan. Tidak seperti kategori kontekstual yang terdeteksi Google, sinyal ini hanya diisi jika diberikan oleh penayang. Sinyal ini dikirim dalam objek BidRequest.site.content dan BidRequest.app.content, seperti content.data.segment dan content.genre. Taksonomi yang digunakan untuk entri content.data.segment dilaporkan di content.data.ext.segtax. Untuk mengetahui informasi selengkapnya, lihat Sinyal yang diberikan penayang (PPS) untuk Bidding Real-time (RTB).

File kamus

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

Makro URL bidder

Secara opsional, beberapa informasi dari BidRequest dapat disisipkan ke dalam URL endpoint bidding menggunakan makro. Jika Anda mengonfigurasi URL endpoint dengan satu atau beberapa makro, URL tersebut akan diperluas jika informasi tersebut ada dalam permintaan bid. Hal ini dapat berguna, misalnya, jika Anda ingin melakukan load balancing berdasarkan informasi dalam BidRequest. Hubungi Account Manager Anda untuk meminta dukungan bagi makro baru.

MakroDeskripsi
%%GOOGLE_USER_ID%%

Diganti dengan ID Pengguna Google yang ada di BidRequest.user.id. Misalnya, URL bidder http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% akan diganti dengan http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl pada waktu permintaan.

Jika ID Pengguna Google tidak diketahui, string kosong akan diganti, dengan hasil yang mirip dengan

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

Diganti dengan 1 untuk menunjukkan bahwa permintaan bid berasal dari perangkat seluler, atau 0 jika tidak. Hal ini didasarkan pada nilai BidRequest.device.devicetype, dengan perangkat seluler ditunjukkan oleh HIGHEND_PHONE (4) atau Tablet (5).
%%HAS_VIDEO%%

Diganti dengan 1 untuk menunjukkan bahwa permintaan bid berisi inventaris video, atau 0 jika tidak. Hal ini didasarkan pada apakah BidRequest.imp.video diisi dalam permintaan bid.
%%IS_CTV%%

Diganti dengan 1 untuk menunjukkan bahwa permintaan bid berasal dari perangkat CTV, atau 0 jika tidak. Hal ini didasarkan pada nilai BidRequest.device.devicetype. Untuk Protobuf, perangkat CTV adalah CONNECTED_TV, CONNECTED_DEVICE, atau SET_TOP_BOX, yang sesuai dengan nilai bilangan bulat 3, 6, atau 7 untuk JSON.
%%HOSTED_MATCH_DATA%%

Diganti dengan nilai berdasarkan BidRequest.user.buyeruid.

%%MOBILE_IS_APP%%

Diganti dengan 1 untuk menunjukkan bahwa permintaan bid adalah untuk inventaris aplikasi seluler, atau 0 jika tidak. Hal ini didasarkan pada apakah BidRequest.app diisi.

Menemukan ID aplikasi seluler dari URL transaksi

Transaksi aplikasi seluler akan melaporkan URL yang terlihat seperti ini:

mbappgewtimrzgyytanjyg4888888.com

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

Anda dapat menggunakan dekoder online, tetapi Anda harus menggunakan huruf kapital dan mengganti 8 di akhir dengan nilai =.

Jadi, mendekode nilai ini: 

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

Berikut contoh lainnya. URL yang dilaporkan adalah: 

mbappgewtgmjug4ytmmrtgm888888.com
 Mendekode 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
 Mendekode nilai ini: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 menghasilkan: 
air.com.hypah.io.slither
 Hasilnya sama dengan aplikasi Android slither.io.

Kolom Bidding Terbuka

Permintaan bid yang dikirim ke bidder bursa dan jaringan yang berpartisipasi dalam Bidding Terbuka mirip dengan permintaan bid Authorized Buyers yang berpartisipasi dalam bidding real-time standar. Pelanggan Bidding Terbuka akan menerima sejumlah kecil kolom tambahan, dan beberapa kolom yang ada mungkin memiliki penggunaan alternatif. Contoh ini meliputi:

OpenRTB Detail
BidRequest.imp.ext.dfp_ad_unit_code

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

Sebagai contoh, ini akan muncul dengan pemformatan yang serupa dengan: /1234/cruises/mars.
BidRequest.user.data.segment

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

Anda dapat menentukan bahwa nilai adalah pasangan nilai kunci yang dikirim oleh penayang saat BidRequest.user.data.name disetel ke “Publisher Passed”.

Mendeklarasikan vendor yang diizinkan

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

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

  1. Beberapa vendor tidak perlu dinyatakan; vendor ini tercantum di Vendor Eksternal Tersertifikasi Ad Manager.
  2. Vendor lain hanya dapat berpartisipasi jika mereka dinyatakan dalam BidRequest:
    • Di BidRequest, kolom BidRequest.imp.ext.allowed_vendor_type menentukan vendor yang diizinkan oleh penjual. Vendor yang akan dikirim dalam allowed_vendor_type tercantum dalam file kamus vendors.txt.

Contoh permintaan bid

Contoh berikut menunjukkan contoh permintaan Protobuf dan JSON yang dapat dibaca manusia.

Protobuf OpenRTB

JSON OpenRTB

Untuk mengonversi permintaan bid ke dalam bentuk biner, seperti yang akan Anda dapatkan dari payload POST dalam permintaan sebenarnya, Anda dapat melakukan hal berikut (di C++). Namun, perhatikan bahwa hal ini tidak berlaku untuk JSON OpenRTB.

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

Masukan real-time

Masukan real-time tersedia untuk Authorized Buyers, serta bursa dan jaringan yang menggunakan Bidding Terbuka.

Masukan real-time diisi di BidRequest.ext.bid_feedback berdasarkan hasil satu atau beberapa bid yang Anda ajukan sebelumnya, dan dapat digunakan untuk menemukan detail seperti apakah bid memenangkan lelang, atau bid minimum yang diperlukan untuk memenangkan lelang. Hubungi pengelola akun Anda untuk mengaktifkan masukan real-time.

Selain kolom default yang dikirim dalam Masukan Respons Bid, Anda juga dapat mengirim data kustom dalam respons bid menggunakan kolom BidResponse.seatbid.bid.ext.event_notification_token. event_notification_token adalah data arbitrer yang hanya diketahui oleh bidder yang mungkin membantu proses debug, misalnya: 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 file OpenRTB Extensions Protocol Buffer.

Saat Authorized Buyers mengirimkan permintaan bid kepada bidder, bidder akan membalas dengan BidResponse. Jika bidder mengaktifkan masukan real-time, maka dalam permintaan bid berikutnya, Authorized Buyers akan mengirimkan masukan tentang respons dalam pesan BidFeedback:

message BidFeedback {
  // The unique id from BidRequest.id.
  optional string request_id = 1;

  // The status code for the ad. See creative-status-codes.txt in the
  // technical documentation for a list of ids.
  optional int32 creative_status_code = 2;

  // Deprecated. This field is not populated and will be removed after March,
  // 2025. If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional double price = 3 [deprecated = true];

  // The minimum bid value necessary to have won the auction, in your account
  // currency. If your bid won the auction, this is the second highest bid
  // that was not filtered (including the floor price). If your bid didn't win
  // the auction, this is the winning candidate's bid. This field will only be
  // populated if your bid participated in a first-price auction, and will not
  // be populated if your bid was filtered prior to the auction.
  optional double minimum_bid_to_win = 6;

  // Billable event rate multiplier that was applied to this bid during
  // ranking. The adjustment reflects the likelihood that your bid would
  // generate a billable event (namely, the ad renders successfully) if it won
  // the auction, relative to the probability that other bids generate a
  // billable event if they won the auction. This adjustment can be larger or
  // smaller than 1. This affects the final ranking in the auction only; in
  // particular, this multiplier does not affect the payment or whether the
  // bid clears any floor price.
  optional float billable_event_rate_bid_adjustment = 13 [default = 1];

  // When a publisher uses an RTB auction and waterfall-based SDK mediation on
  // the same query, the winner of the real-time auction must also compete in
  // a mediation waterfall (which is ordered by price) to win the impression.
  // If the bid participated in the auction and there was no waterfall, the
  // value of this field is 0. If the bid participated in the auction and
  // there was a waterfall, the value of this field is a price representing a
  // sample bid from the eligible mediation networks that were higher than the
  // auction winner, weighted by expected fill rate. This field can be used
  // in conjunction with minimum_bid_to_win to train bidding models. The CPM
  // is in your account currency.
  optional double sampled_mediation_cpm_ahead_of_auction_winner = 8;

  message EventNotificationToken {
    // The contents of the token.
    optional string payload = 1;
  }

  // The token included in the corresponding bid.
  optional EventNotificationToken event_notification_token = 4;

  // The creative ID included in the corresponding bid.
  optional string buyer_creative_id = 5;
}

Dari pesan ini, kolom pertama yang harus Anda periksa adalah bid_feedback.creative_status_code; Anda dapat menemukan arti kode di creative-status-codes.txt. Perhatikan bahwa jika Anda memenangkan bid, Anda dapat memilih untuk tidak menerima masukan harga. Untuk mengetahui informasi selengkapnya, lihat Cara menonaktifkan.

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

Hasil lelang Masukan real-time
Pembeli tidak mengajukan bid. Tidak ada.
Pembeli mengirimkan 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 (kalah bid dalam lelang).
Pembeli mengirimkan bid yang memenangkan lelang. Harga pembersihan dan kode status materi iklan 1.

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

Contoh

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

Protobuf OpenRTB

JSON OpenRTB

Membangun model bidding untuk lelang harga pertama

Setelah mengajukan bid dalam lelang harga pertama, Anda akan menerima masukan real-time, termasuk kolom minimum_bid_to_win dan sampled_mediation_cpm_ahead_of_auction_winner jika bid tidak difilter dari lelang. Sinyal ini dapat digunakan untuk menginformasikan logika bidding Anda tentang seberapa tinggi atau rendah bid Anda seharusnya agar dapat memenangkan tayangan iklan.

  • minimum_bid_to_win: Bid minimum yang dapat diajukan untuk memenangkan lelang bidding real-time. Jika Anda memenangkan lelang, ini akan menjadi bid terendah yang dapat Anda ajukan sambil tetap menang. Jika Anda kalah dalam lelang, ini akan menjadi bid yang menang.
  • sampled_mediation_cpm_ahead_of_auction_winner: Jika ada jaringan lain dalam rantai mediasi, nilai kolom ini adalah harga yang mewakili contoh bid dari salah satu jaringan mediasi yang memenuhi syarat yang lebih tinggi daripada pemenang lelang, yang diberi bobot berdasarkan rasio pengisian yang diharapkan. Nilai ini akan ditetapkan ke 0 jika tidak ada jaringan dalam rantai mediasi yang diharapkan akan mengisi, atau jika penayang tidak menggunakan mediasi SDK.

Cara kerjanya

Untuk menjelaskan penghitungan yang digunakan untuk menentukan kemungkinan nilai untuk minimum_bid_to_win dan sampled_mediation_cpm_ahead_of_auction_winner, pertama-tama kita perlu menentukan hal berikut:

  • Berikut adalah CPM dalam rantai mediasi dalam urutan menurun:
    \[C_1, C_2, …, C_n\]
  • Berikut adalah rasio pengisian yang sesuai untuk CPM dalam rantai mediasi:
    \[f_1, f_2, …, f_n\]
  • Berikut adalah fungsi yang digunakan untuk menentukan CPM yang diharapkan dan probabilitasnya dari elemen rantai mediasi \(i\), berdasarkan rasio pengisian yang diberikan:
    \(X_i = \{C_i\) dengan probabilitas \(f_i\); \(0\) dengan probabilitas \(1 - f_i\}\)
  • Rantai mediasi pemenang akhir akan menjadi:
    \[\{C_1, C_2, …, C_K, W\}\]
    dengan \(W\) adalah bid yang menang, dan \(C_K > W >= C_{K+1}\)
  • Harga minimum, atau minimum, dilambangkan sebagai \(F\).
  • Bid runner-up dilambangkan 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 peserta lelang yang kalah
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:

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 (W) $1,00
Runner-UP Lelang (R) $0,05
Harga Minimum / Harga Dasar (F) $0
Bid yang memenangkan lelang

Berikut adalah contoh cara 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 adalah contoh cara menghitung nilai dan probabilitas untuk minimum_bid_to_win dan sampled_mediation_cpm_ahead_of_auction_winner 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\%\)

Pemerataan bid

Pemisahan bid menjelaskan pemrosesan satu BidRequest yang kompleks menjadi beberapa permintaan bid yang dikirim ke aplikasi Anda. Saat permintaan bid di-flatten, Anda dapat mengetahui permintaan bid mana yang merupakan bagian dari permintaan bid asli karena permintaan bid tersebut akan memiliki nilai yang sama di kolom BidRequest.ext.google_query_id.

Perataan bid diaktifkan secara default, tetapi Anda dapat menghubungi Account Manager Anda jika ingin menonaktifkannya.

Format iklan

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

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

  • Banner
  • Video
  • Audio
  • Native

Contoh perataan format iklan

Berikut adalah contoh yang menunjukkan permintaan bid JSON OpenRTB yang disederhanakan tanpa perataan format iklan dibandingkan dengan kumpulan permintaan yang diratakan yang setara:

Pra-ratakan

Pasca-perataan

Promo

Peluang iklan untuk bidder tertentu dapat berlaku untuk berbagai jenis transaksi, selain lelang terbuka. Dengan pemisahan bid untuk transaksi, satu permintaan bid akan dikirim untuk lelang terbuka, dan satu permintaan bid untuk setiap jenis transaksi harga tetap. Dalam praktiknya, batasan iklan dapat berbeda antara lelang dan jenis penawaran harga tetap, misalnya, untuk peluang iklan video tertentu yang tersedia untuk lelang terbuka dan penawaran harga tetap, bidder akan menerima permintaan bid yang berbeda untuk setiap jenis kesepakatan tersebut, dengan batasan seperti durasi iklan maksimum dan apakah iklan yang dapat dilewati diizinkan atau tidak. Hasilnya, perataan yang diterapkan pada peluang iklan memungkinkan Anda membedakan batasan iklan untuk lelang terbuka dan transaksi harga tetap dengan lebih mudah.

Batas Waktu dan Durasi Video

Spesifikasi OpenRTB tidak memiliki kolom terpisah untuk menentukan durasi video maksimum iklan yang dapat dilewati dan tidak dapat dilewati. Penerapan Google menggunakan perataan bid untuk membedakan keduanya menggunakan kolom BidRequest.video.maxduration dan BidRequest.video.skip yang ada.

Berikut adalah contoh cara inventaris video diratakan jika durasi maksimum iklan yang tidak dapat dilewati adalah 15 dan durasi maksimum iklan yang dapat dilewati adalah 60.

Contoh max_ad_duration skip (benar OR salah)
Permintaan asli tanpa perataan 15 true
Permintaan yang diratakan #1: Tidak dapat dilewati 15 false
Permintaan yang disatukan #2: Dapat dilewati 60 true

Perataan permintaan bid durasi video yang dapat dilewati hanya akan terjadi jika kondisi berikut terpenuhi:

  • Permintaan ini mengizinkan video.
  • Video yang dapat dilewati dan tidak dapat dilewati diizinkan, dan kedua durasi maksimum masing-masing memiliki nilai yang berbeda.
  • Permintaan ini memenuhi syarat untuk Lelang Pribadi atau Lelang Terbuka.

Anda dapat memilih untuk tidak menggunakan perataan jenis ini dengan menghubungi pengelola akun teknis Anda. Jika dinonaktifkan, dan penayang mengizinkan iklan video yang dapat dilewati dan tidak dapat dilewati dengan durasi maksimum yang berbeda berdasarkan kemampuan untuk dilewati, skip akan ditetapkan ke true dan maxduration akan ditetapkan ke durasi yang lebih singkat antara batasan iklan yang dapat dilewati dan tidak dapat dilewati.

Pod video

Permintaan bid untuk pod video dengan beberapa peluang iklan akan diratakan, 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 lingkungan aplikasi seluler.

Anda dapat menentukan apakah penayang mendukung Pengukuran Terbuka dalam permintaan bid dengan memeriksa apakah peluang iklan mengecualikan atribut OmsdkType: OMSDK 1.0 yang ditemukan di Atribut materi iklan yang dapat dikecualikan penayang. Atribut ini dapat ditemukan di bagian atribut battr untuk Banner atau Video, bergantung pada formatnya.

Untuk mengetahui informasi selengkapnya tentang cara menafsirkan permintaan bid yang berisi sinyal Pengukuran Terbuka, lihat artikel Pusat Bantuan SDK Pengukuran Terbuka.

Contoh permintaan bid

Bagian berikut menunjukkan contoh permintaan bid untuk berbagai jenis iklan.

Banner aplikasi

Protobuf OpenRTB

JSON OpenRTB

Interstisial aplikasi

Protobuf OpenRTB

JSON OpenRTB

Video interstisial aplikasi

Protobuf OpenRTB

JSON OpenRTB

Native aplikasi

Protobuf OpenRTB

JSON OpenRTB

Video web

Protobuf OpenRTB

JSON OpenRTB

Banner web seluler untuk bidder bursa

Protobuf OpenRTB

JSON OpenRTB

Native dan Video Multiformat

Protobuf OpenRTB

JSON OpenRTB