ประมวลผลคำขอ

การโต้ตอบกับการเสนอราคาแบบเรียลไทม์จะเริ่มขึ้นเมื่อ Google ส่งคําขอราคาเสนอไปยังแอปพลิเคชันของคุณ คู่มือนี้จะอธิบายวิธีเขียนโค้ดแอปพลิเคชันเพื่อประมวลผลคําขอราคาเสนอ

แยกวิเคราะห์คําขอ Protobuf

Google ส่งคําขอราคาเสนอเป็นบัฟเฟอร์โปรโตคอลที่แปลงเป็นอนุกรมซึ่งแนบมากับเพย์โหลดไบนารีของคําขอ HTTP POST ตั้งค่า Content-Type เป็น application/octet-stream ดูตัวอย่างได้ที่ตัวอย่างคําขอราคาเสนอ

คุณต้องแยกวิเคราะห์คําขอนี้เป็นอินสแตนซ์ของBidRequest ข้อความ BidRequest จะได้รับการกําหนดใน openrtb.proto หรือ realtime-bidding.proto ที่เลิกใช้งานแล้ว ทั้งนี้ขึ้นอยู่กับโปรโตคอลที่คุณเลือก ซึ่งดูได้จากหน้าข้อมูลอ้างอิง คุณสามารถแยกวิเคราะห์ข้อความได้โดยใช้เมธอด ParseFromString() ในคลาสที่สร้างขึ้นสำหรับ BidRequest ตัวอย่างเช่น โค้ด C++ ต่อไปนี้จะแยกวิเคราะห์คําขอจากเพย์โหลด POST ในสตริง 

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

เมื่อได้ BidRequest แล้ว คุณจะทํางานกับ BidRequest ในรูปแบบออบเจ็กต์ได้ ซึ่งจะดึงข้อมูลและตีความช่องที่ต้องการ ตัวอย่างเช่น ใน C++ การวนดูดีลใน `BidRequest` ของ OpenRTB อาจมีลักษณะดังนี้

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

รหัสการเรียกเก็บเงิน

คุณจะได้รับคําขอราคาเสนอเมื่อพื้นที่โฆษณาของผู้เผยแพร่โฆษณาได้รับการกําหนดเป้าหมายโดย การกำหนดค่าการกำหนดเป้าหมายล่วงหน้าอย่างน้อย 1 รายการ BidRequest.imp.ext.billing_id จะสร้างขึ้นด้วยรหัสการเรียกเก็บเงินของผู้ซื้อที่มีสิทธิ์และการกําหนดค่าการกําหนดเป้าหมายเบื้องต้นที่เกี่ยวข้อง นอกจากนี้ คุณยังดูรหัสการเรียกเก็บเงินที่เชื่อมโยงกับผู้ซื้อที่เกี่ยวข้องสำหรับพื้นที่โฆษณาของดีลได้โดยใช้ BidRequest.imp.pmp.deal.ext.billing_id คุณจะระบุได้เฉพาะรหัสการเรียกเก็บเงินของผู้ซื้อที่รวมอยู่ในคำขอราคาเสนอเมื่อเสนอราคา

หากมีรหัสการเรียกเก็บเงินหลายรายการในคำขอราคาเสนอ คุณต้องระบุรหัสการเรียกเก็บเงินของผู้ซื้อที่คุณต้องการระบุแหล่งที่มาของราคาเสนอด้วยฟิลด์ BidResponse.seatbid.bid.ext.billing_id

ไฟล์พจนานุกรม

คําขอราคาเสนอใช้ตัวระบุที่กําหนดไว้ในไฟล์พจนานุกรม ซึ่งดูได้ในหน้าข้อมูลอ้างอิง

มาโคร URL การเสนอราคาของโปรโตคอล RTB ของ Google

คุณอาจแทรกช่องบางส่วนของ BidRequest ลงใน URL ที่ใช้กับคำขอ HTTP POST ได้ การดำเนินการนี้มีประโยชน์ เช่น หากคุณใช้ฟีดด้านหน้าแบบเบาที่กระจายภาระงานไปยังแบ็กเอนด์หลายรายการโดยใช้ค่าจากคำขอ โปรดติดต่อผู้จัดการฝ่ายดูแลลูกค้าด้านเทคนิคเพื่อขอรับการสนับสนุนสำหรับมาโครใหม่

