প্রোটেক্টেড অডিয়েন্স API দিয়ে কাস্টম অডিয়েন্স টার্গেটিং সমর্থন করুন

সাম্প্রতিক আপডেটগুলি

• কাস্টম দর্শক আপডেটের সময়সূচী নির্ধারণ সম্পর্কে তথ্য যোগ করা হয়েছে
• সুরক্ষিত দর্শকদের সাথে অ্যাট্রিবিউশন রিপোর্টিং ইন্টিগ্রেশন যোগ করা হয়েছে
• সুরক্ষিত দর্শক বৈশিষ্ট্যগুলির একটি টাইমলাইন প্রকাশ করা হয়েছে।
• FLEDGE এর নাম পরিবর্তন করে Protected Audience API রাখা হয়েছে।
• কাস্টম শ্রোতা প্রতিনিধিদলের জন্য প্রস্তাব যোগ করা হয়েছে।
• দৈনিক আপডেট URL এর জন্য k-অজ্ঞাতনামা প্রয়োজনীয়তা সরানো হয়েছে।

সুরক্ষিত শ্রোতা বিটাতে রয়েছে এবং এটি উন্নয়নের জন্য উপলব্ধ।

সুরক্ষিত দর্শকের সাহায্যে আপনি যা করতে পারেন:

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

শুরু করতে, Protected Audience ডেভেলপার গাইডটি পড়ুন। আমরা Protected Audience ডেভেলপ করার কাজ চালিয়ে যাওয়ার সাথে সাথে আপনার প্রতিক্রিয়ার প্রশংসা করা হবে।

সময়রেখা

আগামী মাসগুলিতে আমরা নতুন বৈশিষ্ট্য প্রকাশ করব। বৈশিষ্ট্যের উপর নির্ভর করে সঠিক প্রকাশের তারিখগুলি পরিবর্তিত হবে এবং এই টেবিলটি উপলব্ধ হওয়ার সাথে সাথে ডকুমেন্টেশনের লিঙ্ক সহ আপডেট করা হবে।

সংক্ষিপ্ত বিবরণ

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

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

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

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

উচ্চ স্তরে, ইন্টিগ্রেশনটি নিম্নরূপ কাজ করে:

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

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

3. বিজ্ঞাপন পরিবেশনকারী অ্যাপ বা বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মের SDK নির্বাচিত বিজ্ঞাপনটি রেন্ডার করে।

4. এই প্ল্যাটফর্মটি ইম্প্রেশন এবং বিজ্ঞাপন নির্বাচনের ফলাফলের প্রতিবেদন তৈরিতে সহায়তা করে। এই প্রতিবেদন করার ক্ষমতা অ্যাট্রিবিউশন রিপোর্টিং API- এর পরিপূরক। বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মগুলি তাদের প্রতিবেদনের চাহিদার উপর ভিত্তি করে কাস্টমাইজ করতে পারে।

অ্যান্ড্রয়েড এপিআই-তে সুরক্ষিত দর্শকদের অ্যাক্সেস পান

প্রোটেক্টেড অডিয়েন্স API অ্যাক্সেস করার জন্য অ্যাড টেক প্ল্যাটফর্মগুলিকে নথিভুক্ত করতে হবে। আরও তথ্যের জন্য প্রাইভেসি স্যান্ডবক্স অ্যাকাউন্টের জন্য নথিভুক্ত করুন দেখুন।

কাস্টম শ্রোতা ব্যবস্থাপনা

কাস্টম দর্শক

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

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

কাস্টম দর্শক মেটাডেটা

প্রতিটি কাস্টম দর্শকের মধ্যে নিম্নলিখিত মেটাডেটা থাকে:

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

কাস্টম দর্শক প্রতিনিধিদল

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

একটি কাস্টম দর্শকদের সাথে যোগ দিন

কাস্টম অডিয়েন্সে যোগদান দুটি উপায়ে করা যেতে পারে:

joinCustomAudience()

একটি অ্যাপ বা SDK প্রত্যাশিত প্যারামিটার দিয়ে CustomAudience অবজেক্টটি ইনস্ট্যান্টিয়েট করার পরে joinCustomAudience() কল করে কাস্টম অডিয়েন্সে যোগদানের জন্য অনুরোধ করতে পারে। এখানে একটি উদাহরণমূলক কোড স্নিপেট উদাহরণ দেওয়া হল:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

একটি অ্যাপ বা SDK, এমন কোনও বিজ্ঞাপন প্রযুক্তিবিদ যার ডিভাইসে উপস্থিতি নেই, তার পক্ষ থেকে কাস্টম দর্শকদের সাথে যোগদানের জন্য অনুরোধ করতে পারে fetchAndJoinCustomAudience() কে প্রত্যাশিত প্যারামিটার ব্যবহার করে, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

ক্রেতার মালিকানাধীন URL এন্ডপয়েন্টটি রেসপন্স বডিতে একটি CustomAudience JSON অবজেক্ট দিয়ে প্রতিক্রিয়া জানায়। কাস্টম অডিয়েন্সের ক্রেতা এবং মালিক ক্ষেত্রগুলি উপেক্ষা করা হয় (এবং API দ্বারা স্বয়ংক্রিয়ভাবে পূরণ করা হয়)। API এও জোর দেয় যে দৈনিক আপডেট URL ক্রেতার eTLD+1 এর সাথেও মিলবে।

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

fetchAndJoinCustomAudience() API fetchUri এর eTLD+1 থেকে ক্রেতার পরিচয় নির্ধারণ করে। CustomAudience ক্রেতার পরিচয় joinCustomAudience() দ্বারা করা একই তালিকাভুক্তি এবং অ্যাপ অনুমোদন পরীক্ষা করার জন্য ব্যবহৃত হয় এবং ফেচ প্রতিক্রিয়া দ্বারা এটি পরিবর্তন করা যায় না। CustomAudience মালিক হলেন কলিং অ্যাপ্লিকেশনের প্যাকেজ নাম। eTLD+1 চেক ছাড়া fetchUri এর অন্য কোনও বৈধতা নেই, এবং বিশেষ করে, কোনও k-anon চেক নেই। fetchAndJoinCustomAudience() API fetchUri তে একটি HTTP GET অনুরোধ জারি করে এবং কাস্টম দর্শকদের প্রতিনিধিত্বকারী একটি JSON অবজেক্ট আশা করে। কাস্টম দর্শকদের অবজেক্ট ফিল্ডের জন্য একই বাধ্যতামূলক, ঐচ্ছিক সীমাবদ্ধতা এবং ডিফল্ট মান প্রতিক্রিয়াতে প্রয়োগ করা হয়। আমাদের বিকাশকারীর নির্দেশিকাতে বর্তমান প্রয়োজনীয়তা এবং সীমাবদ্ধতা সম্পর্কে জানুন।

ক্রেতার কাছ থেকে যেকোনো HTTP ত্রুটির প্রতিক্রিয়া fetchAndJoinCustomAudience ব্যর্থ করে। বিশেষ করে 429 (Too Many Requests) এর HTTP স্ট্যাটাস প্রতিক্রিয়া বর্তমান অ্যাপ্লিকেশন থেকে অনুরোধগুলিকে একটি নির্দিষ্ট সময়ের জন্য ব্লক করে। ক্রেতার প্রতিক্রিয়া ত্রুটিপূর্ণ হলে API কলটিও ব্যর্থ হয়। অস্থায়ী ব্যর্থতার (যেমন সার্ভার সাড়া না দেওয়া) বা ক্রমাগত ব্যর্থতার (যেমন ডেটা যাচাইকরণ ব্যর্থতা বা সার্ভারের সাথে যোগাযোগের ক্ষেত্রে অন্যান্য অ-ক্ষণস্থায়ী ত্রুটি) কারণে পুনরায় চেষ্টা করার জন্য দায়ী API কলারের কাছে ব্যর্থতার প্রতিবেদন করা হয়।

