প্রাসঙ্গিক অ্যাপ ইনস্টল বিজ্ঞাপন সমর্থন করার জন্য সুরক্ষিত অ্যাপ সংকেত

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

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

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

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

ক্রস-পার্টি ব্যবহারকারী শনাক্তকারীর উপর নির্ভরতা দূর করে ব্যবহারকারীর গোপনীয়তা উন্নত করে এমন কার্যকর অ্যাপ ইনস্টল বিজ্ঞাপনগুলিকে সমর্থন করার জন্য নিম্নলিখিত API গুলি প্রস্তাব করা হয়েছে:

1. সুরক্ষিত অ্যাপ সিগন্যাল API : এটি ব্যবহারকারীর সম্ভাব্য আগ্রহের প্রতিনিধিত্ব করে এমন বিজ্ঞাপন প্রযুক্তিগত বৈশিষ্ট্যগুলি সংরক্ষণ এবং তৈরির উপর কেন্দ্রীভূত। বিজ্ঞাপন প্রযুক্তিবিদরা অ্যাপ ইনস্টল, প্রথম খোলা, ব্যবহারকারীর ক্রিয়া (ইন-গেম লেভেলিং, অর্জন), ক্রয় কার্যকলাপ, বা অ্যাপে সময় ইত্যাদির মতো স্ব-সংজ্ঞায়িত প্রতি-অ্যাপ ইভেন্ট সংকেত সংরক্ষণ করে। ডেটা ফাঁস থেকে রক্ষা করার জন্য সংকেতগুলি ডিভাইসে লেখা এবং সংরক্ষণ করা হয় এবং শুধুমাত্র সেই বিজ্ঞাপন প্রযুক্তিগত যুক্তির কাছে উপলব্ধ করা হয় যারা সুরক্ষিত পরিবেশে পরিচালিত সুরক্ষিত নিলামের সময় প্রদত্ত সংকেত সংরক্ষণ করেছিল।
2. বিজ্ঞাপন নির্বাচন API : এটি একটি বিশ্বস্ত কার্যকর পরিবেশ (TEE) তে চলমান একটি সুরক্ষিত নিলাম কনফিগার এবং কার্যকর করার জন্য একটি API প্রদান করে যেখানে বিজ্ঞাপন প্রযুক্তিবিদরা সুরক্ষিত অ্যাপ সিগন্যাল এবং প্রকাশক-প্রদত্ত রিয়েল-টাইম প্রাসঙ্গিক তথ্য উভয় ব্যবহার করে বিজ্ঞাপন প্রার্থীদের পুনরুদ্ধার করে, অনুমান চালায়, বিড গণনা করে এবং "বিজয়ী" বিজ্ঞাপন চয়ন করার জন্য স্কোরিং করে।

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

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

সময়রেখা

সুরক্ষিত অ্যাপ সিগন্যালগুলি কিউরেট করুন

সিগন্যাল হল একটি অ্যাপের বিভিন্ন ব্যবহারকারীর ইন্টারঅ্যাকশনের প্রতিনিধিত্ব যা বিজ্ঞাপন প্রযুক্তি দ্বারা প্রাসঙ্গিক বিজ্ঞাপন পরিবেশনের জন্য কার্যকর বলে নির্ধারিত হয়। একটি অ্যাপ বা ইন্টিগ্রেটেড SDK ব্যবহারকারীর কার্যকলাপের উপর ভিত্তি করে বিজ্ঞাপন প্রযুক্তি দ্বারা সংজ্ঞায়িত সুরক্ষিত অ্যাপ সিগন্যাল সংরক্ষণ বা মুছে ফেলতে পারে, যেমন অ্যাপ খোলা, অর্জন, ক্রয় কার্যকলাপ, বা অ্যাপে সময়। সুরক্ষিত অ্যাপ সিগন্যালগুলি ডিভাইসে নিরাপদে সংরক্ষণ করা হয় এবং ডিভাইস থেকে পাঠানোর আগে এনক্রিপ্ট করা হয় যাতে উপযুক্ত সুরক্ষা এবং গোপনীয়তা নিয়ন্ত্রণ সহ বিশ্বস্ত কার্যকর পরিবেশের মধ্যে চলমান বিডিং এবং নিলাম পরিষেবাগুলি বিজ্ঞাপন বিডিং এবং স্কোরিংয়ের জন্য এটি ডিক্রিপ্ট করতে পারে। কাস্টম অডিয়েন্স API এর মতো, একটি ডিভাইসে সংরক্ষিত সিগন্যালগুলি অ্যাপ বা SDK দ্বারা পড়া বা পরিদর্শন করা যায় না; সিগন্যালের মান পড়ার জন্য কোনও API নেই এবং API গুলি সিগন্যালের উপস্থিতি ফাঁস হওয়া এড়াতে ডিজাইন করা হয়েছে। অ্যাড টেক কাস্টম লজিক তাদের কিউরেটেড সিগন্যালগুলিতে অ্যাক্সেস সুরক্ষিত করেছে যাতে প্রোটেক্টেড নিলামে বিজ্ঞাপন নির্বাচনের ভিত্তি হিসাবে কাজ করে এমন বৈশিষ্ট্যগুলি ইঞ্জিনিয়ার করা যায়।

সুরক্ষিত অ্যাপ সিগন্যাল API

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