มาโครคำอธิบาย
%%GOOGLE_USER_ID%%

แทนที่ด้วย google_user_id จาก BidRequest เช่น URL ของผู้เสนอราคา 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
 จะแทนที่ด้วยข้อความประมาณนี้ 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
 ณ เวลาส่งคำขอ

หากไม่ทราบรหัสผู้ใช้ Google ระบบจะแทนที่ด้วยสตริงว่าง โดยมีผลลัพธ์คล้ายกับ

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

แทนที่ด้วย 1 หรือ 0 เมื่อเรียกใช้ has_mobile() ของ BidRequest
%%HAS_VIDEO%%

แทนที่ด้วย 1 (จริง) หรือ 0 (เท็จ) เมื่อเรียกใช้ has_video() ของ BidRequest
%%HOSTED_MATCH_DATA%%

แทนที่ด้วยค่าของช่อง hosted_match_data จาก BidRequest
%%MOBILE_IS_APP%%

แทนที่ด้วย 1 (จริง) หรือ 0 (เท็จ) จากช่อง mobile.is_app ของ BidRequest

ค้นหารหัสแอปบนอุปกรณ์เคลื่อนที่จาก URL ของธุรกรรม

ธุรกรรมแอปพลิเคชันบนอุปกรณ์เคลื่อนที่จะรายงาน URL ที่มีลักษณะดังนี้

mbappgewtimrzgyytanjyg4888888.com

ใช้เครื่องมือถอดรหัสฐาน 32 เพื่อถอดรหัสส่วนของสตริงที่เป็นตัวหนา (gewtimrzgyytanjyg4888888)

คุณสามารถใช้โปรแกรมถอดรหัสออนไลน์ได้ แต่จะต้องเปลี่ยนตัวอักษรเป็นตัวพิมพ์ใหญ่และแทนที่ 8 ต่อท้ายด้วยค่า =

ดังนั้นการถอดรหัสค่านี้ 

GEWTIMRZGYYTANJYG4======
 ให้ผลลัพธ์ดังนี้ 
1-429610587
 สตริง 429610587 คือรหัสแอปสําหรับแอป iOS iFunny

มาดูตัวอย่างอื่นกัน URL ที่รายงานคือ 

mbappgewtgmjug4ytmmrtgm888888.com
 การถอดรหัสค่านี้ 
GEWTGMJUG4YTMMRTGM======
 จะให้ผลลัพธ์ดังนี้ 
1-314716233
 ผลลัพธ์ 314716233 คือรหัสแอปสําหรับแอป iOS TextNow

ค้นหาชื่อแอปบนอุปกรณ์เคลื่อนที่จาก URL ของธุรกรรม

ต่อไปนี้คือตัวอย่างการเรียกชื่อแอป URL ที่รายงานมีดังนี้ 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 การถอดรหัสค่านี้ 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 ให้ผลลัพธ์ดังนี้ 
air.com.hypah.io.slither
 ผลลัพธ์เทียบเท่ากับแอป Android slither.io

ช่องการเสนอราคาแบบเปิด

คําขอราคาเสนอที่ส่งไปยังผู้เสนอราคา Exchange และเครือข่ายที่เข้าร่วมการเสนอราคาแบบเปิดจะคล้ายกับคําขอของ Authorized Buyers ที่เข้าร่วมการเสนอราคาแบบเรียลไทม์มาตรฐาน ลูกค้าของการเสนอราคาแบบเปิดจะได้รับช่องเพิ่มเติมจํานวนไม่มากนัก และช่องที่มีอยู่ 2-3 ช่องอาจมีการใช้งานทางเลือก ซึ่งรวมถึงแอปต่อไปนี้

OpenRTB Authorized Buyers รายละเอียด
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

มีรหัสเครือข่าย Ad Manager ของผู้เผยแพร่โฆษณาตามด้วยลําดับชั้นของหน่วยโฆษณา โดยคั่นด้วยเครื่องหมายทับ

ตัวอย่างเช่น ข้อความนี้จะปรากฏโดยมีการจัดรูปแบบคล้ายกับตัวอย่างต่อไปนี้ /1234/cruises/mars
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

คู่คีย์-ค่าที่ซ้ำกันซึ่งส่งจากผู้เผยแพร่โฆษณาไปยังผู้เสนอราคา Exchange

