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

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

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

Google ส่งคําขอราคาเสนอที่แปลงเป็นรูปแบบ OpenRTB JSON หรือ Protobuf โดยแนบมากับเพย์โหลดของคําขอ HTTP POST รูปแบบที่ได้รับจะขึ้นอยู่กับการกำหนดค่าปลายทาง ดูตัวอย่างได้ที่ตัวอย่างคําขอราคาเสนอ

คุณต้องแยกวิเคราะห์คําขอนี้เพื่อรับBidRequestที่แปลงเป็นอนุกรม หากใช้รูปแบบ Protobuf คุณต้องดาวน์โหลด openrtb.proto และ openrtb-adx.proto จากหน้าข้อมูลอ้างอิง และใช้เพื่อสร้างไลบรารีที่ใช้แยกวิเคราะห์ข้อความ 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 ของผู้เสนอราคา

คุณอาจแทรกข้อมูลบางอย่างจาก BidRequest ลงใน URL ปลายทางของการเสนอราคาโดยใช้มาโคร หากคุณกําหนดค่า URL ปลายทางด้วยมาโครอย่างน้อย 1 รายการ ระบบจะขยาย URL เหล่านั้นหากมีข้อมูลดังกล่าวอยู่ในคําขอราคาเสนอ ซึ่งจะมีประโยชน์ในกรณีต่างๆ เช่น หากต้องการใช้การกระจายภาระตามข้อมูลใน BidRequest โปรดติดต่อผู้จัดการฝ่ายดูแลลูกค้าเพื่อขอรับการสนับสนุนเกี่ยวกับมาโครใหม่

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

แทนที่ด้วยรหัสผู้ใช้ Google ที่พบใน BidRequest.user.id เช่น ระบบจะแทนที่ URL ของผู้เสนอราคา http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% ด้วย URL ประมาณ http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl ณ เวลาที่มีคำขอ

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

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

แทนที่ด้วย 1 เพื่อระบุว่าคำขอราคาเสนอมาจากอุปกรณ์เคลื่อนที่ หรือ 0 หากไม่ใช่ ซึ่งอิงตามค่าของ BidRequest.device.devicetype โดยอุปกรณ์เคลื่อนที่จะระบุด้วย HIGHEND_PHONE (4) หรือ Tablet (5)
%%HAS_VIDEO%%

แทนที่ด้วย 1 เพื่อระบุว่าคำขอราคาเสนอมีพื้นที่โฆษณาวิดีโอ หรือ 0 หากไม่ใช่ ซึ่งขึ้นอยู่กับว่ามีการป้อนข้อมูล BidRequest.imp.video ในคำขอราคาเสนอหรือไม่
%%HOSTED_MATCH_DATA%%

แทนที่ด้วยค่าตาม BidRequest.user.buyeruid

%%MOBILE_IS_APP%%

แทนที่ด้วย 1 เพื่อระบุว่าคำขอราคาเสนอมีไว้สำหรับพื้นที่โฆษณาแอปบนอุปกรณ์เคลื่อนที่ หรือ 0 หากไม่ใช่ ซึ่งขึ้นอยู่กับว่ามีการป้อนข้อมูล BidRequest.app หรือไม่

ค้นหารหัสแอปบนอุปกรณ์เคลื่อนที่จาก 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 รายละเอียด
BidRequest.imp.ext.dfp_ad_unit_code

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

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

คู่คีย์-ค่าที่ซ้ำกันซึ่งส่งจากผู้เผยแพร่โฆษณาไปยังผู้เสนอราคา 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

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

ความคิดเห็นแบบเรียลไทม์จะป้อนข้อมูลลงใน BidRequest.ext.bid_feedback โดยอิงตามผลการเสนอราคาอย่างน้อย 1 รายการที่คุณเสนอก่อนหน้านี้ และสามารถใช้เพื่อดูรายละเอียดต่างๆ เช่น ราคาเสนอชนะการประมูลหรือไม่ หรือราคาเสนอขั้นต่ำที่จําเป็นต่อการชนะการประมูล โปรดติดต่อผู้จัดการฝ่ายดูแลลูกค้าเพื่อเปิดใช้ความคิดเห็นแบบเรียลไทม์

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

เมื่อ 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

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

ความสามารถในการข้ามและระยะเวลาของวิดีโอ

ข้อกําหนดของ OpenRTB ไม่มีช่องแยกต่างหากสําหรับการระบุระยะเวลาวิดีโอสูงสุดของโฆษณาแบบข้ามได้และแบบข้ามไม่ได้ การใช้งานของ Google ใช้การแปลงราคาเสนอเพื่อแยกความแตกต่างระหว่างราคาเสนอเหล่านี้โดยใช้ช่อง BidRequest.video.maxduration และ BidRequest.video.skip ที่มีอยู่

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

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

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

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

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

พ็อดวิดีโอ

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

Open Measurement

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

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

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

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

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

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

ในแอป

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON