বিডিং এবং নিলাম পরিষেবা

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

বিডিং এবং নিলাম পরিষেবা (B&A) প্রস্তাবটি ব্যবহারকারীর ডিভাইসে স্থানীয়ভাবে চালানোর পরিবর্তে একটি বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্টে (TEE) ক্লাউড সার্ভারে সুরক্ষিত দর্শক গণনা করার অনুমতি দেওয়ার একটি উপায়ের রূপরেখা দেয়৷ B&A প্রস্তাবের লক্ষ্য প্রাসঙ্গিক এবং পুনঃবিপণন বিজ্ঞাপনের চাহিদা বিবেচনা করার জন্য একটি ঐক্যবদ্ধ প্রবাহকে সমর্থন করা। সার্ভারে গণনা সরানো একটি ডিভাইসের জন্য কম্পিউটেশনাল চক্র এবং নেটওয়ার্ক ব্যান্ডউইথ মুক্ত করে সুরক্ষিত শ্রোতা নিলামকে অপ্টিমাইজ করতে সাহায্য করতে পারে।

Google B&A এর উপাদানগুলি সরবরাহ করবে এবং সেগুলিকে ওপেন সোর্স হিসাবে উপলব্ধ করা হবে৷ আগ্রহী বিজ্ঞাপন প্রযুক্তি সমর্থিত পাবলিক ক্লাউড প্রদানকারীদের সাথে তাদের নিজস্ব উদাহরণ হোস্ট করতে পারে। আপনি GitHub- এ B&A প্রস্তাব সম্পর্কে আরও পড়তে পারেন। মনে রাখবেন যে সেই নথিতে উপস্থাপিত তারিখগুলি Chrome এর বাস্তবায়নকে প্রতিফলিত করে এবং আমরা ভবিষ্যতে Android এর সাথে একীকরণ সম্পর্কে আরও তথ্য প্রকাশ করব৷ এই নথিটি B&A-এর ভূমিকা হিসাবে কাজ করে এবং নতুন APIs Android প্রদান করবে B&A-এর সাথে ইন্টারঅ্যাক্ট করার জন্য। আমরা ভবিষ্যতের আপডেটগুলিতে এই নতুন APIগুলি কীভাবে ব্যবহার করবেন সে সম্পর্কে আরও প্রযুক্তিগত তথ্য পোস্ট করব৷

যেখানে B&A পরিষেবাগুলি উপযুক্ত

B&A Google দ্বারা প্রদত্ত ওপেন সোর্স বাইনারি চালানো বিজ্ঞাপন প্রযুক্তির মালিকানাধীন বিশ্বস্ত সার্ভারের মধ্যে একটি নিলাম চালানোর জন্য একটি অতিরিক্ত বিকল্প প্রদান করে। ব্যবহারকারীর ডেটা এখনও ডিভাইসে থাকে এবং Google সেই ডেটা নিরাপদে TEE-তে সরানোর জন্য API প্রদান করবে। নীচে আমাদের এনক্রিপশন কৌশল সম্পর্কে আরও।

এর মানে হল যে নিলাম প্রক্রিয়ার কিছু অংশ ডিভাইসে এবং অন্যগুলি ক্লাউডে ঘটে। DSP-এর দৃষ্টিকোণ থেকে, কাস্টম অডিয়েন্স (পুনঃবিপণন প্রচারাভিযানের জন্য প্রার্থীর বিজ্ঞাপন অন্তর্ভুক্ত) এখনও ডিভাইসে একই কাস্টম অডিয়েন্স ম্যানেজমেন্ট API ব্যবহার করে পরিচালনা করা হয় যখন ডিভাইসে নিলাম চালানো হয় । একটি SSPs দৃষ্টিকোণ থেকে, অনুরোধগুলি এখনও ডিভাইসে ট্রিগার করা হয়, এবং এই নথিটি ব্যবহার করা হবে এমন নতুন APIগুলি বর্ণনা করে৷ সমস্ত পক্ষের জন্য, একটি নিলামের ফলাফলের রিপোর্ট করা এখনও ডিভাইস থেকে শুরু হয়, B&A কল সম্পূর্ণ হওয়ার পরে।

যেখানে বিডিং, স্কোরিং এবং রিপোর্টিং ইউআরএল জেনারেশন লজিক সম্পাদিত হয় তার সাথে প্রধান পার্থক্য আসে। ডিভাইসে বিডিং, নিলাম এবং রিপোর্টিং লজিক চালানোর পরিবর্তে, generateBid() , scoreAd() , reportResult() , এবং reportWin() লজিক টিইইতে কার্যকর করা হয়। একজন ক্রেতার বিডিং লজিক এবং বিক্রেতার স্কোরিং লজিক তাদের নিজস্ব B&A পরিবেশের মধ্যে সম্পাদিত হয়, সুরক্ষিত শ্রোতা নিলাম প্রবাহের মাঝখানে:

সুরক্ষিত শ্রোতা নিলাম প্রবাহ

তথ্য এনক্রিপশন

B&A এর সাথে, সুরক্ষিত দর্শকের তথ্য যেমন কাস্টম অডিয়েন্স এবং বিডের পরিমাণ ডিভাইস থেকে প্রবাহিত হয়, বিক্রেতার বিজ্ঞাপন প্রযুক্তি সার্ভারের মাধ্যমে, ক্রেতা বিজ্ঞাপন প্রযুক্তি সার্ভারে এবং ডিভাইসে ফিরে আসে। এই কারণে, প্ল্যাটফর্মটি সুরক্ষিত শ্রোতা পরিষেবাগুলিতে যাওয়া ডেটা এনক্রিপ্ট করে এবং কেবলমাত্র প্রত্যয়িত পরিষেবাগুলির দ্বারাই ডিক্রিপ্ট করা যায়৷ GitHub এ এনক্রিপশন কৌশল সম্পর্কে আরও পড়ুন।

স্থাপত্য এবং নিলাম প্রবাহ

এই প্রস্তাবে ডিভাইস থেকে B&A-তে ডেটা প্রবাহ সহ GitHub- এ বিশদ কিছু নতুন উপাদানের প্রয়োজনীয়তা অন্তর্ভুক্ত রয়েছে।

একীভূত প্রাসঙ্গিক এবং সুরক্ষিত শ্রোতা নিলাম প্রবাহ, বিডিং এবং নিলাম পরিষেবা সহ।

একটি উচ্চ স্তরে, তথ্য প্রবাহ নিম্নরূপ বর্ণনা করা হয়:

1. ডিভাইসে, বিক্রেতারা getAdSelectionData API ব্যবহার করে সুরক্ষিত দর্শকদের কাছ থেকে তথ্য সংগ্রহ করে।
2. ডিভাইসে থাকা SDK তাদের বিক্রেতা বিজ্ঞাপন পরিষেবায় একটি অনুরোধ পাঠায়। এই অনুরোধে প্রাসঙ্গিক পেলোড এবং এনক্রিপ্ট করা ProtectedAudienceInput অন্তর্ভুক্ত রয়েছে।
3. বিক্রেতা বিজ্ঞাপন পরিষেবাটি ক্রেতাদের রিয়েল টাইম বিডিং (RTB) পরিষেবার কাছে একটি অনুরোধ পাঠায় যা একটি TEE এর বাইরে প্রার্থীর প্রাসঙ্গিক বিজ্ঞাপনগুলি পেতে, এবং তারপর স্কোর করে এবং একটি বিজয়ী প্রাসঙ্গিক বিজ্ঞাপন নির্বাচন করে৷
4. বিক্রেতা বিজ্ঞাপন পরিষেবা একটি TEE তে চলমান তাদের SellerFrontEnd পরিষেবাতে একটি অনুরোধ পাঠায়।
5. SellerFrontEnd পরিষেবা ক্রেতার নির্দিষ্ট ডেটা সহ BuyerFrontEnd পরিষেবাগুলিতে অনুরোধ পাঠায়৷
6. ক্রেতারা তাদের নিজস্ব কী/মান পরিষেবা এবং বিডিং পরিষেবা ব্যবহার করে, যা রিমার্কেটিং-এর জন্য বিবেচিত সমস্ত কাস্টম দর্শকদের জন্য ডিভাইস থেকে উৎসারিত বিজ্ঞাপন প্রার্থীদের জন্য বিড তৈরি করে।
7. SellerFrontEnd পরিষেবা তাদের কী/মান পরিষেবা থেকে পড়ে এবং প্রার্থীর বিজ্ঞাপনগুলিকে স্কোর করে৷ ফলাফল এনক্রিপ্ট করা হয় এবং বিক্রেতা বিজ্ঞাপন পরিষেবাতে ফিরে আসে।
8. বিক্রেতা বিজ্ঞাপন পরিষেবাটি এনক্রিপ্ট করা বিজয়ী ফলাফল এবং ঐচ্ছিকভাবে একটি প্রাসঙ্গিক ফলাফল, ডিভাইসে থাকা SDK-এ ফেরত দেয়।
9. ডিভাইসে, বিক্রেতারা processAdSelectionResult API ব্যবহার করে বিজয়ী বিজ্ঞাপনটি পুনরুদ্ধার করে, যা বিক্রেতা বিজ্ঞাপন পরিষেবা থেকে প্রতিক্রিয়া ডিক্রিপ্ট করে।

প্রতিটি ধাপের একটি বিশদ বিবরণ এবং কীভাবে ডেটা এনক্রিপ্ট করা হয় তা GitHub- এ পাওয়া যায়। এই উপাদানগুলির জন্য কোডটি ওপেন সোর্সের মাধ্যমে উপলব্ধ করা হবে। প্রদত্ত কোড SellerFrontEnd পরিষেবা থেকে BuyerFrontEnd পরিষেবাগুলিতে অনুরোধের ফেডারেশন পরিচালনা করবে।

ক্লাউড স্থাপনা

বিজ্ঞাপন প্রযুক্তিগুলি একটি সমর্থিত পাবলিক ক্লাউড প্ল্যাটফর্মে B&A পরিষেবাগুলি স্থাপন করবে৷ এই স্থাপনাগুলি বিজ্ঞাপন প্রযুক্তি দ্বারা পরিচালিত হবে যারা একটি প্রাপ্যতা পরিষেবা স্তরের উদ্দেশ্য নির্ধারণের জন্য দায়ী থাকবে৷

একটি নিলাম চালান

B&A নিলাম চালানোর প্রথম ধাপ হল অন-ডিভাইস কাস্টম দর্শকদের থেকে ডেটা সংগ্রহ করা এবং সার্ভার সাইড নিলামে পাঠানোর জন্য এনক্রিপ্ট করা। এটি করতে, getAdSelectionData API ব্যবহার করুন:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

getAdSelectionData পদ্ধতি B&A উপাদানগুলির জন্য প্রয়োজনীয় ইনপুট তৈরি করে, যেমন BuyerInput এবং ProtectedAudienceInput , এবং ফলাফলটি কলারের কাছে উপলব্ধ করার আগে ডেটা এনক্রিপ্ট করে৷ অ্যাপ জুড়ে ডেটা ফাঁস প্রতিরোধ করতে, এই ডেটাতে ডিভাইসে উপস্থিত সমস্ত ক্রেতার তথ্য রয়েছে৷ গোপনীয়তা বিবেচনা বিভাগে এই সিদ্ধান্ত সম্পর্কে আরও পড়ুন।

এই API একটি AdSelectionData অবজেক্ট প্রদান করে:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

এই AdSelectionData ব্যবহার করে, ডিভাইসে থাকা SDK একটি POST বা PUT অনুরোধে ডেটা অন্তর্ভুক্ত করে তাদের বিক্রেতা বিজ্ঞাপন পরিষেবায় একটি অনুরোধ পাঠাতে পারে:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

ডিভাইসে থাকা SDK এই ডেটা এনকোড করার জন্য দায়ী৷ এটি একটি স্থান দক্ষ সমাধান ব্যবহার করার সুপারিশ করা হয় যেমন বিক্রেতা বিজ্ঞাপন পরিষেবাকে multipart/form-data হিসাবে অনুরোধ পাঠানো।