คุณสามารถระบุว่าค่าเป็นคู่คีย์-ค่าที่ผู้เผยแพร่โฆษณาส่งได้เมื่อตั้งค่า BidRequest.user.data[].name เป็น “Publisher Passed”

ประกาศผู้ให้บริการที่อนุญาต

ผู้ให้บริการเทคโนโลยีที่ให้บริการต่างๆ เช่น การวิจัย รีมาร์เก็ตติ้ง และการแสดงโฆษณา อาจมีส่วนเกี่ยวข้องกับการโต้ตอบระหว่างผู้ซื้อและผู้ขาย อนุญาตให้มีเฉพาะผู้ให้บริการที่ Google ตรวจสอบแล้วให้เข้าร่วมการโต้ตอบกับ Authorized Buyers

หากต้องการทําความเข้าใจBidRequestและสร้างBidResponse คุณต้องทราบถึง 2 วิธีที่แตกต่างกันในการประกาศผู้ให้บริการเทคโนโลยี ดังนี้

  1. ผู้ให้บริการบางรายไม่จําเป็นต้องประกาศ ผู้ให้บริการเหล่านี้จะแสดงอยู่ในผู้ให้บริการภายนอกที่ผ่านการรับรองจาก Ad Manager
  2. ผู้ให้บริการรายอื่นๆ จะเข้าร่วมได้ก็ต่อเมื่อมีการประกาศไว้ใน BidRequest
    • ใน BidRequest ช่อง BidRequest.imp.ext.allowed_vendor_type จะระบุผู้ให้บริการที่ผู้ขายอนุญาต ผู้ให้บริการที่จะส่งใน allowed_vendor_type จะแสดงอยู่ในไฟล์พจนานุกรม vendors.txt

ตัวอย่างคำขอราคาเสนอ

ตัวอย่างต่อไปนี้แสดงตัวอย่างคําขอ Protobuf และ JSON ที่มนุษย์อ่านได้

OpenRTB Protobuf

OpenRTB JSON

Google (เลิกใช้งานแล้ว)

หากต้องการแปลงคําขอราคาเสนอเป็นรูปแบบไบนารี เช่น ที่คุณได้รับจากเพย์โหลด POST ในคําขอจริง ให้ทําดังนี้ (ใน C++) อย่างไรก็ตาม โปรดทราบว่าวิธีนี้ใช้ไม่ได้กับ 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
  }
}

ความคิดเห็นแบบเรียลไทม์

ผู้ซื้อที่ได้รับอนุญาต รวมถึง Exchange และเครือข่ายที่ใช้การเสนอราคาแบบเปิดจะได้รับความคิดเห็นแบบเรียลไทม์

ระบบรองรับการแสดงความคิดเห็นเกี่ยวกับการเสนอราคาตอบในคำขอราคาเสนอที่ตามมาสำหรับทั้งโปรโตคอล OpenRTB และ Google RTB ที่เลิกใช้งานแล้ว สำหรับ OpenRTB ระบบจะส่งใน BidRequest.ext.bid_feedback

นอกจากช่องเริ่มต้นที่ส่งในความคิดเห็นเกี่ยวกับการเสนอราคาตอบแล้ว คุณยังส่งข้อมูลที่กำหนดเองในการเสนอราคาตอบได้โดยใช้ช่อง BidResponse.seatbid.bid.ext.event_notification_token event_notification_token คือข้อมูลที่กำหนดเองซึ่งผู้เสนอราคาเท่านั้นที่ทราบ ซึ่งอาจช่วยในการแก้ไขข้อบกพร่อง เช่น รหัสการกำหนดเป้าหมายหรือรหัสการเสนอราคาใหม่ซึ่งแสดงถึงกลยุทธ์ใหม่ หรือข้อมูลเมตาที่เชื่อมโยงกับครีเอทีฟโฆษณาซึ่งผู้เสนอราคาเท่านั้นที่ทราบ ดูรายละเอียดได้ที่บัฟเฟอร์โปรโตคอลส่วนขยาย OpenRTB สำหรับ OpenRTB หรือโปรโตคอล Google RTB ที่เลิกใช้งานแล้ว

