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.
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.
Yêu cầu phân tích cú pháp
Google gửi một yêu cầu giá thầu được chuyển đổi tuần tự ở định dạng OpenRTB JSON hoặc Protobuf, được đính kèm dưới dạng tải trọng của yêu cầu POST HTTP. Định dạng nhận được phụ thuộc vào cấu hình của điểm cuối. Hãy xem phần 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 để nhận được BidRequest đã chuyển đổi tuần tự. Nếu đang sử dụng định dạng Protobuf, bạn phải tải openrtb.proto và openrtb-adx.proto xuống từ trang dữ liệu tham chiếu và sử dụng các tệp này để tạo một thư viện có thể dùng để phân tích cú pháp thông báo BidRequest. Ví dụ: mã C++ sau đây phân tích cú pháp một yêu cầu được cung cấp tải trọng POST trong một chuỗi:
Sau khi có BidRequest, bạn có thể xử lý tệp này dưới dạng một đối tượng, trích xuất và diễn giải các trường mà bạn cần. Ví dụ: trong C++, việc lặp lại các giao dịch trong "BidRequest" OpenRTB có thể có dạng như sau:
Bạn sẽ 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 bằng một hoặc nhiều
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 khoảng không quảng cáo của thoả thuận, bạn có thể tìm thấy mã nhận dạng thanh toán được liên kết với người mua có liên quan bằng cách 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 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 của bên đặt giá thầu
Nếu muốn, bạn có thể chèn một số thông tin từ BidRequest vào URL điểm cuối đặt giá thầu bằng cách sử dụng macro. Nếu bạn định cấu hình một URL điểm cuối bằng một hoặc nhiều macro, thì các macro đó sẽ được mở rộng nếu thông tin đó có trong yêu cầu giá thầu. Điều này có thể hữu ích, chẳng hạn như nếu bạn muốn cân bằng tải dựa trên thông tin trong BidRequest.
Hãy liên hệ với người quản lý tài khoản của bạn để yêu cầu hỗ trợ về các macro mới.
Macro
Mô tả
%%GOOGLE_USER_ID%%
Được thay thế bằng Mã nhận dạng người dùng của Google có trong BidRequest.user.id. 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%%
Thay thế bằng 1 để cho biết yêu cầu giá thầu đến từ thiết bị di động hoặc 0 nếu không. Điều này dựa trên giá trị của BidRequest.device.devicetype, trong đó thiết bị di động được biểu thị bằng HIGHEND_PHONE (4) hoặc Tablet (5).
%%HAS_VIDEO%%
Thay thế bằng 1 để cho biết rằng yêu cầu giá thầu chứa khoảng không quảng cáo trong video hoặc 0 nếu không. Điều này dựa trên việc liệu BidRequest.imp.video có được điền vào yêu cầu giá thầu hay không.
%%HOSTED_MATCH_DATA%%
Được thay thế bằng một giá trị dựa trên BidRequest.user.buyeruid.
%%MOBILE_IS_APP%%
Thay thế bằng 1 để cho biết rằng yêu cầu giá thầu là dành cho khoảng không quảng cáo ứng dụng di động, nếu không thì là 0. Điều này dựa trên việc liệu BidRequest.app có được điền sẵn hay không.
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ã cơ số 32 để giải mã phần chuỗi 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, hãy giải mã giá trị này:
GEWTIMRZGYYTANJYG4======
sẽ dẫn đến:
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 được báo cáo là:
mbappgewtgmjug4ytmmrtgm888888.com
Giải mã giá trị này:
GEWTGMJUG4YTMMRTGM======
sẽ dẫn đến:
1-314716233
Kết quả 314716233 là mã ứng dụng cho ứng dụng iOS
TextNow.
Tìm tên ứng dụng di động qua 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:
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 trên mạng và sàn giao dịch tham gia tính năng Đặt giá thầu mở tương tự như yêu cầu của Authorized Buyers tham gia tính năng đặt giá thầu theo thời gian thực tiêu chuẩn. 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 tính năng này bao gồm:
OpenRTB
Thông tin chi tiết
BidRequest.imp.ext.dfp_ad_unit_code
Chứa mã mạng Ad Manager của nhà xuất bản, theo sau là hệ thống 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ụ: nội dung này sẽ xuất hiện với định dạng tương tự như:
/1234/cruises/mars.
BidRequest.user.data.segment
Các 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 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ệ:
Các nhà cung cấp khác chỉ có thể tham gia nếu được khai báo trong BidRequest:
Trong BidRequest, trường BidRequest.imp.ext.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 allowed_vendor_type được liệt kê trong tệp từ điển vendors.txt.
Ví dụ về yêu cầu giá thầu
Các ví dụ sau đây thể hiện 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 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.
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.
Thông tin phản hồi theo thời gian thực sẽ điền sẵn BidRequest.ext.bid_feedback dựa trên kết quả của một hoặc nhiều giá thầu mà bạn đã đặt trước đó và có thể được dùng để tìm thông tin chi tiết như liệu giá thầu có thắng phiên đấu giá hay không hoặc giá thầu tối thiểu cần thiết để thắng phiên đấu giá. Hãy liên hệ với người quản lý tài khoản của bạn để bật tính năng phản hồi theo thời gian thực.
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 tệp Vùng đệm giao thức của tiện ích OpenRTB.
Khi Authorized Buyers gửi yêu cầu giá thầu đến một 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:
messageBidFeedback{//TheuniqueidfromBidRequest.id.optionalstringrequest_id=1;//Thestatuscodeforthead.Seecreative-status-codes.txtinthe//technicaldocumentationforalistofids.optionalint32creative_status_code=2;//Deprecated.ThisfieldisnotpopulatedandwillberemovedafterMarch,//2025.Ifthebidwontheauction,thisisthepricepaidinyouraccount//currency.Ifthebidparticipatedintheauctionbutwasout-bid,this//istheCPMthatshouldhavebeenexceededinordertowin.Thisisnot//setifthebidwasfilteredpriortotheauction,ifthepublisheror//winningbidderhasoptedoutofpricefeedbackorifyouraccounthas//optedoutofsharingwinningpriceswithotherbidders.Forfirst-price//auctions,minimum_bid_to_winispopulatedinsteadofthisfield.optionaldoubleprice=3[deprecated=true];//Theminimumbidvaluenecessarytohavewontheauction,inyouraccount//currency.Ifyourbidwontheauction,thisisthesecondhighestbid//thatwasnotfiltered(includingthefloorprice).Ifyourbiddidn't win//theauction,thisisthewinningcandidate's bid. This field will only be//populatedifyourbidparticipatedinafirst-priceauction,andwillnot//bepopulatedifyourbidwasfilteredpriortotheauction.optionaldoubleminimum_bid_to_win=6;//Theminimumbidvaluenecessarytohavewontheserver-sidecomponentof//theoverallauctiongiventhattherewasalsoaninterestgroupbidding//componenttotheoverallauctionwhichranusingtheProtectedAudience//API.ThevalueisexpressedinCPMofthebuyeraccountcurrency.The//minimumbidtowinfortheoverallauction,includingbidsfromthe//server-sideandtheon-deviceinterestgroupcomponents,ispopulatedin//theminimum_bid_to_winfieldofthesameBidFeedbackobject.optionaldoublesscminbidtowin=14;//Billableeventratemultiplierthatwasappliedtothisbidduring//ranking.Theadjustmentreflectsthelikelihoodthatyourbidwould//generateabillableevent(namely,theadrenderssuccessfully)ifitwon//theauction,relativetotheprobabilitythatotherbidsgeneratea//billableeventiftheywontheauction.Thisadjustmentcanbelargeror//smallerthan1.Thisaffectsthefinalrankingintheauctiononly;in//particular,thismultiplierdoesnotaffectthepaymentorwhetherthe//bidclearsanyfloorprice.optionalfloatbillable_event_rate_bid_adjustment=13[default=1];//WhenapublisherusesanRTBauctionandwaterfall-basedSDKmediationon//thesamequery,thewinnerofthereal-timeauctionmustalsocompetein//amediationwaterfall(whichisorderedbyprice)towintheimpression.//Ifthebidparticipatedintheauctionandtherewasnowaterfall,the//valueofthisfieldis0.Ifthebidparticipatedintheauctionand//therewasawaterfall,thevalueofthisfieldisapricerepresentinga//samplebidfromtheeligiblemediationnetworksthatwerehigherthanthe//auctionwinner,weightedbyexpectedfillrate.Thisfieldcanbeused//inconjunctionwithminimum_bid_to_wintotrainbiddingmodels.TheCPM//isinyouraccountcurrency.optionaldoublesampled_mediation_cpm_ahead_of_auction_winner=8;messageEventNotificationToken{//Thecontentsofthetoken.optionalstringpayload=1;}//Thetokenincludedinthecorrespondingbid.optionalEventNotificationTokenevent_notification_token=4;//ThecreativeIDincludedinthecorrespondingbid.optionalstringbuyer_creative_id=5;//Possibletypesofbidresponsefeedbackobjects.enumFeedbackType{FEEDBACK_TYPE_UNSPECIFIED=0;//Feedbackforabidthatwassubmittedonabidresponse.BID_FEEDBACK=1;//Feedbackforaninterestgroupbuyersubmittedonabidresponseto//particpateinaninterestgroupbiddingcomponentoftheauctionrun//usingtheProtectedAudienceAPI.INTEREST_GROUP_BUYER_FEEDBACK=2;}//ThetypeoftheBidFeedbackmessage.Googlewillsendseparate//BidFeedbackobjectsfor://a)Eachbidsubmittedonabidresponse//b)Eachbuyersubmittedonabidresponsetoparticpateinaninterest//groupbiddingcomponentoftheauctionrunusingtheProtectedAudience//API.optionalFeedbackTypefeedbacktype=15;//Originofaninterestgroupbuyerthatwasincludedinthebidresponse.//Thisfieldispopulatedonlyforfeedbackwhereabidderoptedinan//interestgroupbuyertoparticipateintheinterestgroupbidding//componentoftheoverallauctionrunusingtheProtectedAudienceAPI.//Tolearnmoreaboutorigins,seehttps://www.rfc-editor.org/rfc/rfc6454.//TolearnmoreaboutinterestgroupbiddingandtheProtectedAudience//API,see//https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.optionalstringbuyerorigin=16;//Thestatuscodeforthesubmittedinterestgroupbuyer.Thisfieldis//onlypopulatedinthefeedbackforaninterestgroupbuyerthatabidder//requestedtoenterintotheinterestgroupauctionthroughthebid//response.Individualcreativestatuscodesofbidssubmittedbythebuyer//intheon-deviceinterestgroupauctionarenotavailable.See//https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt//foralistofinterestgroupbuyerstatuscodes.optionalint32igbuyerstatus=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 ý nghĩa của mã trong
creative-status-codes.txt. Xin lưu ý rằng nếu thắng giá thầu, bạn có thể chọn không tham gia tính năng ý kiến phản hồi về giá. Để biết thêm thông tin, hãy xem bài viết Cách chọn không tham gia.
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 đến phiên đấu giá.
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 (bị trả giá cao hơn trong phiên đấu giá).
Người mua đã gửi một 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
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ác trường minimum_bid_to_win và sampled_mediation_cpm_ahead_of_auction_winner nếu giá thầu không bị lọc khỏi phiên đấu giá. Bạn có thể sử 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 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, thì giá trị của trường này là giá thể hiện giá thầu mẫu từ một trong các mạng dàn xếp đủ điều kiện cao hơn giá thầu của người 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ẽ đáp ứng 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 điều 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à 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ệ đáp ứng đã cho:
\(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 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 của người về nhì được biểu thị là \(R\).
Cách tính cho 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\) có xác suất \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Đối với \(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 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\%\)
Network 4
\(C_4 = $0.10\)
\(f_4 = 85\%\)
Giả sử kết quả của phiên đấu giá RTB như sau:
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 USD
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 tính giá trị và xác suất cho minimum_bid_to_win và sampled_mediation_cpm_ahead_of_auction_winner cho một giá thầu đã thắng.
Sau đây là ví dụ về cách tính giá trị và xác suất cho minimum_bid_to_win và sampled_mediation_cpm_ahead_of_auction_winner đối với một giá thầu thua cuộc.
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
Tính năng làm phẳng giá thầu mô tả quá trình 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. Khi một yêu cầu giá thầu được làm phẳng, bạn có thể biết yêu cầu giá thầu nào thuộc yêu cầu ban đầu vì các yêu cầu đó sẽ có giá trị giống hệt nhau trong trường BidRequest.ext.google_query_id.
Tính năng làm phẳng giá thầu được bật theo mặc định, nhưng bạn có thể liên hệ với người quản lý tài khoản nếu muốn tắt tính năng này.
Đị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:
Cơ hội quảng cáo cho một bên đặt giá thầu cụ thể có thể áp dụng cho nhiều loại giao dịch, ngoài phiên đấu giá mở. Khi làm phẳng giá thầu cho các 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.
Khả năng bỏ qua và thời lượng video
Thông số kỹ thuật OpenRTB không có các trường riêng để chỉ định thời lượng video tối đa của quảng cáo có thể bỏ qua và không thể bỏ qua. Phương thức triển khai của Google sử dụng tính năng làm phẳng giá thầu để phân biệt giữa các giá thầu này bằng cách sử dụng các trường BidRequest.video.maxduration và BidRequest.video.skip hiện có.
Sau đây là ví dụ về cách khoảng không quảng cáo dạng video được làm phẳng khi thời lượng tối đa của quảng cáo không thể bỏ qua là 15 và thời lượng tối đa của quảng cáo có thể bỏ qua là 60.
Ví dụ:
max_ad_duration
skip (true HOẶC false)
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 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 đăng video.
Cả video có thể bỏ qua và video 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 tham gia Phiên đấu giá kín hoặc Phiên đấu giá mở.
Bạn có thể chọn không sử dụng loại làm phẳng này bằng cách liên hệ với người quản lý tài khoản kỹ thuật. Khi bạn tắt chế độ này và nhà xuất bản cho phép cả quảng cáo dạng video có thể bỏ qua và không thể bỏ qua với thời lượng tối đa khác nhau dựa trên khả năng bỏ qua, skip sẽ được đặt thành true và maxduration sẽ được đặt thành thời lượng ngắn hơn giữa các giới hạn quảng cáo có thể bỏ qua và không thể bỏ qua.
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,
tức là 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ẻ trong 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 một nhà xuất bản có hỗ trợ Đ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 mà nhà xuất bản có thể loại trừ hay không. Bạn có thể tìm thấy thuộc tính 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ở trên Trung tâm trợ giúp.
Yêu cầu giá thầu mẫu
Các phần sau đây cho thấy các yêu cầu giá thầu mẫu cho nhiều loại quảng cáo.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-05-01 UTC."],[[["Bid requests are sent as HTTP POST requests with a binary payload in Protobuf format, and they are parsed into a `BidRequest` object for access."],["Billing IDs, which are essential for transactions, are provided in specific fields of the `BidRequest` and must be used in corresponding bids."],["Real-time feedback, available in subsequent bid requests, offers details like creative status codes and minimum bid amounts, including a custom `event_notification_token` for debugging."],["First-price auction bidding models utilize `minimum_bid_to_win` and `sampled_mediation_cpm_ahead_of_auction_winner` feedback signals to help adjust bidding strategies."],["Bid flattening separates complex `BidRequest` data into multiple requests based on ad formats, deals, and video ad types, all identifiable by a shared `google_query_id`."]]],["Bid requests are HTTP POSTs using OpenRTB Protobuf, replacing the deprecated Google RTB protocol. Parsing involves `ParseFromString()` to access fields in the `BidRequest` object. Billing IDs, found in `BidRequest.imp.ext.billing_id` and `BidRequest.imp.pmp.deal.ext.billing_id`, must be specified in `BidResponse.seatbid.bid.ext.billing_id`. Key information comes from dictionary files. Bid URL macros dynamically insert `BidRequest` data. Complex bid requests can be broken into simpler, flattened requests per format or deal, such as skippable/non-skippable video ads, or video pods. Bidders get real-time feedback. The provided sample requests are used to help the process.\n"]]