একবার অনুরোধ শুরু হলে, বিক্রেতা বিজ্ঞাপন পরিষেবাটি অনুরোধটিকে একটি TEE-তে চলমান SellerFrontEnd পরিষেবার কাছে পাঠায়৷ একটি SellerFrontEnd পরিষেবা কনফিগার করার সময়, বিক্রেতারা ডোমেন ঠিকানাগুলির একটি তালিকা প্রদান করবে যা ক্রেতাদের দ্বারা পরিচালিত BuyerFrontEnd পরিষেবাগুলির সাথে মিলে যায় যার সাথে বিক্রেতা অংশীদার হয়৷ অনুরোধগুলি বিক্রেতার প্রদান করা বিভিন্ন BuyerFrontEnd পরিষেবাগুলিতে ফেডারেট করা হবে, যাতে ক্রেতারা তাদের নির্বাচিত বিজ্ঞাপন প্রার্থীদের জন্য বিড তৈরি করতে সক্ষম হবে৷ একটি নির্দিষ্ট ক্রেতার জন্য, B&A শুধুমাত্র ক্রেতার মালিকানাধীন কাস্টম শ্রোতাদের সম্পর্কে তথ্য পাঠাবে যাতে ক্রেতাদের মধ্যে ডেটা ক্রস-লিক না হয়। বিড তৈরি করার পর, প্রার্থীর বিজ্ঞাপনের তালিকা SellerFrontEnd পরিষেবাতে ফিরে আসে যেখানে একজন বিজয়ী নির্বাচিত হয়। অবশেষে, SellerFrontEnd পরিষেবা ডিভাইসে এনক্রিপ্ট করা বিজয়ী বিজ্ঞাপন ফেরত দেয়।

ডিভাইসে বিক্রেতা বিজ্ঞাপন পরিষেবার অনুরোধের প্রতিক্রিয়ার সাথে, প্ল্যাটফর্মটি ফলাফল ডিক্রিপ্ট করার জন্য একটি দ্বিতীয় নতুন API অফার করে এবং একটি AdSelectionOutcome প্রদান করে, একই বস্তু যা আজকে একটি অন ডিভাইস নিলাম থেকে ফেরত দেওয়া হয়।

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

রিপোর্টিং

B&A পরিষেবাগুলিতে রিপোর্টিং URL তৈরি করা হবে। নিলামের জন্য ইম্প্রেশন এবং ইন্টারঅ্যাকশন রিপোর্ট করার জন্য সেই URLগুলিতে পিংগুলি এখনও ডিভাইসে ট্রিগার করা দরকার। অন-ডিভাইস SDK-কে এখনও B&A ফ্লো চলাকালীন তৈরি AdSelectionId ব্যবহার করে reportImpression() এবং reportInteraction() API গুলি ব্যবহার করতে হবে। ইন্টারঅ্যাকশন রিপোর্টিংয়ের জন্য তৈরি করা বীকন এবং সংশ্লিষ্ট URLগুলি এনক্রিপ্ট করা প্রতিক্রিয়াতে থাকে, তাই প্রতিক্রিয়ার ডিক্রিপশনের সময় ইভেন্ট এবং URL ম্যাপিংগুলি ডিভাইসে সংরক্ষণ করা হয়।

গোপনীয়তা বিবেচনা

GitHub-এ ব্রাউজার বিডিং এবং নিলাম API প্রস্তাবটি বর্ণনা করে যে কীভাবে গোপনীয়তা বিবেচনা করা হয়েছে। এই প্রস্তাবটি Chrome-এর নামকরণ ব্যবহার করে, কিন্তু একই নীতিগুলি Android-এর ক্ষেত্রে প্রযোজ্য৷

ট্রানজিটের ডেটা শুধুমাত্র PPAPI এবং বিশ্বস্ত সার্ভারগুলিতে অ্যাক্সেসযোগ্য তা নিশ্চিত করতে adSelectionData এনক্রিপ্ট করা হয়েছে। adSelectionData আকার পরিবর্তনের কারণে ডেটা ফাঁস হওয়ার ঝুঁকি কমাতে, আমরা getAdSelectionData API-এ সমস্ত কলের জন্য একই adSelectionData তৈরি করার পরিকল্পনা করছি। এটি বোঝায় যে ডিভাইসের সমস্ত CustomAudience adSelectionData তৈরি করতে ব্যবহৃত হয়। আমরা জেনারেট করা adSelectionData এ GetAdSelectionData ইনপুট প্যারামিটারের প্রভাব সীমিত করার পরিকল্পনাও করি।

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

আকার বিবেচনা