เมื่อ Authorized Buyers ส่งคำขอราคาเสนอไปยังผู้เสนอราคา ผู้เสนอราคาจะตอบกลับด้วย BidResponse หากผู้เสนอราคาเปิดใช้ความคิดเห็นแบบเรียลไทม์ไว้ ในคำขอราคาเสนอครั้งถัดไป Authorized Buyers จะส่งความคิดเห็นเกี่ยวกับการตอบกลับใน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;

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

จากข้อความนี้ ช่องแรกที่คุณควรตรวจสอบคือ bid_feedback.creative_status_code โดยดูความหมายของรหัสได้ใน creative-status-codes.txt โปรดทราบว่าหากชนะการเสนอราคา คุณจะเลือกไม่ใช้ความคิดเห็นเกี่ยวกับราคาได้ ดูข้อมูลเพิ่มเติมได้ที่วิธีเลือกไม่ใช้

ความคิดเห็นแบบเรียลไทม์ประกอบด้วยรหัสคำขอราคาเสนอและรายการต่อไปนี้

ผลการประมูล ความคิดเห็นแบบเรียลไทม์
ผู้ซื้อไม่ได้ส่งราคาเสนอ ไม่มี
ผู้ซื้อส่งราคาเสนอที่ถูกกรองออกก่อนที่จะเข้าสู่การประมูล รหัสสถานะครีเอทีฟโฆษณา (creative-status-codes.txt)
ผู้ซื้อส่งราคาเสนอแต่แพ้การประมูล รหัสสถานะครีเอทีฟโฆษณา 79 (ราคาเสนอสูงกว่าในการประมูล)
ผู้ซื้อส่งราคาเสนอที่ชนะการประมูล ราคาเคลียร์และรหัสสถานะครีเอทีฟโฆษณา 1

สําหรับการแสดงผลในแอปและรหัสสถานะครีเอทีฟโฆษณา 83 ผู้เผยแพร่โฆษณาแอปอาจใช้การแสดงโฆษณาสื่อกลางตามลำดับขั้น ดังนั้นราคาเสนอที่ชนะจึงต้องแข่งขันกับดีมานด์อื่นๆ ในเชนการแสดงโฆษณาสื่อกลางตามลำดับขั้นแบบส่งต่อของผู้เผยแพร่โฆษณา ดูวิธีใช้ sampled_mediation_cpm_ahead_of_auction_winner เมื่อเสนอราคา

ตัวอย่าง

ต่อไปนี้เป็นตัวอย่างของความคิดเห็นแบบเรียลไทม์ที่แสดงในโปรโตคอลที่รองรับ

OpenRTB Protobuf

OpenRTB JSON

Google (เลิกใช้งานแล้ว)

สร้างรูปแบบการเสนอราคาสําหรับการประมูลแบบใช้ราคาอันดับ 1

หลังจากเสนอราคาในการประมูลแบบใช้ราคาอันดับ 1 แล้ว คุณจะได้รับความคิดเห็นแบบเรียลไทม์ รวมถึงช่อง minimum_bid_to_win และ sampled_mediation_cpm_ahead_of_auction_winner หากระบบไม่ได้กรองราคาเสนอออกจากการประมูล สัญญาณเหล่านี้สามารถใช้เป็นข้อมูลในตรรกะการเสนอราคาเกี่ยวกับระดับราคาเสนอที่อาจสูงขึ้นหรือต่ำลงเพื่อรับการแสดงผล

  • minimum_bid_to_win: ราคาเสนอต่ำสุดที่เสนอเพื่อให้ชนะการประมูลแบบเรียลไทม์ หากคุณชนะการประมูล ราคาเสนอนี้จะเป็นราคาเสนอต่ำสุดที่คุณเสนอได้ในขณะที่ยังคงชนะ หากคุณแพ้การประมูล ราคาเสนอนี้จะเป็นราคาเสนอที่ชนะ
  • sampled_mediation_cpm_ahead_of_auction_winner: หากมีเครือข่ายอื่นๆ ในเชนสื่อกลาง ค่าของช่องนี้คือราคาที่แสดงราคาเสนอตัวอย่างจากเครือข่ายสื่อกลางที่มีสิทธิ์เครือข่ายใดเครือข่ายหนึ่งซึ่งสูงกว่าผู้ชนะการประมูล โดยถ่วงน้ำหนักตามอัตราการส่งโฆษณาที่คาดไว้ ระบบจะตั้งค่านี้เป็น 0 หากไม่มีเครือข่ายใดในเชนสื่อกลางที่คาดว่าจะแสดงโฆษณา หรือหากผู้เผยแพร่โฆษณาไม่ได้ใช้สื่อกลาง SDK

