বিডিং এবং নিলাম পরিষেবা একীকরণ এবং অপ্টিমাইজেশান

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

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

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

  1. সার্ভার নিলামের জন্য ডেটা সংগ্রহ এবং এনক্রিপ্ট করুন
  2. একটি অবিশ্বস্ত বিক্রেতা পরিষেবাতে একটি অনুরোধ পাঠান
  3. একটি অবিশ্বস্ত বিক্রেতা পরিষেবা থেকে একটি প্রতিক্রিয়া পান
  4. সুরক্ষিত দর্শক নিলামের প্রতিক্রিয়া ডিক্রিপ্ট করুন এবং নিলামের ফলাফল পান

সার্ভার নিলাম পরিচালনার জন্য প্রোটেক্টেড অডিয়েন্স দুটি নতুন API চালু করছে:

  1. getAdSelectionData API সার্ভার নিলামের জন্য ডেটা সংগ্রহ করে এবং নিলামের ডেটা ধারণকারী একটি এনক্রিপ্টেড পেলোড তৈরি করে। বিডিং এবং নিলাম সার্ভার এই পেলোড ব্যবহার করে নিলাম চালায়, নিলামের ফলাফল তৈরি করে এবং নিলামের ফলাফল ফেরত দেয়।
  2. অন-ডিভাইস বিজ্ঞাপন প্রযুক্তি ক্লায়েন্টরা সার্ভার নিলামের মাধ্যমে উৎপন্ন ফলাফল ডিক্রিপ্ট করতে এবং বিজয়ী বিজ্ঞাপন রেন্ডার URL পেতে persistAdSelectionResult API-এ কল করতে পারেন।

নিলাম পরিচালনা করার জন্য ডিভাইসে বিক্রেতা বিজ্ঞাপন প্রযুক্তিবিদকে নিম্নলিখিতগুলি একীভূত এবং তৈরি করতে হবে:

  1. সার্ভার নিলামের জন্য ডেটা সংগ্রহ এবং এনক্রিপ্ট করুন বিক্রেতা : বিজ্ঞাপন প্রযুক্তিবিদদের এনক্রিপ্ট করা পেলোড পেতে getAdSelectionData API কল করা উচিত।
  2. অবিশ্বস্ত বিক্রেতা পরিষেবাতে অনুরোধ পাঠান পাঠান : একটি HTTP POST বা PUT অনুরোধ যার মধ্যে getAdSelectionData API দ্বারা তাদের অবিশ্বস্ত বিক্রেতা পরিষেবাতে তৈরি এনক্রিপ্ট করা পেলোড এবং প্রাসঙ্গিক ফলাফল তৈরি করার জন্য অবিশ্বস্ত বিক্রেতা পরিষেবার দ্বারা প্রয়োজনীয় ডেটা থাকে।
  3. অবিশ্বস্ত বিক্রেতা পরিষেবা থেকে প্রতিক্রিয়া গ্রহণ করুন : অবিশ্বস্ত বিক্রেতা পরিষেবা থেকে প্রতিক্রিয়ায় এনক্রিপ্ট করা সুরক্ষিত দর্শক নিলামের ফলাফল এবং প্রাসঙ্গিক নিলামের ফলাফল থাকবে।
  4. সুরক্ষিত দর্শক নিলামের প্রতিক্রিয়া ডিক্রিপ্ট করুন এবং নিলামের ফলাফল পান: সুরক্ষিত দর্শক নিলামের ফলাফল ডিক্রিপ্ট করতে, বিক্রেতা বিজ্ঞাপন প্রযুক্তিবিদদের persistAdSelectionResult API কল করা উচিত। persistAdSelectionResult দ্বারা উৎপন্ন ফলাফল বিজ্ঞাপন প্রযুক্তিবিদদের প্রাসঙ্গিক বিজ্ঞাপন নাকি সুরক্ষিত দর্শক বিজ্ঞাপন নিলামে জিতেছে তা নির্ধারণ করতে এবং প্রযোজ্য ক্ষেত্রে বিজয়ী সুরক্ষিত দর্শক বিজ্ঞাপনের URI নির্ধারণ করতে সহায়তা করবে।

সার্ভার নিলামের জন্য সমর্থিত বৈশিষ্ট্যগুলি

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

