Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
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á đơn đăng ký để xử lý yêu cầu giá thầu.
Phân tích cú pháp yêu cầu
Google gửi 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 POST qua HTTP. 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 bản sao của thông báo BidRequest. BidRequest được xác định trong realtime-bidding.proto, có thể lấy trên trang dữ liệu tham chiếu. Bạn có thể phân tích cú pháp thông báo
bằng phương thức ParseFromString() trong lớp đã tạo cho
BidRequest. Ví dụ: mã C++ sau đây phân tích cú pháp một yêu cầu khi có 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ý đối tượng này dưới dạng một đối tượng, trích xuất và diễn giải các trường cần thiết. 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ư Mã nhận dạng người dùng Google, 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 lượt hiển thị nhất định, thì các nhóm quảng cáo đó sẽ không khớp. Trong trường hợp thông tin bị thiếu không quan trọng đối với các điều kiện nhắm mục tiêu trước, thì yêu cầu giá thầu sẽ được gửi kèm theo thông tin bị bỏ qua.
Thông tin về nhóm quảng cáo nhắm mục tiêu trước có sẵn trong
nhóm MatchingAdData cho mỗi AdSlot. Tệp này chứa mã nhóm quảng cáo phù hợ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 một số trường hợp nhất định, bạn cần chỉ định rõ ràng billing_id để phân bổ trong BidResponse.AdSlot, chẳng hạn như khi BidRequest.AdSlot có nhiều hơn một matching_ad_data.
Để biết thêm thông tin về các quy tắc 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 giá trị nhận dạng được xác định trong các tệp từ điển có sẵn trên trang 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 trong những trường hợp như khi bạn sử dụng một giao diện người dùng gọn nhẹ tải cân bằng 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 của bạn để yêu cầu hỗ trợ về
các macro mới.
Macro
Nội dung mô tả
%%GOOGLE_USER_ID%%
Thay thế bằng google_user_id từ BidRequest. Ví dụ: URL của bên đặt giá thầu
Kết quả tương đương với ứng dụng Android
slither.io.
Các trường Đặt giá thầu mở
Yêu cầu giá thầu được gửi đến bên đặt giá thầu trao đổi và bên đặt giá thầu trong mạng tham gia Đặt giá thầu mở cũng tương tự như yêu cầu của Authorized Buyers tham gia đặt giá thầu theo thời gian thực tiêu chuẩn. Khách hàng trong tính năng Đặt giá thầu mở sẽ nhận được một số ít trường bổ sung và một số trường hiện có có thể có trường hợp sử dụng thay thế. 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à hệ phân cấp đơn vị quảng cáo, được phân tách bằng dấu gạch chéo lên.
Ví dụ: thành phần này sẽ xuất hiện với định dạng tương tự như: /1234/cruises/mars.
BidRequest.user.data[].segment[]
BidRequest.adslot[].exchange_bidding.key_value[]
Cặp khoá-giá trị lặp lại được gửi từ nhà xuất bản đến bên đặt giá thầu trao đổi.
Bạn có thể xác định rằng giá trị là các cặp khoá-giá trị do nhà xuất bản gửi khi đặt BidRequest.user.data[].name thành “Publisher Passed”.
Khai báo nhà cung cấp được cho 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ỉ cho phép những nhà cung cấp mà Google đã xét duyệt để tham gia vào hoạt động tương tác của Authorized Buyers.
Để hiểu rõ BidRequest và tạo BidResponse, bạn cần lưu ý 2 khả năng khai báo nhà cung cấp công nghệ:
Các nhà cung cấp khác chỉ có thể tham gia nếu được khai báo trong cả BidRequest và BidResponse:
Trong BidRequest, trường allowed_vendor_type chỉ định những nhà cung cấp mà người bán cho phép. Các nhà cung cấp sẽ được gửi trong trường allowed_vendor_type của BidRequest được liệt kê trong tệp từ điển Vendors.txt.
Trong BidResponse, trường vendor_type chỉ định nhà cung cấp được phép nào mà người mua dự định sử dụng.
Yêu cầu giá thầu mẫu
Các ví dụ sau đây biểu thị các mẫu yêu cầu Protobuf và JSON mà con người có thể đọc được.
Để chuyển đổi yêu cầu giá thầu thành dạng nhị phân, như khi bạn nhận được từ tải trọng POST trong một yêu cầu thực, bạn có thể thực hiện các thao tác sau (trong C++). Tuy nhiên, lưu ý rằng điều này không áp dụng cho JSON của 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 các 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 của iOS hoặc
mã nhận dạng cho quảng cáo của Android. Những mã này được gửi qua macro
%%EXTRA_TAG_DATA%% trong thẻ JavaScript do
Authorized Buyers quản lý.
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 đã mã hoá MobileAdvertisingId như
%%EXTRA_TAG_DATA%%:
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 trong quá trình hiển thị lượt hiển thị. Những danh sách người dùng này có thể được duy trì
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 công cụ 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 hoạt động tái tiếp thị.
Phản hồi theo thời gian thực
Tính năng phản hồi theo thời gian thực được cung cấp cho Authorized Buyers, cũng như đối tác trao đổi và mạng sử dụng tính năng Đặt giá thầu mở.
Tính năng phản hồi giá thầu phản hồi được hỗ trợ trong yêu cầu giá thầu tiếp theo cho cả
Giao thức AdX và OpenRTB. Đối với OpenRTB, mã nhận dạng này được gửi trong
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ũng có thể gửi dữ liệu tuỳ chỉnh trong giá thầu phản hồi (trong AdX Proto hoặc OpenRTB) bằng cách 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 có thể biết và có thể giúp gỡ lỗi. Ví dụ: mã nhắm mục tiêu hoặc mã đặt giá thầu mới đạ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 biết. Để biết thông tin chi tiết, hãy xem Vùng đệm giao thức tiện ích OpenRTB cho RTB và Proto AdX 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 sẽ gửi ý kiến phản hồi về phản hồi bằng thông báo BidResponseFeedback như thể hiện 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ã
có nghĩa trong tệp
creative-status-codes.txt. Lưu ý rằng nếu thắng giá thầu, bạn có thể chọn không nhận phản hồi về giá. Để biết thêm thông tin, hãy xem phần Cách chọn không sử dụng.
Nội dung 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 các nội dung sau:
Kết quả đấu giá
Phản hồi theo thời gian thực
Người mua chưa gửi giá thầu.
Miễn phí.
Người mua đã gửi một giá thầu đã được lọc ra trước khi tham gia phiên đấu giá.
Đối với lượt hiển thị ứng dụng và mã trạng thái mẫu quảng cáo của 83, nhà xuất bản ứng dụng có thể đang 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 sẽ cạnh tranh với 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
Sau đây là mẫu phản hồi theo thời gian thực như trong các giao thức được hỗ trợ:
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 theo thời gian thực bao gồm các trường minimum_bid_to_win và sampled_mediation_cpm_ahead_of_auction_winner nếu giá thầu không được lọc khỏi phiên đấu giá. Bạn có thể dùng các tín hiệu này để thông báo cho logic đặt giá thầu về mức giá thầu có thể cao hơn hoặc thấp hơn để giành được lượt hiển thị.
minimum_bid_to_win: Giá thầu tối thiểu có thể đặt để 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á, đây sẽ là giá thầu thấp nhất mà bạn có thể đặt trong khi vẫn giành chiến thắng. Nếu bạn thua phiên đấu giá, đây sẽ là giá thầu thắng cuộc.
sampled_mediation_cpm_ahead_of_auction_winner: Nếu có các mạng khác trong chuỗi dàn xếp, thì giá trị của trường này là giá đại diện cho giá thầu mẫu từ một trong các mạng dàn xếp đủ điều kiện có giá trị cao hơn mạng dàn xếp giành chiến thắng trong phiên đấu giá, được tính trọng số theo tỷ lệ đáp ứng 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ẽ thực hiện, hoặc nếu nhà xuất bản không sử dụng tính năng dàn xếp SDK.
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 thông tin 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\]
Dưới đây là tỷ lệ đáp ứng tương ứng cho 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 CPM đó từ phần tử chuỗi dàn xếp \(i\), dựa trên tỷ lệ lấp đầy
nhất định:
\(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á khởi điểm, hay còn gọi là giá sàn, được ký hiệu là \(F\).
Giá thầu thứ hai được biểu thị là \(R\).
Tính toán người 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\) với 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\).
Tính toán cho người 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 như 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ử kết quả sau đây là kết quả của phiên đấu giá RTB:
Phiên đấu giá RTB
CPM
Người thắng phiên đấu giá (W)
1 đô la
Loạt phiên đấu giá (R)
0,05 USD
Giá đặt trước / sàn (F)
$0
Giá thầu thắng phiên đấu giá
Sau đây là ví dụ về cách tính các giá trị và xác suất của
minimum_bid_to_win và
sampled_mediation_cpm_ahead_of_auction_winner cho
giá thầu chiến thắng.
Sau đây là ví dụ về cách tính toán các giá trị và xác suất của
minimum_bid_to_win và
sampled_mediation_cpm_ahead_of_auction_winner cho
những giá thầu bị 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\%\)
Làm phẳng giá thầu
Quy trình làm phẳng giá thầu mô tả cách xử lý một BidRequest phức tạp thành nhiều yêu cầu giá thầu được gửi đến ứng dụng của bạn. Vì các giá trị này giữ lại 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 có 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 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.
Những yêu cầu giá thầu chứa các định dạng sau đây 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ề cách làm phẳng định dạng quảng cáo
Dưới đây là ví dụ về yêu cầu giá thầu JSON OpenRTB đơ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 đã làm phẳng tương đương:
Ngoài phiên đấu giá mở, 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 loại giao dịch. Với tính năng làm phẳng giá thầu cho các giao dịch, một yêu cầu 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 giao dịch theo giá cố định. Trong thực tế, các điều kiện ràng buộc quảng cáo có thể khác nhau giữa các phiên đấu giá và các loại giao dịch theo 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á mở và giao dịch theo giá cố định, người đặt giá thầu sẽ nhận được yêu cầu giá thầu riêng biệt cho từng trường hợp 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ó được phép hay không. Do đó, tính năng làm phẳng được áp dụng cho cơ hội quảng cáo cho phép bạn dễ dàng phân biệt các giới hạn quảng cáo cho phiên đấu giá mở và giao dịch theo giá cố định.
Thời lượng video tối đa có thể bỏ qua
Phương thức triển khai giao thức và OpenRTB của Google hỗ trợ các trường sau đây về thời lượng và khả năng bỏ qua của 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ó thời lượng chi tiết
có thể bỏ qua và không thể bỏ qua, nhưng phương thức triển khai OpenRTB chỉ có một giá trị thời lượng tối đa
duy nhất.
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 của các trường max_ad_duration và
skippable_max_ad_duration trong giao thức Google. Hành vi này hiện đã chuyển 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 giá trị thể hiện maxduration cho cơ hội có thể bỏ qua và giá trị còn lại biểu thị cơ hội không thể bỏ qua.
Các ví dụ sau đây cho thấy cách yêu cầu giao thức Google chuyển sang OpenRTB trước và sau khi làm phẳng giá thầu. Yêu cầu giao thức tương đương của Google có max_ad_duration là 15 và skippable_max_ad_duration là 60.
Ví dụ:
max_ad_duration
skip (đúng HOẶC sai)
Yêu cầu ban đầu 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 #2: Có thể bỏ qua
60
true
Việc làm phẳng yêu cầu giá thầu cho 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 cho phép video.
Cả hai video có thể bỏ qua và không thể bỏ qua đều được phép, đồng thời 2 thời lượng tối đa tương ứ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 người đặt giá thầu có cá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 nhà quản lý tài khoản hỗ trợ kỹ thuật của mình.
Nhóm video
Các 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 làm phẳng, để mỗi yêu cầu giá thầu là 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 trên 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 những 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 được phân phát trong các môi trường trên ứ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 yêu cầu 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 có trong Thuộc tính mẫu quảng cáo có thể loại trừ của nhà xuất bản hay không. Đối với giao thức Authorized Buyers, bạn có thể tìm thấy giao thức này
trong BidRequest.adslot[].excluded_attribute. Đối với
giao thức OpenRTB, bạn có thể tìm thấy thông số này trong thuộc tính battr cho Biểu ngữ hoặc Video, tuỳ thuộc vào đị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ở trong Trung tâm trợ giúp.
Yêu cầu giá thầu mẫu
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.
