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

bookmark_border সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।

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

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

সুরক্ষিত দর্শক বিটাতে রয়েছে এবং সর্বজনীন ডিভাইসে পরীক্ষার জন্য উপলব্ধ!

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

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

শুরু করতে, সুরক্ষিত দর্শক বিকাশকারী নির্দেশিকা পড়ুন। আমরা সুরক্ষিত শ্রোতা বিকাশ অব্যাহত রেখে আপনার প্রতিক্রিয়া প্রশংসা করা হয়।

টাইমলাইন

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

ওভারভিউ

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

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

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

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

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

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

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

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

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

Android API-এ সুরক্ষিত শ্রোতাদের অ্যাক্সেস পান

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

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

কাস্টম শ্রোতা

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

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

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

প্রতিটি কাস্টম শ্রোতা নিম্নলিখিত মেটাডেটা ধারণ করে:

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

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

ঐতিহ্যগত কাস্টম দর্শকের সংজ্ঞা এবং কনফিগারেশন সাধারণত সার্ভার-সাইড প্রযুক্তি এবং এজেন্সি এবং বিজ্ঞাপনদাতা ক্লায়েন্ট এবং অংশীদারদের সাথে অংশীদারিত্বে বিজ্ঞাপন প্রযুক্তি দ্বারা চালিত ইন্টিগ্রেশনের উপর নির্ভর করে। সুরক্ষিত দর্শক API ব্যবহারকারীর গোপনীয়তা রক্ষা করার সময় কাস্টম শ্রোতা সংজ্ঞা এবং কনফিগারেশন সক্ষম করে। কাস্টম শ্রোতাদের সাথে যোগ দিতে, ক্রেতা বিজ্ঞাপন প্রযুক্তি যাদের অ্যাপে SDK উপস্থিতি নেই তাদের বিজ্ঞাপন প্রযুক্তির সাথে সহযোগিতা করতে হবে যাদের ডিভাইসে উপস্থিতি রয়েছে, যেমন মোবাইল পরিমাপ অংশীদার (MMPs) এবং সাপ্লাই-সাইড প্ল্যাটফর্ম (SSPs)। প্রোটেক্টেড অডিয়েন্স 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 দ্বারা স্বয়ংক্রিয়ভাবে পূরণ করা হয়)। এপিআই আরও প্রয়োগ করে যে দৈনিক আপডেট 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 একটি HTTP GET অনুরোধ fetchUri ইস্যু করে এবং কাস্টম দর্শকদের প্রতিনিধিত্বকারী একটি JSON অবজেক্ট আশা করে। একই বাধ্যতামূলক, ঐচ্ছিক সীমাবদ্ধতা এবং কাস্টম অডিয়েন্স অবজেক্ট ক্ষেত্রগুলির জন্য ডিফল্ট মানগুলি প্রতিক্রিয়াতে প্রয়োগ করা হয়। আমাদের ডেভেলপার গাইডে বর্তমান প্রয়োজনীয়তা এবং সীমাবদ্ধতা সম্পর্কে জানুন।

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

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

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

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

• যাচাইকরণ টোকেনটি সুরক্ষিত শ্রোতা API দ্বারা কোন উদ্দেশ্যে ব্যবহার করা হয় না এবং এটি ঐচ্ছিক।

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

একটি কাস্টম শ্রোতা ছেড়ে

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

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

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

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

• প্রস্তাবটি ব্যবহারকারীদের ইনস্টল করা অ্যাপের তালিকায় দৃশ্যমানতা দিতে চায় যা কমপক্ষে একটি কাস্টম দর্শক তৈরি করেছে
• ব্যবহারকারীরা এই তালিকা থেকে অ্যাপগুলি সরাতে পারেন। অপসারণ অ্যাপগুলির সাথে যুক্ত সমস্ত কাস্টম শ্রোতা সাফ করে এবং অ্যাপগুলিকে নতুন কাস্টম দর্শকদের সাথে যুক্ত হতে বাধা দেয়৷
• ব্যবহারকারীদের সুরক্ষিত শ্রোতা API সম্পূর্ণরূপে পুনরায় সেট করার ক্ষমতা আছে। এটি ঘটলে, ডিভাইসে বিদ্যমান যেকোনো কাস্টম দর্শক সাফ হয়ে যায়।
• ব্যবহারকারীদের Android-এ গোপনীয়তা স্যান্ডবক্স থেকে সম্পূর্ণরূপে অপ্ট-আউট করার ক্ষমতা রয়েছে, যার মধ্যে রয়েছে সুরক্ষিত দর্শক API। যদি ব্যবহারকারী গোপনীয়তা স্যান্ডবক্স থেকে অপ্ট আউট করে থাকে, সুরক্ষিত দর্শক 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 কল পাঠানো হবে। ক্রেতার পরিচয় ইটিএলডি+1 থেকে অভ্যন্তরীণভাবে অনুমান করা হয়েছে এবং স্পষ্টভাবে প্রদান করার প্রয়োজন নেই এবং আপডেট প্রতিক্রিয়া দ্বারা পরিবর্তন করা যাবে না। GET অনুরোধের বিনিময়ে customAudience অবজেক্টের একটি তালিকা ধারণকারী একটি JSON অবজেক্ট আশা করে।
• বিলম্বের সময় : scheduleCustomAudienceUpdate() এপিআই কল করার সময় থেকে আপডেটের সময়সূচী করার সময় থেকে বিলম্ব বোঝায়।

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

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

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

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

প্রস্তাবটি তার কাস্টম শ্রোতাদের উপর অ্যাপস নিয়ন্ত্রণ প্রদান করতে চায়:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• বিক্রেতা : eTLD+1 ফর্ম্যাট অনুসরণ করে সেল-সাইড বিজ্ঞাপন প্ল্যাটফর্মের জন্য শনাক্তকারী
• ডিসিশন লজিক URL : যখন একটি বিজ্ঞাপন নিলাম শুরু হয়, তখন প্ল্যাটফর্ম এই URLটি ব্যবহার করে একটি বিজয়ী বিজ্ঞাপন স্কোর করার জন্য বিক্রয়-সাইড প্ল্যাটফর্ম থেকে জাভাস্ক্রিপ্ট কোড আনয়ন করবে৷
• কাস্টম দর্শক ক্রেতা : 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);

বাই-সাইড বিডিং যুক্তি

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

প্ল্যাটফর্মটি কাস্টম দর্শকদের "বিডিং লজিক ইউআরএল" মেটাডেটা ব্যবহার করবে জাভাস্ক্রিপ্ট কোড আনার জন্য যাতে নিচের ফাংশন স্বাক্ষর অন্তর্ভুক্ত করা উচিত:

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 বিটে রাউন্ড করা হয়। adCost এর বৃত্তাকার মান তারপর ইম্প্রেশন রিপোর্টিংয়ের সময় reportWin এ contextual_signals প্যারামিটারে পাস করা হয়।

বাই-সাইড ফিল্টারিং যুক্তি

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

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

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

সেল-সাইড স্কোরিং যুক্তি

স্কোরিং লজিক সাধারণত সেল-সাইড প্ল্যাটফর্ম দ্বারা প্রদান করা হয়। কোডের উদ্দেশ্য হল বিডিং লজিক আউটপুটের উপর ভিত্তি করে একটি বিজয়ী বিজ্ঞাপন নির্ধারণ করা। ফলাফল নির্ধারণ করতে এটি অতিরিক্ত ব্যবসায়িক যুক্তি প্রয়োগ করতে পারে। একাধিক ডিসিশন লজিক প্রোভাইডার থাকলে, সিস্টেমটি প্রদানকারীদের মধ্যে এক্সিকিউশন সিকোয়েন্সের গ্যারান্টি দেয় না। প্ল্যাটফর্মটি JavaScript কোড আনার জন্য 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-এ পাস করা হয়।

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

ইমপ্রেশন এবং ইভেন্ট রিপোর্টিং

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

1. সেল-সাইড রিপোর্টিং।
2. বাই-সাইড রিপোর্টিং।

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

ইভেন্ট রিপোর্টিংকে সমর্থন করার জন্য দুটি ধাপ প্রয়োজন: সেল-সাইড এবং বাই-সাইড জাভাস্ক্রিপ্ট রেজিস্টার করতে হবে কোন ইভেন্টের জন্য ইভেন্ট রিপোর্ট পেতে হবে এবং সেল-সাইড ইভেন্ট-স্তরের তথ্য রিপোর্ট করার জন্য দায়ী।

সুরক্ষিত শ্রোতা বেকন নিবন্ধন করে বিজয়ী নিলাম সম্পর্কিত ভবিষ্যতের ইভেন্টগুলিতে সাবস্ক্রাইব করার জন্য একটি ব্যবস্থা সরবরাহ করে। একজন বিক্রেতার reportResult() জাভাস্ক্রিপ্ট ফাংশনে, বিক্রয়-সাইড প্ল্যাটফর্মগুলি প্ল্যাটফর্মের registerAdBeacon() ফাংশনটি ব্যবহার করে বেকনগুলি নিবন্ধভুক্ত করতে পারে। একইভাবে, বাই-সাইড প্ল্যাটফর্মগুলি তাদের reportWin() জাভাস্ক্রিপ্ট ফাংশন থেকে registerAdBeacon() পদ্ধতিটি কল করতে পারে।

registerAdBeacon(beacons)

ইনপুট:

• event_key : একটি স্ট্রিং বোঝায় কোন ইন্টারঅ্যাকশন প্রকারের জন্য নিবন্ধন করা যায়। নিলামের ফলাফলগুলি প্রতিবেদন করার সময় প্ল্যাটফর্মের পিংসকে শেষ পয়েন্টটি সন্ধান করার জন্য এটি কী হিসাবে ব্যবহৃত হয়।
• reporting_url : ইভেন্টটি পরিচালনা করার জন্য বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মের মালিকানাধীন ইউআরএল।

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

বিক্রয়-পক্ষের প্রতিবেদন

প্ল্যাটফর্মটি selectAds() এপিআইয়ের জন্য বিক্রেতার সিদ্ধান্তের যুক্তিযুক্ত ইউআরএল প্যারামিটার থেকে ডাউনলোড করা সরবরাহের পার্শ্ব-সরবরাহিত কোডটিতে reportResult() ফাংশনটি অনুরোধ করে:

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}};
}

আউটপুট: একটি জসন অবজেক্টযুক্ত

• স্থিতি: 0 সাফল্যের জন্য, ব্যর্থতার জন্য অন্য কোনও মান।
• রিপোর্টিং ইউআরএল: প্ল্যাটফর্মটি এই ইউআরএলটি ফাংশন থেকে ফিরে আসে।
• ক্রেতার জন্য সংকেত: ক্রেতার reportWin ফাংশনে পাস করার জন্য একটি জেএসএন অবজেক্ট।

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

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

কিনুন-সাইড রিপোর্টিং

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

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}};
}

ইনপুট:

• auction_signals এবং per_buyer_signals AuctionConfig থেকে আনা হয়। ক্রয়-সাইড প্ল্যাটফর্মের রিপোর্টিং ইউআরএলে যেতে হবে এমন কোনও তথ্য এই ডেটাম থেকে আসতে পারে।
• signals_for_buyer হ'ল বিক্রয়-পক্ষের রিপোর্টসাল্টের আউটপুট। এটি বিক্রয়-পক্ষের প্ল্যাটফর্মটিকে প্রতিবেদনের উদ্দেশ্যে ক্রয়-সাইড প্ল্যাটফর্মের সাথে ডেটা ভাগ করার সুযোগ সহ সরবরাহ করে।
• contextual_signals অ্যাপের নাম এবং custom_audience_signals মতো তথ্য রয়েছে কাস্টম শ্রোতার তথ্য। ভবিষ্যতে অন্যান্য তথ্য যুক্ত করা যেতে পারে।

আউটপুট:

• স্থিতি: 0 সাফল্যের জন্য, ব্যর্থতার জন্য অন্য কোনও মান।
• রিপোর্টিং ইউআরএল: প্ল্যাটফর্মটি এই ইউআরএলটি ফাংশন থেকে ফিরে আসে।

ইভেন্ট রিপোর্টিং

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

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)

ইনপুট:

• ad_selection_id AdSelectionOutcome থেকে প্রাপ্ত সম্প্রতি রান নিলামের AdSelectionId হওয়া দরকার।
• event_key একটি বিক্রয়-পক্ষের সংজ্ঞায়িত স্ট্রিং যা ইন্টারঅ্যাকশন ইভেন্টটি বর্ণনা করে।
• event_data হ'ল একটি স্ট্রিং যা event_key সম্পর্কিত ডেটা উপস্থাপন করে
• reporting_destinations প্ল্যাটফর্ম দ্বারা সরবরাহিত পতাকা ব্যবহার করে কিছুটা মাস্ক সেট। এটি FLAG_REPORTING_DESTINATION_SELLER বা FLAG_REPORTING_DESTINATION_BUYER , বা উভয়ই হতে পারে।
• input_event (al চ্ছিক) অ্যাট্রিবিউশন রিপোর্টিং এপিআইয়ের সাথে সংহতকরণের জন্য ব্যবহৃত হয়। এটি হয় একটি InputEvent অবজেক্ট (একটি ক্লিক ইভেন্টের জন্য) বা নাল (কোনও ভিউ ইভেন্টের জন্য)। এই প্যারামিটারে আরও তথ্যের জন্য অ্যাট্রিবিউশন রিপোর্টিং এপিআই ইন্টিগ্রেশন দেখুন।

বিক্রয়-পক্ষের এসডিকে reportEvent আহ্বান জানানোর পরে এবং reporting_destinations পতাকার উপর নির্ভর করে, প্ল্যাটফর্মটি তাদের reportWin এবং reportResult জাভাস্ক্রিপ্ট ফাংশনগুলিতে ক্রেতাদের এবং বিক্রেতাদের দ্বারা নিবন্ধিত কীগুলির সাথে event_key সাথে মেলে। যদি কোনও মিল থাকে তবে প্ল্যাটফর্মটি সম্পর্কিত reporting_url event_data পোস্ট করে। অনুরোধের সামগ্রীর ধরণটি হ'ল সরল পাঠ্য যা শরীরের event_data । এই অনুরোধটি সর্বোত্তম প্রচেষ্টা হিসাবে তৈরি করা হয়েছে এবং কোনও নেটওয়ার্ক ত্রুটি, সার্ভার ত্রুটি প্রতিক্রিয়া বা কোনও মিলে যাওয়া কীগুলি পাওয়া না গেলে নিঃশব্দে ব্যর্থ হয়।

অ্যাট্রিবিউশন রিপোর্টিং এপিআই ইন্টিগ্রেশন

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

এই ক্রস-এপিআই সংহতকরণের মাধ্যমে, অ্যাডটেকগুলি করতে পারে:

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

যখন কোনও ব্যবহারকারী কোনও বিজ্ঞাপনে দেখেন বা ক্লিক করেন:

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

উত্স নিবন্ধকরণ সক্ষম করা

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

যেহেতু অ্যান্ড্রয়েড অন এআরএ ভিউ এবং ক্লিক ইভেন্টগুলিকে সমর্থন করে, InputEvents দুটি ধরণের মধ্যে পার্থক্য করতে ব্যবহৃত হয়। ঠিক যেমন এআরএ উত্স নিবন্ধকরণে, reportEvent() এপিআই একটি প্ল্যাটফর্ম-যাচাই করা InputEvent ক্লিক ইভেন্ট হিসাবে ব্যাখ্যা করবে। যদি InputEvent অনুপস্থিত, নাল বা অবৈধ থাকে তবে উত্স নিবন্ধকরণটি একটি ভিউ হিসাবে বিবেচিত হবে।

দ্রষ্টব্য পোস্ট-নিলাম eventData সংবেদনশীল তথ্য থাকতে পারে, সুতরাং প্ল্যাটফর্মটি পুনঃনির্দেশিত উত্স নিবন্ধকরণের অনুরোধগুলিতে eventData ফেলে দেয়।

বাগদান এবং রূপান্তর প্রতিবেদনের উদাহরণ

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

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

ওয়ার্কফ্লো: নিলাম শুরুর আগে, ক্রেতা তাদের প্রোগ্রাম্যাটিক রিয়েল-টাইম বিডিং ("আরটিবি") বিড প্রতিক্রিয়ার অংশ হিসাবে বিক্রেতাকে একটি অনন্য আইডি প্রেরণ করে। আইডি auctionId মতো ভেরিয়েবল হিসাবে সেট করা যেতে পারে। আইডিটি auctionConfig perBuyerSignals হিসাবে পাস করা হয় এবং এটি ক্রেতার বিডিং যুক্তিতে উপলব্ধ হয়।