วิธีการทำงาน

หากต้องการอธิบายการคํานวณที่ใช้เพื่อระบุค่าที่เป็นไปได้สําหรับ minimum_bid_to_win และ sampled_mediation_cpm_ahead_of_auction_winner ก่อนอื่นเราต้องกําหนดสิ่งต่อไปนี้

  • ต่อไปนี้แสดง CPM ในเชนสื่อกลางตามลําดับจากมากไปน้อย
    \[C_1, C_2, …, C_n\]
  • ข้อมูลต่อไปนี้แสดงอัตราการส่งโฆษณาที่เกี่ยวข้องสําหรับ CPM ในเชนสื่อกลาง
    \[f_1, f_2, …, f_n\]
  • ฟังก์ชันต่อไปนี้ใช้เพื่อกําหนด CPM ที่คาดไว้และความน่าจะเป็นจากองค์ประกอบเชนสื่อกลาง \(i\)โดยอิงตามอัตราการส่งโฆษณาที่ระบุ
    \(X_i = \{C_i\) with probability \(f_i\); \(0\) with probability \(1 - f_i\}\)
  • เชนสื่อกลางที่ชนะในขั้นสุดท้ายจะเป็นเชนต่อไปนี้
    \[\{C_1, C_2, …, C_K, W\}\]
    โดยที่ \(W\) คือราคาเสนอที่ชนะ และ \(C_K > W >= C_{K+1}\)
  • ราคาเสนอขั้นต่ำหรือราคาพื้นจะแสดงเป็น \(F\)
  • ราคาเสนอของผู้ที่ได้อันดับ 2 จะแสดงเป็น \(R\)
การคํานวณสำหรับผู้ชนะการประมูล
ช่อง การคำนวณ
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) with probability \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
สำหรับ \(1 <= i <= K\)
การคำนวณสำหรับผู้แพ้การประมูล
ช่อง การคำนวณ
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

ตัวอย่างที่มีเชนสื่อกลางแบบง่าย

สมมติว่าผู้เผยแพร่โฆษณาใช้ทั้งการเสนอราคาแบบเรียลไทม์และเชนสื่อกลาง SDK ดังนี้

เชนสื่อกลาง SDK CPM ที่คาดไว้ อัตราการส่งโฆษณา
เครือข่าย 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
เครือข่าย 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
เครือข่าย 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
เครือข่าย 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

สมมติว่าผลลัพธ์ของการประมูล RTB ดังต่อไปนี้

การประมูล RTB CPM
ผู้ชนะการประมูล (W) $1.00
ผู้เข้าร่วมการประมูลรองชนะเลิศ (R) $0.05
ราคาจอง / ราคาพื้น (F) $0
ราคาเสนอที่ชนะการประมูล

ต่อไปนี้เป็นตัวอย่างวิธีคํานวณค่าและแนวโน้มสําหรับ minimum_bid_to_win และ sampled_mediation_cpm_ahead_of_auction_winner ของราคาเสนอที่ชนะ

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\%\)
ราคาเสนอที่แพ้การประมูล

ต่อไปนี้เป็นตัวอย่างวิธีคํานวณค่าและความน่าจะเป็นสําหรับ minimum_bid_to_win และ sampled_mediation_cpm_ahead_of_auction_winner ของราคาเสนอที่แพ้

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

การแยกการเสนอราคา

การแยกคำขอราคาเสนออธิบายการประมวลผลBidRequestที่ซับซ้อนรายการเดียวออกเป็นคำขอราคาเสนอหลายรายการที่ส่งไปยังแอปพลิเคชัน เมื่อมีการยุบคำขอราคาเสนอ คุณจะบอกได้ว่าคำขอราคาเสนอใดเป็นส่วนหนึ่งของคำขอเดิม เนื่องจากจะมีค่าเหมือนกันในช่อง BidRequest.ext.google_query_id

ระบบจะเปิดใช้การรวมราคาเสนอโดยค่าเริ่มต้น แต่คุณติดต่อผู้จัดการฝ่ายดูแลลูกค้าได้หากต้องการปิดใช้

รูปแบบโฆษณา

โอกาสในการลงโฆษณาบางรายการยอมรับรูปแบบได้หลายรูปแบบ เมื่อใช้การแยกราคาเสนอ ระบบจะส่งแต่ละรูปแบบในคำขอราคาเสนอที่แตกต่างกัน โดยแอตทริบิวต์ต่างๆ เช่น รหัสการเรียกเก็บเงินที่มีสิทธิ์จะเกี่ยวข้องกับรูปแบบที่ระบุในคำขอ

ระบบจะแยกคำขอราคาเสนอที่มีรูปแบบต่อไปนี้ออกเป็นคำขอราคาเสนอที่แยกต่างหาก

  • แบนเนอร์
  • วิดีโอ
  • เสียง
  • เนทีฟ

ตัวอย่างการแปลงรูปแบบโฆษณา

ด้านล่างนี้คือตัวอย่างที่แสดงคำขอราคาเสนอ JSON ของ OpenRTB แบบง่ายโดยไม่มีการแยกรูปแบบโฆษณา เมื่อเทียบกับชุดคำขอแบบแบนเทียบเท่า

ปรับให้แบนล่วงหน้า

หลังการผสาน

ดีล

โอกาสในการลงโฆษณาสำหรับผู้เสนอราคารายหนึ่งอาจใช้ได้กับดีลประเภทต่างๆ นอกเหนือจากการประมูลแบบเปิด เมื่อใช้การแยกการเสนอราคาสำหรับดีล ระบบจะส่งคำขอราคาเสนอ 1 รายการสําหรับการประมูลแบบเปิด และ 1 รายการสําหรับดีลราคาคงที่แต่ละประเภท ในทางปฏิบัติ ข้อจำกัดของโฆษณาอาจแตกต่างกันระหว่างประเภทการประมูลและดีลราคาคงที่ เช่น สําหรับโอกาสโฆษณาวิดีโอหนึ่งๆ ที่พร้อมใช้งานสําหรับทั้งการประมูลแบบเปิดและดีลราคาคงที่ ผู้เสนอราคาจะได้รับคําขอราคาเสนอที่แตกต่างกันสําหรับแต่ละรายการ โดยข้อจํากัดต่างๆ เช่น ระยะเวลาสูงสุดของโฆษณาและอนุญาตให้ใช้โฆษณาแบบข้ามได้หรือไม่อาจแตกต่างกัน ด้วยเหตุนี้ การแปลงค่าที่ใช้กับโอกาสในการโฆษณาจึงช่วยให้คุณแยกแยะข้อจำกัดของโฆษณาสําหรับการประมูลแบบเปิดและดีลราคาคงที่ได้ง่ายขึ้น

ระยะเวลาสูงสุดของวิดีโอแบบข้ามได้

โปรโตคอลของ Google และการใช้งาน OpenRTB รองรับฟิลด์ต่อไปนี้สำหรับระยะเวลาของวิดีโอและความสามารถในการข้าม

ระยะเวลา ระยะเวลาที่ข้ามได้ ความสามารถในการข้าม
โปรโตคอลของ Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration ไม่มี skip

ซึ่งหมายความว่าแม้ว่าโปรโตคอล Google จะมีระยะเวลาที่ข้ามได้และข้ามไม่ได้แบบละเอียด แต่การใช้งาน OpenRTB จะมีค่าระยะเวลาสูงสุดเพียงค่าเดียว

ก่อนการแปลงราคาเสนอเป็นราคาเดียว ระบบจะตั้งค่า maxduration ของ OpenRTB เป็นค่าที่ต่ำกว่าของช่อง max_ad_duration และ skippable_max_ad_duration ของโปรโตคอล Google ตอนนี้ลักษณะการทำงานนี้เปลี่ยนไปเป็นการส่งคําขอราคาเสนอ 2 รายการแยกกันเมื่อค่าเหล่านี้แตกต่างกัน โดยค่าหนึ่งแสดง maxduration สําหรับโอกาสแบบข้ามได้ และอีกค่าหนึ่งแสดงโอกาสแบบข้ามไม่ได้

ตัวอย่างต่อไปนี้แสดงวิธีที่คำขอโปรโตคอล Google แปลเป็น OpenRTB ก่อนและหลังการแปลงราคาเสนอ คำขอโปรโตคอล Google ที่เทียบเท่ามีmax_ad_durationเท่ากับ 15 และskippable_max_ad_durationเท่ากับ 60