ডিভাইসে নিলাম

সার্ভার নিলাম

ডেভেলপার প্রিভিউ

বিটা

ডেভেলপার প্রিভিউ

বিটা

ইভেন্ট-স্তরের জয়ের রিপোর্টিং

Q1 '23

Q3 '23

নিষিদ্ধ

চতুর্থ ত্রৈমাসিক '২৩

জলপ্রপাত মধ্যস্থতা

Q1 '23

চতুর্থ ত্রৈমাসিক '২৩

নিষিদ্ধ

চতুর্থাংশ ২৪

ফ্রিকোয়েন্সি ক্যাপ ফিল্টারিং

Q2 '23

Q3 '23

নিষিদ্ধ

চতুর্থ ত্রৈমাসিক '২৩

ফিল্টার করার জন্য প্রাসঙ্গিক বিজ্ঞাপনগুলিকে বিজ্ঞাপন নির্বাচনের কর্মপ্রবাহে স্থানান্তর করুন

Q2 '23

চতুর্থাংশ '২৪

নিষিদ্ধ

নিষিদ্ধ

মিথস্ক্রিয়া প্রতিবেদন

Q2 '23

Q3 '23

নিষিদ্ধ

চতুর্থ ত্রৈমাসিক '২৩

কাস্টম অডিয়েন্স ডেলিগেশনে যোগ দিন

Q3 '23

চতুর্থ ত্রৈমাসিক '২৩

নিষিদ্ধ

চতুর্থ ত্রৈমাসিক '২৩

নন-সিপিএম বিলিং

Q3 '23

চতুর্থ ত্রৈমাসিক '২৩

ডিবাগ
রিপোর্টিং

Q3 '23

চতুর্থ ত্রৈমাসিক '২৩

Q3 '23

চতুর্থ ত্রৈমাসিক '২৩

ওপেন বিডিং মধ্যস্থতা

নিষিদ্ধ

নিষিদ্ধ

নিষিদ্ধ

চতুর্থাংশ '২৪

অ্যাপ ইনস্টল বিজ্ঞাপন ফিল্টারিং

Q2 '23

চতুর্থাংশ '২৪

নিষিদ্ধ

চতুর্থাংশ '২৪

মুদ্রা ব্যবস্থাপনা

নিষিদ্ধ

নিষিদ্ধ

নিষিদ্ধ

চতুর্থাংশ '২৪

কে-অ্যানন ইন্টিগ্রেশন

নিষিদ্ধ

চতুর্থাংশ '২৪

নিষিদ্ধ

চতুর্থাংশ '২৪

ব্যক্তিগত সমষ্টি ইন্টিগ্রেশন

নিষিদ্ধ

নিষিদ্ধ

নিষিদ্ধ

Q3 '24

সুরক্ষিত শ্রোতা API ব্যবহার করে সার্ভার নিলাম চালান

ডেভেলপার প্রিভিউ ট্র্যাকে, AdSelectionManager দুটি নতুন API প্রকাশ করে: getAdSelectionData এবং persistAdSelectionResult । এই API গুলি বিজ্ঞাপন প্রযুক্তি SDK গুলিকে বিডিং এবং নিলাম সার্ভারের সাথে একীভূত করার অনুমতি দেয়।

সার্ভার নিলামের জন্য ডেটা সংগ্রহ এবং এনক্রিপ্ট করুন

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

