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

การโต้ตอบกับการเสนอราคาแบบเรียลไทม์จะเริ่มขึ้นเมื่อ 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 คุณสามารถใช้งานบัญชีในฐานะ การแตกข้อมูล และตีความฟิลด์ที่คุณต้องการ ตัวอย่างเช่น ใน C++ ที่ทำซ้ำผ่านดีลใน "BidRequest" ของ OpenRTB อาจมีลักษณะดังนี้ ดังต่อไปนี้

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

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

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

ใช้ตัวถอดรหัส base-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 คุณต้องคำนึงถึงความแตกต่าง ที่เป็นไปได้สำหรับการประกาศผู้ให้บริการเทคโนโลยี:

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

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

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

โปรโตคอล OpenRTB

JSON ของ OpenRTB

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

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

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

ความคิดเห็นแบบเรียลไทม์พร้อมให้บริการแก่ Authorized Buyers รวมถึง 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;

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

  // The minimum bid value necessary to have 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 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 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 ค่า ผู้เผยแพร่แอปอาจเคยใช้ Waterfall ของสื่อกลาง ดังนั้น ที่จะแข่งขันกับความต้องการอื่นๆ ในสกุลเงินของผู้เผยแพร่โฆษณา เชน Waterfall ของรายการส่งคืน ดูวิธีใช้ sampled_mediation_cpm_ahead_of_auction_winner เมื่อเสนอราคา

ตัวอย่าง

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

โปรโตคอล OpenRTB

JSON ของ OpenRTB

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 หากไม่มีเครือข่ายใน เชนสื่อกลาง (Mediation Chain) จะได้รับการส่งโฆษณา หรือหากผู้เผยแพร่โฆษณาไม่ได้ใช้ 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\) พร้อมความน่าจะเป็น \(\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 ของโปรโตคอล Google และ skippable_max_ad_duration ช่อง ตอนนี้ลักษณะการทำงานนี้เปลี่ยนไปเป็นการส่งคําขอราคาเสนอ 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

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

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

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

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

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

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

โปรโตคอล OpenRTB

JSON ของ OpenRTB

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

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

โปรโตคอล OpenRTB

JSON ของ OpenRTB

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

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

โปรโตคอล OpenRTB

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

ในแอป

OpenRTB Protobuf

JSON ของ OpenRTB

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

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

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

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

OpenRTB Protobuf