ตัวอย่าง max_ad_duration skip (true OR false)
คำขอเดิมแบบไม่แผ่ 15 true
คําขอที่ผสานรวม #1: ข้ามไม่ได้ 15 false
คำขอที่แยกเป็นหลายรายการ #2: ข้ามได้ 60 true

การแยกคําขอราคาเสนอตามระยะเวลาของวิดีโอแบบข้ามได้จะเกิดขึ้นก็ต่อเมื่อเป็นไปตามเงื่อนไขต่อไปนี้เท่านั้น

  • คำขออนุญาตให้มีวิดีโอ
  • อนุญาตให้ใช้ทั้งวิดีโอแบบข้ามได้และข้ามไม่ได้ และระยะเวลาสูงสุดของวิดีโอแต่ละประเภทจะแตกต่างกัน
  • คําขอนี้มีสิทธิ์ใช้การประมูลแบบเปิดหรือการประมูลส่วนตัว
  • บัญชีผู้เสนอราคามีปลายทาง OpenRTB ที่ใช้งานอยู่

คุณเลือกไม่ใช้การแยกประเภทนี้ได้โดยติดต่อผู้จัดการลูกค้าด้านเทคนิค

พ็อดวิดีโอ

ระบบจะรวมคำขอราคาเสนอสำหรับพ็อดวิดีโอที่มีโอกาสโฆษณาหลายรายการเข้าด้วยกันเพื่อให้คำขอราคาเสนอแต่ละรายการมีไว้สำหรับโอกาสโฆษณาแต่ละรายการจากพ็อดนั้น ซึ่งจะช่วยให้คุณเสนอราคาสำหรับโอกาสในการแสดงโฆษณาหลายรายการสำหรับพ็อดหนึ่งๆ ได้

การวัดผลแบบเปิด

Open Measurement ช่วยให้คุณระบุผู้ให้บริการบุคคลที่สามที่ให้บริการวัดผลและยืนยันตัวตนอิสระสําหรับโฆษณาที่แสดงในสภาพแวดล้อมแอปบนอุปกรณ์เคลื่อนที่ได้

คุณสามารถดูว่าผู้เผยแพร่โฆษณารองรับการวัดผลแบบเปิดในคำขอราคาเสนอหรือไม่โดยตรวจสอบว่าโอกาสในการโฆษณายกเว้นแอตทริบิวต์ OmsdkType: OMSDK 1.0 ที่พบในแอตทริบิวต์ครีเอทีฟโฆษณาที่ผู้เผยแพร่โฆษณายกเว้นได้หรือไม่ ซึ่งจะอยู่ในbattr แอตทริบิวต์สำหรับแบนเนอร์หรือวิดีโอ ทั้งนี้ขึ้นอยู่กับรูปแบบ

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีตีความคําขอราคาเสนอที่มีสัญญาณการวัดผลแบบเปิดได้ที่บทความSDK การวัดผลแบบเปิดในศูนย์ช่วยเหลือ

ตัวอย่างคำขอราคาเสนอ

ส่วนต่อไปนี้แสดงตัวอย่างคําขอราคาเสนอสําหรับโฆษณาประเภทต่างๆ

แบนเนอร์ของแอป

OpenRTB Protobuf

OpenRTB JSON

Google (เลิกใช้งานแล้ว)

โฆษณาคั่นระหว่างหน้าในแอป

OpenRTB Protobuf

OpenRTB JSON

Google (เลิกใช้งานแล้ว)

โฆษณาคั่นระหว่างหน้าแบบวิดีโอในแอป

OpenRTB Protobuf

OpenRTB JSON

Google (เลิกใช้งานแล้ว)

ในแอป

OpenRTB Protobuf

OpenRTB JSON

Google (เลิกใช้งานแล้ว)

วิดีโอบนเว็บ

OpenRTB Protobuf

OpenRTB JSON

Google (เลิกใช้งานแล้ว)

แบนเนอร์บนเว็บในอุปกรณ์เคลื่อนที่สำหรับผู้เสนอราคา Exchange

OpenRTB Protobuf

OpenRTB JSON

เนทีฟและวิดีโอแบบหลายรูปแบบ

OpenRTB Protobuf

OpenRTB JSON

Google (เลิกใช้งานแล้ว)