API অ্যাক্সেস করতে, Protected Audience API-তে অ্যাক্সেস সক্ষম করতে হবে এবং ACCESS_ADSERVICES_CUSTOM_AUDIENCE অনুমতি কলারের ম্যানিফেস্টে সংজ্ঞায়িত করতে হবে।

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest সম্পর্কে

  1. অনুরোধটি পরিবেশন করার আগে, কলকারীকে অনুরোধে seller ক্ষেত্রটি সেট করতে হবে কারণ এটি তালিকাভুক্তি পরীক্ষা চালানোর জন্য ব্যবহৃত হয়।
  2. coordinatorOriginUri ক্ষেত্রটি ঐচ্ছিক।
    1. যদি সেট করা থাকে, তাহলে এটি বিক্রেতার B&A সার্ভার স্থাপনের সময় কনফিগার করা সমন্বয়কারী URL-এর স্কিম, হোস্টনেম এবং পোর্টের সমান হবে।
    2. সমন্বয়কারীকে অবশ্যই অনুমোদিত সমন্বয়কারীদের তালিকার অন্তর্ভুক্ত হতে হবে:
      সরবরাহকারী ইউআরআই URI অরিজিন ডিফল্ট
      গুগল ক্লাউড https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.gcp.privacysandboxservices.com হাঁ
      অ্যামাজন ওয়েব সার্ভিসেস https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.aws.privacysandboxservices.com না
    3. যদি কোন সমন্বয়কারীর উৎপত্তি প্রদান না করা হয়, তাহলে ডিফল্ট সমন্বয়কারী ব্যবহার করা হয়।
    4. যদিও কোঅর্ডিনেটর URL পরিবর্তন হওয়ার সম্ভাবনা খুবই কম, তবুও এই URL টি গতিশীলভাবে পরিচালনা করার জন্য একটি ব্যবস্থা বাস্তবায়নের জন্য জোরালোভাবে সুপারিশ করা হচ্ছে। এটি নিশ্চিত করে যে URL-এ ভবিষ্যতের যেকোনো পরিবর্তন নতুন SDK রিলিজের প্রয়োজন ছাড়াই গ্রহণ করা যেতে পারে।
public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

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

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome getAdSelectionData API এর ফলাফল হিসেবে তৈরি করা হয়। এতে নিম্নলিখিতগুলি রয়েছে:

  1. adSelectionId : getAdSelectionData এর এই আহ্বান সনাক্ত করার জন্য একটি অস্বচ্ছ পূর্ণসংখ্যা। বিজ্ঞাপন প্রযুক্তি ক্লায়েন্টের এই adSelectionId মানটি ধরে রাখা উচিত কারণ এটি getAdSelectionData কলের পয়েন্টার হিসেবে কাজ করে। বিডিং এবং নিলাম সার্ভার থেকে নিলামের ফলাফল ডিক্রিপ্ট করার জন্য persistAdSelectionResult API-এর জন্য এই শনাক্তকারীর প্রয়োজন এবং reportImpression এবং reportEvent API-এর জন্যও এটি প্রয়োজন।
  2. adSelectionData : এটি হল এনক্রিপ্ট করা নিলাম ডেটা যা নিলাম চালানোর জন্য বিডিং এবং নিলাম সার্ভারের প্রয়োজন হবে। এই পদ্ধতিতে রয়েছে:
    1. কাস্টম অডিয়েন্সের জন্য ফ্রিকোয়েন্সি ক্যাপিং, অ্যাপ ইনস্টল ফিল্টার এবং সার্ভার নিলামের প্রয়োজনীয়তার উপর ভিত্তি করে ফিল্টার করা কাস্টম অডিয়েন্স ডেটা।
    2. ভবিষ্যতের সংস্করণে, এতে অ্যাপ ইনস্টল ডেটা থাকবে।
public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

ত্রুটি, ব্যতিক্রম এবং ব্যর্থতা পরিচালনা

