Xử lý yêu cầu

Một lượt 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 mã hoá ứng dụng của bạn để xử lý yêu cầu giá thầu.

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

Google gửi một yêu cầu giá thầu dưới dạng vùng đệm giao thức tuần tự được đính kèm dưới dạng tải trọng nhị phân của yêu cầu HTTP POST. Content-Type được đặt thành application/octet-stream Xem Yêu cầu giá thầu mẫ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 BidRequest . BidRequest được xác định trong realtime-bidding.proto, lấy từ trang dữ liệu tham chiếu. Bạn có thể phân tích cú pháp tin nhắn bằng phương thức ParseFromString() trong lớp được tạo cho giá trị 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++:

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

Một số thông tin được gửi trong BidRequest, chẳng hạn như Người dùng Google Mã nhận dạng, ngôn ngữ hoặc vị trí địa lý không phải lúc nào cũng có sẵn. Nếu bạn có nhóm quảng cáo nhắm mục tiêu trước sử dụng thông tin chưa xác định cho một nhóm quảng cáo thì các nhóm quảng cáo đó sẽ không khớp. Trong trường hợp thiếu không quan trọng đối với các điều kiện nhắm mục tiêu trước, yêu cầu giá thầu gửi kèm thông tin bị bỏ qua.

Có sẵn thông tin về nhóm quảng cáo nhắm mục tiêu trước trong MatchingAdData nhóm cho mỗi AdSlot. Chiến dịch này có chứa mã nhóm quảng cáo trùng khớp đầu tiên của nhóm quảng cáo nhắm mục tiêu trước đã nhắc Google gửi yêu cầu giá thầu, tức là nhóm quảng cáo và chiến dịch được tính phí nếu phản hồi của bạn thắng phiên đấu giá cho lượt hiển thị. Trong phạm vi nhất định trong trường hợp cụ thể, bạn cần chỉ định rõ billing_id cho trong BidResponse.AdSlot, ví dụ: khi BidRequest.AdSlot có nhiều matching_ad_data. Để biết thêm thông tin về những ràng buộc đối với nội dung của giá thầu, hãy tham khảo realtime-bidding.proto.

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

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 hữu ích, ví dụ: nếu bạn sử dụng một giao diện người dùng gọn nhẹ tải số dư trên nhiều phần phụ trợ bằng cách sử dụng một giá trị khỏi 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 nội dung nào đó như 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
 theo yêu cầu.

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

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 khỏi BidRequest.
%%MOBILE_IS_APP%%

Được thay thế bằng 1 (đúng) hoặc 0 (sai) qua 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 qua ứ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 giải pháp nhưng bạn sẽ phải viết hoa các chữ cái và thay thế các chữ cái ở cuối 8 với = giá trị.

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

GEWTIMRZGYYTANJYG4======
 kết quả trong: 
1-429610587
 Chuỗi 429610587 là mã ứng dụng của ứ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 trong URL giao dịch

Sau đâ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 Đặt giá thầu mở sẽ nhận được một số ít các 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 giá trị là cặp khoá-giá trị được gửi bởi nhà xuất bản khi đặt BidRequest.user.data[].name thành “Publisher Passed”

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

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à việc phân phát quảng cáo có thể đóng một vai trò trong sự 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 Authorized Buyers tương tác.

Để hiểu rõ BidRequest và tạo BidResponse, bạn cần lưu ý đến hai giới hạn này khả năng 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; những nhà cung cấp này được liệt kê trong trang Trợ giúp của Authorized Buyers.
  2. Các nhà cung cấp khác chỉ có thể tham gia nếu họ được khai báo trong cả BidRequest và BidResponse:
    • Trong BidRequest, allowed_vendor_type chỉ định nhà cung cấp nào người bán cho phép. Những nhà cung cấp sẽ được gửi đến trường allowed_vendor_type của BidRequest là được liệt kê trong Vendors.txt tệp từ điển.
    • Trong BidResponse, trường vendor_type chỉ định nhà cung cấp nào trong số các nhà cung cấp được phép mà người mua dự định sử dụng.

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.

Google

JSON OpenRTB

Protobuf OpenRTB

Để chuyển đổi yêu cầu giá thầu thành dạng nhị phân, giống như cách bạn thực hiện từ Tải trọng POST trong yêu cầu thực, bạn có thể làm như sau (trong C++). Xin lưu ý rằng tuy nhiên, điều 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
  }
}

Tiếp thị lại

Authorized Buyers chuyển mã nhận dạng cho quảng cáo trên thiết bị di động trong yêu cầu giá thầu từ ứng dụng dành cho thiết bị di động. Mã nhận dạng cho quảng cáo trên thiết bị di động có thể là IDFA iOS hoặc Mã nhận dạng cho quảng cáo của Android, được gửi qua Macro %%EXTRA_TAG_DATA%% trong thẻ JavaScript được quản lý bởi Authorized Buyers.

Macro %%ADVERTISING_IDENTIFIER%% cho phép người mua nhận IDFA của iOS hoặc mã nhận dạng cho quảng cáo của Android khi hiển thị lượt hiển thị. Phương thức này trả về một vùng đệm proto được mã hoá MobileAdvertisingId như %%EXTRA_TAG_DATA%%:

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

user_id_type là một trong những giá trị được xác định trong enum AdxMobileIdType:

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

Bạn có thể tạo danh sách người dùng từ mã nhận dạng cho quảng cáo trên thiết bị di động bằng mã nhận dạng cho quảng cáo mà bạn đã thu thập được trong khi hiển thị. Bạn có thể duy trì những danh sách người dùng này trên máy chủ của bạn hoặc trên máy chủ của chúng tôi. Để tạo danh sách người dùng trên máy chủ của Google, bạn có thể sử dụng tải lên hàng loạt của chúng tôi.

Khi mã nhận dạng cho quảng cáo trên thiết bị di động khớp với một danh sách người dùng, bạn có thể sử dụng mã đó để chạy tiếp thị lại.

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

Authorized Buyers cũng có phản hồi theo thời gian thực đối tác trao đổi và mạng sử dụng tính năng Đặt giá thầu mở.

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 Giao thức AdX và OpenRTB. Đối với OpenRTB, mã được gửi bằng BidRequestExt.

Ngoài các trường mặc định được gửi trong phần Phản hồi giá thầu, bạn có thể đồng thời gửi dữ liệu tuỳ chỉnh trong giá thầu phản hồi (dưới dạng AdX Proto hoặc OpenRTB) sử dụng event_notification_token được trả về trong BidResponse event_notification_token là dữ liệu tuỳ ý mà chỉ bên đặt giá thầu biết có thể giúp gỡ lỗi, cho ví dụ: mã nhắm mục tiêu hoặc mã đặt giá thầu mới thể hiện 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 OpenRTB Vùng đệm giao thức tiện ích cho RTB và AdX Proto cho AdX.

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 yêu cầu giá thầu tiếp theo, Authorized Buyers gửi phản hồi về phản hồi trong một tin nhắn BidResponseFeedback, như minh hoạ dưới đây:

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

Trong thông báo này, trường đầu tiên bạn nên kiểm tra là bid_response_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 giành được 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.

Thông tin 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 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 giá thầu bị lọc ra trước khi tiếp cận 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 mẫu 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á bù trừ và mã trạng thái mẫu quảng cáo 1.

Đối với lượt hiển thị trong ứng dụng và mã trạng thái mẫu quảng cáo là 83, tham số nhà xuất bản ứng dụng có thể đã sử dụng quy trình dàn xếp kiểu thác nước và do đó giá thầu giành chiến thắng đã cạnh tranh với nhu cầu khác trong chiến dịch của nhà xuất bản chuỗi thác nước trả về. 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:

Google

JSON OpenRTB

Protobuf OpenRTB

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 cho biết 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ể là để thắng phiên đấu giá đặt giá thầu theo thời gian thực. Nếu bạn thắng phiên đấu giá, việc này sẽ là mức giá thầu thấp nhất mà bạn có thể đã đặt mà vẫn giành chiến thắng. Nếu bạn mất thì đây sẽ là giá thầu giành chiến thắng.
  • 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à các CPM trong chuỗi dàn xếp theo thứ tự giảm dần:
    \[C_1, C_2, …, C_n\]
  • Biểu đồ sau đây thể hiện 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\) có 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á khởi điểm hoặc giá sàn được ký hiệu 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 toán bên thua trong phiên đấu giá
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ề 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 thắng phiên đấu giá (W) 1 đô la
Ứng dụng xếp thứ 2 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

Hoạt động 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 . Vì các mã này giữ nguyên các mã nhận dạng giống nhau (BidRequest.google_query_id trong Giao thức RTB của Authorized Buyers hoặc BidRequestExt.google_query_id trong giao thức OpenRTB), bạn có thể xác định các yêu cầu giá thầu tương quan sau khi làm phẳ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. Với chức năng phân tách giá thầu, mỗi đượ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ư đủ điều kiện mã thanh toán có liên quan đến định dạng được chỉ định trong yêu cầu.

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

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

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

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

Làm phẳng trước

Làm phẳng sau

Ư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ở. Với tính năng phân tách giá thầu cho các giao dịch, một giá thầu sẽ được gửi cho phiên đấu giá mở và một yêu cầu cho mỗi loại giá cố định giao dịch. 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 phiên đấu giá và giá cố định các loại giao dịch, 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á mở và giao dịch giá cố định, thì bên đặt giá thầu sẽ nhận được cho mỗi yêu cầu giá thầu trong đó có các quy tắc ràng buộc như thời lượng quảng cáo tối đa và liệu quảng cáo có thể bỏ qua được phép có thể khác nhau. Do đó, làm phẳng được áp dụng cho quảng cáo cho phép bạn dễ dàng hơn trong việc phân biệt những hạn chế về quảng cáo cho phiên đấu giá và giao dịch giá cố định.

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

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

Thời lượng Thời lượng có thể bỏ qua Khả năng bỏ qua
Giao thức của 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 Google có thể có URL có thể bỏ qua chi tiết và thời lượng không thể bỏ qua, thì việc triển khai OpenRTB chỉ có một giá trị thời lượng tối đa.

Trước khi phân tách giá thầu, maxduration của OpenRTB sẽ được đặt thành phần dưới của max_ad_duration trong giao thức Google và skippable_max_ad_duration trường. 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 minh hoạ cách dịch một yêu cầu giao thức của Google thành OpenRTB trước và sau khi phân tách giá thầu. Giao thức tương đương của Google yêu cầu có max_ad_duration là 15 và skippable_max_ad_duration trong tổng số 60.

Ví dụ: max_ad_duration skip (đúng HOẶC sai)
Yêu cầu ban đầu mà không làm phẳng 15 true
Yêu cầu đã được làm phẳng #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 thời lượng video có thể bỏ qua sẽ chỉ diễn ra khi các điều kiện sau được đáp ứng:

  • Yêu cầu cho phép phát video.
  • Cả video bỏ qua và không bỏ qua đều được phép và hai giới hạn tối đa tương ứng thời lượng khác nhau về giá trị.
  • 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 đó. Nhờ đó, bạn có thể đặt giá thầu cho nhiều cơ hội quảng cáo cho một nhóm nhất định.

Đo lường mở

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

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. Đối với giao thức Authorized Buyers, được tìm thấy trong BidRequest.adslot[].excluded_attribute. Đối với Giao thức OpenRTB, trong đó có thuộc tính battr cho Quảng cáo biểu ngữ hoặc Video, tùy thuộc vào định dạng.

Để biết thêm thông tin về cách diễn giải yêu cầu giá thầu có chứa nội dung Mở Các tín hiệu đo lường, vui lòng tham khảo bài viết Đo lường mở SDK trong 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

Google

JSON OpenRTB

Protobuf OpenRTB

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

Google

JSON OpenRTB

Protobuf OpenRTB

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

Google

Protobuf OpenRTB

Gốc ứng dụng

Google

JSON OpenRTB

Protobuf OpenRTB

Video trên web

Google

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

Protobuf OpenRTB