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

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

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

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

คุณต้องแยกวิเคราะห์คำขอนี้เป็นอินสแตนซ์ของข้อความ BidRequest BidRequest กำหนดไว้ใน 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++:

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

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

ข้อมูลเกี่ยวกับกลุ่มโฆษณาของการกำหนดเป้าหมายล่วงหน้าจะอยู่ในกลุ่ม MatchingAdData สำหรับแต่ละ AdSlot ไฟล์นี้ประกอบด้วยรหัสกลุ่มโฆษณากลุ่มแรกของกลุ่มโฆษณาที่กำหนดเป้าหมายล่วงหน้าซึ่งแจ้งให้ Google ส่งคำขอราคาเสนอ กล่าวคือ กลุ่มโฆษณาและแคมเปญที่เรียกเก็บเงินหากการตอบกลับของคุณชนะการประมูลสำหรับการแสดงผล ในบางสถานการณ์ คุณต้องระบุ billing_id อย่างชัดแจ้งสำหรับการระบุแหล่งที่มาใน BidResponse.AdSlot ตัวอย่างเช่น เมื่อBidRequest.AdSlotมีmatching_ad_dataมากกว่า 1 รายการ ดูข้อมูลเพิ่มเติมเกี่ยวกับข้อจำกัดของเนื้อหาของราคาเสนอได้ที่ realtime-bidding.proto

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

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

มาโคร URL การเสนอราคา

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

Macroคำอธิบาย
%%GOOGLE_USER_ID%%

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

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
จะถูกแทนที่ด้วย
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
ในเวลาของคำขอ

หากไม่ทราบ User ID ของ 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[]

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

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

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

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

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

  1. ผู้ให้บริการบางรายไม่จำเป็นต้องได้รับแจ้ง ผู้ให้บริการเหล่านี้แสดงรายการอยู่ในศูนย์ช่วยเหลือของ Authorized Buyers
  2. ผู้ให้บริการรายอื่นๆ จะเข้าร่วมได้ต่อเมื่อมีการประกาศยืนยันทั้งใน BidRequest และ BidResponse ต่อไปนี้
    • ในช่อง BidRequest ช่อง allowed_vendor_type จะระบุผู้ให้บริการที่ผู้ขายอนุญาต ผู้ให้บริการที่จะส่งในช่อง allowed_vendor_type ของ BidRequest จะมีรายชื่ออยู่ในไฟล์พจนานุกรม Vendors.txt
    • ในช่อง BidResponse ช่อง vendor_type จะระบุผู้ให้บริการที่ได้รับอนุญาตที่ผู้ซื้อตั้งใจจะใช้

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

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

Google

JSON ของ OpenRTB

โปรโตคอล OpenRTB

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

รีมาร์เก็ตติ้ง

Authorized Buyers ส่งรหัสโฆษณาบนอุปกรณ์เคลื่อนที่ในคำขอราคาเสนอจากแอปพลิเคชันบนอุปกรณ์เคลื่อนที่ รหัสโฆษณาบนอุปกรณ์เคลื่อนที่อาจเป็น iOS IDFA หรือ รหัสโฆษณาของ Android ซึ่งส่งผ่านมาโคร %%EXTRA_TAG_DATA%% ในแท็ก JavaScript ที่จัดการโดย Authorized Buyers

มาโคร %%ADVERTISING_IDENTIFIER%% ช่วยให้ผู้ซื้อได้รับ iOS IDFA หรือรหัสโฆษณาของ Android ในการแสดงผล โดยแสดงผลบัฟเฟอร์ Proto ที่เข้ารหัส MobileAdvertisingId เช่น %%EXTRA_TAG_DATA%%:

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

user_id_type เป็นค่าหนึ่งที่กำหนดไว้ใน enum AdxMobileIdType

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

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

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

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

ความคิดเห็นแบบเรียลไทม์มีให้บริการแก่ Authorized Buyers รวมถึง Exchange และเครือข่ายที่ใช้การเสนอราคาแบบเปิด

ระบบรองรับความคิดเห็นการเสนอราคาตอบในคำขอราคาเสนอที่ตามมาสำหรับทั้งโปรโตคอล AdX และ OpenRTB สำหรับ OpenRTB ระบบจะส่งใน BidRequestExt

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

เมื่อ Authorized Buyers ส่งคำขอราคาเสนอไปยังผู้เสนอราคา ผู้เสนอราคาจะตอบกลับด้วย BidResponse หากผู้เสนอราคาเปิดใช้ความคิดเห็นแบบเรียลไทม์ จากนั้นในคำขอราคาเสนอที่ตามมา Authorized Buyers จะส่งความคิดเห็นเกี่ยวกับการตอบกลับในข้อความ BidResponseFeedback ดังที่แสดงด้านล่าง