যদি অবৈধ আর্গুমেন্ট, টাইমআউট, অথবা অতিরিক্ত রিসোর্স ব্যবহারের মতো কারণে বিজ্ঞাপন নির্বাচন ডেটা জেনারেশন সফলভাবে সম্পন্ন না হয়, তাহলে OutcomeReceiver.onError() কলব্যাক নিম্নলিখিত আচরণ সহ একটি AdServicesException প্রদান করে:

  1. যদি getAdSelectionData অবৈধ আর্গুমেন্ট দিয়ে শুরু করা হয়, তাহলে AdServicesException ` একটি IllegalArgumentException কে কারণ হিসেবে নির্দেশ করে।
  2. অন্য সকল ত্রুটির জন্য একটি AdServicesException পাওয়া যায় যার কারণ হিসেবে একটি IllegalStateException থাকে।

একটি অবিশ্বস্ত বিক্রেতা পরিষেবাতে একটি অনুরোধ পাঠান

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

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

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

অবিশ্বস্ত বিক্রেতা পরিষেবা থেকে প্রতিক্রিয়া পান

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

অবিশ্বস্ত বিক্রেতা পরিষেবাটি এনক্রিপ্ট করা adSelectionData এবং AuctionConfig TEE-তে চলমান বিডিং এবং নিলাম সার্ভারের SellerFrontEnd পরিষেবাতে ফরোয়ার্ড করে।

যখন সুরক্ষিত দর্শক নিলাম সম্পন্ন হয়, তখন SellerFrontEnd পরিষেবা নিলামের ফলাফল এনক্রিপ্ট করে এবং অবিশ্বস্ত বিক্রেতা পরিষেবার প্রতিক্রিয়া হিসাবে এটি ফেরত দেয়।

অবিশ্বস্ত বিক্রেতা পরিষেবাটি প্রাসঙ্গিক বিজ্ঞাপন এবং/অথবা এনক্রিপ্ট করা সুরক্ষিত দর্শক নিলামের ফলাফল সম্বলিত ডিভাইসে একটি প্রতিক্রিয়া পাঠায়।

প্রতিক্রিয়া পাওয়ার পর, ডিভাইসে বিক্রেতা বিজ্ঞাপন প্রযুক্তি কোডটি প্রতিক্রিয়ায় কেবল প্রাসঙ্গিক বিজ্ঞাপনটি ব্যবহার করতে পারে অথবা যদি মনে করে যে সুরক্ষিত দর্শকের ফলাফল পাওয়ার ক্ষেত্রে ক্রমবর্ধমান মূল্য রয়েছে, তাহলে তারা PersistAdSelectionResult API কল করে সুরক্ষিত দর্শকের ফলাফলটি ডিক্রিপ্ট করতে পারে।

PersistAdSelectionResult API

Protected Audience ফলাফল ডিক্রিপ্ট করার জন্য, বিক্রেতা বিজ্ঞাপন প্রযুক্তিবিদ দ্বিতীয় Protected Audience API persistAdSelectionResult কল করতে পারেন। API ফলাফল ডিক্রিপ্ট করে এবং একটি AdSelectionOutcome প্রদান করে, যা আজ একটি অন-ডিভাইস নিলাম থেকে ফেরত পাঠানো একই বস্তু।

API অ্যাক্সেস করার জন্য, কলারকে Protected Audience API অ্যাক্সেস সক্ষম করতে হবে এবং তাদের ম্যানিফেস্টে ACCESS_ADSERVICES_CUSTOM_AUDIENCE অনুমতি সংজ্ঞায়িত করতে হবে

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest সম্পর্কে

কলকারীকে অনুরোধে নিম্নলিখিতগুলি সেট করতে হবে:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}
  1. adSelectionId : getAdSelectionData কলের মাধ্যমে তৈরি অস্বচ্ছ শনাক্তকারী যার ফলাফল কলার ডিক্রিপ্ট করতে চায়।
  2. seller : অনুরোধটি পরিবেশন করার আগে তালিকাভুক্তি পরীক্ষা চালানোর জন্য অনুরোধে বিক্রেতার বিজ্ঞাপন প্রযুক্তি শনাক্তকারী সেট করতে হবে।
  3. adSelectionResult : বিডিং এবং নিলাম সার্ভার দ্বারা তৈরি এনক্রিপ্ট করা নিলামের ফলাফল যা কলকারী ডিক্রিপ্ট করতে চান।

AdSelectionOutcome প্রতিক্রিয়া

যদি কোনও Protected Audience বিজয়ী থাকে, তাহলে AdSelectionOutcome বিজয়ী বিজ্ঞাপন রেন্ডার URI ফেরত দেয়। adSelectionResult ডিক্রিপ্ট হয়ে গেলে, রিপোর্টিং ডেটা অভ্যন্তরীণভাবে টিকে থাকে। OutcomeReceiver.onResult() কলব্যাক একটি AdSelectionOutcome ফেরত দেয় যাতে থাকে:

  • URI : যদি কোনও বিজয়ী সুরক্ষিত দর্শক বিজ্ঞাপন থাকে, তাহলে বিজয়ী বিজ্ঞাপনের জন্য একটি বিজ্ঞাপন রেন্ডার URL ফেরত পাঠানো হয়। যদি কোনও সুরক্ষিত দর্শক বিজয়ী না থাকে, তাহলে `Uri.EMPTY ফেরত পাঠানো হয়।
  • adSelectionId : এই সার্ভার নিলাম পরিচালনার সাথে সম্পর্কিত adSelectionId

ত্রুটি, ব্যতিক্রম এবং ব্যর্থতা পরিচালনা

যদি অবৈধ আর্গুমেন্ট, টাইমআউট, অথবা অতিরিক্ত রিসোর্স ব্যবহারের মতো কারণে বিজ্ঞাপন নির্বাচন ডেটা জেনারেশন সফলভাবে সম্পন্ন না হয়, তাহলে OutcomeReceiver.onError() কলব্যাক নিম্নলিখিত আচরণ সহ একটি AdServicesException প্রদান করে:

  1. যদি getAdSelectionData অবৈধ আর্গুমেন্ট দিয়ে শুরু করা হয়, তাহলে AdServicesException একটি IllegalArgumentException কারণ হিসেবে নির্দেশ করে।
  2. অন্য সকল ত্রুটির জন্য একটি AdServicesException পাওয়া যায় যার কারণ হিসেবে একটি IllegalStateException থাকে।

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

adSelectionData এনক্রিপ্ট করা হয় যাতে নিশ্চিত করা যায় যে ট্রানজিটে থাকা ডেটা শুধুমাত্র PPAPI এবং বিশ্বস্ত সার্ভারগুলিতে অ্যাক্সেসযোগ্য।

এনক্রিপশন থাকা সত্ত্বেও, adSelectionData আকারের কারণে ডেটা লিকেজ হতে পারে। adSelectionData আকার নিম্নলিখিত কারণে পরিবর্তিত হতে পারে:

  1. ডিভাইসে উপস্থিত CustomAudience ডেটাতে পরিবর্তন।
  2. CustomAudience ফিল্টারিং লজিকে পরিবর্তন।
  3. getAdSelectionData কলের ইনপুটে পরিবর্তন।

১-বিট লিক আলোচনায় উল্লেখিত ক্রস-অ্যাপ আইডেন্টিফায়ার তৈরির জন্য adSelectionData আকার পরিবর্তন ব্যবহার করা যেতে পারে। ১-বিট লিক-এর ক্ষেত্রে প্রযোজ্য অনেক প্রশমন এখানেও প্রযোজ্য।

এই লিকগুলি পরিচালনা করার জন্য, আমরা getAdSelectionData API-তে সমস্ত কলের জন্য একই adSelectionData তৈরি করার পরিকল্পনা করছি। প্রাথমিক রিলিজে, ডিভাইসের সমস্ত CustomAudiences adSelectionData তৈরির জন্য ব্যবহার করা হয় এবং আকারের তারতম্যগুলি মাস্ক করার জন্য এনক্রিপ্ট করা পেলোড প্যাড করা হবে। আমরা adSelectionData তৈরির উপর GetAdSelectionData ইনপুট প্যারামিটারের প্রভাবও সীমিত করব।

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

আকার অপ্টিমাইজেশন

বিজ্ঞাপন প্রযুক্তি ক্লায়েন্ট SDK থেকে adSelectionData এর এনক্রিপ্ট করা বাইটগুলিকে বিজ্ঞাপন প্রযুক্তি সার্ভারে করা HTTP PUT/POST প্রাসঙ্গিক কলে প্যাকেজ করা হবে বলে আশা করা হচ্ছে। রাউন্ড-ট্রিপ সময় বিলম্ব এবং খরচ কমানোর জন্য, ইউটিলিটি প্রভাবিত না করে adSelectionData আকার যতটা সম্ভব কমানো প্রয়োজন।

আমরা adSelectionData আকার কমাতে আসন্ন রিলিজগুলিতে নিম্নলিখিত অপ্টিমাইজেশনগুলি অন্বেষণ এবং সম্ভাব্যভাবে প্রবর্তনের পরিকল্পনা করছি:

  1. প্যাডিং সহ নির্দিষ্ট বালতি আকারের সেটে পেলোড তৈরি করা : আকারের তারতম্য থেকে লিকেজ কমাতে এবং কম পেলোডের সুযোগ করে দিতে, আমরা জেনারেট করা পেলোডের জন্য স্থির আকারের বাকেটিং ব্যবহার করার পরামর্শ দিচ্ছি। উদাহরণস্বরূপ, বালতির সংখ্যা কম রাখলে, getAdSelectionData তে প্রতি কলে 3 বিটেরও কম এনট্রপি লিক হবে।

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

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

    এই কনফিগারেশনটি প্রতিটি getAdSelectionData অনুরোধের জন্য তৈরি adSelectionData তে ক্রেতার অবদান মূল্যায়ন করতে ব্যবহার করা হবে।

    ক্রেতা পেলোড কনফিগারেশন ক্রেতাদের নির্দিষ্ট করার অনুমতি দেবে:

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

    ক্রেতা কনফিগারেশনের মতোই, প্রতি-বিক্রেতা কনফিগারেশন বিক্রেতাদের নিলামে কোন ক্রেতাদের দেখতে চান তা নির্দিষ্ট করার এবং পেলোডের আকারে প্রতি ক্রেতার অবদানের সীমা নির্দিষ্ট করার অনুমতি দেবে।

    বিক্রেতা নিলাম কনফিগারেশন বিক্রেতাদের নির্দিষ্ট করার অনুমতি দেবে:

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

    1. কাস্টম অডিয়েন্স অগ্রাধিকার নির্দিষ্ট করুন : ক্রেতাদের একটি কাস্টম অডিয়েন্সে একটি অগ্রাধিকার মান নির্দিষ্ট করার অনুমতি দিন। priority ক্ষেত্রটি কাস্টম অডিয়েন্স সনাক্ত করতে ব্যবহৃত হবে যা নিলামে অন্তর্ভুক্ত করা উচিত যদি ক্রেতা কাস্টম অডিয়েন্সের সেট প্রতি-বিক্রেতা বা প্রতি-ক্রেতার আকারের সীমা অতিক্রম করে। একটি কাস্টম অডিয়েন্সে একটি অনির্দিষ্ট অগ্রাধিকার মান ডিফল্ট 0.0 হবে।
  5. পেলোড ডেটা পরিবর্তন

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

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

লেটেন্সি অপ্টিমাইজেশন

সার্ভার নিলামের জন্য প্রয়োজনীয় স্তরের ইউটিলিটি পেতে, আমাদের নিশ্চিত করতে হবে যে getAdSelectionData API এবং persistAdSelectionResult API-এর প্রতি কলে কম ল্যাটেন্সি আছে। যদিও আমরা ২০২৩ সালে API-এর জন্য বৈশিষ্ট্য সমর্থন প্রদানের লক্ষ্য রাখি, আমাদের পরবর্তী প্রকাশনা API-এর জন্য ল্যাটেন্সি বেঞ্চমার্ক এবং অপ্টিমাইজেশনের উপর ফোকাস করবে।

গ্রহণযোগ্য সীমার মধ্যে বিলম্বিতা বজায় রাখার জন্য আমরা নিম্নলিখিত কৌশলগুলি অন্বেষণ করছি:

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

    এর জন্য প্ল্যাটফর্মটিকে কাস্টম দর্শক আপডেটগুলি পর্যবেক্ষণ করার জন্য একটি ব্যবস্থা তৈরি করতে হবে এবং আপডেটগুলির উপর ভিত্তি করে পূর্ব-উত্পাদিত সুরক্ষিত দর্শক ডেটা সংশোধন করতে হবে। প্ল্যাটফর্মটিকে কাস্টম দর্শক আপডেট এবং সার্ভার নিলামের জন্য তৈরি করা adSelectionData `-এর পরিবর্তন দেখার মধ্যে বিজ্ঞাপন প্রযুক্তি যে রেস বিলম্ব আশা করতে পারে তার উপর SLO ঘোষণা করতে হবে।

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

    সুরক্ষিত দর্শকের ডেটা প্রাক-উত্পাদিত করার পরে এর উপর ভিত্তি করে হবে

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

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

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

    getAdSelectionData তে পরবর্তী কলগুলির জন্য, কলার adSelectionData জেনারেশনের জন্য ব্যবহৃত প্রাক-গণিত পেলোডের রেফারেন্স প্রদান করতে পারে।

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

অপব্যবহার প্রশমন এবং সনাক্তকরণ

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

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

প্রশমন

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

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

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

ক্ষতিকারক সত্তার সনাক্তকরণ

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

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