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

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

มาโครคำอธิบาย
%%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

ใช้ตัวถอดรหัส base-32 เพื่อถอดรหัสสตริงบางส่วนเป็นตัวหนา (gewtimrzgyytanjyg4888888)

คุณสามารถใช้บัญชี ออนไลน์ ตัวถอดรหัส [decoder] แต่จะต้องใช้ตัวอักษรพิมพ์ใหญ่หรือต่อท้าย 8s ที่มี = ค่า

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

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

  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++) หมายเหตุ แต่ก็ใช้ไม่ได้กับ 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 ส่งรหัสโฆษณาบนอุปกรณ์เคลื่อนที่ในคำขอราคาเสนอจาก แอปพลิเคชันบนอุปกรณ์เคลื่อนที่ รหัสโฆษณาบนอุปกรณ์เคลื่อนที่อาจเป็นรหัส iOS IDFA หรือ รหัสโฆษณาของ Android ซึ่งจะส่งผ่าน %%EXTRA_TAG_DATA%% ในแท็ก JavaScript ที่จัดการโดย Authorized Buyers

มาโคร %%ADVERTISING_IDENTIFIER%% ช่วยให้ผู้ซื้อได้รับ IDFA ของ iOS หรือรหัสโฆษณาของ 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 และเครือข่ายที่ใช้การเสนอราคาแบบเปิด

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

นอกจากช่องเริ่มต้นที่ส่งในความคิดเห็นเกี่ยวกับการเสนอราคาตอบแล้ว คุณยังสามารถ ส่งข้อมูลที่กำหนดเองในการเสนอราคาตอบ (ในโปรโตคอล AdX หรือ 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 ของสื่อกลาง ดังนั้น ที่จะแข่งขันกับความต้องการอื่นๆ ในสกุลเงินของผู้เผยแพร่โฆษณา เชน 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 หากไม่มีเครือข่ายใน เชนสื่อกลาง (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\) กับความน่าจะเป็น \(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) $1.00
ผู้ประมูล (R) 0.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) คุณสามารถ พิจารณาว่าคำขอราคาเสนอใดมีความสัมพันธ์หลังจากแยกเป็นหลายรายการ

รูปแบบโฆษณา

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

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

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

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

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

ปรับอากาศล่วงหน้า

หลังแบน

ดีล

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

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

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

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

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

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

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

Google

JSON ของ OpenRTB

โปรโตคอล OpenRTB

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

Google

JSON ของ OpenRTB

โปรโตคอล OpenRTB

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

Google

โปรโตคอล OpenRTB

เนทีฟของแอป

Google

JSON ของ OpenRTB

โปรโตคอล OpenRTB

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

Google

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

โปรโตคอล OpenRTB