Xử lý yêu cầu

Quá trình tương tác đặt giá thầu theo thời gian thực bắt đầu khi Google gửi yêu cầu giá thầu đến ứng dụng của bạn. Hướng dẫn này giải thích cách lập trình ứng dụng để xử lý yêu cầu giá thầu.

Phân tích cú pháp yêu cầu Protobuf

Google gửi yêu cầu giá thầu dưới dạng vùng đệm giao thức được chuyển đổi tuần tự đính kèm dưới dạng tải trọng tệp nhị phân của yêu cầu POST HTTP. Content-Type được đặt thành application/octet-stream. Hãy xem Ví dụ về yêu cầu giá thầu để biết ví dụ.

Bạn phải phân tích cú pháp yêu cầu này thành một thực thể của thông báo BidRequest. Tuỳ thuộc vào giao thức bạn chọn, BidRequest được xác định trong openrtb.proto hoặc realtime-bidding.proto không dùng nữa. Bạn có thể lấy dữ liệu này từ trang dữ liệu tham chiếu. Bạn có thể phân tích cú pháp thông báo bằng cách sử dụng phương thức ParseFromString() trong lớp được tạo cho BidRequest. Ví dụ: mã C++ sau đây phân tích cú pháp yêu cầu khi đã cho tải trọng POST trong một chuỗi: 

string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
  // Process the request.
}

Sau khi có BidRequest, bạn có thể xử lý nó như một đối tượng, trích xuất và diễn giải các trường bạn cần. Ví dụ: trong C++ lặp lại thông qua các giao dịch trong `BidRequest` OpenRTB có thể trông giống như như sau:

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

ID thanh toán

Bạn nhận được yêu cầu giá thầu khi khoảng không quảng cáo của nhà xuất bản được nhắm mục tiêu theo một hoặc nhiều của bạn cấu hình nhắm mục tiêu trước. BidRequest.imp.ext.billing_id sẽ được điền sẵn mã thanh toán của mọi người mua đủ điều kiện và các cấu hình nhắm mục tiêu trước có liên quan. Ngoài ra, đối với giao dịch khoảng không quảng cáo, bạn có thể tìm thấy mã thanh toán liên kết với người mua có liên quan đang sử dụng BidRequest.imp.pmp.deal.ext.billing_id. Bạn chỉ có thể chỉ định mã thanh toán của người mua có trong yêu cầu giá thầu khi đặt giá thầu.

Nếu yêu cầu giá thầu có nhiều mã thanh toán, bạn phải chỉ định mã thanh toán của người mua mà bạn dự định phân bổ giá thầu bằng trường BidResponse.seatbid.bid.ext.billing_id.

Tệp từ điển

Yêu cầu giá thầu sử dụng các giá trị nhận dạng được xác định trong tệp từ điển, có trong dữ liệu tham chiếu .

Macro URL giá thầu theo giao thức RTB của Google

Nếu muốn, bạn có thể chèn một số trường của BidRequest vào URL dùng trong yêu cầu POST qua HTTP. Điều này rất hữu ích, ví dụ: nếu bạn sử dụng một giao diện người dùng nhẹ giúp cân bằng tải trên nhiều phần phụ trợ bằng cách sử dụng một giá trị từ yêu cầu. Hãy liên hệ với nhà quản lý tài khoản hỗ trợ kỹ thuật để yêu cầu hỗ trợ về macro mới.

MacroMô tả
%%GOOGLE_USER_ID%%

Được thay thế bằng google_user_id khỏi BidRequest. Ví dụ: URL của bên đặt giá thầu

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
sẽ được thay thế bằng một URL như
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
tại thời điểm yêu cầu.

Nếu không xác định được Mã nhận dạng người dùng của Google, thì chuỗi trống sẽ được thay thế, với kết quả tương tự như

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

Được thay thế bằng 1 hoặc 0 khi gọi has_mobile() của BidRequest.
%%HAS_VIDEO%%

Được thay thế bằng 1 (đúng) hoặc 0 (sai) khi gọi has_video() của BidRequest.
%%HOSTED_MATCH_DATA%%