এই উদাহরণটি adtech1.com এর সাথে যুক্ত একটি স্কেলার সিগন্যাল এবং একটি টাইম সিরিজ সিগন্যাল প্রদর্শন করে:

• বেস৬৪ মান কী " A1c " এবং মান " c12Z " সহ একটি স্কেলার সিগন্যাল। সিগন্যাল স্টোরটি ১ জুন ২০২৩ তারিখে com.google.android.game_app দ্বারা ট্রিগার করা হয়েছে।
• দুটি ভিন্ন অ্যাপ্লিকেশন দ্বারা তৈরি " dDE " কী সহ সিগন্যালের একটি তালিকা।

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

যদি জেনারেটিং অ্যাপ্লিকেশনটি আনইনস্টল করা হয়, প্রোটেক্টেড অ্যাপ সিগন্যাল API ব্যবহার থেকে ব্লক করা হয়, অথবা ব্যবহারকারী যদি অ্যাপ ডেটা সাফ করে দেয় তবে স্টোরেজ থেকে প্রোটেক্টেড অ্যাপ সিগন্যালগুলি সরিয়ে ফেলা হয়।

সুরক্ষিত অ্যাপ সিগন্যাল API নিম্নলিখিত অংশগুলি নিয়ে গঠিত:

• সিগন্যাল যোগ, আপডেট বা অপসারণের জন্য একটি জাভা এবং জাভাস্ক্রিপ্ট API।
• একটি জাভাস্ক্রিপ্ট API যা একটি বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট ( TEE ) -এ পরিচালিত একটি সুরক্ষিত নিলামের সময় রিয়েল টাইমে আরও বৈশিষ্ট্য প্রকৌশলের জন্য প্রস্তুত করার জন্য স্থায়ী সংকেতগুলি প্রক্রিয়া করে ।

সিগন্যাল যোগ করুন, আপডেট করুন বা সরান

বিজ্ঞাপন প্রযুক্তিবিদরা fetchSignalUpdates() API ব্যবহার করে সিগন্যাল যোগ, আপডেট বা অপসারণ করতে পারেন। এই API Protected Audience কাস্টম audience delegation এর মতো ডেলিগেশান সমর্থন করে।

সিগন্যাল যোগ করার জন্য, যেসব ক্রেতার বিজ্ঞাপন প্রযুক্তি অ্যাপে SDK উপস্থিতি নেই তাদের অন-ডিভাইস উপস্থিতি আছে এমন বিজ্ঞাপন প্রযুক্তিবিদদের সাথে সহযোগিতা করতে হবে, যেমন মোবাইল পরিমাপ অংশীদার (MMP) এবং সাপ্লাই-সাইড প্ল্যাটফর্ম (SSP)। প্রোটেক্টেড অ্যাপ সিগন্যাল API এর লক্ষ্য হল প্রোটেক্টেড অ্যাপ সিগন্যাল ব্যবস্থাপনার জন্য নমনীয় সমাধান প্রদান করে এই বিজ্ঞাপন প্রযুক্তিগুলিকে সমর্থন করা, যাতে ডিভাইস কলাররা ক্রেতাদের পক্ষে প্রোটেক্টেড অ্যাপ সিগন্যাল তৈরি করতে পারে। এই প্রক্রিয়াটিকে ডেলিগেশান বলা হয় এবং fetchSignalUpdates() API ব্যবহার করে। fetchSignalUpdates() একটি URI নেয় এবং সিগন্যাল আপডেটের একটি তালিকা পুনরুদ্ধার করে। উদাহরণস্বরূপ, fetchSignalUpdates() স্থানীয় সিগন্যাল স্টোরেজে প্রয়োগ করার জন্য আপডেটের তালিকা পুনরুদ্ধার করার জন্য প্রদত্ত URI-তে একটি GET অনুরোধ জারি করে। ক্রেতার মালিকানাধীন URL এন্ডপয়েন্ট, কমান্ডের একটি JSON তালিকা দিয়ে প্রতিক্রিয়া জানায়।

সমর্থিত JSON কমান্ডগুলি হল:

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

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

সমস্ত কী এবং মান Base64-এ প্রকাশ করা হয়েছে।

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

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

স্টোরেজ কোটা এবং উচ্ছেদ

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

ডেটা ট্রান্সমিশনের জন্য ডিভাইসে এনকোডিং

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

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

যদি কোনও ক্রেতা সিগন্যাল এনকোডার নিবন্ধন না করে থাকেন, তাহলে সিগন্যাল প্রস্তুত করা হয় না এবং ডিভাইসে থাকা কোনও সিগন্যাল বিডিং এবং নিলাম পরিষেবাগুলিতে পাঠানো হয় না।

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

বিজ্ঞাপন নির্বাচনের কর্মপ্রবাহ

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

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

বিজ্ঞাপন নির্বাচনের কর্মপ্রবাহ নিম্নরূপ:

1. বিক্রেতার SDK প্রোটেক্টেড অ্যাপ সিগন্যালের অন-ডিভাইস এনক্রিপ্টেড পেলোড পাঠায়।
2. বিক্রেতার সার্ভার একটি নিলাম কনফিগারেশন তৈরি করে এবং বিজ্ঞাপন নির্বাচনের কর্মপ্রবাহ শুরু করার জন্য এনক্রিপ্ট করা পেলোড সহ বিক্রেতার বিশ্বস্ত বিডিং এবং নিলাম পরিষেবাতে পাঠায়।
3. বিক্রেতার বিডিং এবং নিলাম পরিষেবা অংশগ্রহণকারী বিশ্বস্ত ক্রেতাদের ফ্রন্টএন্ড সার্ভারগুলিতে পেলোড প্রেরণ করে।
4. ক্রেতার বিডিং পরিষেবা বাই-সাইড বিজ্ঞাপন নির্বাচনের যুক্তি কার্যকর করে
   1. বাই-সাইড বিজ্ঞাপন পুনরুদ্ধার লজিক এক্সিকিউশন ।
   2. বাই-সাইড বিডিং লজিক এক্সিকিউশন ।
5. বিক্রয়-পক্ষের স্কোরিং যুক্তি কার্যকর করা হয় ।
6. বিজ্ঞাপনটি রেন্ডার করা হয় এবং রিপোর্টিং শুরু হয়।

বিজ্ঞাপন নির্বাচনের কর্মপ্রবাহ শুরু করুন

যখন কোনও অ্যাপ্লিকেশন বিজ্ঞাপন দেখানোর জন্য প্রস্তুত থাকে, তখন বিজ্ঞাপন প্রযুক্তি SDK (সাধারণত SSPs) প্রকাশকের কাছ থেকে প্রাসঙ্গিক প্রাসঙ্গিক ডেটা এবং প্রতি-ক্রেতা এনক্রিপ্ট করা পেলোডগুলিকে getAdSelectionData কল ব্যবহার করে সুরক্ষিত নিলামে পাঠানোর অনুরোধে অন্তর্ভুক্ত করার মাধ্যমে বিজ্ঞাপন নির্বাচনের কর্মপ্রবাহ শুরু করে। এটি একই API যা পুনঃবিপণন কর্মপ্রবাহের জন্য ব্যবহৃত হয় এবং Android প্রস্তাবের জন্য বিডিং এবং নিলাম ইন্টিগ্রেশনে বর্ণিত হয়েছে।

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

বিক্রেতা নিম্নলিখিতগুলি নির্ধারণ করে:

• getAdSelectionData থেকে প্রাপ্ত পেলোড, যাতে সুরক্ষিত অ্যাপ সিগন্যাল রয়েছে।

• প্রাসঙ্গিক সংকেতগুলি ব্যবহার করে:

  • auction_config.auction_signals ( নিলাম সম্পর্কে তথ্যের জন্য)

  • auction_config.seller_signals ( বিক্রেতার সিগন্যালের জন্য)

  • auction_config.per_buyer_config["buyer"].buyer_signals ( ক্রেতাদের সংকেতের জন্য)

• buyer_list ফিল্ড ব্যবহার করে নিলামে অন্তর্ভুক্ত ক্রেতাদের তালিকা ।

বাই-সাইড বিজ্ঞাপন নির্বাচনের লজিক এক্সিকিউশন

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

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

1. BuyerFrontEnd পরিষেবাটি একটি বিজ্ঞাপনের অনুরোধ পায়।
2. BuyerFrontEnd পরিষেবা ক্রেতার বিডিং পরিষেবাতে একটি অনুরোধ পাঠায়। ক্রেতার বিডিং পরিষেবা prepareDataForAdRetrieval() নামে একটি UDF চালায়, যা বিজ্ঞাপন পুনরুদ্ধার পরিষেবা থেকে শীর্ষ k প্রার্থীদের পেতে একটি অনুরোধ তৈরি করে। বিডিং পরিষেবা এই অনুরোধটি কনফিগার করা পুনরুদ্ধার সার্ভার এন্ডপয়েন্টে পাঠায়।
3. বিজ্ঞাপন পুনরুদ্ধার পরিষেবা getCandidateAds() UDF চালায়, যা শীর্ষ k প্রার্থী বিজ্ঞাপনগুলির সেটে ফিল্টার করে, যা ক্রেতার বিডিং পরিষেবাতে পাঠানো হয়।
4. ক্রেতার বিডিং পরিষেবা generateBid() UDF চালায়, যা সেরা প্রার্থীকে বেছে নেয়, তার বিড গণনা করে, তারপর এটি BuyerFrontEnd পরিষেবাতে ফেরত দেয়।
5. BuyerFrontEnd পরিষেবা বিক্রেতার কাছে বিজ্ঞাপন এবং বিড ফেরত পাঠায়।

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

এর কিছু অংশ আরও বিস্তারিতভাবে দেখার আগে, এই চিত্রে TEE সম্পর্কে কিছু গুরুত্বপূর্ণ স্থাপত্য নোট রয়েছে।

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

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

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

মডেল ফ্যাক্টরাইজেশন

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

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

এর ফলে নিম্নলিখিত নকশাটি সম্ভব হয়:

1. মডেলটিকে একটি ব্যক্তিগত অংশ (ব্যবহারকারীর ডেটা) এবং এক বা একাধিক অ-ব্যক্তিগত অংশ (প্রসঙ্গিক এবং বিজ্ঞাপনের ডেটা) এ ভাগ করুন।
2. ঐচ্ছিকভাবে, কিছু বা সমস্ত নন-প্রাইভেট টুকরো আর্গুমেন্ট হিসেবে এমন একটি UDF-কে পাঠান যার ভবিষ্যদ্বাণী করা প্রয়োজন। উদাহরণস্বরূপ, প্রাসঙ্গিক এম্বেডিংগুলি per_buyer_signals এ UDF-তে পাঠানো হয়।
3. ঐচ্ছিকভাবে, বিজ্ঞাপন প্রযুক্তিবিদরা নন-প্রাইভেট টুকরোগুলির জন্য মডেল তৈরি করতে পারেন, তারপর সেই মডেলগুলি থেকে বিজ্ঞাপন পুনরুদ্ধার পরিষেবার কী-ভ্যালু স্টোরে এমবেডিংগুলিকে বাস্তবায়িত করতে পারেন। বিজ্ঞাপন পুনরুদ্ধার পরিষেবার UDFগুলি রানটাইমে এই এমবেডিংগুলি আনতে পারে।
4. UDF চলাকালীন ভবিষ্যদ্বাণী করার জন্য, ইনফারেন্স সার্ভিস থেকে প্রাইভেট এম্বেডিংগুলিকে UDF ফাংশন আর্গুমেন্ট থেকে নন-প্রাইভেট এম্বেডিংগুলির সাথে একত্রিত করুন অথবা কী-ভ্যালু স্টোরকে ডট প্রোডাক্টের মতো একটি অপারেশনের সাথে একত্রিত করুন। এটিই চূড়ান্ত ভবিষ্যদ্বাণী।

এটি ব্যাখ্যা করার পর, আমরা প্রতিটি UDF-কে আরও বিশদে দেখতে পারব। আমরা ব্যাখ্যা করব তারা কী করে, কীভাবে তারা একীভূত হয় এবং কীভাবে তারা শীর্ষ k বিজ্ঞাপনগুলি বেছে নেওয়ার জন্য এবং তাদের বিড গণনা করার জন্য প্রয়োজনীয় ভবিষ্যদ্বাণী করতে পারে।

prepareDataForAdRetrieval() UDF

ক্রেতার বিডিং পরিষেবাতে চলমান prepareDataForAdRetrieval() অনুরোধ পেলোড তৈরির জন্য দায়ী যা শীর্ষ k প্রার্থী বিজ্ঞাপনগুলি আনতে বিজ্ঞাপন পুনরুদ্ধার পরিষেবাতে পাঠানো হবে।

prepareDataForAdRetrieval() নিম্নলিখিত তথ্য গ্রহণ করে:

• getAdSelectionData থেকে প্রাপ্ত প্রতি-ক্রেতা পেলোড। এই পেলোডে সুরক্ষিত অ্যাপ সিগন্যাল রয়েছে।
• প্রাসঙ্গিক সংকেতের auction_signals ( নিলাম সম্পর্কে তথ্যের জন্য) এবং buyer_signals ( ক্রেতাদের সংকেত ক্ষেত্রগুলির জন্য)।

prepareDataForAdRetrieval() দুটি কাজ করে:

• বৈশিষ্ট্যকরণ : যদি পুনরুদ্ধার-সময়ের অনুমানের প্রয়োজন হয়, তবে এটি ইনফরমেশন পরিষেবায় কল করার সময় ব্যবহারের জন্য আগত সংকেতগুলিকে বৈশিষ্ট্যগুলিতে রূপান্তরিত করে যাতে পুনরুদ্ধারের জন্য ব্যক্তিগত এম্বেডিং পাওয়া যায়।
• পুনরুদ্ধারের জন্য ব্যক্তিগত এম্বেডিং গণনা করে : যদি পুনরুদ্ধারের পূর্বাভাসের প্রয়োজন হয়, তবে এটি এই বৈশিষ্ট্যগুলি ব্যবহার করে অনুমান পরিষেবার বিরুদ্ধে কল করে এবং পুনরুদ্ধার-সময়ের পূর্বাভাসের জন্য একটি ব্যক্তিগত এম্বেডিং পায়।

prepareDataForAdRetrieval() রিটার্ন করে:

• সুরক্ষিত অ্যাপ সিগন্যাল : বিজ্ঞাপন প্রযুক্তি-সজ্জিত সিগন্যাল পেলোড।
• নিলাম-নির্দিষ্ট সংকেত : প্ল্যাটফর্ম-নির্দিষ্ট বিক্রয়-সাইড সংকেত, এবং SelectAdRequest থেকে auction_signals এবং per_buyer_signals (প্রসঙ্গিক এম্বেডিং সহ) এর মতো প্রাসঙ্গিক তথ্য। এটি Protected Audiences এর অনুরূপ।
• অতিরিক্ত সংকেত : অতিরিক্ত তথ্য যেমন ব্যক্তিগত এম্বেডিং ইনফারেন্স পরিষেবা থেকে পুনরুদ্ধার করা হয়েছে।

এই অনুরোধটি বিজ্ঞাপন পুনরুদ্ধার পরিষেবাতে পাঠানো হয়, যা প্রার্থীদের মিল করে এবং তারপর getCandidateAds() UDF চালায়।

getCandidateAds() UDF

getCandidateAds() বিজ্ঞাপন পুনরুদ্ধার পরিষেবাতে চলে। এটি ক্রেতার বিডিং পরিষেবাতে prepareDataForAdRetrieval() দ্বারা তৈরি অনুরোধ গ্রহণ করে। পরিষেবাটি getCandidateAds() কার্যকর করে যা অনুরোধটিকে সেট কোয়েরি, ডেটা ফেচ এবং কাস্টম ব্যবসায়িক লজিক এবং অন্যান্য কাস্টম পুনরুদ্ধার লজিক কার্যকর করে বিডিংয়ের জন্য শীর্ষ-কে প্রার্থীদের নিয়ে আসে।