CustomAudienceFetchRequest অবজেক্ট API কলারকে উদাহরণে দেখানো ঐচ্ছিক বৈশিষ্ট্য ব্যবহার করে কাস্টম অডিয়েন্সের জন্য কিছু তথ্য সংজ্ঞায়িত করতে দেয়। যদি অনুরোধে সেট করা থাকে, তাহলে প্ল্যাটফর্ম দ্বারা প্রাপ্ত ক্রেতার প্রতিক্রিয়া দ্বারা এই মানগুলি ওভাররাইট করা যাবে না; Protected Audience API প্রতিক্রিয়ার ক্ষেত্রগুলিকে উপেক্ষা করে। যদি অনুরোধে সেট না করা থাকে, তাহলে তাদের প্রতিক্রিয়াতে সেট করতে হবে, কারণ এই ক্ষেত্রগুলি একটি কাস্টম অডিয়েন্স তৈরি করার জন্য প্রয়োজনীয়। API কলার দ্বারা আংশিকভাবে সংজ্ঞায়িত CustomAudience এর বিষয়বস্তুর একটি JSON উপস্থাপনা fetchUri এর GET অনুরোধে একটি বিশেষ হেডার X-CUSTOM-AUDIENCE-DATA তে অন্তর্ভুক্ত করা হয়েছে। কাস্টম অডিয়েন্সের জন্য নির্দিষ্ট ডেটার সিরিয়ালাইজড ফর্মের আকার 8KB-তে সীমাবদ্ধ। যদি আকার অতিক্রম করা হয় তবে fetchAndJoinCustomAudience API কল ব্যর্থ হয়।

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

যাচাইকরণ টোকেনের সংজ্ঞা এবং সংরক্ষণের উপর একটি নোট

• প্রোটেক্টেড অডিয়েন্স এপিআই কোনও উদ্দেশ্যে যাচাইকরণ টোকেন ব্যবহার করে না এবং এটি ঐচ্ছিক।

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

একটি কাস্টম দর্শক রেখে যান

একটি কাস্টম অডিয়েন্সের মালিক leaveCustomAudience() কল করে চলে যেতে পারেন, যেমনটি এই চিত্রিত কোড স্নিপেটে দেখানো হয়েছে:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

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

ব্যবহারকারী নিয়ন্ত্রণ

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

এই সক্ষমতার নকশার কাজ চলছে, এবং বিস্তারিত পরবর্তী আপডেটে অন্তর্ভুক্ত করা হবে।

নির্ধারিত আপডেট

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

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

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

কাস্টম-শ্রোতাদের আপডেট অনুরোধের সময়সূচী

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest এ প্ল্যাটফর্মে বিলম্বিত কাজ নিবন্ধনের জন্য প্রয়োজনীয় তথ্য থাকে। নির্দিষ্ট বিলম্বের পরে, একটি ব্যাকগ্রাউন্ড কাজ পর্যায়ক্রমে চলবে এবং অনুরোধ(গুলি) পাঠাবে। ScheduleCustomAudienceUpdateRequest এ নিম্নলিখিত তথ্য থাকতে পারে:

• UpdateUri : URI এন্ডপয়েন্ট যেখানে আপডেট আনার জন্য একটি GET কল পাঠানো হবে। ক্রেতার পরিচয় eTLD+1 থেকে অন্তর্নিহিতভাবে অনুমান করা হয় এবং স্পষ্টভাবে প্রদানের প্রয়োজন হয় না এবং আপডেট প্রতিক্রিয়া দ্বারা এটি পরিবর্তন করা যায় না। GET অনুরোধটি বিনিময়ে একটি JSON অবজেক্ট আশা করে যার মধ্যে customAudience অবজেক্টের একটি তালিকা থাকবে।
• DelayTime : আপডেটের সময়সূচী নির্ধারণের জন্য scheduleCustomAudienceUpdate() API কল করার সময় থেকে বিলম্বকে নির্দেশ করে সময়।