Được thay thế bằng giá trị của trường hosted_match_data từ BidRequest.
%%MOBILE_IS_APP%%

Được thay thế bằng 1 (đúng) hoặc 0 (sai) từ trường mobile.is_app của BidRequest.

Tìm mã ứng dụng di động từ URL giao dịch

Các giao dịch ứng dụng di động sẽ báo cáo các URL có dạng như sau:

mbappgewtimrzgyytanjyg4888888.com

Sử dụng bộ giải mã base-32 để giải mã phần của chuỗi được in đậm (gewtimrzgyytanjyg4888888).

Bạn có thể sử dụng trình giải mã trực tuyến, nhưng bạn sẽ phải viết hoa các chữ cái và thay thế 8 ở cuối bằng các giá trị =.

Vì vậy, việc giải mã giá trị này: 

GEWTIMRZGYYTANJYG4======
sẽ cho kết quả: 
1-429610587
Chuỗi 429610587 là mã ứng dụng cho ứng dụng iOS iFunny.

Sau đây là một ví dụ khác. URL bị báo cáo là: 

mbappgewtgmjug4ytmmrtgm888888.com
Giải mã giá trị này: 
GEWTGMJUG4YTMMRTGM======
kết quả trong: 
1-314716233
Kết quả 314716233 là mã ứng dụng của ứng dụng iOS TextNow.

Tìm tên ứng dụng di động từ URL giao dịch

Dưới đây là ví dụ về cách lấy tên ứng dụng. URL được báo cáo như sau: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
Giải mã giá trị này: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
kết quả trong: 
air.com.hypah.io.slither
Kết quả tương đương với ứng dụng Android slither.io.

Các trường trong tính năng Đặt giá thầu mở

Yêu cầu giá thầu được gửi đến đối tác trao đổi và bên đặt giá thầu trong mạng tham gia giải pháp Mở Tính năng đặt giá thầu tương tự như tính năng đặt giá thầu của Authorized Buyers tham gia chương trình chuẩn đặt giá thầu theo thời gian thực. Khách hàng sử dụng tính năng Đặt giá thầu mở sẽ nhận được một số trường bổ sung và một vài trường hiện có có thể có cách sử dụng thay thế. Các bao gồm:

OpenRTB Authorized Buyers Thông tin chi tiết
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

Chứa mã mạng Ad Manager của nhà xuất bản, theo sau là quảng cáo hệ thống phân cấp đơn vị, được phân tách bằng dấu gạch chéo lên.

Ví dụ: đoạn mã này sẽ xuất hiện với định dạng tương tự như sau: /1234/cruises/mars.
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

Cặp khoá-giá trị lặp lại được nhà xuất bản gửi đến bên đặt giá thầu trao đổi.

Bạn có thể xác định rằng các giá trị này là cặp khoá-giá trị do nhà xuất bản gửi khi BidRequest.user.data[].name được đặt thành “Publisher Passed”.

Khai báo nhà cung cấp được phép

Các nhà cung cấp công nghệ cung cấp các dịch vụ như nghiên cứu, tái tiếp thị và phân phát quảng cáo có thể đóng vai trò trong hoạt động tương tác giữa người mua và người bán. Chỉ những nhà cung cấp mà Google đã kiểm tra để tham gia các hoạt động tương tác với Authorized Buyers mới được phép.

Để hiểu BidRequest và tạo BidResponse, bạn cần biết hai cách khai báo nhà cung cấp công nghệ:

  1. Bạn không cần khai báo một số nhà cung cấp; các nhà cung cấp này được liệt kê trong Bên ngoài được Ad Manager chứng nhận Nhà cung cấp.
  2. Các nhà cung cấp khác chỉ có thể tham gia nếu họ được khai báo trong BidRequest:
    • Trong BidRequest, Chỉ định trường BidRequest.imp.ext.allowed_vendor_type nhà cung cấp nào người bán cho phép. Những nhà cung cấp sẽ được gửi trong allowed_vendor_type có tên trong danh sách vendors.txt tệp từ điển.

Yêu cầu giá thầu mẫu

Các ví dụ sau đây thể hiện các mẫu Protobuf mà con người có thể đọc được và Yêu cầu JSON.