getCandidateAds() নিম্নলিখিত তথ্য গ্রহণ করে:

• সুরক্ষিত অ্যাপ সিগন্যাল : বিজ্ঞাপন প্রযুক্তি-সজ্জিত সিগন্যাল পেলোড।
• নিলাম-নির্দিষ্ট সংকেত : প্ল্যাটফর্ম-নির্দিষ্ট বিক্রয়-সাইড সংকেত, এবং SelectAdRequest থেকে auction_signals এবং per_buyer_signals (প্রসঙ্গিক এম্বেডিং সহ) এর মতো প্রাসঙ্গিক তথ্য। এটি Protected Audiences এর অনুরূপ।
• অতিরিক্ত সংকেত : অতিরিক্ত তথ্য যেমন ব্যক্তিগত এম্বেডিং ইনফারেন্স পরিষেবা থেকে পুনরুদ্ধার করা হয়েছে।

getCandidateAds() নিম্নলিখিত কাজ করে:

1. বিজ্ঞাপন প্রার্থীদের একটি প্রাথমিক সেট আনুন : বিজ্ঞাপন প্রার্থীদের ফিল্টার করার জন্য ভাষা, ভূ-প্রকৃতি, বিজ্ঞাপনের ধরণ, বিজ্ঞাপনের আকার বা বাজেটের মতো লক্ষ্যবস্তু মানদণ্ড ব্যবহার করে আনুন।
2. পুনরুদ্ধার এমবেডিং ফেচ : যদি শীর্ষ k নির্বাচনের জন্য পুনরুদ্ধার-সময় পূর্বাভাস দেওয়ার জন্য কী-মান পরিষেবা থেকে এম্বেডিংয়ের প্রয়োজন হয়, তবে সেগুলি অবশ্যই কী-মান পরিষেবা থেকে পুনরুদ্ধার করতে হবে।
3. শীর্ষস্থানীয় প্রার্থী নির্বাচন : কী-ভ্যালু স্টোর থেকে প্রাপ্ত বিজ্ঞাপন মেটাডেটা এবং ক্রেতার বিডিং পরিষেবা থেকে প্রেরিত তথ্যের উপর ভিত্তি করে ফিল্টার করা বিজ্ঞাপন প্রার্থীদের সেটের জন্য একটি হালকা স্কোর গণনা করুন এবং সেই স্কোরের উপর ভিত্তি করে শীর্ষস্থানীয় প্রার্থীদের নির্বাচন করুন। উদাহরণস্বরূপ, বিজ্ঞাপনটি দেওয়া কোনও অ্যাপ ইনস্টল করার সুযোগ হতে পারে স্কোর।
4. বিডিং এম্বেডিং ফেচ : বিডিং-টাইম ভবিষ্যদ্বাণী করার জন্য যদি বিডিং কোডের মাধ্যমে কী-ভ্যালু পরিষেবা থেকে এম্বেডিংয়ের প্রয়োজন হয়, তাহলে সেগুলি কী-ভ্যালু পরিষেবা থেকে পুনরুদ্ধার করা যেতে পারে।

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

• নিলাম-নির্দিষ্ট সংকেত ইনপুট ব্যবহার করে প্রাসঙ্গিক এম্বেডিং পাস করা হয়েছে।
• অতিরিক্ত সিগন্যাল ইনপুট ব্যবহার করে ব্যক্তিগত এম্বেডিং পাস করা হয়েছে।
• যেকোনো অ-ব্যক্তিগত এম্বেডিং বিজ্ঞাপন প্রযুক্তিবিদ তাদের সার্ভার থেকে বিজ্ঞাপন পুনরুদ্ধার পরিষেবার মূল-মূল্য পরিষেবাতে রূপান্তরিত হয়েছে।

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

getCandidateAds() ফেরত দেয়:

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

আমরা বিজ্ঞাপন স্কোর করার জন্য অন্যান্য পদ্ধতিগুলি তদন্ত করছি, যার মধ্যে SelectAdRequest কলের অংশ হিসাবে এটি উপলব্ধ করাও অন্তর্ভুক্ত। এই বিজ্ঞাপনগুলি RTB বিড অনুরোধ ব্যবহার করে পুনরুদ্ধার করা যেতে পারে। মনে রাখবেন যে এই ধরনের ক্ষেত্রে, সুরক্ষিত অ্যাপ সিগন্যাল ছাড়াই বিজ্ঞাপনগুলি পুনরুদ্ধার করতে হবে। আমরা আশা করি যে বিজ্ঞাপন প্রযুক্তিবিদরা তাদের সেরা বিকল্পটি বেছে নেওয়ার আগে ট্রেডঅফগুলি মূল্যায়ন করবেন, যার মধ্যে প্রতিক্রিয়া পেলোডের আকার, লেটেন্সি, খরচ এবং সিগন্যালের প্রাপ্যতা অন্তর্ভুক্ত রয়েছে।

generateBid() ইউডিএফ