• PartialCustomAudience : API ডিভাইসের SDK-কে আংশিকভাবে নির্মিত কাস্টম অডিয়েন্সের একটি তালিকা পাঠানোর অনুমতি দেয়। এটি ইন-অ্যাপ SDK-গুলিকে DSP-এর সাথে অংশীদারিত্বের ভিত্তিতে কাস্টম অডিয়েন্স ব্যবস্থাপনার উপর সম্পূর্ণ থেকে আংশিক নিয়ন্ত্রণ পর্যন্ত দ্বৈত ভূমিকা পালন করতে দেয়।

  • এটি এই API কে fetchAndJoinCustomAudience() API এর সাথে সামঞ্জস্যপূর্ণ রাখে যা একই রকম তথ্য ভাগ করে নেওয়ার অনুমতি দেয়।

• ShouldReplacePendingUpdates : বুলিয়ান যা নির্ধারণ করে যে কোনও মুলতুবি থাকা শিডিউল আপডেট বাতিল করা উচিত কিনা এবং বর্তমান ScheduleCustomAudienceUpdateRequest এ বিশদভাবে উল্লেখিত আপডেট দিয়ে প্রতিস্থাপন করা উচিত কিনা। যদি এটি false তে সেট করা থাকে এবং একই অ্যাপে একই ক্রেতার জন্য পূর্বে অনুরোধ করা আপডেটগুলি এখনও মুলতুবি থাকে, তাহলে এই ScheduleCustomAudienceUpdateRequest দিয়ে scheduleCustomAudienceUpdate এ কল করা ব্যর্থ হবে। ডিফল্টভাবে false তে সেট করা হয়।

অ্যাপের অনুমতি এবং নিয়ন্ত্রণ

এই প্রস্তাবটি অ্যাপগুলিকে তার কাস্টম দর্শকদের উপর নিয়ন্ত্রণ প্রদানের উদ্দেশ্যে তৈরি করেছে:

• একটি অ্যাপ কাস্টম দর্শকদের সাথে তার সম্পর্ক পরিচালনা করতে পারে।
• একটি অ্যাপ তার পক্ষ থেকে কাস্টম দর্শকদের পরিচালনা করার জন্য তৃতীয় পক্ষের বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মগুলিকে অনুমতি দিতে পারে।

এই সক্ষমতার নকশার কাজ চলছে, এবং বিস্তারিত পরবর্তী আপডেটে অন্তর্ভুক্ত করা হবে।

বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্ম নিয়ন্ত্রণ

এই প্রস্তাবে বিজ্ঞাপন প্রযুক্তিবিদদের তাদের কাস্টম দর্শকদের নিয়ন্ত্রণ করার উপায়গুলি বর্ণনা করা হয়েছে:

• বিজ্ঞাপন প্রযুক্তিবিদরা প্রাইভেসি স্যান্ডবক্সে নথিভুক্ত হন এবং একটি eTLD+1 ডোমেন প্রদান করেন যা কাস্টম দর্শকদের জন্য সমস্ত URL-এর সাথে মেলে।
• বিজ্ঞাপন প্রযুক্তিবিদরা অ্যাপ বা SDK-এর সাথে অংশীদারিত্ব করে যাচাইকরণ টোকেন সরবরাহ করতে পারেন যা কাস্টম দর্শক তৈরির যাচাইকরণের জন্য ব্যবহৃত হয়। যখন এই প্রক্রিয়াটি কোনও অংশীদারের কাছে অর্পণ করা হয়, তখন কাস্টম দর্শক তৈরির বিষয়টি বিজ্ঞাপন প্রযুক্তিবিদদের দ্বারা স্বীকৃতির প্রয়োজন অনুসারে কনফিগার করা যেতে পারে।
• একজন বিজ্ঞাপন প্রযুক্তিবিদ তাদের পক্ষ থেকে joinCustomAudience কল নিষ্ক্রিয় করতে পারেন এবং শুধুমাত্র fetchAndJoinCustomAudience API-কে সমস্ত কল কাস্টম দর্শকদের সক্ষম করার অনুমতি দিতে পারেন। গোপনীয়তা স্যান্ডবক্স তালিকাভুক্তির সময় নিয়ন্ত্রণ আপডেট করা যেতে পারে। মনে রাখবেন নিয়ন্ত্রণটি হয় সমস্ত বিজ্ঞাপন প্রযুক্তিবিদকে অনুমতি দেয় অথবা কাউকেই অনুমতি দেয় না। প্ল্যাটফর্মের সীমাবদ্ধতার কারণে, ডেলিগেশন অনুমতিগুলি প্রতিটি বিজ্ঞাপন প্রযুক্তির ভিত্তিতে হতে পারে না।