message BidResponseFeedback {
  // The unique id from BidRequest.id
  optional bytes request_id = 1;

  // The index of the BidResponse_Ad if there was more than one. The index
  // starts at zero for the first creative.
  optional int32 creative_index = 2;

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

  // If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional int64 cpm_micros = 4;

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

  // The minimum bid value necessary to have won the server-side component of
  // the overall auction given that there was also an interest group bidding
  // component to the overall auction which ran using the Protected Audience
  // API. The value is expressed in CPM micros of the buyer account currency.
  // The minimum bid to win for the overall auction, including bids from the
  // server-side and the on-device interest group components, is populated in
  // the minimum_bid_to_win field of the same BidResponseFeedback object.
  optional int64 server_side_component_minimum_bid_to_win = 16;

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

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

  // Event notification token that was included in the bid response.
  optional bytes event_notification_token = 5;

  // Buyer creative ID that was included in the bid response.
  optional string buyer_creative_id = 6;

  // Possible types of bid response feedback objects.
  enum FeedbackType {
    FEEDBACK_TYPE_UNSPECIFIED = 0;

    // Feedback for a bid that was submitted on a bid response.
    BID_FEEDBACK = 1;

    // Feedback for an interest group buyer submitted on a bid response to
    // particpate in an interest group bidding component of the auction run
    // using the Protected Audience API.
    INTEREST_GROUP_BUYER_FEEDBACK = 2;
  }

  // The type of the BidResponseFeedback message. Google will send separate
  // BidResponseFeedback objects for:
  // a) Each bid submitted on a bid response
  // b) Each buyer submitted on a bid response to particpate in an interest
  // group bidding component of the auction run using the Protected Audience
  // API.
  optional FeedbackType feedback_type = 17;

  // Origin of an interest group buyer that was included in the bid response.
  // This field is populated only for feedback where a bidder opted in an
  // interest group buyer to participate in the interest group bidding
  // component of the overall auction run using the Protected Audience API.
  // To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
  // To learn more about interest group bidding and the Protected Audience
  // API, see
  // https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
  optional string buyer_origin = 18;

  // The status code for the submitted interest group buyer. This field is
  // only populated in the feedback for an interest group buyer that a bidder
  // requested to enter into the interest group auction through the bid
  // response. Individual creative status codes of bids submitted by the buyer
  // in the on-device interest group auction are not available. See
  // https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
  // for a list of interest group buyer status codes.
  optional int32 interest_group_buyer_status_code = 19;
}

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

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

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

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

ตัวอย่าง

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

Google

JSON ของ OpenRTB

โปรโตคอล OpenRTB

สร้างโมเดลการเสนอราคาสำหรับการประมูลแบบใช้ราคาอันดับ 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\) กับความน่าจะเป็น \(f_i\)\(0\) ที่มีความน่าจะเป็น \(1 - f_i\}\)
  • เชนสื่อกลางที่ชนะในขั้นสุดท้ายคือ
    \[\{C_1, C_2, …, C_K, W\}\]
    โดยที่ \(W\) เป็นราคาเสนอที่ชนะ และ \(C_K > W >= C_{K+1}\)
  • ราคาจองหรือราคาพื้นจะระบุเป็น \(F\)
  • ราคาเสนอรองจะแสดงเป็น \(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) 30.00 บาท
ผู้ชนะการประมูล (R) 10.50 บาท
ราคาจอง / ชั้น (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.google_query_id ในโปรโตคอล RTB ของ Authorized Buyers หรือ BidRequestExt.google_query_id ในโปรโตคอล OpenRTB) คุณจึงสามารถ กำหนดได้ว่าคำขอราคาเสนอใดมีความสัมพันธ์กันหลังจากการแยก

รูปแบบโฆษณา

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

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

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

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

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

แบบเรียบ

หลังผ้าแบน

ดีล

โอกาสในการโฆษณาสำหรับผู้เสนอราคาหนึ่งๆ สามารถใช้ได้กับดีลประเภทต่างๆ นอกเหนือจากการประมูลแบบเปิด เมื่อมีการแยกราคาเสนอสำหรับดีล จะมีการส่งคำขอราคาเสนอ 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 (จริงหรือเท็จ)
คำขอเดิมที่ไม่มีการแยก 15 true
คำขอที่แยกเป็นหลายรายการ #1: ข้ามไม่ได้ 15 false
คำขอที่แยกเป็นหลายรายการ #2: ข้ามได้ 60 true

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

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

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

พ็อดวิดีโอ

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

Open Measurement

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

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

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

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

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

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

Google

JSON ของ OpenRTB

โปรโตคอล OpenRTB

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

Google

JSON ของ OpenRTB

โปรโตคอล OpenRTB

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

Google

โปรโตคอล OpenRTB

เนทีฟของแอป

Google

JSON ของ OpenRTB

โปรโตคอล OpenRTB

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

Google

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

โปรโตคอล OpenRTB