OpenRTB Protobuf

JSON OpenRTB

Google (Không dùng nữa)

Để chuyển đổi yêu cầu giá thầu thành một dạng tệp nhị phân, như bạn sẽ nhận được từ tải trọng POST trong một yêu cầu thực, bạn có thể làm như sau (trong C++). Tuy nhiên, xin lưu ý rằng phương thức này không áp dụng cho 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
  }
}

Phản hồi theo thời gian thực

Authorized Buyers cũng như các sàn giao dịch và mạng sử dụng tính năng Đặt giá thầu mở có thể xem ý kiến phản hồi theo thời gian thực.

Phản hồi giá thầu phản hồi được hỗ trợ trên yêu cầu giá thầu tiếp theo cho cả hai OpenRTB và giao thức RTB của Google không được dùng nữa. Đối với OpenRTB, mã được gửi bằng BidRequest.ext.bid_feedback.

Ngoài các trường mặc định được gửi trong Ý kiến phản hồi về phản hồi giá thầu, bạn cũng có thể gửi dữ liệu tuỳ chỉnh trong phản hồi giá thầu bằng cách sử dụng trường BidResponse.seatbid.bid.ext.event_notification_token. event_notification_token là dữ liệu tuỳ ý mà chỉ bên đặt giá thầu mới biết và có thể giúp gỡ lỗi, ví dụ: mã nhắm mục tiêu mới hoặc mã đặt giá thầu đại diện cho một chiến thuật mới hoặc siêu dữ liệu liên kết với mẫu quảng cáo mà chỉ bên đặt giá thầu mới biết. Để biết thông tin chi tiết, hãy xem Vùng đệm giao thức của tiện ích OpenRTB cho OpenRTB hoặc không được dùng nữa Giao thức RTB của Google.

Khi Authorized Buyers gửi yêu cầu giá thầu cho bên đặt giá thầu, bên đặt giá thầu sẽ phản hồi bằng BidResponse. Nếu bên đặt giá thầu đã bật tính năng phản hồi theo thời gian thực, thì trong một yêu cầu giá thầu tiếp theo, Authorized Buyers sẽ gửi phản hồi về phản hồi trong một thông báo BidFeedback:

message BidFeedback {
  // The unique id from BidRequest.id.
  optional string request_id = 1;

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

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

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

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

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

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

  message EventNotificationToken {
    // The contents of the token.
    optional string payload = 1;
  }

  // The token included in the corresponding bid.
  optional EventNotificationToken event_notification_token = 4;

  // The creative ID included in the corresponding bid.
  optional string buyer_creative_id = 5;

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

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

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

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

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

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

Trong thông báo này, trường đầu tiên bạn nên kiểm tra là bid_feedback.creative_status_code; bạn có thể tìm thấy mã nghĩa bằng quảng cáo trạng thái-mã.txt. Lưu ý rằng nếu bạn thắng giá thầu, bạn có thể chọn không tham gia dựa trên ý kiến phản hồi về giá. Để biết thêm thông tin, hãy xem Cách chọn không sử dụng.

Phản hồi theo thời gian thực bao gồm mã yêu cầu giá thầu và một trong những thông tin sau:

Kết quả đấu giá Phản hồi theo thời gian thực
Người mua không gửi giá thầu. Miễn phí.
Người mua đã gửi một giá thầu bị lọc ra trước khi tham gia phiên đấu giá. Mã trạng thái mẫu quảng cáo (creative-status-codes.txt).
Người mua đã gửi giá thầu nhưng thua phiên đấu giá. Mã trạng thái quảng cáo 79 (đặt giá thầu cao hơn phiên đấu giá).
Người mua đã gửi giá thầu thắng phiên đấu giá. Giá thanh toán và mã trạng thái mẫu quảng cáo 1.

Đối với một lượt hiển thị ứng dụng và mã trạng thái mẫu quảng cáo là 83, nhà xuất bản ứng dụng có thể đang sử dụng quy trình dàn xếp dạng thác nước, do đó, giá thầu chiến thắng sẽ cạnh tranh với các nhu cầu khác trong chuỗi thác nước trả về của nhà xuất bản. Tìm hiểu cách sử dụng sampled_mediation_cpm_ahead_of_auction_winner khi đặt giá thầu.

Mẫu

Dưới đây là mẫu phản hồi theo thời gian thực như được thấy trong giao thức:

OpenRTB Protobuf

JSON OpenRTB

Google (Không dùng nữa)

Xây dựng mô hình đặt giá thầu cho phiên đấu giá theo giá đầu tiên

Sau khi đặt giá thầu trong phiên đấu giá theo giá đầu tiên, bạn sẽ nhận được phản hồi bao gồm minimum_bid_to_win và sampled_mediation_cpm_ahead_of_auction_winner trường nếu giá thầu không bị lọc khỏi phiên đấu giá. Bạn có thể dùng những tín hiệu này để logic đặt giá thầu xem giá thầu của bạn có thể cao hơn hoặc thấp hơn bao nhiêu để giành được lượt hiển thị.

  • minimum_bid_to_win: Giá thầu tối thiểu có thể được đặt để giành chiến thắng trong phiên đấu giá đặt giá thầu theo thời gian thực. Nếu bạn đã thắng phiên đấu giá, thì đây sẽ là giá thầu thấp nhất mà bạn có thể đặt mà vẫn thắng. Nếu bạn thua phiên đấu giá, đây sẽ là giá thầu thắng thầu.
  • sampled_mediation_cpm_ahead_of_auction_winner: Nếu có các mạng khác trong chuỗi dàn xếp, giá trị của trường này là mức giá đại diện cho giá thầu mẫu từ một trong mạng dàn xếp đủ điều kiện cao hơn mạng chiến thắng trong phiên đấu giá, được tính trọng số theo tỷ lệ lấp đầy dự kiến. Giá trị này sẽ được đặt thành 0 nếu không có mạng nào trong chuỗi dàn xếp dự kiến sẽ được thực hiện hoặc nếu nhà xuất bản không sử dụng SDK dàn xếp.

Cách hoạt động

Để mô tả các phép tính dùng để xác định các giá trị có thể có cho minimum_bid_to_win và sampled_mediation_cpm_ahead_of_auction_winner, trước tiên chúng ta cần xác định những yếu tố sau:

  • Dưới đây là CPM trong chuỗi dàn xếp theo thứ tự giảm dần:
    \[C_1, C_2, …, C_n\]
  • Dưới đây là tỷ lệ đáp ứng tương ứng cho các CPM trong chuỗi dàn xếp:
    \[f_1, f_2, …, f_n\]
  • Sau đây là một hàm dùng để xác định CPM dự kiến và xác suất của phần tử chuỗi dàn xếp \(i\), dựa trên khoảng lấp đầy đã cho tỷ lệ:
    \(X_i = \{C_i\) với xác suất \(f_i\); \(0\) với xác suất \(1 - f_i\}\)
  • Chuỗi dàn xếp chiến thắng cuối cùng sẽ là:
    \[\{C_1, C_2, …, C_K, W\}\]
    trong đó \(W\) là giá thầu giành chiến thắng và \(C_K > W >= C_{K+1}\)
  • Giá đặt trước (hoặc giá sàn) được biểu thị là \(F\).
  • Giá thầu cao hơn được biểu thị là \(R\).
Cách tính toán cho chiến dịch chiến thắng trong phiên đấu giá
Trường Cách tính
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) có xác suất \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Dành cho \(1 <= i <= K\).
Cách tính cho phiên đấu giá thua
Trường Cách tính
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

Ví dụ về một chuỗi dàn xếp đơn giản

Giả sử một nhà xuất bản sử dụng cả tính năng đặt giá thầu theo thời gian thực và chuỗi dàn xếp SDK sau:

Chuỗi dàn xếp SDK CPM dự kiến Tỷ lệ đáp ứng
Mạng 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
Mạng 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
Mạng 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
Mạng 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Giả sử phiên đấu giá đặt giá thầu theo thời gian thực (RTB) là kết quả của phiên đấu giá:

Phiên đấu giá RTB CPM
Người chiến thắng trong phiên đấu giá (W) 1 đô la
Á quân trong phiên đấu giá (R) $0,05
Giá đặt trước/giá sàn (F) $0
Giá thầu thắng phiên đấu giá

Sau đây là ví dụ về cách giá trị và xác suất cho minimum_bid_to_win và sampled_mediation_cpm_ahead_of_auction_winner được tính theo giá thầu giành chiến thắng.

minimum_bid_to_win Xác suất
\(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		 Xác suất
\(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\%\)
Giá thầu thua phiên đấu giá

Sau đây là ví dụ về cách giá trị và xác suất cho minimum_bid_to_win và sampled_mediation_cpm_ahead_of_auction_winner được tính theo giá thầu đã thua.

minimum_bid_to_win Xác suất
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Xác suất
\(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\%\)

Phân tách giá thầu

Phân tách giá thầu mô tả quá trình xử lý một tổ hợp phức tạp BidRequest vào nhiều yêu cầu giá thầu được gửi đến . Khi một yêu cầu giá thầu được phân tách, bạn có thể biết những yêu cầu giá thầu nào là một phần của tệp gốc vì chúng sẽ có giá trị giống hệt nhau trong thuộc tính Trường BidRequest.ext.google_query_id.

Tính năng phân tách giá thầu được bật theo mặc định, nhưng bạn có thể liên hệ với tài khoản của mình người quản lý nếu bạn muốn tắt tính năng đó.

Định dạng quảng cáo

Một số cơ hội quảng cáo có thể chấp nhận nhiều định dạng. Khi áp dụng tính năng làm phẳng giá thầu, mỗi định dạng sẽ được gửi trong một yêu cầu giá thầu riêng biệt, trong đó các thuộc tính như mã thanh toán đủ điều kiện có liên quan đến định dạng được chỉ định trong yêu cầu.

Các yêu cầu giá thầu chứa các định dạng sau sẽ được phân tách thành các yêu cầu giá thầu riêng biệt:

  • Biểu ngữ
  • Video
  • Âm thanh
  • Mã gốc

Ví dụ về việc làm phẳng định dạng quảng cáo

Dưới đây là ví dụ về một yêu cầu giá thầu JSON OpenRTB được đơn giản hoá mà không làm phẳng định dạng quảng cáo so với một nhóm yêu cầu tương đương đã được làm phẳng:

Làm phẳng trước

Sau khi làm phẳng

Ưu đãi

Cơ hội quảng cáo cho một bên đặt giá thầu nhất định có thể áp dụng cho nhiều giao dịch ngoài phiên đấu giá mở. Khi làm phẳng giá thầu cho giao dịch, hệ thống sẽ gửi một yêu cầu giá thầu cho phiên đấu giá mở và một yêu cầu cho mỗi loại giao dịch giá cố định. Trong thực tế, các quy tắc ràng buộc về quảng cáo có thể khác nhau giữa các loại phiên đấu giá và giao dịch giá cố định. Ví dụ: đối với một cơ hội quảng cáo dạng video nhất định có sẵn cho cả phiên đấu giá công khai và giao dịch giá cố định, người đặt giá thầu sẽ nhận được các yêu cầu giá thầu riêng biệt cho từng loại, trong đó các quy tắc ràng buộc như thời lượng quảng cáo tối đa và liệu có cho phép quảng cáo có thể bỏ qua hay không có thể khác nhau. Do đó, việc làm phẳng áp dụng cho cơ hội quảng cáo giúp bạn dễ dàng phân biệt các quy tắc ràng buộc quảng cáo cho phiên đấu giá mở và giao dịch theo giá cố định.

Thời lượng tối đa của video có thể bỏ qua

Giao thức và cách triển khai OpenRTB của Google hỗ trợ các trường sau đây cho thời lượng video và khả năng bỏ qua:

Thời lượng Thời lượng có thể bỏ qua Khả năng bỏ qua
Giao thức Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration không áp dụng skip

Điều này có nghĩa là mặc dù giao thức của Google có thể có thời lượng chi tiết có thể bỏ qua và không thể bỏ qua, nhưng cách triển khai OpenRTB chỉ có một giá trị thời lượng tối đa.

Trước khi làm phẳng giá thầu, maxduration của OpenRTB sẽ được đặt thành giá trị thấp hơn trong các trường max_ad_duration và skippable_max_ad_duration của giao thức Google. Hành vi này hiện đã thay đổi thành gửi hai yêu cầu giá thầu riêng biệt khi các giá trị này khác nhau: một yêu cầu đại diện maxduration cho quảng cáo có thể bỏ qua và quảng cáo còn lại cho quảng cáo không thể bỏ qua cơ hội.

Các ví dụ sau đây cho thấy cách một yêu cầu giao thức của Google được dịch sang OpenRTB trước và sau khi làm phẳng giá thầu. Yêu cầu tương đương về giao thức của Google có max_ad_duration là 15 và skippable_max_ad_duration là 60.

Ví dụ: max_ad_duration skip (true HOẶC false)
Yêu cầu ban đầu mà không làm phẳng 15 true
Yêu cầu đã được làm phẳng số 1: Không thể bỏ qua 15 false
Yêu cầu đã được làm phẳng số 2: Có thể bỏ qua 60 true

Việc phân tách yêu cầu giá thầu theo thời lượng video có thể bỏ qua sẽ chỉ diễn ra khi đáp ứng các điều kiện sau:

  • Yêu cầu này cho phép phát video.
  • Cả video có thể bỏ qua và không thể bỏ qua đều được cho phép, đồng thời hai thời lượng tối đa tương ứng sẽ khác nhau.
  • Yêu cầu này đủ điều kiện cho Phiên đấu giá kín hoặc Phiên đấu giá mở.
  • Tài khoản của người đặt giá thầu có điểm cuối OpenRTB đang hoạt động.

Bạn có thể chọn không sử dụng hình thức làm phẳng này bằng cách liên hệ với bộ phận kỹ thuật người quản lý tài khoản.

Nhóm video

Yêu cầu giá thầu cho một nhóm video có nhiều cơ hội quảng cáo sẽ được phân tách, sao cho mỗi yêu cầu giá thầu dành cho một cơ hội quảng cáo riêng lẻ từ nhóm đó. Điều này cho phép bạn đặt giá thầu cho nhiều cơ hội quảng cáo cho một nhóm quảng cáo nhất định.

Đo lường mở

Đo lường mở cho phép bạn chỉ định các nhà cung cấp bên thứ ba cung cấp dịch vụ đo lường và xác minh độc lập cho quảng cáo được phân phát đến môi trường ứng dụng di động.

Bạn có thể xác định xem nhà xuất bản có hỗ trợ tiêu chuẩn Đo lường mở trong giá thầu hay không bằng cách kiểm tra xem cơ hội quảng cáo có loại trừ thuộc tính OmsdkType: OMSDK 1.0 trong mục Có thể loại trừ của nhà xuất bản hay không thuộc tính của mẫu quảng cáo. Thông tin này sẽ nằm trong battr thuộc tính cho Biểu ngữ hoặc Video, tùy thuộc vào về định dạng.

Để biết thêm thông tin về cách diễn giải các yêu cầu giá thầu chứa tín hiệu Đo lường mở, hãy tham khảo bài viết về SDK Đo lường mở trên Trung tâm trợ giúp.

Yêu cầu giá thầu mẫu

Các phần sau đây trình bày các yêu cầu giá thầu mẫu cho các loại quảng cáo khác nhau.

Biểu ngữ ứng dụng

Protobuf OpenRTB

JSON OpenRTB

Google (Không dùng nữa)

Quảng cáo xen kẽ trong ứng dụng

Protobuf OpenRTB

JSON OpenRTB

Google (Không dùng nữa)

Video quảng cáo xen kẽ trong ứng dụng

OpenRTB Protobuf

Google (Không dùng nữa)

Ứng dụng gốc

Protobuf OpenRTB

JSON OpenRTB

Google (Không dùng nữa)

Video trên web

Google (Không dùng nữa)

Biểu ngữ web dành cho thiết bị di động cho bên đặt giá thầu trao đổi

Protobuf OpenRTB