প্রার্থীর বিজ্ঞাপন এবং মেটাডেটা প্রতিক্রিয়া

বাই-সাইড প্ল্যাটফর্ম থেকে ফেরত আসা প্রার্থীর বিজ্ঞাপন এবং মেটাডেটাতে নিম্নলিখিত ক্ষেত্রগুলি অন্তর্ভুক্ত করা উচিত:

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

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

এই প্রস্তাবের লক্ষ্য হল বিজ্ঞাপন নির্বাচন API চালু করার মাধ্যমে গোপনীয়তা উন্নত করা, যা বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মগুলির জন্য নিলাম সম্পাদনের ব্যবস্থা করে।

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

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

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

এই বিজ্ঞাপন নির্বাচন কর্মপ্রবাহটি নিম্নলিখিত ক্রমের উপর ভিত্তি করে বিজ্ঞাপন প্রযুক্তি-প্রদত্ত জাভাস্ক্রিপ্ট কোডের ডিভাইসে কার্যকরকরণের ব্যবস্থা করে:

1. বাই-সাইড বিডিং লজিক এক্সিকিউশন
2. বাই-সাইড বিজ্ঞাপন ফিল্টারিং এবং প্রক্রিয়াকরণ
3. বিক্রয়-পক্ষের সিদ্ধান্তের যুক্তি সম্পাদন

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

কাস্টম দর্শকদের জড়িত না করে এমন বিজ্ঞাপন নির্বাচনের নকশা সক্রিয় নকশার অধীনে রয়েছে।

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

যখন কোনও অ্যাপকে কোনও বিজ্ঞাপন দেখানোর প্রয়োজন হয়, তখন বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্ম SDK প্রত্যাশিত প্যারামিটার সহ AdSelectionConfig অবজেক্টটি ইনস্ট্যান্টিয়েট করার পরে selectAds() পদ্ধতিতে কল করে বিজ্ঞাপন নির্বাচনের কর্মপ্রবাহ শুরু করতে পারে:

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

নিম্নলিখিত চিত্রিত কোড স্নিপেটটি একটি বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্ম SDK দেখায় যা প্রথমে AdSelectionConfig সংজ্ঞায়িত করে এবং তারপর বিজয়ী বিজ্ঞাপন পেতে selectAds ব্যবহার করে বিজ্ঞাপন নির্বাচনের কর্মপ্রবাহ শুরু করে:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

বাই-সাইড বিডিং লজিক

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

প্ল্যাটফর্মটি জাভাস্ক্রিপ্ট কোড আনতে কাস্টম অডিয়েন্সের "বিডিং লজিক URL" মেটাডেটা ব্যবহার করবে যার মধ্যে নিম্নলিখিত ফাংশন স্বাক্ষর অন্তর্ভুক্ত থাকা উচিত:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

generateBid() পদ্ধতিটি গণনা করা বিডের পরিমাণ ফেরত দেয়। প্ল্যাটফর্মটি ক্রমানুসারে সমস্ত বিজ্ঞাপনের (প্রাসঙ্গিক বা পুনঃবিপণন) জন্য এই ফাংশনটি ব্যবহার করবে। যদি একাধিক বিডিং লজিক প্রদানকারী থাকে, তাহলে সিস্টেমটি প্রদানকারীদের মধ্যে কার্যকরকরণ ক্রম নিশ্চিত করে না।