বিজ্ঞাপন প্রযুক্তির ক্লায়েন্ট SDK বিক্রেতার সার্ভারে করা প্রাসঙ্গিক বিজ্ঞাপনের জন্য একটি কলে adSelectionData এনক্রিপ্ট করা বাইট প্যাকেজ করবে বলে আশা করা হচ্ছে। সর্বোত্তম পারফরম্যান্সের জন্য, কার্যকারিতার সাথে আপস না করে adSelectionData আকার অপ্টিমাইজ করা গুরুত্বপূর্ণ। adSelectionData সাইজ কমাতে পেলোড অপ্টিমাইজেশান ব্যাখ্যাকারীতে উল্লিখিত অপ্টিমাইজেশান চালু করার পরিকল্পনা করছি। এই অপ্টিমাইজেশানগুলি অন্তর্ভুক্ত করবে:

1. CustomAudience এ ad_render_id যোগ করা যাতে বিজ্ঞাপন রেন্ডার URI এবং মেটাডেটা ব্যবহার না করে adSelectionData ব্যবহার করে পাঠানো হয়। বিজ্ঞাপন প্রযুক্তিগুলি adSelectionData এ বিজ্ঞাপন ডেটা না পাঠিয়ে এটিকে আরও অপ্টিমাইজ করতে পারে৷ এই বিকল্পটি ভবিষ্যতের রিলিজে CustomAudience API এ সমর্থিত হবে।
2. নিশ্চিত করুন user_bidding_signals adSelectionData এ পাঠানো হয়নি। পরিবর্তে, বিজ্ঞাপন প্রযুক্তিগুলি তাদের কী/মান সার্ভার থেকে user_bidding_signals আনতে পারে।
3. ক্রেতাদের CustomAudience অগ্রাধিকার দেওয়ার অনুমতি দিন।
4. ক্রেতাকে বিক্রেতার অগ্রাধিকার নির্দিষ্ট করার অনুমতি দিন।
5. পেলোডের আকার হ্রাস করার সময় বিট লিকেজ সীমিত করতে কয়েকটি নির্দিষ্ট বালতিতে adSelectionData তৈরি করুন।

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

বিরোধী অপব্যবহার বিবেচনা

গোপনীয়তা বিবেচনায় উল্লিখিত হিসাবে, ডিভাইসে সমস্ত ক্রেতার ডেটা ব্যবহার করে adSelectionData তৈরি করা হয়।

এটি সম্ভাব্য দূষিত সত্ত্বাগুলির জন্য ইকোসিস্টেমকে উন্মুক্ত করে যা প্রতারণামূলক ক্রেতা ডেটা যোগ করতে পারে যা কার্যক্ষমতা হ্রাস করতে পারে, খরচ বাড়াতে পেলোডগুলিকে ব্লাট করতে পারে ইত্যাদি।

adSelectionData অপব্যবহার মোকাবেলা করার জন্য, আমরা নিম্নলিখিত ব্যবস্থাগুলি প্রবর্তন করব৷

• CustomAudience স্পষ্টভাবে অনুমোদিত বিক্রেতা এবং বিক্রেতার অগ্রাধিকার নির্দিষ্ট করার অনুমতি দিন
• SSPs কে সুস্পষ্টভাবে ক্রেতা, ক্রেতার অগ্রাধিকার, প্রতি-ক্রেতার কোটা উত্পন্ন পেলোডে নির্দিষ্ট করার অনুমতি দিন
• প্রতি কলে সর্বাধিক সংখ্যক ক্রেতা বা ক্রেতা প্রতি সর্বোচ্চ আকার নির্ধারণের জন্য SSP-এর জন্য একটি প্রক্রিয়া প্রদান করুন।

এই ব্যবস্থাগুলি বিজ্ঞাপন প্রযুক্তিগুলিকে অন্য কোন বিজ্ঞাপন প্রযুক্তিগুলির সাথে তারা সহযোগিতা করে তা নির্ধারণ করার অনুমতি দেওয়ার জন্য এবং adSelectionData পেলোডের জন্য তাদের প্রক্রিয়া করার জন্য গ্রহণযোগ্য সীমা সেট করার জন্য ডিজাইন করা হয়েছে৷ আমরা বিক্রেতাকে একটি পৃথক কলে এই ক্রেতা তালিকা এবং অগ্রাধিকার নির্দিষ্ট করার অনুমতি দেওয়ার প্রস্তাব করছি। বারবার কলের মাধ্যমে ব্যবহারকারীর সম্পর্কে অতিরিক্ত ডেটা প্রকাশ এড়াতে এই স্পেসিফিকেশন কিছু সময়ের ব্যবধানে স্থির থাকবে।

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