1. reportWin মৃত্যুদন্ড কার্যকর করার সময়, ক্রেতা বিজ্ঞাপন রেন্ডার সময় এবং নির্দিষ্ট ইন্টারঅ্যাকশন ইভেন্টগুলির জন্য ট্রিগার করার জন্য একটি বিজ্ঞাপন বীকন নিবন্ধন করতে পারে ( registerAdBeacon() )। কোনও বিজ্ঞাপন ইভেন্টের জন্য নিলাম সংকেতগুলি সংযুক্ত করার জন্য, বীকন ইউআরএল এর ক্যোয়ারী প্যারাম হিসাবে auctionId সেট করুন।
2. বিজ্ঞাপন রেন্ডার সময় চলাকালীন, নিলামের সময় আপনি নিবন্ধিত বেকনগুলি ইভেন্ট-স্তরের ডেটা দিয়ে ট্রিগার বা উন্নত করা যেতে পারে। বিক্রেতাকে অবশ্যই reportEvent() ট্রিগার করতে হবে এবং ইভেন্ট-স্তরের ডেটা পাস করতে হবে। প্ল্যাটফর্মটি ক্রেতার নিবন্ধিত বিজ্ঞাপন বীকন ইউআরএলকে পিং করবে যা reportEvent() এর সাথে সম্পর্কিত যা ট্রিগার করা হয়েছিল।
3. ক্রেতা Attribution-Reporting-Register-Source শিরোনাম সহ বিজ্ঞাপন বীকন অনুরোধগুলিতে প্রতিক্রিয়া জানিয়ে এপিআই রিপোর্টিং এপিআইয়ের সাথে বিজ্ঞাপনটি নিবন্ধভুক্ত করবে। কোনও রূপান্তর ইভেন্টের জন্য নিলাম সংকেতগুলি সংযুক্ত করতে, নিবন্ধের উত্স ইউআরএলে auctionId সেট করুন।

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

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

বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্ম পরিচালিত বিশ্বস্ত সার্ভার

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

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

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

কাস্টম দর্শকদের কাছ থেকে বিশ্বস্ত বিডিং সিগন্যাল মেটাডেটার উপর ভিত্তি করে বিশ্বস্ত বিডিং ডেটা আনার জন্য নীচে একটি নমুনা ইউআরএল রয়েছে:

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

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

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

সৃজনশীল রেন্ডার ইউআরএলগুলির উপর ভিত্তি করে নিলামে বিবেচিত ক্রিয়েটিভ সম্পর্কিত তথ্য আনার জন্য নীচে একটি নমুনা ইউআরএল রয়েছে:

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

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

এই সার্ভারগুলি বেশ কয়েকটি সুরক্ষা এবং গোপনীয়তা সুবিধা দেওয়ার জন্য একটি বিশ্বস্ত উপায়ে কাজ করবে:

• প্রতিটি কী জন্য সার্ভারের রিটার্ন মানটি কেবল সেই কীটির উপর ভিত্তি করে বিশ্বাস করা যায়।
• সার্ভার ইভেন্ট-স্তরের লগিং সম্পাদন করে না।
• এই অনুরোধগুলির উপর ভিত্তি করে সার্ভারের অন্য কোনও পার্শ্ব প্রতিক্রিয়া নেই।

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

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

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

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

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

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

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

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

টাইমলাইন

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

ওভারভিউ

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

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

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

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

একটি উচ্চ স্তরে, সংহতকরণ নিম্নলিখিত হিসাবে কাজ করে:

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

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

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

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

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

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

কাস্টম শ্রোতা পরিচালনা

কাস্টম শ্রোতা

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

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

কাস্টম শ্রোতা মেটাডেটা

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

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

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

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

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

কাস্টম দর্শকদের সাথে যোগ দেওয়া দুটি উপায়ে করা যেতে পারে:

joinCustomAudience()

একটি অ্যাপ্লিকেশন বা এসডিকে প্রত্যাশিত পরামিতিগুলির সাথে 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()

কোনও অ্যাপ্লিকেশন বা এসডিকে কোনও বিজ্ঞাপন প্রযুক্তির পক্ষে কাস্টম দর্শকদের সাথে যোগ দেওয়ার জন্য অনুরোধ করতে পারে যার প্রত্যাশিত পরামিতিগুলির সাথে 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);

