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

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

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

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

คุณต้องแยกวิเคราะห์คำขอนี้เพื่อรับ 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": {
    ...
  }
}
      

ระบุหมวดหมู่ตามบริบท

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

หมวดหมู่ตามบริบทที่ Google ตรวจพบ

Google จะป้อนข้อมูลในช่องต่อไปนี้ด้วยหมวดหมู่เนื้อหาของ IAB ที่ตรวจพบสำหรับเว็บไซต์ แอป หรือหน้าเว็บ

ช่อง คำอธิบาย
BidRequest.site.cat อาร์เรย์ของรหัสหมวดหมู่เนื้อหาที่อธิบายเว็บไซต์
BidRequest.site.pagecat อาร์เรย์ของรหัสหมวดหมู่เนื้อหาที่อธิบายหน้าหรือมุมมองปัจจุบันของเว็บไซต์
BidRequest.app.cat อาร์เรย์ของรหัสหมวดหมู่เนื้อหาที่อธิบายแอป
BidRequest.app.pagecat อาร์เรย์ของรหัสหมวดหมู่เนื้อหาที่อธิบายหน้าหรือมุมมองปัจจุบันของแอป

คุณสามารถดูการจัดหมวดหมู่ที่แน่นอนซึ่งใช้สำหรับฟิลด์เหล่านี้สำหรับคำขอราคาเสนอหนึ่งๆ ได้ในฟิลด์ BidRequest.site.cattax หรือ BidRequest.app.cattax ระบบอาจไม่ได้ป้อนข้อมูลในช่องหมวดหมู่ตามบริบทเสมอไปเนื่องจากค่ากำหนดของผู้เผยแพร่โฆษณาหรือข้อกังวลด้านกฎระเบียบ ดูข้อมูลเพิ่มเติมได้ที่หมวดหมู่ตามบริบท OpenRTB ใน Google Ad Manager

สัญญาณที่ผู้เผยแพร่โฆษณามีให้

นอกจากหมวดหมู่ตามบริบทที่ Google ตรวจพบแล้ว คำขอราคาเสนอยังอาจมีสัญญาณที่ได้จากผู้เผยแพร่โฆษณา ซึ่งอธิบายบริบทของการแสดงผลด้วย สัญญาณเหล่านี้จะสร้างขึ้นเมื่อผู้เผยแพร่โฆษณาระบุเท่านั้น ซึ่งต่างจากหมวดหมู่ตามบริบทที่ Google ตรวจพบ ระบบจะส่งสัญญาณเหล่านี้ในออบเจ็กต์ BidRequest.site.content และ BidRequest.app.content เช่น content.data.segment และ content.genre ระบบจะรายงานการจัดหมวดหมู่ที่ใช้สำหรับรายการ content.data.segment ใน content.data.ext.segtax ดูข้อมูลเพิ่มเติมได้ที่สัญญาณที่ได้จากผู้เผยแพร่โฆษณา (PPS) สำหรับการเสนอราคาแบบเรียลไทม์ (RTB)

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

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

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

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

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

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

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

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

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

%%HAS_VIDEO%%

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

%%IS_CTV%%

แทนที่ด้วย 1 เพื่อระบุว่าคำขอราคาเสนอมาจากอุปกรณ์ CTV หรือ 0 ในกรณีอื่นๆ ซึ่งอิงตามค่าของ BidRequest.device.devicetype สำหรับ Protobuf อุปกรณ์ CTV จะเป็น CONNECTED_TV, CONNECTED_DEVICE หรือ SET_TOP_BOX ซึ่งสอดคล้องกับค่าจำนวนเต็ม 3, 6 หรือ 7 สำหรับ JSON

%%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 ที่มนุษย์อ่านได้

OpenRTB Protobuf

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

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

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

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

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

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

ตัวอย่าง

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

OpenRTB Protobuf

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 ในเชนสื่อกลาง (Mediation Chain) โดยเรียงลำดับจากมากไปน้อย
    \[C_1, C_2, …, C_n\]
  • ข้อมูลต่อไปนี้แสดงอัตราการส่งโฆษณาที่สอดคล้องกับ CPM ในเชนสื่อกลาง (Mediation Chain)
    \[f_1, f_2, …, f_n\]
  • ต่อไปนี้เป็นฟังก์ชันที่ใช้ในการกำหนด CPM ที่คาดหวังและความน่าจะเป็นจากองค์ประกอบเชนสื่อกลาง (Mediation Chain) \(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\}\)

ตัวอย่างที่มีเชนสื่อกลาง (Mediation Chain) แบบง่าย

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

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

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

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

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

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

OpenRTB Protobuf

JSON ของ OpenRTB

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

OpenRTB Protobuf

JSON ของ OpenRTB

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

OpenRTB Protobuf

JSON ของ OpenRTB

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

Protobuf ของ OpenRTB

OpenRTB JSON

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

OpenRTB Protobuf

JSON ของ OpenRTB

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON