এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

সুরক্ষিত শ্রোতা API (পূর্বে FLEDGE)

প্রাইভেসি স্যান্ডবক্সের অংশ হিসেবে, ক্রোম প্রোটেক্টেড অডিয়েন্স এপিআই প্রস্তাব করেছে — একটি ইন-ব্রাউজার এপিআই যা বিজ্ঞাপনদাতাদের এবং বিজ্ঞাপন প্রযুক্তি কোম্পানিগুলিকে তৃতীয়-পক্ষের কুকিজের উপর নির্ভর না করেই আগ্রহ-গোষ্ঠী লক্ষ্যযুক্ত বিজ্ঞাপন দেখাতে দেয়, একই সাথে ব্যবহারকারীদের ক্রস-সাইট ট্র্যাকিং থেকে রক্ষা করে।

Chrome Protected Audience API-এর জন্য একটি অরিজিন ট্রায়াল চালাচ্ছে। অনুমোদিত ক্রেতারা Ad Manager প্রকাশক ইনভেন্টরিতে Protected Audience API-এর পরীক্ষায় অংশগ্রহণ করতে পারবেন। Protected Audience API পরীক্ষা করে দরদাতারা নিম্নলিখিত অর্জন করতে পারবেন:

সুরক্ষিত শ্রোতা API প্রবাহের কার্যকারিতা সম্পর্কে পুনরাবৃত্তি করুন এবং জানুন।
পাবলিক ফোরামে সম্ভাব্য API উন্নতির উপর প্রতিক্রিয়া তৈরি করুন—যেমন, GitHub ।
তৃতীয় পক্ষের কুকিজের উপর নির্ভর না করে API এর মাধ্যমে ব্যক্তিগতকৃত বিজ্ঞাপন সমর্থন করার জন্য প্রস্তুত থাকুন।

পরীক্ষায় আগ্রহী অনুমোদিত ক্রেতাদের বিস্তারিত জানার জন্য অনবোর্ডিং বিভাগটি পরীক্ষা করা উচিত।

দ্রষ্টব্য: যখন প্রোটেক্টেড অডিয়েন্স API (পূর্বে FLEDGE নামে পরিচিত) Chrome-এ সাধারণভাবে উপলব্ধ হবে, তখন অ্যাড ম্যানেজার তার পরীক্ষায় অন্তর্ভুক্ত ট্র্যাফিকের পরিমাণ ধীরে ধীরে বৃদ্ধি করতে শুরু করবে। আমরা প্রকাশকের আয়ের উপর প্রভাব পর্যবেক্ষণ করব কারণ আমরা ধীরে ধীরে ট্র্যাফিকের শতাংশ বৃদ্ধি করব, এবং যদি কোনও লক্ষণীয় নেতিবাচক প্রভাব দেখা দেয় তবে তা আর বাড়বে না। আমরা আশা করি যে 2023 সালের শেষ নাগাদ, প্রোটেক্টেড অডিয়েন্স API পরীক্ষার জন্য 10% পর্যন্ত Chrome ট্র্যাফিক সক্ষম করা হবে।

পরিবেশন প্রবাহের সারাংশ

অনুমোদিত ক্রেতা অংশীদারদের জন্য সুরক্ষিত দর্শক বিজ্ঞাপন পরিবেশন প্রবাহের একটি সারসংক্ষেপ এখানে দেওয়া হল:

Flow diagram

একজন দরদাতা তার বিজ্ঞাপনদাতাদের সাথে কাজ করে প্রতিটি বিজ্ঞাপনদাতার জন্য আগ্রহের গোষ্ঠী বজায় রাখার জন্য। প্রায়শই, বিজ্ঞাপনদাতারা আগ্রহের গোষ্ঠীগুলিতে একটি ব্রাউজার যুক্ত করার জন্য বিজ্ঞাপনদাতার পৃষ্ঠায় একটি দরদাতার ট্যাগ যুক্ত করে।
একজন শেষ ব্যবহারকারী একজন বিজ্ঞাপনদাতার পৃষ্ঠায় যান। পৃষ্ঠাটিতে দরদাতার ট্যাগ থাকতে পারে।
দরদাতার ট্যাগটি Protected Audience API joinAdInterestGroup() ব্যবহার করে। এই কলটি ব্রাউজারকে ব্যবহারকারীকে একটি আগ্রহের গোষ্ঠীতে যুক্ত করার অনুরোধ করে।
ব্যবহারকারী প্রকাশকের ওয়েবপেজ পরিদর্শন করেন। ব্যবহারকারীর ব্রাউজার গুগলের প্রকাশক বিজ্ঞাপন ট্যাগের জন্য অনুরোধ করে।
গুগলের প্রকাশক বিজ্ঞাপন ট্যাগ একটি গুগল সার্ভারে একটি প্রাসঙ্গিক বিজ্ঞাপনের অনুরোধ করে।
গুগল অংশগ্রহণকারী দরদাতাদের কাছে প্রাসঙ্গিক দরপত্রের অনুরোধ পাঠায়। আরও তথ্যের জন্য দরপত্রের অনুরোধ পরিবর্তন বিভাগটি দেখুন।
দরদাতা একটি দরপত্রের প্রতিক্রিয়া ফেরত পাঠান যার মধ্যে InterestGroupBidding বার্তা অন্তর্ভুক্ত থাকে, যা আগ্রহ গোষ্ঠী নিলামে অংশগ্রহণের জন্য প্রয়োজনীয়। OpenRTB-তে এটি BidResponse.ext.igbid ক্ষেত্রের সাথে নির্দিষ্ট করা হয়, এবং অবচিত Google RTB প্রোটোকলে এটি BidResponse.interest_group_bidding ক্ষেত্রের সাথে নির্দিষ্ট করা হয়। যদি দরদাতা এই তথ্য নির্দিষ্ট না করে, তাহলে Google নিলাম কনফিগারেশনে interestGroupBuyers এ দরদাতার উৎপত্তি অন্তর্ভুক্ত করে না। InterestGroupBidding ঐচ্ছিক ক্রেতা-নির্দিষ্ট সংকেতও থাকতে পারে যা ইন-ব্রাউজার নিলামের সময় দরদাতার বিডিং ফাংশনে প্রেরণ করা হবে। OpenRTB-তে এটি BidResponse.ext.igbid.igbuyer.buyerdata ক্ষেত্রের সাথে নির্দিষ্ট করা হয়, এবং অবচিত Google RTB প্রোটোকলে এটি BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals ক্ষেত্রের সাথে নির্দিষ্ট করা হয়। আরও তথ্যের জন্য দরপত্রের প্রতিক্রিয়া পরিবর্তন বিভাগটি দেখুন।
গুগল সার্ভার-সাইড নিলাম পরিচালনা করে এবং ব্রাউজারে একটি বিড প্রতিক্রিয়া ফেরত দেয়। সার্ভার-সাইড নিলামে ঐতিহ্যবাহী, সার্ভার-সাইড বিড বিবেচনা করা হয়। বিড প্রতিক্রিয়াতে একটি প্রাসঙ্গিক বিজয়ী বিড (যদি থাকে) সম্পর্কে তথ্য থাকতে পারে।
বিড প্রতিক্রিয়াতে ব্রাউজারে নিলামের জন্য একটি নিলাম কনফিগারেশন থাকে। এতে প্রতিটি অংশগ্রহণকারী ক্রেতার কাছ থেকে প্রাসঙ্গিক সংকেত (যা OpenRTB-এর buyerdata বা পূর্বে বাতিল করা Google RTB প্রোটোকলের per_buyer_signals এর মাধ্যমে পাঠানো হয়েছিল), প্রাসঙ্গিক বিজয়ীর তথ্য এবং বিড যোগ্যতার জন্য সেটিংস অন্তর্ভুক্ত থাকতে পারে।
Google-এর প্রকাশক ট্যাগটি ডিভাইসে আগ্রহের গ্রুপ নিলাম শুরু করার জন্য Protected Audience API runAdAuction() ব্যবহার করে। Google শুধুমাত্র সেই ক্রেতাদের অন্তর্ভুক্ত করে যাদের নিলাম কনফিগারেশনের সময় InterestGroupBidding এ InterestGroupBuyer হিসেবে অন্তর্ভুক্ত করা হয়েছিল।
Google প্রতিটি যোগ্য দরদাতার ঐচ্ছিক ক্রেতা-নির্দিষ্ট সংকেতগুলিকে সুরক্ষিত দর্শক নিলাম কনফিগারেশনে প্রেরণ করে।
যদি কোনও দরদাতার আগ্রহের গোষ্ঠী trustedBiddingSignalsUrl নির্দিষ্ট করে, তাহলে ব্রাউজারটি প্রতিটি গোষ্ঠীর trustedBiddingSignalsUrl কে প্রতিটি গোষ্ঠীর জন্য রিয়েল-টাইম সিগন্যাল আনার জন্য অনুরোধ করে। Protected Audience API spec- এ বিস্তারিত দেখুন।
ব্রাউজারটি প্রতিটি আগ্রহী গোষ্ঠীর জন্য দরদাতার generateBid() ব্যবহার করে যারা নিলামে অংশগ্রহণের জন্য যোগ্য এবং যারা নিলামে অংশগ্রহণ করতে আগ্রহী। এই ধাপে দরপত্র গণনা করা হয় এবং একটি সৃজনশীল নির্বাচন করা হয়। generateBid() দরদাতার দ্বারা প্রদত্ত ঐচ্ছিক ক্রেতা সংকেত এবং প্রদত্ত আগ্রহ গোষ্ঠীর জন্য বিশ্বস্ত দরপত্র সংকেতগুলিতে অ্যাক্সেস রাখে।
ব্রাউজারটি বিক্রেতার (এই ক্ষেত্রে, Google এর) scoreAd() ব্যবহার করে আগ্রহ গোষ্ঠীর বিজ্ঞাপন নিলামে প্রতিটি বিডকে একটি র‍্যাঙ্ক নির্ধারণ করে। প্রকাশকদের সুরক্ষা, বিজ্ঞাপন নীতি এবং অন্যান্য সীমাবদ্ধতার উপর ভিত্তি করে বিডগুলিকে র‍্যাঙ্ক এবং ফিল্টার করা হয়।
ব্রাউজারটি যোগ্য আগ্রহী গোষ্ঠীর দরপত্রের মাধ্যমে একটি নিলাম পরিচালনা করে। শীর্ষস্থানীয় প্রাসঙ্গিক দরপত্রটি ব্রাউজারে নিলামে অংশগ্রহণ করে।
নিলামের পরে, যদি কোনও আগ্রহী গোষ্ঠী বিজয়ী হয়, তাহলে ব্রাউজারটি বিক্রেতার reportResult() এবং দরদাতার reportWin() ব্যবহার করে প্রতিটি পক্ষকে ইন-ব্রাউজার নিলামের বিজয়ীর বিষয়ে অবহিত করে।
যদি কোনও আগ্রহ গোষ্ঠীর বিজ্ঞাপন জয়ী হয়, তাহলে Google-এর প্রকাশক ট্যাগ বিজ্ঞাপনটিকে একটি আইফ্রেমে রেন্ডার করে।

পরিবেশন প্রবাহের বিবরণ

বিজ্ঞাপন পরিবেশনের আগে

সৃজনশীল পর্যালোচনা

প্রোটেক্টেড অডিয়েন্স ইন-ব্রাউজার নিলাম থেকে পরিবেশন করার আগে ক্রিয়েটিভগুলি অবশ্যই Google দ্বারা পর্যালোচনা এবং অনুমোদিত হতে হবে। আপনি রিয়েল-টাইম বিডিং API এর মাধ্যমে অথবা স্বয়ংক্রিয় ক্রিয়েটিভ স্ক্যানিংয়ের মাধ্যমে ক্রিয়েটিভগুলি পর্যালোচনার জন্য জমা দিতে পারেন। প্রোটেক্টেড অডিয়েন্স ইন-ব্রাউজার ইন্টারেস্ট গ্রুপ বিজ্ঞাপন নিলামের জন্য ক্রিয়েটিভগুলিতে পর্যালোচনার জন্য renderUrls অন্তর্ভুক্ত থাকতে হবে।

renderUrls জন্য প্রয়োজনীয়তা:

API এর মাধ্যমে জমা দেওয়া renderUrl সাথে আগ্রহ গোষ্ঠীর বিজ্ঞাপন নিলামে ব্যবহৃত renderUrl মিল থাকা উচিত।
প্রতিটি renderUrl শুধুমাত্র একজন বিজ্ঞাপনদাতা বা বিজ্ঞাপন প্রচারণার প্রতিনিধিত্ব করতে পারে। একটি নির্দিষ্ট renderUrl একাধিক বিজ্ঞাপনদাতার পক্ষে বিজ্ঞাপন রেন্ডার করার জন্য ব্যবহার করা যাবে না। প্রতিটি renderUrl একটি একক সৃজনশীলের সাথে ম্যাপ করতে হবে।
বিজ্ঞাপনটি শেষবার বিড করার পর থেকে ৭ দিন পর্যন্ত Google এর অফলাইন সৃজনশীল পর্যালোচনা সিস্টেমের মাধ্যমে renderUrl অ্যাক্সেসযোগ্য এবং আনা যায়।

রিয়েল-টাইম বিডিং এপিআই

দরদাতারা আগ্রহ গোষ্ঠীর বিডিংয়ের জন্য সৃজনশীল আপলোড করতে রিয়েল-টাইম বিডিং API ব্যবহার করতে পারেন।

স্বয়ংক্রিয় সৃজনশীল স্ক্যানিং

রিয়েল-টাইম বিডিং API-এর মাধ্যমে আপলোড না করা সৃজনশীল জিনিসগুলির জন্য দরদাতারা স্বয়ংক্রিয় সৃজনশীল স্ক্যানিং সেট আপ করতে পারেন।

আপনি যদি স্বয়ংক্রিয় সৃজনশীল স্ক্যানিং সেট আপ করেন, তাহলে Google ইন-ব্রাউজার নিলামে সৃজনশীল জিনিসগুলি খুঁজে বের করে এবং স্বয়ংক্রিয়ভাবে সেগুলি স্ক্যান করে, যাতে সেগুলি ভবিষ্যতের নিলামের জন্য যোগ্য হয়।

স্বয়ংক্রিয় সৃজনশীল স্ক্যানিং কীভাবে চালু করবেন তা এখানে দেওয়া হল:

অনুমোদিত ক্রেতা অ্যাকাউন্টে সমস্ত আগ্রহী গোষ্ঠীর ক্রিয়েটিভের renderUrl অরিজিন যোগ করুন।

ক্রিয়েটিভের HTTP প্রতিক্রিয়ায় নিম্নলিখিত কাস্টম HTTP হেডারগুলি যোগ করুন:

Authorized-Buyers-Creative-ID

স্ট্রিং

ক্রেতা-নির্দিষ্ট সৃজনশীল আইডি। সৃজনশীল আইডির সর্বোচ্চ দৈর্ঘ্য ১২৮ বাইট।

Authorized-Buyers-Click-Through-URLs

স্ট্রিং

RFC2396 অনুসারে এনকোড করা সৃজনশীলের জন্য ঘোষিত গন্তব্য URL গুলির সেট।

উদাহরণ:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

সৃজনশীল মেয়াদ শেষ

সৃজনশীল ছবি ১৫ দিনের জন্য অনুমোদিত হয়। আপনি যদি রিয়েল-টাইম বিডিং API ব্যবহার করে সৃজনশীল ছবি জমা দেন, তাহলে ১৫ দিন পরে আপনাকে সৃজনশীল ছবি পুনরায় জমা দিতে হবে। আপনি যদি স্বয়ংক্রিয় সৃজনশীল স্ক্যানিংয়ের উপর নির্ভর করেন, তাহলে স্ক্যানিং প্রক্রিয়া স্বয়ংক্রিয়ভাবে সেগুলি পুনরায় স্ক্যান করে।

ক্রেতা রিপোর্টিং আইডি

ক্রেতার দেওয়া মাত্রা (যেমন, প্রচারণা আইডি বা বিজ্ঞাপনদাতা আইডি) ব্যবহার করে আপনি রিপোর্টিং মেট্রিক্স (যেমন ইমপ্রেশন) ভেঙে ফেলতে পারেন। আগ্রহের গ্রুপের খরচের জন্য একটি মাত্রা যোগ করতে, ব্যবহারকারীর ডিভাইসটি আগ্রহের গ্রুপে যোগ করার সময় আপনার বিজ্ঞাপনের জন্য একটি buyerAndSellerReportingId নির্দিষ্ট করুন। সুরক্ষিত দর্শক ডকুমেন্টেশনে অতিরিক্ত বিবরণ দেখুন।

ইন্টারেস্ট গ্রুপ কনফিগারেশনে buyerAndSellerReportingId কীভাবে যোগ করবেন তার একটি উদাহরণ নিচে দেওয়া হল:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

buyer_reporting_id অনুমোদিত ক্রেতার রিপোর্টিং টুলে একটি নতুন মাত্রা হিসেবে Buyer Reporting ID মাত্রা হিসেবে উপস্থিত হবে।

সার্ভার-সাইড নিলাম

বিড অনুরোধের পরিবর্তন

পরীক্ষায় ব্যবহারের জন্য সমর্থিত প্রোটোকলের প্রাথমিক সংস্করণগুলি নিম্নরূপ:

OpenRTB এর প্রাথমিক লিঙ্ক
গুগল আরটিবি প্রোটোকল (অবঞ্চিত) প্রাথমিক লিঙ্ক

আগ্রহ গোষ্ঠীর নিলাম সহায়তা নির্দেশ করুন

আগ্রহ গোষ্ঠীর নিলামের জন্য সমর্থন নির্দেশ করার জন্য বিড অনুরোধগুলিতে একটি নতুন ক্ষেত্র রয়েছে:

ওপেনআরটিবি:
- BidRequest.imp.ext.ae
- BidRequest.imp.ext.igbid
গুগল আরটিবি প্রোটোকল (অবঞ্চিত):
- BidRequest.adslot.supported_auction_environment
- BidRequest.adslot.interest_group_bidding_allowed

আপনি এই ক্ষেত্রটি ব্যবহার করে ব্রাউজারে সুরক্ষিত শ্রোতাদের আগ্রহ গোষ্ঠীর নিলামকে সমর্থন করে এমন ইম্প্রেশন সুযোগ এবং শুধুমাত্র ঐতিহ্যবাহী সার্ভার-সাইড এক্সচেঞ্জ নিলামকে সমর্থন করে এমন ইম্প্রেশন সুযোগের মধ্যে পার্থক্য করতে পারেন। AuctionEnvironment enum-এর নিম্নলিখিত মান থাকতে পারে:

SERVER_SIDE_AUCTION (OpenRTB JSON: 0 ): বিজয়ী বিজ্ঞাপন নির্ধারণকারী নিলাম এক্সচেঞ্জের সার্ভারে চলে।
ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1 ): সুরক্ষিত দর্শক সমর্থন সহ অনুরোধ, যেখানে এক্সচেঞ্জের সার্ভারে একটি প্রাসঙ্গিক নিলাম এবং আগ্রহী গোষ্ঠীর বিডিং এবং চূড়ান্ত নিলাম ব্রাউজারে চলে।
SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3 ): প্রাসঙ্গিক নিলাম এক্সচেঞ্জের সার্ভারে চলে এবং আগ্রহ গোষ্ঠীর বিডের জন্য বিডিং লজিক এবং চূড়ান্ত বিজয়ী বিজ্ঞাপন নির্ধারণের জন্য স্কোরিং লজিক বিডিং এবং নিলাম সার্ভারে চালানো হয়।

সুরক্ষিত দর্শকদের বিজ্ঞাপন স্লটের আকার নির্দেশ করুন

সুরক্ষিত দর্শক বিজ্ঞাপন স্লটের আকার প্রদানের জন্য বিড অনুরোধে নিম্নলিখিত ক্ষেত্রগুলি অন্তর্ভুক্ত রয়েছে:

ওপেনআরটিবি:
- BidRequest.imp.ext.interest_group_auction । width
- BidRequest.imp.ext.interest_group_auction . height
গুগল আরটিবি প্রোটোকল (অবঞ্চিত):
- BidRequest.adslot.interest_group_auction.width
- BidRequest.adslot.interest_group_auction.height

এই ক্ষেত্রগুলি সুরক্ষিত দর্শক নিলামের বিজ্ঞাপন স্লটের আকার পিক্সেলের আকারে নির্দেশ করে।

এই আকারটি প্রাসঙ্গিক অনুরোধের আকার থেকে ভিন্ন হতে পারে, যেমন OpenRTB-এর BidRequest.imp.banner.format.w এবং BidRequest.imp.banner.format.h ক্ষেত্রগুলিতে দেখা যায় অথবা অবচিত Google RTB প্রোটোকলের BidRequest.adslot.width এবং BidRequest.adslot.height ক্ষেত্রগুলিতে দেখা যায়।

প্রাসঙ্গিক অনুরোধটির একাধিক আকার থাকতে পারে। ডিভাইসে নিলামে জেতা বিজ্ঞাপনটি কেবলমাত্র একটি নির্দিষ্ট স্লট আকার পূরণ করবে বলে আশা করা হচ্ছে।

সুরক্ষিত দর্শকদের বিজ্ঞাপন রেন্ডারেবিলিটি নির্দেশ করুন

বর্তমান ইন্টিগ্রেশন পর্যায়ের উপর নির্ভর করে সুরক্ষিত দর্শকদের বিজ্ঞাপনগুলি রেন্ডার হতে পারে বা নাও হতে পারে ( নন-রেন্ডারিং পরীক্ষা দেখুন)। বিড অনুরোধের render_interest_group_ads ক্ষেত্রটি নির্দেশ করে যে বিজয়ী সুরক্ষিত দর্শকদের বিজ্ঞাপনটি রেন্ডার করা হবে কিনা।

ওপেনআরটিবি: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
গুগল আরটিবি প্রোটোকল (অবঞ্চিত): BidRequest.adslot.interest_group_auction.render_interest_group_ads

ব্যবহারকারী শনাক্তকারীদের উপর নির্ভর করা কম করুন

প্রোটেক্টেড অডিয়েন্স API পরীক্ষার ক্ষেত্রে প্রাসঙ্গিক বিড অনুরোধগুলি ব্রাউজার থেকে পাওয়া গেলেও ঐতিহ্যবাহী কুকি-ভিত্তিক শনাক্তকারী, যেমন BidRequest.user.id এবং BidRequest.user.buyerid ক্ষেত্র, অথবা BidRequest.google_user_id এবং BidRequest.hosted_match_data ব্যবহার করতে পারে। বিড অনুরোধগুলিতে এই ধরনের শনাক্তকারীর উপস্থিতি বিদ্যমান গোপনীয়তা নীতির উপর নির্ভর করে। তৃতীয় পক্ষের কুকিজ আর উপলব্ধ না থাকলে দক্ষ কেনার জন্য আরও ভালভাবে প্রস্তুতি নিতে পরীক্ষার সময় লক্ষ্যবস্তু এবং বিডিংয়ের উদ্দেশ্যে কুকি-ভিত্তিক শনাক্তকারীর উপর নির্ভর না করার পরামর্শ দেওয়া হচ্ছে।

Google ছোট আকারের পরীক্ষাও চালাতে পারে যেখানে Protected Audience API পরীক্ষার সুযোগে বিড অনুরোধ থেকে কুকি-ভিত্তিক শনাক্তকারীগুলিকে মুছে ফেলা হয়। এটি তৃতীয় পক্ষের কুকি অবচয় হ্রাসের সম্ভাব্য প্রভাব মূল্যায়ন করার জন্য।

Chrome-সুবিধাপ্রাপ্ত থার্ড-পার্টি কুকি ডিপ্রিকেশন টেস্টিং

২০২৪ সালে থার্ড-পার্টি কুকি ডিপ্রিকেশন (3PCD) এর জন্য প্রস্তুতি নিতে, Chrome এখন Chrome-সুবিধাযুক্ত পরীক্ষার অফার করে।

সাইট এবং বিক্রেতারা 3PCD এর অধীনে তাদের সিস্টেম পরীক্ষা করার জন্য Chrome-সুবিধাযুক্ত পরীক্ষা ব্যবহার করতে পারেন। পরীক্ষায়, Chrome ব্রাউজারগুলিকে একটি 3PCD পরীক্ষা গোষ্ঠীতে বরাদ্দ করা হয়, হয় মোড A অথবা মোড B। প্রতিটি ব্রাউজারকে একটি নির্দিষ্ট 3PCD পরীক্ষা গোষ্ঠীর সাথে সম্পর্কিত একটি সামঞ্জস্যপূর্ণ লেবেল বরাদ্দ করা হয় যা আপনি ইন-ব্রাউজার Chrome API এর মাধ্যমে অ্যাক্সেস করতে পারেন।

RTB বিড অনুরোধে Google Chrome API থেকে অপরিবর্তিত লেবেলটি পাস করে। একটি পৃথক লেবেলের ছোট ট্রাফিক স্লাইসের কারণে, Google সর্বদা গোপনীয়তা-সীমাবদ্ধ প্রসঙ্গে লেবেলটি অন্তর্ভুক্ত করে না।

এখানে সেই ক্ষেত্রগুলি দেওয়া হল যেখানে আপনি লেবেলটি দেখতে পারবেন:

ওপেনআরটিবি: BidRequest.device.ext.cdep
গুগল আরটিবি প্রোটোকল (অবঞ্চিত): BidRequest.device.cookie_deprecation_label

বিড প্রতিক্রিয়া পরিবর্তন

আগ্রহ গোষ্ঠীর নিলামে অংশগ্রহণ নির্দেশ করুন

প্রাসঙ্গিক বিড প্রতিক্রিয়ায় InterestGroupBidding অবজেক্টটি ফেরত দিয়ে ব্রাউজারে নিলামে অংশগ্রহণের আপনার ইচ্ছা স্পষ্টভাবে নির্দেশ করার জন্য আপনি দায়ী:

ওপেনআরটিবি: BidResponse.ext.igbid
গুগল আরটিবি প্রোটোকল (অবঞ্চিত): BidResponse.interest_group_bidding

আপনাকে অবশ্যই একটি প্রাসঙ্গিক বিড প্রতিক্রিয়া প্রদান করতে হবে। প্রতিক্রিয়াতে একটি প্রাসঙ্গিক বিড অন্তর্ভুক্ত করার প্রয়োজন নেই। InterestGroupBidding অবজেক্টে প্রতিটি InterestGroupBuyer এর জন্য origin থাকা উচিত, যা দরদাতার দ্বারা তাদের অ্যাকাউন্টের জন্য কনফিগার করা অরিজিনের সাথে মেলে। যখন Google Publisher ট্যাগ runAdAuction() কল করে তখন origin নিলাম কনফিগারেশনের interestGroupBuyers এ যোগ করা হয়।

ক্রেতার প্রাসঙ্গিক সংকেত প্রচার করুন

আপনি ক্রেতার সিগন্যালগুলিকে প্রাসঙ্গিক বিড প্রতিক্রিয়ায় অন্তর্ভুক্ত করতে পারেন, যা Google perBuyerSignals আর্গুমেন্টের মাধ্যমে তাদের অন-ডিভাইস বিডিং ফাংশনে JSON অবজেক্ট হিসাবে প্রচার করে। প্রোটোকলের উপর নির্ভর করে নিম্নলিখিত ক্ষেত্রগুলির সাথে এটি বিড প্রতিক্রিয়াতে অন্তর্ভুক্ত করা যেতে পারে:

OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
গুগল আরটিবি (অবঞ্চিত): BidResponse.interest_group_bidding.per_buyer_signals

ক্রেতার প্রাসঙ্গিক রেন্ডারিং সংকেত প্রচার করুন

আগ্রহী গোষ্ঠীর সৃজনশীলরা রেন্ডারিংয়ের সময় সীমিত প্রাসঙ্গিক সংকেত ব্যবহার করতে পারে, প্রাসঙ্গিক বিড প্রতিক্রিয়ার মাধ্যমে সেই সংকেতগুলি প্রেরণ করে এবং ম্যাক্রো সম্প্রসারণ ব্যবহার করে রেন্ডার URL অনুরোধে সেগুলি গ্রহণ করে। উদাহরণস্বরূপ, রেন্ডারিং সংকেতগুলি একটি নির্দিষ্ট বিজ্ঞাপন স্লট বা প্রকাশক পৃষ্ঠার প্রেক্ষাপটে কর্মক্ষমতা উন্নত করার জন্য একজন সৃজনশীলের চেহারা এবং অনুভূতি কাস্টমাইজ করতে ব্যবহার করা যেতে পারে।

আপনি প্রাসঙ্গিক বিড প্রতিক্রিয়ায় একটি URL-নিরাপদ স্ট্রিং হিসাবে সিরিয়ালাইজ করা ক্রেতার রেন্ডারিং সিগন্যাল অন্তর্ভুক্ত করতে পারেন, যা Google ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]} ম্যাক্রো তৈরি করে বিজয়ী আগ্রহ গ্রুপ রেন্ডার URL-এ প্রতিস্থাপন করবে।

প্রোটোকলের উপর নির্ভর করে, নিম্নলিখিত ক্ষেত্রগুলির মাধ্যমে বিড প্রতিক্রিয়ায় রেন্ডারিং সংকেত নির্দিষ্ট করা যেতে পারে:

ওপেনআরটিবি: BidResponse.ext.igbid.igbuyer.rsig
গুগল আরটিবি (অবঞ্চিত): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

বিভিন্ন সংকেতকে আলাদা করার জন্য বিড রেসপন্সে বিভিন্ন ম্যাক্রো সাফিক্স সহ সর্বোচ্চ ৩ সেট রেন্ডারিং সিগন্যাল অন্তর্ভুক্ত করা যেতে পারে। উদাহরণস্বরূপ, শুধুমাত্র সৃজনশীলদের জন্য প্রযোজ্য একটি নির্দিষ্ট সিগন্যালের সেটকে তাদের রেন্ডার URL-এ সংশ্লিষ্ট ম্যাক্রোর সাথে মেলাতে একটি সাফিক্স ব্যবহার করা যেতে পারে, ফলে ডেটা ট্রান্সফারের আকার হ্রাস পায়।

যদি সিগন্যালগুলি URL-নিরাপদ না হয়, ম্যাক্রো সাফিক্সগুলি অনন্য না হয়, অথবা 3 টিরও বেশি সিগন্যাল সরবরাহ করা হয়, তাহলে আগ্রহী গোষ্ঠীর ক্রেতাকে সুরক্ষিত দর্শক নিলামে অংশগ্রহণ থেকে প্রত্যাখ্যান করা হবে।

ব্রাউজারে সর্বোচ্চ বিড মূল্য উল্লেখ করুন

সুরক্ষিত দর্শক প্রস্তাবে , বিড গণনা এবং চূড়ান্ত নিলাম স্থানীয়ভাবে ডিভাইসে চালানো হবে বলে আশা করা হচ্ছে। এটি সম্ভাব্য অপব্যবহারের ভেক্টর তৈরি করতে পারে যা চূড়ান্ত নিলাম ফলাফলের অখণ্ডতাকে প্রভাবিত করতে পারে, যেমন বিজয়ী বিড মূল্য।

গুগলের RTB অংশীদারদের জন্য Protected Audience API পরীক্ষার সময় সমর্থিত একটি প্রশমন হিসাবে, আপনি প্রতিটি প্রাসঙ্গিক বিড প্রতিক্রিয়ায় একটি প্রত্যাশিত সর্বাধিক বিড মান নির্দিষ্ট করতে পারেন। প্রত্যাশিত সর্বাধিক বিড হল আপনার বিডিং ফাংশন দ্বারা ফেরত পাঠানোর জন্য প্রত্যাশিত সর্বোচ্চ বিড মূল্য। যদি ইন-ব্রাউজার নিলাম থেকে রিপোর্ট করা বিজয়ী বিড এই পরিমাণের বেশি হয়, তাহলে বিজয়ী বিডকে বিলযোগ্য ইভেন্ট হিসাবে গণনা করা হবে না। এই পদ্ধতি পরিবর্তন সাপেক্ষে।

বিডের প্রতিক্রিয়ায়, আপনি নিম্নলিখিত ক্ষেত্রগুলিতে প্রত্যাশিত সর্বোচ্চ বিড মান নির্দিষ্ট করতে পারেন:

OpenRTB: BidResponse.igbid.igbuyer.maxbid (CPM মুদ্রা এককগুলিতে প্রকাশিত)
গুগল আরটিবি প্রোটোকল (অবঞ্চিত): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (মাইক্রোসিপিএমে প্রকাশিত)

একাধিক অ্যাকাউন্টে অ্যাট্রিবিউট ইম্প্রেশন যোগ করুন

একজন দরদাতাকে নিম্নলিখিত ক্ষেত্রগুলি ব্যবহার করে তাদের আগ্রহের গোষ্ঠীর দরপত্রের ছাপগুলি চিহ্নিত করার জন্য একটি বিলিং আইডি নির্বাচন করতে হবে:

ওপেনআরটিবি: BidResponse.igbid.igbuyer.billing_id
গুগল আরটিবি প্রোটোকল (অবঞ্চিত): BidResponse.interest_group_bidding.interest_group_buyers.billing_id

নির্বাচিত বিলিং আইডিটি অবশ্যই বিড অনুরোধের একটি যোগ্য বিলিং আইডি হতে হবে:

ওপেনআরটিবি: BidRequest.imp.ext.billing_id
গুগল আরটিবি প্রোটোকল (অবঞ্চিত): BidRequest.adslot.matching_ad_data.billing_id

যদি আগ্রহ গোষ্ঠীর বিডিং ইম্প্রেশনের জন্য বিলিং আইডি প্রদান না করা হয়, তাহলে দরদাতা সুরক্ষিত দর্শক নিলামে অংশগ্রহণ করতে পারবেন না।

চাইল্ড অ্যাকাউন্টে সর্বাধিক দুটি বিলিং আইডি থাকতে পারে। ক্রেতা প্রাসঙ্গিক ব্যয়ের জন্য একটি বিলিং আইডি এবং অন্যটি আগ্রহের গ্রুপ ব্যয়ের জন্য ব্যবহার করতে পারেন। আপনি যদি চাইল্ড অ্যাকাউন্টের জন্য দুটি বিলিং আইডি কনফিগার করতে চান তবে আপনার অ্যাকাউন্ট ম্যানেজারের সাথে যোগাযোগ করুন।

প্রতিটি বিলিং আইডির জন্য একটি দৈনিক বাজেট সেট করা সম্ভব। চাইল্ড অ্যাকাউন্টের বিলিং আইডির জন্য দৈনিক বাজেট সেট করতে আপনার অ্যাকাউন্ট ম্যানেজারের সাথে যোগাযোগ করুন।

ব্যয় অ্যাট্রিবিউশন নির্বাচনের জন্য বিড অনুরোধে প্রদর্শিত ইম্প্রেশনের উপর বিড করার যোগ্য উপলব্ধ বাজেট সহ সমস্ত চাইল্ড অ্যাকাউন্টের বিলিং আইডি। একটি আগ্রহ গ্রুপ বিলিং আইডির বাজেট পরিবর্তন করতে আপনার অ্যাকাউন্ট ম্যানেজারের সাথে যোগাযোগ করুন।

ব্রাউজারে নিলামের সময়

ব্রাউজারে বিড তৈরি করুন

ব্রাউজারে বিড তৈরি করতে generateBid() ব্যবহার করুন।

গুগল নিম্নলিখিত প্যারামিটারগুলি প্রদান করে:

auctionSignals : খালি
perBuyerSignals : প্রাসঙ্গিক প্রতিক্রিয়ায় দরদাতার দ্বারা প্রদত্ত একই সংকেতের একটি জাভাস্ক্রিপ্ট অবজেক্ট।

নিম্নলিখিত প্যারামিটারগুলি ফেরত পাঠানো হয়:

ad : গুগল এই ক্ষেত্রটি উপেক্ষা করে।
bid : একটি সংখ্যাসূচক বিড যা নিলামে প্রবেশ করে। অবশ্যই CPM ইউনিটে (মাইক্রো নয়) হতে হবে।
render : নিলামে বিড জেতার ক্ষেত্রে সৃজনশীলতা প্রদর্শনের জন্য রেন্ডার করা URL। Google-কে অবশ্যই এই URLটি পর্যালোচনা এবং অনুমোদন করতে হবে, অন্যথায় এটি নিলাম থেকে ফিল্টার করা হবে।
allowComponentAuction : অবশ্যই true হতে হবে। গুগল বর্তমানে মাল্টি-সেলার নিলামের পরীক্ষা সমর্থন করে।

এখানে একটি উদাহরণ:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

generateBid() ফাংশনের ব্যাখ্যার জন্য Protected Audience spec On-Device Bidding বিভাগটি দেখুন।

বিড মুদ্রা

ব্রাউজারে নিলামের দরগুলি নির্বাচিত বিড মুদ্রার CPM-এর ইউনিটে স্থাপন করা হয়।

বিড মুদ্রা অবশ্যই প্রাসঙ্গিক বিড প্রতিক্রিয়া এবং generateBid এর রিটার্ন মান উভয় ক্ষেত্রেই নির্দেশিত হতে হবে এবং এটি অবশ্যই একটি বৈধ ISO 4217 আলফা কোড হতে হবে, যেমন "USD", "EUR", অথবা "JPY"।

OpenRTB-তে, Google-এর বিড রেসপন্স এক্সটেনশনে InterestGroupBuyer অবজেক্টে নতুন cur ফিল্ডটি ব্যবহার করুন।

এখানে একটি উদাহরণ:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

গুগল আরটিবি প্রোটোকলে, বিড রেসপন্সে InterestGroupBuyer মেসেজে নতুন currency ক্ষেত্রটি ব্যবহার করুন।

এখানে একটি উদাহরণ:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

দরদাতাদের generateBid ফাংশনগুলিকে প্রাসঙ্গিক দরপত্রের প্রতিক্রিয়ায় নির্দেশিত মুদ্রায় দরপত্র ফেরত দিতে হবে। generateBid এর রিটার্ন মানটিতে নতুন bidCurrency সম্পত্তি পূরণ করুন:

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

যদি প্রাসঙ্গিক বিড প্রতিক্রিয়া থেকে পাওয়া মুদ্রা generateBid দ্বারা ফেরত পাঠানো মুদ্রার থেকে আলাদা হয়, অথবা যদি তাদের মধ্যে কোনটি অবৈধ মুদ্রা ফেরত দেয়, তাহলে নিলামের আগে বিডটি ফিল্টার করা হবে।

বিজ্ঞাপনের মান পরীক্ষা

RTB অংশীদারদের জন্য Protected Audience API পরীক্ষার সময়, ব্রাউজারে থাকা ইন্টারেস্ট গ্রুপ বিডের ক্ষেত্রে সৃজনশীল নীতি এবং প্রকাশক নিয়ন্ত্রণ প্রয়োগ আরও সীমাবদ্ধ হতে পারে।

ডিজিটাল সার্ভিসেস অ্যাক্ট সমর্থন

ডিজিটাল সার্ভিসেস অ্যাক্টের ২৬ নম্বর ধারা অনুসারে, প্রকাশকদের ক্রেতাদের বিজ্ঞাপনের মধ্যে স্বচ্ছতা প্রকাশ করতে হতে পারে। যখন "ক্রেতাদের কেবল EEA-তে আমার সাইট বা অ্যাপে DSA স্বচ্ছতা তথ্য সহ বিজ্ঞাপন দেখাতে বলুন" নিয়ন্ত্রণটি একজন প্রকাশক দ্বারা সক্ষম করা হয়, তখন আগ্রহী গোষ্ঠীর ক্রেতারা বিড অনুরোধে (অপ্রচলিত Google RTB প্রোটোকলে যথাক্রমে BidRequest.regs.dsa.required এবং BidRequest.dsa.pubrender ) BidRequest.dsa.dsa_support এবং BidRequest.dsa.publisher_rendering_support ) মানগুলি লক্ষ্য করে কোন সুযোগগুলির জন্য ক্রেতার স্বচ্ছতা প্রদান করতে হবে তা নির্ধারণ করতে পারেন।

যখন কোনও দরদাতা যিনি সুরক্ষিত শ্রোতা API নিলামে অংশগ্রহণ করতে চান, তিনি বিড অনুরোধে এই সংকেত পান যে সুরক্ষিত শ্রোতা API এর মাধ্যমে প্রদত্ত বিজ্ঞাপনের জন্য DSA স্বচ্ছতা প্রদর্শন করতে হবে, তখন তাদের মূল্যায়ন করা উচিত যে তারা প্রয়োজনীয় তথ্য যথাযথভাবে প্রদর্শন করতে পারে কিনা এবং BidResponse.ext.igbid.igbuyer.dsaadrender ( BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render ) অপ্রচলিত Google RTB প্রোটোকলে সেট করে নির্দিষ্ট করা উচিত। অন্যথায়, ক্রেতাকে সুরক্ষিত শ্রোতা API নিলামে অন্তর্ভুক্ত করা হবে না।

ডিজিটাল সার্ভিসেস অ্যাক্ট বিজ্ঞাপন স্বচ্ছতা সম্পর্কে আরও তথ্যের জন্য, সহায়তা কেন্দ্রের নিবন্ধটি দেখুন: ডিজিটাল সার্ভিসেস অ্যাক্ট সমর্থন করা ।

বিড ফিল্টারিং

ডিভাইসে নিলামের সময় Google প্রকাশক নিয়ন্ত্রণ এবং বিজ্ঞাপন নীতি প্রয়োগ করে।

ব্রাউজারে নিলামের পরে

নিলামের ফলাফল ক্রেতাকে জানান: reportWin()

গুগল নিম্নলিখিত যুক্তিগুলি পূরণ করে না:

auctionSignals
sellerSignals

ক্রেতাকে নিলামের ফলাফল জানাতে reportWin() ব্যবহার করুন।

আরও তথ্যের জন্য Protected Audience API ব্যাখ্যাকারীর রেন্ডার এবং বিজ্ঞাপন ইভেন্টের উপর ক্রেতা প্রতিবেদন বিভাগটি দেখুন।

ম্যাক্রো

সুরক্ষিত শ্রোতা API ক্রিয়েটিভের উল্লেখকারী renderUrl এক বা একাধিক স্থানধারক থাকতে পারে, যাদেরকে ম্যাক্রো বলা হয়। আগ্রহ গোষ্ঠী নিলাম শেষ হওয়ার পরে, কিন্তু রেন্ডারিংয়ের আগে, ম্যাক্রোগুলি সংশ্লিষ্ট মান দ্বারা প্রতিস্থাপিত হয়। অন-ডিভাইস নিলামে ব্যবহৃত renderUrl নিম্নলিখিত ম্যাক্রোগুলি অন্তর্ভুক্ত থাকতে পারে:

`${GDPR}`	GDPR প্রযোজ্য না হলে 0 বা GDPR প্রযোজ্য হলে 1 পর্যন্ত প্রসারিত হয়। ডকুমেন্টেশন দেখুন।
`${GDPR_CONSENT_XXXX}`	অনুরোধের সাথে সম্পর্কিত ট্রান্সপারেন্সি ও কনসেন্ট (TC) স্ট্রিং পর্যন্ত প্রসারিত হয়। ট্রান্সপারেন্সি ও কনসেন্ট (TC) স্ট্রিংটি ফাঁকা বা অবৈধ হলে, এই ম্যাক্রোটি প্রসারিত হয় না। এই ম্যাক্রো ব্যবহার করে একটি URL-এ IAB GVL-নিবন্ধিত বিক্রেতার কাছে TC স্ট্রিংটি পাস করুন। `XXXX` এর পরিবর্তে IAB GVL-নিবন্ধিত বিক্রেতার IAB GVL ID লিখুন। যদি TC স্ট্রিংটি ফাঁকা থাকে বা অবৈধ থাকে, তাহলে এই ম্যাক্রোটি প্রসারিত হবে না। আপনার প্রবেশ করানো IAB GVL আইডির সাথে যুক্ত IAB GVL-নিবন্ধিত বিক্রেতার যদি ব্যবহারকারীর সম্মতি না থাকে, তাহলে `${GDPR_CONSENT_XXXX}` ম্যাক্রো সহ ক্রিয়েটিভগুলি ব্লক করা হতে পারে। `${GDPR_CONSENT_XXXX}` ম্যাক্রোটি `renderUrl` মধ্যে শুধুমাত্র একবারই হওয়া উচিত।
`${ADDL_CONSENT}`	অনুরোধের সাথে সম্পর্কিত অতিরিক্ত সম্মতি (AC) স্ট্রিং পর্যন্ত প্রসারিত হয়।
`${AD_WIDTH}, ${AD_HEIGHT)`	এই ম্যাক্রোগুলি বিজ্ঞাপন স্লটের প্রস্থ এবং উচ্চতা সন্নিবেশ করায়।
`${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}`	বিড প্রতিক্রিয়ায় নির্দিষ্ট রেন্ডার-টাইম ক্রেতা সংকেত ধারণকারী ম্যাক্রো। `buyer.origin.example` প্লেসহোল্ডারটিকে আগ্রহ গ্রুপ ক্রেতার অরিজিন দিয়ে প্রতিস্থাপন করুন, যা বিড প্রতিক্রিয়ায় `interest_group_buyers.origin` এর সাথে সঙ্গতিপূর্ণ হওয়া উচিত। আপনি তিনটি পর্যন্ত ভিন্ন রেন্ডারিং সিগন্যাল মান প্রদানের জন্য একটি `_OPTIONAL_SUFFIX` অন্তর্ভুক্ত করতে পারেন।

ছাপ গণনা

RTB পার্টনারদের সাথে Protected Audience API পরীক্ষার সময়, ব্রাউজার যখন তার reportResult() ফাংশন কল করে এবং পরবর্তীতে sendReportTo() এ কল করে Google এর রিপোর্টিং URL আনে, তখন Google ইম্প্রেশন গণনা করবে।

যেহেতু প্রোটেক্টেড অডিয়েন্স ইন-ব্রাউজার নিলামে ইম্প্রেশন গণনার জন্য Google দ্বারা ব্যবহৃত ইভেন্টটি তার RTB ক্রেতা অংশীদারদের ইম্প্রেশন গণনার জন্য ব্যবহৃত ইভেন্ট থেকে আলাদা হতে পারে, তাই ইম্প্রেশন গণনা ভিন্ন হতে পারে।

প্রোটেক্টেড অডিয়েন্স এপিআই পরীক্ষা করার জন্য গুগলের একটি লক্ষ্য হল এই অসঙ্গতিগুলি সনাক্ত করা এবং হ্রাস করা।

বিলযোগ্য ইম্প্রেশনের অ্যাট্রিবিউশন

ব্রাউজারে সুরক্ষিত শ্রোতা নিলাম থেকে একজন দরদাতার সমস্ত ব্যয় দরদাতার জন্য কনফিগার করা আগ্রহ গোষ্ঠীর মালিকের উৎস থেকে ম্যাপিংয়ের উপর ভিত্তি করে একটি একক দরদাতা অ্যাকাউন্টে জমা করা হয়। দরদাতার বিভিন্ন চাইল্ড সিট অ্যাকাউন্টে ব্যয় জমা করা সমর্থিত নয়।

দৈনিক বাজেটের সর্বোচ্চ সীমা

সুরক্ষিত শ্রোতা API পরীক্ষার সময়, প্রতিটি অ্যাকাউন্টের একটি অ্যাকাউন্ট-স্তরের সুরক্ষিত শ্রোতাদের দৈনিক বাজেটের সীমা থাকে। দৈনিক বাজেটের সীমা ব্রাউজারে নিলাম পরিবেশে ঝুঁকি সীমিত করে। দৈনিক বাজেটের সীমা পৌঁছে গেলে, অ্যাকাউন্টটি আর সুরক্ষিত শ্রোতাদের জন্য উপযুক্ত বিড অনুরোধ গ্রহণ করে না।

সুরক্ষিত শ্রোতাদের সীমায় পৌঁছানোর পরেও অ্যাকাউন্টটি সার্ভার-সাইড প্রাসঙ্গিক নিলামে অংশগ্রহণ চালিয়ে যেতে পারে। উদাহরণস্বরূপ, সুরক্ষিত শ্রোতাদের সীমায় পৌঁছানো একটি দরদাতা অ্যাকাউন্ট auction_environment = SERVER_SIDE_AUCTION (OpenRTB JSON: 0 ) সহ একটি দর অনুরোধ পেতে পারে, এমনকি যদি বিড অনুরোধটি সুরক্ষিত শ্রোতাদের নিলামের জন্য যোগ্য হয়।

রিয়েল-টাইম প্রতিক্রিয়া এবং জেতার জন্য সর্বনিম্ন দর

রিয়েল-টাইম প্রতিক্রিয়া পাওয়ার জন্য নির্বাচিত দরদাতারা অন-ডিভাইস সুরক্ষিত দর্শক নিলামে অন্তর্ভুক্ত করার জন্য অনুরোধ করা আগ্রহী গোষ্ঠীর ক্রেতাদের প্রতিক্রিয়া পাবেন। দরদাতা বিড প্রতিক্রিয়ায় নির্দিষ্ট করে এমন প্রতিটি আগ্রহী গোষ্ঠীর ক্রেতা একটি প্রতিক্রিয়া বস্তু পাবেন, সুরক্ষিত দর্শক নিলামে আগ্রহী গোষ্ঠীর ক্রেতা কতগুলি বিড রাখুক না কেন। আগ্রহী গোষ্ঠীর ক্রেতা প্রতিক্রিয়া বস্তুতে নিম্নলিখিত তথ্য উপলব্ধ থাকবে:

প্রতিক্রিয়া বস্তুর প্রতিক্রিয়ার ধরণ হবে INTEREST_GROUP_BUYER_FEEDBACK ।
স্বার্থ গোষ্ঠীর ক্রেতার উৎপত্তি।
সামগ্রিক নিলামে জয়লাভের জন্য আগ্রহী গোষ্ঠীর ক্রেতার জন্য ন্যূনতম দর।
সামগ্রিক নিলামের সার্ভার সাইড কম্পোনেন্ট থেকে সর্বোচ্চ র‍্যাঙ্কযুক্ত বিডকে হারানোর জন্য আগ্রহী গোষ্ঠীর ক্রেতার জন্য ন্যূনতম বিড জেতার সম্ভাবনা।
আগ্রহী গ্রুপ ক্রেতার স্ট্যাটাস কোড। সম্ভাব্য স্ট্যাটাস কোডগুলি interest-group-buyer-status-codes.txt ফাইলে সংজ্ঞায়িত করা হয়েছে।

নির্দিষ্ট ক্ষেত্রের নামগুলির জন্য অনুমোদিত ক্রেতা RTB এবং OpenRTB এক্সটেনশনের প্রোটোকল ডকুমেন্টেশন দেখুন।

বিড প্রতিক্রিয়া বিজ্ঞপ্তি

Chrome Protected Audience API-এর জন্য একটি অস্থায়ী ডিবাগিং API প্রদান করে যা Ad Manager-কে Protected Audience বিডের উপর প্রতিক্রিয়া সহ রিয়েল-টাইম সার্ভার-টু-সার্ভার ডিবাগ বিজ্ঞপ্তি পাঠাতে দেয়। এই বিজ্ঞপ্তিতে Protected Audience ইন-ব্রাউজার নিলামে বিডগুলি কেন ফিল্টার করা হয়েছে তার কারণগুলি এবং নীচে বর্ণিত বিড সম্পর্কে অন্যান্য তথ্য অন্তর্ভুক্ত থাকবে।

দরদাতারা তাদের অ্যাকাউন্ট ম্যানেজারের সাথে যোগাযোগ করে একটি স্ট্যাটিক URL কনফিগার করতে পারেন যা সুরক্ষিত দর্শক ডিবাগিং বিড প্রতিক্রিয়া বিজ্ঞপ্তি প্রদানের জন্য ব্যবহার করা হবে। সুরক্ষিত দর্শক নিলাম সম্পন্ন হওয়ার পরে নির্বাচিত ম্যাক্রোগুলি প্রতিস্থাপন করে এই স্ট্যাটিক URLটি Google সার্ভার থেকে আনা হবে। নিম্নলিখিত ম্যাক্রোগুলি সমর্থিত:

%%GOOGLE_QUERY_ID%% : এই ম্যাক্রোটি সুরক্ষিত শ্রোতা-সক্ষম প্রাসঙ্গিক বিড অনুরোধে প্রেরিত Google Query ID দ্বারা প্রতিস্থাপিত হয়। OpenRTB প্রোটোকলে এটি BidRequest.ext.google_query_id দিয়ে নির্দিষ্ট করা হয়, যেখানে অবচিত Google RTB প্রোটোকল BidRequest.google_query_id ব্যবহার করে।
%%INTEREST_GROUP_OWNER%% : স্বার্থ গোষ্ঠীর মালিকের উৎপত্তি।
%%BID_CPM%% : CPM-এ বিড মূল্য যা ক্রেতা দ্বারা generateBid() ফাংশনে নির্দিষ্ট করা হয়েছিল।
%%RENDER_URL%% : সৃজনশীলের রেন্ডার URL।
%%STATUS%% : scoreAd() এর মধ্যে যদি বিডটি প্রত্যাখ্যাত হয় তবে একটি স্ট্যাটাস কোড। মানগুলি হল সৃজনশীল স্ট্যাটাস কোড ।

এখানে একটি নমুনা স্ট্যাটিক URL দেওয়া হল যা একজন দরদাতা তাদের অ্যাকাউন্ট ম্যানেজারকে দিতে পারেন:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

বিড ফিডব্যাক নোটিফিকেশন হল একটি অস্থায়ী বৈশিষ্ট্য যা Chrome এর অস্থায়ী ForDebuggingOnly API এর উপর নির্ভরশীল।

পণ্য-স্তরের টার্টলেডোভ

প্রোটেক্টেড অডিয়েন্স API পরীক্ষার সময় Google RTB অংশীদারদের জন্য একাধিক টুকরো বা পণ্য-স্তরের TURTLEDOVE (PLTD) সমন্বিত বিজ্ঞাপন সমর্থিত। আপনি যদি PLTD পরীক্ষা করার পরিকল্পনা করেন তবে ইন্টিগ্রেশনের সময় আপনার অ্যাকাউন্ট ম্যানেজারকে জানান, কারণ অতিরিক্ত সংস্থান এবং কনফিগারেশন প্রয়োজন।

অনবোর্ডিং

আপনি কীভাবে সুরক্ষিত শ্রোতা API পরীক্ষা করতে পারেন তা এখানে দেওয়া হল:

ধাপ

সুরক্ষিত শ্রোতা API পরীক্ষায় যোগদানের জন্য অনুরোধ ফর্মটি পূরণ করুন।
অনুরোধ ফর্ম জমা দেওয়ার পরে, আপনার অ্যাকাউন্ট ম্যানেজারের সাথে যোগাযোগ করুন অথবা অনুমোদিত ক্রেতা সহায়তা কেন্দ্র ব্যবহার করে টিকিট ফাইল করুন।
অ্যাকাউন্টটি কনফিগার হয়ে গেলে, Google এবং অংশীদার উভয়ই পরীক্ষামূলক পর্যায়ের ধাপগুলির মাধ্যমে ইন্টিগ্রেশন যাচাই করতে পারবে।

সৃজনশীল পর্যালোচনা

Protected Audience API নিলামে পণ্য-স্তরের বিজ্ঞাপন ( একাধিক অংশের সমন্বয়ে গঠিত বিজ্ঞাপন ) দিয়ে বিড করার জন্য, এই প্রয়োজনীয়তাগুলি অনুসরণ করুন:

সৃজনশীল পর্যালোচনার সময় শীর্ষ-স্তরের renderUrls আলাদা করার জন্য, কম্পোনেন্ট বিজ্ঞাপনের কন্টেইনারের (যাকে শীর্ষ-স্তরের renderUrl ও বলা হয়) renderUrl এ &pltd=True কোয়েরি প্যারামিটার অন্তর্ভুক্ত করুন।
যখন Google দ্বারা সৃজনশীল পর্যালোচনার জন্য উপাদান বিজ্ঞাপনের কন্টেইনার আনা হয় তখন একটি প্রতিনিধিত্বমূলক সৃজনশীল রেন্ডার করুন। কখন একটি প্রতিনিধিত্বমূলক বিজ্ঞাপন রেন্ডারিং ফেরত দেওয়া উচিত তা বোঝার জন্য, আপনি Google সৃজনশীল পর্যালোচনা সিস্টেম দ্বারা সেট করা validation=True ক্যোয়ারী প্যারামিটারটি উল্লেখ করতে পারেন।

ইন্টিগ্রেশন চেকলিস্ট

একটি বিড রিকোয়েস্ট এন্ডপয়েন্ট সেট আপ করুন যা প্রাসঙ্গিক বিড রেসপন্সে প্রোটেক্টেড অডিয়েন্স API সম্পর্কিত ক্ষেত্রগুলি পূরণ করবে—যেমন, interest_group_bidding ।
ব্যবহারকারীর ব্রাউজারকে আগ্রহের গোষ্ঠীতে যোগদানের জন্য বিজ্ঞাপনদাতার পৃষ্ঠাগুলিতে ট্যাগিং প্রয়োগ করুন।
generateBid() এবং reportWin() প্রয়োগ করুন।
আগ্রহের গোষ্ঠীর মালিকের উৎস নির্বাচন করুন এবং তাদের অনুমোদিত ক্রেতা অ্যাকাউন্টে যোগ করুন।
- ইন্টারেস্ট গ্রুপের মালিকের অরিজিনগুলি সেই অরিজিনের সাথে মিলতে হবে যেখানে generateBid() ফাংশনগুলি হোস্ট করা আছে।
- এই ধাপটি সম্পূর্ণ করতে অ্যাকাউন্ট ম্যানেজারের সাথে যোগাযোগ করুন অথবা অনুমোদিত ক্রেতা সহায়তা কেন্দ্র ব্যবহার করে টিকিট ফাইল করুন।
সুরক্ষিত শ্রোতা API পরীক্ষার সাথে প্রাসঙ্গিক ইনভেন্টরির জন্য প্রিটার্গেটিং সেট আপ করুন।
ক্রিয়েটিভস API এর মাধ্যমে পর্যালোচনা এবং অনুমোদনের জন্য ক্রিয়েটিভস জমা দিন।
(ঐচ্ছিক) বিশ্বস্ত বিডিং সিগন্যালের শেষ বিন্দু সেট আপ করুন।
(ঐচ্ছিক) একটি পরীক্ষামূলক বিজ্ঞাপনদাতা পৃষ্ঠা সেট আপ করুন যা Google ইঞ্জিনিয়ারদের আপনার আগ্রহ গোষ্ঠীর ক্রেতার উৎসের মালিকানাধীন আগ্রহ গোষ্ঠীতে তাদের ব্রাউজার যুক্ত করতে দেয়। এটি আমাদের সুরক্ষিত দর্শক নিলাম ম্যানুয়ালি ট্রিগার করতে দেয়।
(ঐচ্ছিক) সুরক্ষিত দর্শক নিলামে অন্তর্ভুক্ত করার জন্য অনুরোধ করা আগ্রহী গোষ্ঠীর ক্রেতাদের প্রতিক্রিয়া পেতে আপনার অ্যাকাউন্টে রিয়েল-টাইম প্রতিক্রিয়া সক্ষম করুন।
(ঐচ্ছিক) আপনার অ্যাকাউন্ট ম্যানেজারের সাথে যোগাযোগ করে একটি স্ট্যাটিক URL কনফিগার করুন যাতে সার্ভার-টু-সার্ভার বিজ্ঞপ্তি পাওয়া যায় যা অপ্রত্যাশিত সমস্যাগুলি ডিবাগ করতে সাহায্য করার জন্য একটি অন-ডিভাইস প্রোটেক্টেড অডিয়েন্স নিলাম থেকে বিডের স্থিতির জন্য প্রোটেক্টেড অডিয়েন্স বিড প্রতিক্রিয়া প্রদান করে। বিস্তারিত জানার জন্য বিড প্রতিক্রিয়া বিজ্ঞপ্তি দেখুন।

