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

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

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

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

যেখানে B&A পরিষেবাগুলি প্রযোজ্য

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

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

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

ডেটা এনক্রিপশন

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

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

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

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

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

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

ক্লাউড ডিপ্লয়মেন্ট

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

নিলাম পরিচালনা করুন

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

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

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

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

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

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

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

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

আকার বিবেচনা

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

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

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

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

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

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

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

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

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

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