ফাংশনটি নিম্নলিখিত পরামিতিগুলি আশা করে:

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

বিজ্ঞাপনের খরচ

বিড ছাড়াও, বাই-সাইড প্ল্যাটফর্মগুলিতে generateBid() এর অংশ হিসেবে প্রতি ক্লিকের খরচ ফেরত দেওয়ার বিকল্প রয়েছে। উদাহরণস্বরূপ:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

যদি এই বিজ্ঞাপনটি বিজয়ী হয়, তাহলে গোপনীয়তার জন্য adCost স্টকাস্টিকভাবে 8 বিটে রাউন্ড করা হয়। তারপর ইম্প্রেশন রিপোর্টিংয়ের সময় reportWin এ adCost এর রাউন্ড করা মান contextual_signals প্যারামিটারে পাস করা হয়।

বাই-সাইড ফিল্টারিং লজিক

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

একটি নির্দিষ্ট বিজ্ঞাপনের জন্য 0 এর বিড মান ফেরত দিয়ে বিডিং লজিকের অংশ হিসেবে বাই-সাইড ফিল্টারিং লজিক প্রয়োগ করা যেতে পারে।

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

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

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

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

ফাংশনটি নিম্নলিখিত পরামিতিগুলি আশা করে:

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

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

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

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

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

প্রোগ্রামিং ভাষা

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

বিজয়ী বিজ্ঞাপন রেন্ডারিং

সর্বোচ্চ স্কোর প্রাপ্ত বিজ্ঞাপনটিকে নিলামের বিজয়ী হিসেবে বিবেচনা করা হয়। এই প্রাথমিক প্রস্তাবে, বিজয়ী বিজ্ঞাপনটি রেন্ডারিংয়ের জন্য SDK-তে পাঠানো হয়।

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

ছাপ এবং ইভেন্ট রিপোর্টিং

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

1. বিক্রয়-পক্ষের প্রতিবেদন।
2. বাই-সাইড রিপোর্টিং।

This gives buy-side and sell-side platforms a way to send important on-device information back to the servers to enable capabilities like real time budgeting, bidding model updates, and accurate billing workflows. This impression reporting support is complementary to the Attribution Reporting API .

There are two steps required to support event reporting: Sell-side and buy-side JavaScript needs to register what event it should receive event reports for, and the sell-side is responsible for reporting event-level information.

Protected Audience provides a mechanism to subscribe to future events related to a winning auction by registering beacons. In a seller's reportResult() JavaScript function, sell-side platforms can register beacons using the platform's registerAdBeacon() function. Similarly, buy-side platforms can call the registerAdBeacon() method from their reportWin() JavaScript function.

registerAdBeacon(beacons)

Input:

• event_key : A string denoting which interaction type to register for. This is used as a key to look up the endpoint the platform pings while reporting the results of the auction.
• reporting_url : The URL owned by the ad tech platform for handling the event.

Event keys are string identifiers that are owned by the sell-side SDK responsible for reporting the results of the auction. For a callback to be made, ad techs register beacons with keys that match the keys used by the sell-side when reporting the events. These don't need to be k-anonymous, though there are limits to the quantity and length of keys that can be registered for a given custom audience. If reportEvent() is called, sell-side platforms that ran the auction are always eligible to receive these event reports. Only the winning buy-side platform is eligible to receive these reports.

Sell-side reporting

The platform invokes the reportResult() JavaScript function in the supply side-provided code downloaded from the seller's Decision logic URL parameter for the selectAds() API:

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

Output: A JSON object containing

• Status: 0 for success, any other value for failure.
• Reporting URL: The platform invokes this URL returned from the function.
• Signals for Buyer: A JSON object to be passed to the buyer's reportWin function.

The supply side may encode relevant signals in the reporting URL to help them gain further insights into the auction and winning ad. For example, it may include signals such as these:

• Ad render URL
• Winning bid amount
• App name
• Query identifiers
• Signals for buyer: To support data sharing between supply side and demand side, the platform passes this return value as an input parameter to demand side reporting code.

Buy-side reporting

The platform invokes the reportWin() JavaScript function in the demand side-provided code downloaded from the Bidding logic URL metadata of the custom audience associated with the auction.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

Input:

• auction_signals and per_buyer_signals are fetched from AuctionConfig . Any information that the buy-side platform needs to pass into the reporting URL may come from this datum.
• signals_for_buyer is the output of the sell-side reportResult. This provides the sell-side platform with an opportunity to share data with the buy-side platform for reporting purposes.
• contextual_signals contains information such as app name and custom_audience_signals contains the custom audience information. Other information may be added in the future.

আউটপুট:

• Status: 0 for success, any other value for failure.
• Reporting URL: The platform invokes this URL returned from the function.

Reporting Events

Reporting events is only possible after impression reporting for the auction has completed. The sell-side SDK is responsible for reporting any events. The platform exposes an API that takes a ReportEventRequest that specifies the recently run auction, the event key that is reported, the data associated with that key, whether the report should be sent to the buyer or the seller (or both), and an optional input event for ad events. The client defines the event key and collection of data to report.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

Input:

• ad_selection_id needs to be an AdSelectionId of a recently run auction retrieved from the AdSelectionOutcome .
• event_key is a sell-side defined string describing the interaction event.
• event_data is a string representing the data associated with the event_key
• reporting_destinations is a bit mask set using flags provided by the platform. It can be one of FLAG_REPORTING_DESTINATION_SELLER or FLAG_REPORTING_DESTINATION_BUYER , or both.
• input_event (optional) is used for integration with Attribution Reporting API. It is either an InputEvent object (for a click event) or null (for a view event). See Attribution Reporting API Integration for more details on this parameter.

After the sell-side SDK invokes reportEvent and, depending on the reporting_destinations flag, the platform attempts to match the event_key to the keys registered by buyers and sellers in their reportWin and reportResult JavaScript functions. If there is a match, the platform POSTs the event_data to the associated reporting_url . The content type of the request is plain text with the body being the event_data . This request is made as best effort and fails silently in the event of a network error, server error response, or if no matching keys were found.

Attribution Reporting API integration

To support buyers who participate in a Protected Audience auction, we are providing cross-API functionality across the Protected Audience and Attribution Reporting APIs (ARA). This functionality enables ad techs to evaluate their attribution performance across various remarketing tactics, so that they can understand which types of audiences deliver the highest ROI.

Through this cross-API integration, adtechs can:

• Create a key-value map of URIs to be used for both 1) ad interaction reporting and 2) source registration.
• Include auction data from the Protected Audience auction in their source-side key mapping for aggregate summary reporting (using the Attribution Reporting API) See the ARA design proposal for more information.

When a user sees or clicks on an ad:

• The URL used to report those events interactions using Protected Audience will provide the necessary data to the buyer to be used to register a view or click as an eligible source with the Attribution Reporting API.
• The ad tech may choose to pass CustomAudience (or other relevant contextual information about the ad such as ad placement or view duration) using that URL so this metadata can propagate down to summary reports when the ad tech is reviewing aggregate campaign performance.

Enabling source registration

reportEvent() will accept a new optional parameter InputEvent . Winning buyers who register ad beacons can choose which reportEvent reports get registered with Attribution Reporting APIs as a registered source. The request header Attribution-Reporting-Eligible will be added to all event reporting requests sent from reportEvent() . Any responses with appropriate ARA headers will be parsed in the same way any other regular ARA source registration response would be. See Attribution Reporting API explainer for how to register a source URL .

Because ARA on Android supports view and click events, InputEvents are used to distinguish between the two types. Just as in ARA source registration, the reportEvent() API will interpret a platform-verified InputEvent as a click event. If the InputEvent is missing, null, or invalid, the source registration will be considered a view.

