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

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

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

กำหนดหมวดหมู่ที่ถูกบล็อก

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

คุณดูหมวดหมู่ที่ถูกบล็อกสําหรับการแสดงผลได้โดยตรวจสอบฟิลด์ BidRequest.bcat ซึ่งจะแสดงหมวดหมู่ใน อนุกรมวิธาน ที่กําหนดค่าไว้สําหรับบัญชีของคุณ

ตัวอย่างต่อไปนี้แสดงหมวดหมู่ที่ถูกบล็อกตามการจัดหมวดหมู่โฆษณาที่กำหนดค่าไว้

การจัดหมวดหมู่เนื้อหาของ IAB 1.0

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

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

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

มาโคร URL ของผู้เสนอราคา

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

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

แทนที่ด้วยรหัสผู้ใช้ Google ที่พบใน BidRequest.user.id เช่น 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 ในกรณีอื่นๆ โดยอิงตามค่าของ 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

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

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

Protobuf ของ OpenRTB

JSON ของ 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 รวมถึง Exchange และเครือข่ายที่ใช้การเสนอราคาแบบเปิด

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

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];
}

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

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

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

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

ตัวอย่าง

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

Protobuf ของ OpenRTB

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

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

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

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

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

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

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

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

พ็อดวิดีโอ

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

Open Measurement

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

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

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

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

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

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

Protobuf ของ OpenRTB

JSON ของ OpenRTB

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

Protobuf ของ OpenRTB

JSON ของ OpenRTB

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

Protobuf ของ OpenRTB

JSON ของ OpenRTB

แอปที่มาพร้อมเครื่อง

Protobuf ของ OpenRTB

JSON ของ OpenRTB

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

Protobuf ของ OpenRTB

JSON ของ OpenRTB

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

Protobuf ของ OpenRTB

JSON ของ OpenRTB

โฆษณาเนทีฟและวิดีโอแบบ Multi-Format

Protobuf ของ OpenRTB

JSON ของ OpenRTB