ক্রেতার মালিকানাধীন ইউআরএল এন্ডপয়েন্টটি প্রতিক্রিয়া বডিটিতে একটি CustomAudience জেএসএন অবজেক্টের সাথে প্রতিক্রিয়া জানায়। কাস্টম দর্শকদের ক্রেতা এবং মালিক ক্ষেত্রগুলি উপেক্ষা করা হয় (এবং এপিআই দ্বারা স্বতঃস্ফূর্ত)। এপিআই আরও প্রয়োগ করে যে ডেইলি আপডেট ইউআরএল ক্রেতার ইটিএলডি+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() এপিআই fetchUri এর ETLD+1 থেকে ক্রেতার পরিচয় নির্ধারণ করে। CustomAudience ক্রেতার পরিচয়টি একই তালিকাভুক্তি এবং অ্যাপ্লিকেশন অনুমোদনের চেকগুলি সম্পাদন করতে ব্যবহার করা হয় joinCustomAudience() দ্বারা সম্পন্ন হয় এবং আনার প্রতিক্রিয়া দ্বারা পরিবর্তন করা যায় না। CustomAudience মালিক হ'ল কলিং অ্যাপ্লিকেশনটির প্যাকেজ নাম। ইটিএলডি+1 চেক ব্যতীত fetchUri অন্য কোনও বৈধতা নেই এবং বিশেষত, কোনও কে-অ্যানন চেক নেই। fetchAndJoinCustomAudience() এপিআই একটি এইচটিটিপি fetchUri অনুরোধ জারি করে এবং কাস্টম দর্শকদের প্রতিনিধিত্বকারী একটি জেএসএন অবজেক্টের প্রত্যাশা করে। কাস্টম শ্রোতা অবজেক্ট ক্ষেত্রগুলির জন্য একই বাধ্যতামূলক, al চ্ছিক সীমাবদ্ধতা এবং ডিফল্ট মানগুলি প্রতিক্রিয়াতে প্রয়োগ করা হয়। আমাদের বিকাশকারী গাইডে বর্তমান প্রয়োজনীয়তা এবং সীমাবদ্ধতা সম্পর্কে জানুন।

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

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

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

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

• যাচাইকরণ টোকেনটি সুরক্ষিত শ্রোতাদের এপিআই দ্বারা কোনও উদ্দেশ্যে ব্যবহৃত হয় না এবং এটি al চ্ছিক।

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

একটি কাস্টম শ্রোতা ছেড়ে দিন

কাস্টম দর্শকদের মালিক নীচের চিত্রের স্নিপেটে যেমন দেখানো হয়েছে leaveCustomAudience() কল করে চলে যেতে বেছে নিতে পারেন:

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

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

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

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

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

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

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

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

/**
* 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 নিম্নলিখিত তথ্য থাকতে পারে:

• আপডেটুরি : ইউআরআই এন্ডপয়েন্ট যা আপডেট আনতে একটি কল কল পাঠানো হবে। ক্রেতার পরিচয়টি ইটিএলডি+1 থেকে অভ্যন্তরীণভাবে অনুমান করা হয় এবং স্পষ্টভাবে সরবরাহ করার প্রয়োজন নেই এবং আপডেটের প্রতিক্রিয়া দ্বারা পরিবর্তন করা যায় না। জিইটি অনুরোধটি বিনিময়ে customAudience অবজেক্টগুলির একটি তালিকাযুক্ত একটি জেএসএন অবজেক্টের প্রত্যাশা করে।
• বিলম্বের সময় : সময়সূচীটি সময়সূচী করার জন্য scheduleCustomAudienceUpdate() তৈরির সময় থেকে বিলম্বকে বোঝানোর সময়।

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

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

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

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

প্রস্তাবটি তার কাস্টম শ্রোতাদের উপর অ্যাপস নিয়ন্ত্রণ সরবরাহ করতে চায়:

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

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

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

This proposal outlines ways for ad techs to control their custom audiences:

• Ad techs enroll with the Privacy Sandbox and provide an eTLD+1 domain which matches all URLs for a custom audience.
• Ad techs can partner with apps or SDKs to provide verification tokens that are used to verify a custom audience creation. When this process is delegated to a partner, custom audience creation can be configured to require acknowledgement by the ad tech.
• An ad tech can choose to deactivate joinCustomAudience calls on their behalf and only allow the fetchAndJoinCustomAudience API to enable all call custom audiences. Control can be updated during Privacy Sandbox enrollment. Note the control allows either all ad techs or none. Due to platform limitations, delegation permissions can't be on a per ad tech basis.

Candidate ads and metadata response

Candidate ads and metadata returned from a buy-side platform should include the following fields:

• Metadata: Buy-side, ad tech-specific ads metadata. For example, this may include information about the ad campaign, and targeting criteria such as location and language.
• Render URL: Endpoint for rendering the ad creative.
• Filter: Optional information necessary for the Protected Audience API to filter ads based on on-device data. For more details, read the section on buy side filtering logic .

Ad selection workflow

This proposal aims to improve privacy by introducing the Ad Selection API, which orchestrates auction execution for ad tech platforms.

Ad tech platforms today typically perform bidding and ad selection exclusively on their servers. With this proposal, custom audiences and other sensitive user signals, such as available installed package information, will be accessible only through the Ad Selection API. Additionally for the remarketing use case candidate ads will be fetched out of band (ie not in the context in which ads will be shown). Ad tech platforms will need to prepare to have some parts of their current auction and ad selection logic deployed and executed on the device. Ad tech platforms may consider the following changes to their ad selection workflow:

• Without installed package information available on the server, ad tech platforms may want to send multiple contextual ads back to the device and invoke the ad selection workflow to enable app install-based filtering in order to maximize chances to show a relevant ad.
• Because remarketing ads are fetched out of band, current bidding models may need to be updated. Ad tech platforms may want to create bidding sub-models (the implementation may be based on a pattern called two-tower model) that can work on ads features and contextual signals separately and combine the sub-model outputs on the device to predict bids. This can benefit from both server-side auctions and auctions for any given ad opportunity.

This approach enables the user's app interactions data to inform ads selection, while limiting the sharing of this data with third-parties.

This ad selection workflow orchestrates the on-device execution of ad tech-provided JavaScript code based on the following sequence:

1. Buy-side bidding logic execution
2. Buy-side ad filtering and processing
3. Sell-side decision logic execution

For ad selections that involve custom audiences, the platform will fetch buy side-provided JavaScript code based on the public URL endpoint defined by the custom audience's "Bidding logic URL" metadata. The URL endpoint for sell-side decision code will also be passed as an input to initiate the ad selection workflow.

The design of ad selections that don't involve custom audiences is under active design.

Initiate ad selection workflow

When an app needs to show an ad, the ad tech platform SDK may initiate the ad selection workflow by calling the selectAds() method after instantiating the AdSelectionConfig object with the expected parameters:

• Seller : Identifier for the sell-side ad platform, following the eTLD+1 format
• Decision logic URL : When an ad auction is initiated, the platform will use this URL to fetch JavaScript code from the sell-side platform to score a winning ad.
• Custom audience buyers : A list of buy-side platforms with custom audience-based demand for this auction, following the eTLD+1 format.
• Ad selection signals : Information about the auction (ad size, ad format etc.).
• Seller signals : Supply side platform specific signals.
• Trusted Scoring Signals URL : URL endpoint of sell-side trusted signal from which creative specific realtime information can be fetched from.
• Per buyer signals : Participating demand sides may use this parameter to provide inputs for the auction. For example, this parameter may include comprehensive contextual information useful for determining bids.

The following illustrative code snippet shows an ad tech platform SDK initiating the ad selection workflow by first defining the AdSelectionConfig and then invoking selectAds to get the winning Ad:

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);

Buy-side bidding logic

The bidding logic is typically provided by buy-side platforms. The purpose of the code is to determine bids for candidate ads. It may apply additional business logic to determine the result.

The platform will use the custom audience's "Bidding logic URL" metadata to fetch the JavaScript code which should include the function signature below:

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

The generateBid() method returns the calculated bid amount. The platform will invoke this function for all ads (contextual or remarketing) sequentially. If there are multiple bidding logic providers, the system does not guarantee the execution sequence among the providers.

The function expects the following parameters:

• Ad : The ad being considered by the buy-side bidding code. This will be an Ad from an eligible custom audience
• Auction signals : Sell-side, platform-specific signals.
• Per buyer signals : Participating demand sides may use this parameter to provide inputs for the auction. For example, this parameter may include comprehensive contextual information useful for determining bids.
• Trusted bidding signals : Ad tech platforms rely on real-time data to inform ad retrieval and scoring. For instance, an ad campaign may run out of budget and needs to be stopped serving immediately. An Ad-tech can define a URL endpoint from where this real-time data can be fetched and the set of keys for which the real-time lookup needs to be performed. The ad tech platform's managed server that serves this request will be a trusted server managed by the ad tech platform.
• Contextual signals : This may include coarsened timestamp or approximate location information, or cost per click on the ad.
• User signals : This may include information such as available installed package information.

বিজ্ঞাপন খরচ

In addition to the bid, buy-side platforms have the option to return the cost per click as part of generateBid() . যেমন:

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

If this ad is the winner, adCost is stochastically rounded to 8 bits for privacy. The rounded value of adCost is then passed into the contextual_signals parameter in reportWin during impression reporting.

Buy-side filtering logic

Buy-side platforms will be able to filter ads based on additional on-device signals available during the ad selection phase. For example, ad tech platforms can implement frequency capping capabilities here. If there are multiple filtering providers, the system does not guarantee the execution sequence among the providers.

The buy-side filtering logic can be implemented as part of the bidding logic by returning a bid value of 0 for a given ad.

In addition to that, buy-side platforms will be able to signal that a given ad should be filtered based on additional on-device signals available to Protected Audience and that won't leave the device. As we solidify the designs of additional filtering logic, buy-side platforms will follow this same structure to signal that the filtering should happen.

Sell-side scoring logic

The scoring logic is typically provided by the sell-side platform. The purpose of the code is to determine a winning ad based on bidding logic outputs. It may apply additional business logic to determine the result. If there are multiple decision logic providers, the system does not guarantee the execution sequence among the providers. The platform will use the "Decision logic URL" input parameter of the selectAds() API to fetch the JavaScript code which should include the function signature below:

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

The function expects the following parameters:

• Ad : The Ad being evaluated; output from the generateBid() function.
• Bid : Bid amount output from the generateBid() function.
• Auction config : Input parameter to selectAds() method.
• Trusted Scoring Signals : Ad tech platforms rely on real-time data to inform ad filtering and scoring. For instance, an app publisher may block an ad campaign from showing ads in the app. This data is fetched from trusted scoring signals url parameter of the auction configuration. The server serving this request should be an ad tech-managed trusted server.
• Contextual signal : This may include coarsened timestamp or approximate location information.
• User signal : This may include information such as the app store that initiated the installation of the app.
• Custom audience signal : If the Ad being scored is coming from an on-device custom audience, this will contain information such as the reader and name of the custom audience.

Ad selection code runtime

In the proposal, the system will fetch ad tech platform-provided auction code from configurable URL endpoints and execute on the device. Given the resource constraints on mobile devices, auction code should adhere to the following guidelines:

• The code should finish executing in a predefined amount of time. This bound will apply uniformly to all buyer ad networks. Details of this bound will be shared in a later update.
• The code must be self-contained and not have any external dependencies.

Since the auction code, such as the bidding logic may need access to private user data such as app install sources, the runtime will not provide network or storage access.

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

Ad tech platform-provided auction code should be written in JavaScript. This would allow ad tech platforms to, for example, share bidding code across platforms that support Privacy Sandbox.

Winning ad rendering

The ad with the highest score is considered the winner of the auction. In this initial proposal, the winning ad is passed into the SDK for rendering.

The plan is to evolve the solution to ensure that information about a user's custom audience membership, or app engagement history, cannot be determined by the app or SDK through information about the winning ad (similar to Chrome's fenced frames proposal) .

Impression and event reporting

Once the ad has been rendered, the winning impression can be reported back to participating buy-side and sell-side platforms. This allows buyers and sellers to include information from the auction, such as the bid or custom audience name, with the winning impression report. Additionally, the sell-side and winning buy-side platform are eligible to receive additional event-level reporting about the winning ad. This provides the ability to include information about the auction (bid, custom audience name etc.) with clicks, views and other ad events. The platform invokes reporting logic in this order:

1. Sell-side reporting.
2. Buy-side reporting.

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)

ইনপুট:

• 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 below:

• Ad render URL
• Winning bid amount
• অ্যাপের নাম
• 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}};
}

ইনপুট:

• 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)

ইনপুট:

• 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.

After the above 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 via these servers the proposal calls for the following restrictions:

• The behaviors of these servers, described later in this section, would not leak user information.
• The servers would not create pseudonymous profiles based on the data it sees, ie 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.

Below 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 the buy side flow above, sell side may want to fetch information about creatives considered in the auction. For instance, 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.

Below 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.