একবার আপনি প্রার্থী বিজ্ঞাপনের সেট এবং পুনরুদ্ধারের সময় এম্বেডিংগুলি পুনরুদ্ধার করার পরে, আপনি বিডিংয়ে এগিয়ে যেতে প্রস্তুত, যা ক্রেতার বিডিং পরিষেবাতে চলে। এই পরিষেবাটি ক্রেতার সরবরাহিত generateBid() UDF চালায় যাতে উপরের k থেকে বিড করার জন্য বিজ্ঞাপনটি নির্বাচন করা হয়, তারপর এটির বিড সহ ফেরত পাঠানো হয়।

generateBid() নিম্নলিখিত তথ্য গ্রহণ করে:

• প্রার্থীদের বিজ্ঞাপন : পুনরুদ্ধার বিজ্ঞাপন পুনরুদ্ধার পরিষেবা দ্বারা ফেরত পাঠানো শীর্ষ k বিজ্ঞাপন।
• নিলাম-নির্দিষ্ট সংকেত : প্ল্যাটফর্ম-নির্দিষ্ট বিক্রয়-সাইড সংকেত, এবং SelectAdRequest থেকে auction_signals এবং per_buyer_signals (প্রসঙ্গিক এম্বেডিং সহ) এর মতো প্রাসঙ্গিক তথ্য।
• অতিরিক্ত সংকেত : বিডিংয়ের সময় অতিরিক্ত তথ্য ব্যবহার করতে হবে।

ক্রেতার generateBid() বাস্তবায়ন তিনটি কাজ করে:

• বৈশিষ্ট্যায়ন : অনুমানের সময় ব্যবহারের জন্য সংকেতগুলিকে বৈশিষ্ট্যে রূপান্তরিত করে।
• অনুমান : মেশিন লার্নিং মডেল ব্যবহার করে পূর্বাভাস তৈরি করে ক্লিক-থ্রু এবং রূপান্তর হারের মতো মান গণনা করে।
• বিডিং : প্রার্থীর বিজ্ঞাপনের জন্য বিড গণনা করার জন্য অন্যান্য ইনপুটগুলির সাথে অনুমানিত মানগুলিকে একত্রিত করা।

generateBid() রিটার্ন করে:

• প্রার্থীর বিজ্ঞাপন।
• এর গণনা করা দরের পরিমাণ।

মনে রাখবেন যে অ্যাপ ইনস্টল বিজ্ঞাপনের জন্য ব্যবহৃত generateBid() এবং রিমার্কেটিং বিজ্ঞাপনের জন্য ব্যবহৃত generateBid() ভিন্ন।

নিম্নলিখিত বিভাগগুলিতে বৈশিষ্ট্য, অনুমান এবং বিডিং সম্পর্কে আরও বিশদভাবে বর্ণনা করা হয়েছে।

বৈশিষ্ট্যায়ন

নিলাম সংকেতগুলি generateBid() দ্বারা বৈশিষ্ট্যগুলিতে প্রস্তুত করা যেতে পারে। ক্লিক-থ্রু এবং রূপান্তর হারের মতো বিষয়গুলি পূর্বাভাস দেওয়ার জন্য এই বৈশিষ্ট্যগুলি অনুমানের সময় ব্যবহার করা যেতে পারে। আমরা মডেল প্রশিক্ষণে ব্যবহারের জন্য উইন রিপোর্টে তাদের কিছু প্রেরণের জন্য গোপনীয়তা-সংরক্ষণের প্রক্রিয়াগুলিও অন্বেষণ করছি।

অনুমান

একটি বিড গণনা করার সময় এক বা একাধিক মেশিন লার্নিং মডেলের উপর ভিত্তি করে অনুমান করা সাধারণ। উদাহরণস্বরূপ, কার্যকর eCPM গণনাগুলি প্রায়শই ক্লিক-থ্রু এবং রূপান্তর হার পূর্বাভাস দেওয়ার জন্য মডেল ব্যবহার করে।

ক্লায়েন্টরা তাদের generateBid() বাস্তবায়নের সাথে সাথে বেশ কয়েকটি মেশিন লার্নিং মডেল সরবরাহ করতে পারে। আমরা generateBid() এর মধ্যে একটি JavaScript APIও সরবরাহ করব যাতে ক্লায়েন্টরা রানটাইমে ইনফারেন্স করতে পারে।

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

সমর্থিত মডেল ফর্ম্যাট এবং সর্বাধিক আকারের মতো অনুমান ক্ষমতা সম্পর্কে আরও তথ্য ভবিষ্যতের আপডেটে সরবরাহ করা হবে।

মডেল ফ্যাক্টরাইজেশন বাস্তবায়ন করুন

আগে আমরা মডেল ফ্যাক্টরাইজেশন ব্যাখ্যা করেছি। বিডিংয়ের সময়, নির্দিষ্ট পদ্ধতিটি হল:

1. একক মডেলটিকে একটি ব্যক্তিগত অংশ (ব্যবহারকারীর ডেটা) এবং এক বা একাধিক অ-ব্যক্তিগত অংশ (প্রসঙ্গিক এবং বিজ্ঞাপনের ডেটা) এ ভাগ করুন।
2. generateBid() তে নন-প্রাইভেট পিস পাস করুন। এগুলি হয় per_buyer_signals থেকে আসতে পারে, অথবা বিজ্ঞাপন প্রযুক্তিবিদরা বাহ্যিকভাবে গণনা করা এম্বেডিং থেকে আসতে পারে, পুনরুদ্ধার পরিষেবার কী-ভ্যালু স্টোরে পরিণত হয়, পুনরুদ্ধারের সময় আনয়ন করে এবং অতিরিক্ত সিগন্যালের অংশ হিসাবে ফিরে আসে। এর মধ্যে ব্যক্তিগত এম্বেডিং অন্তর্ভুক্ত নয় কারণ এগুলি গোপনীয়তার সীমানার বাইরে থেকে সোর্স করা যায় না।
3. generateBid() এ:
   1. ব্যক্তিগত ব্যবহারকারীর এম্বেডিং পেতে মডেলগুলির বিরুদ্ধে অনুমান সম্পাদন করুন।
   2. ডট প্রোডাক্টের মতো একটি অপারেশন ব্যবহার করে, per_buyer_signals থেকে প্রাসঙ্গিক এম্বেডিং বা নন-প্রাইভেট বিজ্ঞাপন এবং পুনরুদ্ধার পরিষেবা থেকে প্রাসঙ্গিক এম্বেডিংয়ের সাথে ব্যক্তিগত ব্যবহারকারীর এম্বেডিং একত্রিত করুন। এটিই চূড়ান্ত ভবিষ্যদ্বাণী যা বিড গণনা করতে ব্যবহার করা যেতে পারে।

এই পদ্ধতি ব্যবহার করে, ক্রেতার বিডিং পরিষেবায় যে মডেলগুলি কার্যকর করা খুব বড় বা ধীর হবে তার বিরুদ্ধে বিডিং সময় অনুমান করা সম্ভব।

বিক্রয়-পক্ষের স্কোরিং যুক্তি

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

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

বিজ্ঞাপন নির্বাচন কোড রানটাইম

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

রিপোর্টিং

এই প্রস্তাবনাটি সুরক্ষিত শ্রোতা প্রতিবেদন প্রস্তাবনার মতো একই প্রতিবেদন API ব্যবহার করে (উদাহরণস্বরূপ, reportImpression() , যা প্ল্যাটফর্মটিকে বিক্রেতা এবং ক্রেতার প্রতিবেদন পাঠাতে ট্রিগার করে)।

One common use case for reporting on the buy-side is getting the training data for models used during ad selection. In addition to existing APIs, the platform will provide a specific mechanism for egressing event-level data from the platform to ad tech servers. These egress payloads can include certain user data.

In the long term, we are investigating privacy-preserving solutions to address model training with data used in Protected Auctions without sending event-level user data outside services running on TEEs. We will provide additional details in a later update.

In the short term, we will provide a temporary way to egress noised data from generateBid() . Our initial proposal for this follows, and we will evolve it (including possible backward-incompatible changes) in response to industry feedback.

Technically, the way this works is:

1. Ad techs define a schema for the data they want to transmit.
2. In generateBid() , they build their chosen egress payload.
3. The platform validates the egress payload against the schema and enforces size limits.
4. The platform adds noise to the egress payload.
5. The egress payload is included in the win report in wire format, received on ad tech servers, decoded, and used for model training.

Defining the schema of egress payloads

For the platform to enforce evolving privacy requirements, egress payloads must be structured in a way the platform can understand. Ad techs will define the structure of their egress payloads by providing a schema JSON file. That schema will be processed by the platform, and will be kept confidential by the Bidding and Auction services using the same mechanisms as other ad tech resources like UDFs and models.

We will provide a CDDL file that defines the structure of that JSON. The CDDL file will include a set of supported feature types (for example, features that are booleans, integers, buckets, and so on). Both the CDDL file and the provided schema will be versioned.

For example, an egress payload that consists of a single boolean feature followed by a bucket feature of size two would look something like:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Details on the set of supported feature types are available on GitHub .

Build egress payloads in generateBid()

All Protected App Signals for a given buyer are available to their generateBid() UDF. Once these are featurized, ad techs create their payload in JSON format. This egress payload will be included in the buyer's win report for transmission to ad tech servers.

An alternative to this design is for egress vector calculation to happen in reportWin() instead of generateBid() . There are trade-offs for each approach, and we'll finalize this decision in response to industry feedback.

Validate the egress payload

The platform will validate any egress payload created by the ad tech. Validation verifies that feature values are valid for their types, size constraints are met, and that malicious actors are not attempting to defeat privacy controls by packing additional information into their egress payloads.

If an egress payload is invalid, it will be silently discarded from the inputs sent to the win report. This is because we don't want to provide debugging information to any bad actor attempting to defeat validation.

We will provide a JavaScript API for ad techs to verify the egress payload they create in generateBid() will pass platform validation:

validate(payload, schema)

This JavaScript API is entirely for callers to determine if a particular payload will pass platform validation. Actual validation must be done in the platform to guard against malicious generateBid() UDFs.

Noise the egress payload

The platform will noise egress payloads before including them in the win report. The initial noise threshold will be 1%, and this value may evolve over time. The platform will provide no indication whether or not a particular egress payload has been noised.

The noising method is:

1. The platform loads the schema definition for the egress payload.
2. 1% of egress payloads will be chosen for noising.
3. If an egress payload is not chosen, the entire original value is retained.
4. If an egress payload is chosen, each feature's value will be replaced with a random valid value for that feature type (for example, either 0 or 1 for a boolean feature).

Transmitting, receiving, and decoding the egress payload for model training