পরীক্ষার পর্যায়

ধাপ ১: ম্যানুয়াল পরীক্ষা

সুরক্ষিত দর্শক নিলাম কীভাবে ম্যানুয়ালি শুরু করবেন, বিজ্ঞাপনটি রেন্ডার করা যাবে তা নিশ্চিত করবেন এবং ছাপ রেকর্ড করবেন তা এখানে দেওয়া হল:

Chrome 101 বা তার পরবর্তী সংস্করণ ব্যবহার করুন।
chrome://flags/#privacy-sandbox-ads-apis এবং chrome://flags/#enable-fenced-frames ব্যবহার করে Privacy Sandbox API এবং Fenced Frame সক্ষম করুন। Test the Privacy Sandbox এ আরও দেখুন।
রিয়েল-টাইম বিডিং API ব্যবহার করে অনুমোদনের জন্য একটি সৃজনশীল জমা দিন।
দরদাতার মালিকানাধীন স্বার্থ গোষ্ঠীতে একটি ব্রাউজার যোগ করতে দরদাতার দ্বারা প্রদত্ত বিজ্ঞাপনদাতার পৃষ্ঠাটি ব্যবহার করুন।
সুরক্ষিত দর্শক নিলাম শুরু করতে নিম্নলিখিত Google-এর সরবরাহিত পরীক্ষামূলক প্রকাশক পৃষ্ঠাটি ব্যবহার করুন:
https://fledge-testing.uc.r.appspot.com/?nid=allow_all
ইন-ব্রাউজার ইন্টারেস্ট গ্রুপকে নিলামে জেতার জন্য যথেষ্ট বেশি বিড করতে হবে, কারণ এটি প্রচলিত সার্ভার-সাইড বিডের বিরুদ্ধে প্রতিযোগিতা করতে পারে। গুগল প্রতিটি অংশীদারের জন্য একটি ডেডিকেটেড টেস্ট পাবলিশার পৃষ্ঠাও প্রদান করে, যেখানে শুধুমাত্র প্রদত্ত অংশীদার নিলামে অংশগ্রহণ করতে পারে। একটি অংশীদার নির্দিষ্ট পৃষ্ঠায় নির্ভরযোগ্যভাবে ইন-ব্রাউজার নিলাম জেতা সহজ হতে পারে।
নিম্নলিখিতগুলি যাচাই করুন:
1. প্রত্যাশিত বিজয়ী বিজ্ঞাপনটি রেন্ডার করা হয়েছে।
2. নিলামের ফলাফল সার্ভার-সাইড পাঠানো হয়—অর্থাৎ একজন বিজয়ী দরদাতা reportWin() থেকে একটি পিং ব্যাক পান।
3. The test publisher page console logs a debug message for each bid with the following information:
  - renderUrl : The render URL of the bid.
  - interestGroupOwner : The interest group owner of the bid.
  - accepted : This field is true if the bid was accepted and false if the bid was rejected by scoreAd() .
  - externalBidStatus : A status code if the bid was rejected within scoreAd() . Values are creative status codes .

Stage 2: (Optional) Non-rendering experiment

After Google and the partner have manually verified that the partner can participate in the Protected Audience auction, Google enables the partner for the next stage of testing.

Google allocates a small amount of live traffic to run Protected Audience auctions. Then, Google and the partner no longer need to manually trigger a Protected Audience auction. The result of the Protected Audience auction isn't rendered. This allows us to test the integration at scale.

Reach out to your account manager or file a ticket through the Authorized Buyer Help Center when you're ready. Google will enable the account for this stage.

Stage 3: Rendering Experiment

Once Google and the partner have verified Protected Audience auctions at scale without rendering, Google can enable the partner to render the Protected Audience winning ad. Google has a small amount of traffic where Protected Audience auctions are eligible to run, and winning interest group ads are rendered. Participating bidders' in-browser bids compete with the traditional bids.

Reach out to your account manager or file a ticket through the Authorized Buyer Help Center when you're ready. Google will enable the account for this stage.

অতিরিক্ত বৈশিষ্ট্য

The following features are extensions of the core protocol.

সমান্তরালকরণ

Parallelization is an optimization that decreases end-to-end auction latency by initiating the contextual ad request in parallel with the requests to the buyer trusted servers specified in trustedBiddingSignalsUrl .

Parallelization reduces latency but affects interest group buyer eligibility and support for coordinated experiments . Parallelization applies to all bidders who participate in the on-device interest group auction. Bidders don't need to take action to participate in parallel auctions but should familiarize themselves with how parallelization may affect their eligibility in on-device auctions. Experiment group IDs for coordinated experiments are not yet supported within parallel auctions.

Serving flow summary

Here's a summary of the parallel auction flow: Flow diagram

On-device interest group buyer eligibility

For parallel auctions, navigator.runAdAuction 's call happens before the contextual ad response is returned. In order to initiate buyer trusted server calls, navigator.runAdAuction requires that the interestGroupBuyers parameter must be passed as a value, while the remaining auction parameters accept Javascript Promises that can be resolved after the contextual ad response. Since interestGroupBuyers is passed before the contextual ad response, the contextual ad response (including bid responses) cannot be used to choose which buyers participate in the parallelized auction for the given request. Instead Google's publisher tag caches, in the user's browser, the interestGroupBuyers parameter from previous navigator.runAdAuction executions on the same domain.

Parallelization has several important considerations:

Auction signals that aren't needed for buyer trusted server requests, such as perBuyerSignals , can continue to be specified in RTB bid responses in the same way as for non-parallelized auctions. Once the Promises for these signals are resolved, the remaining steps of the on-device auction will complete in the same manner as for the non-parallel auction flow.
Since parallelization relies on caching the list of interest group buyers, Google does not always run a parallel auction, as the parallelization cache may be empty or expired. If the cache is empty or expired, Google runs a standard non-parallel Protected Audience API auction and uses buyer intent to participate in the non-parallel auction to build the interest group buyer cache.
If at least one buyer for any bidder is cached for the current publisher domain, then Google will run a parallel auction, which will be indicated on the bid request:
- Google RTB Protocol: BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized
Each registered interest group buyer origin for a given bidder that was included in the parallel auction will have a corresponding ParallelAuctionBuyer entry:
- Google RTB Protocol: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer
If a parallel auction is run, but a specific buyer origin is not present in the cache, then that given buyer cannot be added to the current on-device auction. This is indicated by a request with parallelized=True that lacks a ParallelAuctionBuyer entry for a given interest group buyer origin. However, bidders that indicate interest by including valid and eligible InterestGroupBuyer (s) on their bid response will have the corresponding interest group buyer origins added to the cache, and those origins will be eligible for future parallelized requests from the same browser and domain. Intent to participate in interest group auctions can be indicated in the following fields:
- Google RTB Protocol: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB: BidResponse.ext.igbid.igbuyer
Cached buyer origins (which are included in the parallel auction's interestGroupBuyers parameter) for which a bidder doesn't indicate intent to participate on their bid response may receive a buyer trusted server call but won't participate in the parallel auction.