Note the post-auction eventData may contain sensitive information, so the platform drops the eventData in redirected source registration requests.

Engagement and conversion reporting example

In this example, we'll look at it from the buyer perspective who is interested in associating the data from the auction, rendered ad, and conversion app together.

In this workflow, the buyer coordinates with the seller to send a unique ID into the auction. During the auction, the buyer sends this unique ID with the auction data. During render and conversion time, the data from the rendered ad is also sent out with the same unique ID. Later, the unique ID can be used to associate these reports together.

Workflow: Before the auction starts, the buyer sends a unique ID to the seller as part of their programmatic real-time bidding ("RTB") bid response . The ID can be set as a variable like auctionId . The ID is passed in as perBuyerSignals in the auctionConfig and it becomes available in buyer's bidding logic.

1. During the execution of reportWin , the buyer can register an ad beacon to be triggered during ad render time and for specific interaction events ( registerAdBeacon() ). To associate auction signals for an ad event, set the auctionId as a query param of the beacon URL.
2. During ad render time, the beacons you registered during auction time can be triggered or enhanced with event-level data. The seller must trigger reportEvent() and pass in the event-level data. The platform will ping the buyer's registered ad beacon URL that correlates with the reportEvent() that was triggered.
3. The buyer will register the ad with the Attribution Reporting API by responding to the ad beacon requests with the Attribution-Reporting-Register-Source header. To associate auction signals for a conversion event, set the auctionId in the Register source URL.

At the end of this process, the buyer will have an auction report, interaction report, and conversion report, that can be correlated using the unique ID that can be used to associate with each other.

Similar workflow applies to a seller if it needs access to attribution data, and the seller can also use a unique ID to send with registerAdBeacon() . The reportEvent() call contains a destination property that can be used to send the report to both the buyer and the seller.

Ad tech platform managed trusted server

Ad selection logic today requires real-time information such as budget depletion status to determine if ad candidates should be selected for auction. Both buy-side and sell-side platforms will be able to get this information from servers they operate. In order to minimize leak of any sensitive information using these servers the proposal calls for the following restrictions:

• The behaviors of these servers, described later in this section, wouldn't leak user information.
• The servers wouldn't create pseudonymous profiles based on the data it sees, that is, it will need to be 'trusted'.

Buy side : Once buy side initiates the buy side bidding logic, the platform performs an HTTP fetch of trusted bidding data from the trusted server. The URL is composed by appending the URL and keys present in the Trusted Bidding Signals metadata of the custom audience being processed. This fetch is done only when processing ads from the on device custom audiences. At this stage, buy side can enforce budgets, check for campaign pause / unpause state, perform targeting, etc.

This is a sample URL to fetch trusted bidding data, based on trusted bidding signal metadata from the custom audience:

https://www.kv-server.example/getvalues?keys=key1,key2

The response from the server should be a JSON object whose keys are key1, key2, etc., and whose values will be made available to the buyer's bidding functions.

Sell side : Similar to this buy side flow, sell side may want to fetch information about creatives considered in the auction. For example, a publisher may want to enforce that certain creatives are not shown in their app based on brand safety concerns. This information can be fetched and made available to the sell side auction logic. Similar to the buy side trusted server lookup, sell side trusted server lookup also happens using an HTTP fetch. The URL is composed by appending the Trusted Scoring Signals URL with render URLs of the creatives for which the data needs to be fetched.

Following is a sample URL to fetch information about creatives considered in the auction, based on creative render URLs:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

Response from the server should be a JSON object whose keys are render URLs sent in the request.

These servers would operate in a trusted way to offer several security and privacy benefits:

• The server's return value for each key can be trusted to be based only on that key.
• The server does not perform event-level logging.
• The server has no other side effects based on these requests.

As a temporary mechanism, the buyer and seller can fetch these bidding signals from any server, including one they operate themselves. However, in the release version, the request will only be sent to a trusted key-value-type server.

Buyers and sellers could use a common trusted key-value-type server for platforms compatible with Privacy Sandbox on Android and for the Web.