The validated, noised egress payload will be included in the arguments to reportWin() , and transmitted to buyer ad tech servers outside the privacy boundary for model training. The egress payload will be in its wire format.

Details on the wire format for all feature types and for the egress payload itself are available on GitHub .

Determine the size of the egress payload

The size of the egress payload in bits balances utility and data minimization. We will work with industry to determine the appropriate size via experimentation. While we are running those experiments, we will temporarily egress data with no bit size limitation. That additional egress data with no bit size limitation will be removed once experiments are complete.

The method for determining size is:

1. Initially, we will support two egress payloads in generateBid() :
   1. egressPayload : the size-limited egress payload we've described so far in this document. Initially, this egress payload's size will be 0 bits (meaning it will always be removed during validation).
   2. temporaryUnlimitedEgressPayload : a temporary size-unlimited egress payload for size experiments. The formatting, creation, and processing of this egress payload uses the same mechanisms as egressPayload .
2. Each of these egress payloads will have its own schema JSON file: egress_payload_schema.json and temporary_egress_payload_schema.json .
3. We provide an experiment protocol and set of metrics for determining model utility at various egress payload sizes (for example, 5, 10, ... bits).
4. Based on experiment results, we determine the egress payload size with the correct utility and privacy trade-offs.
5. We set the size of egressPayload from 0 bits to the new size.
6. After a set migration period, we remove temporaryUnlimitedEgressPayload , leaving only egressPayload with its new size.

We are investigating additional technical guardrails for managing this change (for example, encrypting egressPayload when we increase its size from 0 bits). Those details -- along with timing for the experiment and the removal of temporaryUnlimitedEgressPayload -- will be included in a later update.

Next we'll explain a possible experiment protocol for finalizing the size of egressPayload . Our goal is to work with industry to find a size that balances utility and data minimization. The artifact these experiments will produce is a graph where the x-axis is the size of the training payload in bits, and the y-axis is the percentage of revenue generated by a model at that size compared to a size-unlimited baseline.

We'll assume we're training a pInstall model, and our sources of training data are our logs and the contents of the temporaryUnlimitedegressPayload s we receive when we win auctions. The protocol for ad-techs first involves offline experiments:

1. Determine the architecture of the models they will use with Protected App Signals. For example, they will need to determine whether or not they will use model factorization .
2. Define a metric for measuring model quality. Suggested metrics are AUC loss and log loss.
3. Define the set of features they will use during model training.
4. Using that model architecture, quality metric, and set of training features, run ablation studies to determine the utility contributed per bit for each model they want to use in PAS. The suggested protocol for the ablation study is:
   1. Train the model with all features and measure utility; this is the baseline for comparison.
   2. For each feature used to produce the baseline, train the model with all features except that feature.
   3. Measure resulting utility. Divide the delta by the size of the feature in bits; this is the expected utility per bit for that feature.
5. Determine the training payload sizes of interest for experimentation. We suggest [5, 10, 15, ..., size_of_all_training_features_for_baseline ] bits. Each of these represents a possible size for egressPayload that the experiment will evaluate.
6. For each possible size, select a set of features less than or equal to that size that maximize utility per bit, using the results of the ablation study.
7. Train a model for each possible size and evaluate its utility as a percentage of the utility of the baseline model trained on all features.
8. Plot the results on a graph where the x-axis is the size of the training payload in bits, and the y-axis is the percentage of revenue generated by that model compared to baseline.

Next, ad-techs can repeat steps 5-8 in live traffic experiments, using feature data sent via temporaryUnlimitedEgressPayload . Ad-techs can choose to share the results of their offline and live traffic experiments with Privacy Sandbox to inform the decision about the size of egressPayload .

The timeline for these experiments, as well as the timeline for setting the size of egressPayload to the resulting value, is beyond the scope of this document and will come in a later update.

Data protection measures

We will apply a number of protections to egressed data, including:

1. Both egressPayload and temporaryUnlimitedEgressPayload will be noised.
2. For data minimization and protection temporaryUnlimitedEgressPayload will be available only for the duration of size experiments, where we will determine the correct size for egressPayload .

অনুমতিসমূহ

User control

• The proposal intends to give users visibility to the list of installed apps that have stored at least one Protected App Signal or a custom audience.
• Users can block and remove apps from this list. Block and removal does the following:
  • Clears all Protected App Signals and custom audiences associated with the app.
  • Prevents the apps from storing new Protected App Signals and custom audiences
• Users have the ability to reset the Protected App Signals and Protected Audience API completely. When this happens, any existing Protected App Signals and custom audiences on the device are cleared.
• Users have the ability to opt out completely from the Privacy Sandbox on Android, which includes the Protected App Signals API and Protected Audience API. When this is the case, the Protected Audience and Protected App Signals APIs return a standard exception message: SECURITY_EXCEPTION .

App permissions and control

The proposal intends to provide apps control over its Protected App Signals:

• An app can manage its associations with Protected App Signals.
• An app can grant third party ad tech platforms permissions to manage Protected App signals on its behalf.

Ad tech platform control

This proposal outlines ways for ad techs to control their Protected App Signals:

• All ad techs must enroll with the Privacy Sandbox and provide a "site" or "origin" domain which matches all URLs for Protected App Signals.
• Ad techs can partner with apps or SDKs to provide verification tokens that are used to verify creation of Protected App Signals. When this process is delegated to a partner, Protected App Signal creation can be configured to require acknowledgement by the ad tech.