یکپارچه سازی و بهینه سازی خدمات مناقصه و مزایده، یکپارچه سازی و بهینه سازی خدمات مناقصه و مزایده

طرح پیشنهادی خدمات مناقصه و مزایده برای اندروید ، جزئیات اجرا و جریان داده‌های مربوط به مزایده‌های در حال اجرا در اندروید را با استفاده از سرور مناقصه و مزایده مورد اعتماد شرح می‌دهد. برای اطمینان از اینکه داده‌های در حال انتقال فقط توسط APIهای حافظ حریم خصوصی و سرورهای مورد اعتماد مدیریت می‌شوند، داده‌ها بین کلاینت و سرور با استفاده از رمزگذاری کلید عمومی ترکیبی دو طرفه رمزگذاری می‌شوند.

برای اجرای حراج همانطور که قبلاً توضیح داده شد، فروشنده باید مراحل زیر را در دستگاه خود انجام دهد:

1. جمع‌آوری و رمزگذاری داده‌ها برای حراج سرور
2. ارسال درخواست به سرویس فروشندگان غیر قابل اعتماد
3. دریافت پاسخ از یک سرویس فروشنده غیر قابل اعتماد
4. پاسخ حراج مخاطبان محافظت‌شده را رمزگشایی کنید و نتیجه حراج را دریافت کنید

Protected Audience دو API جدید را برای پشتیبانی از اجرای مزایده‌های سرور معرفی می‌کند:

1. رابط برنامه‌نویسی کاربردی getAdSelectionData داده‌ها را برای حراج سرور جمع‌آوری می‌کند و یک payload رمزگذاری‌شده حاوی داده‌های حراج تولید می‌کند. سرور Bidding and Auction از این payload برای اجرای حراج، تولید نتیجه حراج و بازگرداندن نتیجه حراج استفاده می‌کند.
2. مشتریان فناوری تبلیغات روی دستگاه می‌توانند API مربوط به persistAdSelectionResult را فراخوانی کنند تا نتیجه تولید شده توسط مزایده سرور را رمزگشایی کرده و URL رندر تبلیغ برنده را دریافت کنند.

فناوری تبلیغات فروشنده روی دستگاه باید موارد زیر را برای اجرای حراج ادغام و ایجاد کند:

1. جمع‌آوری و رمزگذاری داده‌ها برای حراج سرور فروشنده : تکنسین تبلیغات باید API getAdSelectionData را برای دریافت محتوای رمزگذاری‌شده فراخوانی کند.
2. ارسال درخواست به سرویس فروشنده غیر قابل اعتماد ارسال : یک درخواست HTTP POST یا PUT حاوی بار داده رمزگذاری شده تولید شده توسط API getAdSelectionData به سرویس فروشنده غیر قابل اعتماد آنها و داده‌های مورد نیاز سرویس فروشنده غیر قابل اعتماد برای تولید نتایج زمینه‌ای.
3. دریافت پاسخ از سرویس فروشنده غیر قابل اعتماد : پاسخ از سرویس فروشنده غیر قابل اعتماد شامل نتیجه حراج مخاطبان رمزگذاری شده و محافظت شده و نتیجه حراج زمینه‌ای خواهد بود.
4. رمزگشایی پاسخ حراج مخاطبان محافظت‌شده و دریافت نتیجه حراج: برای رمزگشایی نتیجه حراج مخاطبان محافظت‌شده، تکنسین تبلیغات فروشنده باید API persistAdSelectionResult را فراخوانی کند. نتیجه تولید شده توسط persistAdSelectionResult به تکنسین‌های تبلیغات کمک می‌کند تا تعیین کنند که آیا تبلیغ زمینه‌ای یا تبلیغ مخاطبان محافظت‌شده در حراج برنده شده است و در صورت لزوم، URI تبلیغ مخاطبان محافظت‌شده برنده را دریافت کنند.

ویژگی‌های پشتیبانی‌شده برای حراج سرور

هدف ما پشتیبانی از تمام ویژگی‌هایی است که برای حراج روی دستگاه در دسترس هستند. جدول زمانی پشتیبانی از این ویژگی‌ها در حراج سرور به شرح زیر است:

اجرای مزایده‌های سرور با استفاده از APIهای مخاطب محافظت‌شده

در بخش پیش‌نمایش توسعه‌دهندگان، AdSelectionManager دو API جدید را معرفی می‌کند: getAdSelectionData و persistAdSelectionResult . این APIها به SDKهای فناوری تبلیغات اجازه می‌دهند تا با سرورهای Bidding و Auction ادغام شوند.

جمع‌آوری و رمزگذاری داده‌ها برای حراج سرور

رابط برنامه‌نویسی کاربردی getAdSelectionData ورودی‌های مورد نیاز برای کامپوننت‌های Bidding و Auction مانند BuyerInput و ProtectedAudienceInput را تولید می‌کند و قبل از اینکه نتیجه را در اختیار فراخواننده قرار دهد، داده‌ها را رمزگذاری می‌کند. برای جلوگیری از نشت داده‌ها در برنامه‌ها، این داده‌ها حاوی اطلاعات همه خریداران حاضر در دستگاه هستند. اطلاعات بیشتر در مورد این تصمیم را در بخش ملاحظات حریم خصوصی و راهکارهای بهینه‌سازی آن را در بخش ملاحظات اندازه مطالعه کنید.

برای دسترسی به API، دسترسی به Protected Audience API باید فعال باشد و مجوز ACCESS_ADSERVICES_CUSTOM_AUDIENCE باید در مانیفست فراخواننده تعریف شده باشد.

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

درخواست GetAdSelectionData

1. تماس‌گیرنده باید فیلد seller را در درخواست تنظیم کند، زیرا این فیلد برای اجرای بررسی‌های ثبت‌نام قبل از ارائه درخواست استفاده می‌شود.
2. فیلد coordinatorOriginUri اختیاری است.
   1. در صورت تنظیم، این باید برابر با طرح، نام میزبان و پورت URL هماهنگ‌کننده باشد که هنگام استقرار سرور B&A فروشنده پیکربندی شده است.
   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 ترکیب می‌شوند. سپس شیء payload نهایی با استفاده از رمزگذاری کلید عمومی ترکیبی دو طرفه رمزگذاری می‌شود.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome به عنوان خروجی API مربوط به getAdSelectionData تولید می‌شود و شامل موارد زیر است:

1. adSelectionId : یک عدد صحیح مبهم برای شناسایی این فراخوانی getAdSelectionData . کلاینت فناوری تبلیغات باید این مقدار adSelectionId را حفظ کند زیرا به عنوان اشاره‌گری به فراخوانی getAdSelectionData عمل می‌کند. این شناسه توسط API persistAdSelectionResult برای رمزگشایی نتیجه حراج از سرور Bidding and Auction مورد نیاز است و همچنین توسط APIهای reportImpression و reportEvent مورد نیاز است.
2. adSelectionData : این داده‌های حراج رمزگذاری شده‌ای است که توسط سرور Bidding and Auction برای اجرای حراج‌ها مورد نیاز است. این متد شامل موارد زیر است:
   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 موجود در دستگاه مسئول رمزگذاری این داده‌ها است. توصیه می‌شود از یک راه‌حل کارآمد در فضا مانند ارسال درخواست به سرویس تبلیغاتی فروشنده به صورت multipart/form-data استفاده شود.

دریافت پاسخ از یک سرویس فروشنده‌ی نامعتبر

همانطور که در توضیح سرور مناقصه و مزایده توضیح داده شده است، هنگامی که سرویس فروشنده غیر قابل اعتماد درخواست را دریافت می‌کند، برای تبلیغات زمینه‌ای با خریداران شریک تماس می‌گیرد.

سرویس فروشنده‌ی نامعتبر adSelectionData و AuctionConfig رمزگذاری‌شده را به سرویس SellerFrontEnd سرور Bidding and Auction که در یک TEE اجرا می‌شود، ارسال می‌کند.

وقتی حراج مخاطب محافظت‌شده کامل شد، سرویس SellerFrontEnd نتیجه حراج را رمزگذاری می‌کند و آن را به عنوان پاسخی به سرویس فروشنده غیرقابل اعتماد برمی‌گرداند.

سرویس فروشنده‌ی نامعتبر، پاسخی حاوی آگهی متنی و/یا نتیجه‌ی حراج رمزگذاری‌شده‌ی مخاطب محافظت‌شده را به دستگاه ارسال می‌کند.

با دریافت پاسخ، کد فناوری تبلیغات فروشنده در دستگاه می‌تواند فقط از تبلیغ متنی در پاسخ استفاده کند یا اگر تشخیص دهد که دریافت نتیجه مخاطب محافظت‌شده ارزش افزوده‌ای دارد، می‌تواند با فراخوانی API PersistAdSelectionResult ، نتیجه مخاطب محافظت‌شده را رمزگشایی کند.

API مربوط به PersistAdSelectionResult

برای رمزگشایی نتیجه‌ی مخاطب محافظت‌شده، فروشنده‌ی تبلیغات می‌تواند دومین API مخاطب محافظت‌شده persistAdSelectionResult را فراخوانی کند. این API نتیجه را رمزگشایی کرده و یک AdSelectionOutcome برمی‌گرداند، همان شیء‌ای که امروز از یک حراج روی دستگاه برگردانده شده است.

برای دسترسی به API، فراخواننده باید دسترسی به Protected Audience API را فعال کند و مجوز ACCESS_ADSERVICES_CUSTOM_AUDIENCE را در مانیفست خود تعریف کند .

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

درخواست نتیجه‌ی انتخاب تبلیغات ماندگار

تماس گیرنده باید موارد زیر را در درخواست تنظیم کند:

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 برای تولید شناسه بین برنامه‌ای استفاده کرد. بسیاری از راهکارهای کاهش نشت ۱ بیتی در اینجا نیز قابل اجرا هستند.

برای مدیریت این نشت‌ها، ما قصد داریم adSelectionData یکسانی را برای همه فراخوانی‌های getAdSelectionData API تولید کنیم. در نسخه‌های اولیه، از تمام CustomAudiences موجود در دستگاه برای ایجاد adSelectionData استفاده می‌شود و payload رمزگذاری شده برای پوشاندن تغییرات اندازه، تقویت خواهد شد. ما همچنین تأثیر پارامترهای ورودی GetAdSelectionData را بر adSelectionData تولید شده محدود خواهیم کرد.

با این حال، تولید adSelectionData یکسان برای همه تکنسین‌های تبلیغات با استفاده از تمام داده‌های حراج روی دستگاه، بار داده بزرگی ایجاد می‌کند که اکنون باید در هر فراخوانی به سرور تکنسین تبلیغات منتقل شود. استفاده از همه مخاطبان سفارشی روی دستگاه برای تولید بار داده حراج، اکوسیستم را در معرض سوءاستفاده از سوی نهادهای مخرب نیز قرار می‌دهد. ما این نگرانی‌ها را در بخش‌های بهینه‌سازی اندازه و کاهش سوءاستفاده پوشش داده‌ایم.

بهینه‌سازی اندازه

انتظار می‌رود SDK کلاینت فناوری تبلیغات، بایت‌های رمزگذاری‌شده‌ی adSelectionData را در فراخوانی متنی HTTP PUT/POST که به سرور فناوری تبلیغات ارسال می‌شود، بسته‌بندی کند. برای کاهش تأخیر و هزینه‌ی رفت و برگشت، لازم است اندازه‌ی adSelectionData تا حد امکان کاهش یابد، در حالی که بر کارایی آن تأثیری نگذارد.

ما قصد داریم در نسخه‌های آینده بهینه‌سازی‌های زیر را بررسی و به‌طور بالقوه معرفی کنیم تا اندازه adSelectionData کاهش دهیم:

1. تولید بار مفید در مجموعه‌ای ثابت از اندازه‌های سطل با padding : برای به حداقل رساندن نشت ناشی از تغییرات اندازه و در عین حال امکان استفاده از بارهای مفید کمتر، پیشنهاد می‌کنیم از bucketing با اندازه ثابت برای بار مفید تولید شده استفاده کنید. کوچک نگه داشتن تعداد سطل‌ها، به عنوان مثال، ۷، منجر به کمتر از ۳ بیت آنتروپی نشت شده در هر فراخوانی getAdSelectionData خواهد شد.

   اگر داده‌های روی دستگاه از حداکثر اندازه سطل تجاوز کند، از استراتژی‌هایی مانند مقادیر اولویت برای تصمیم‌گیری در مورد اینکه کدام داده‌ها حذف شوند، استفاده می‌شود.

2. پیکربندی خریدار : ما در حال ارزیابی امکان‌سنجی این هستیم که به خریداران اجازه دهیم پیکربندی payload را برای هر خریدار تنظیم کنند. این پیکربندی برای شناسایی مزایده‌هایی که یک خریدار علاقه‌مند به پیوستن به آنهاست، مفید خواهد بود. در صورت امکان، در طول ثبت‌نام، یک تکنسین تبلیغات خریدار می‌تواند یک نقطه پایانی را ثبت کند که از آن Protected Audience پیکربندی payload را با ریتم منظم روزانه دریافت کند. از طرف دیگر، APIهای حفظ حریم خصوصی، API را در معرض نمایش قرار می‌دهند تا به تکنسین‌های تبلیغات خریدار اجازه دهند این نقطه پایانی را ثبت کنند.

   این پیکربندی سپس برای ارزیابی سهم خریدار در adSelectionData تولید شده برای هر درخواست getAdSelectionData استفاده می‌شود.

   پیکربندی payload خریدار به خریداران اجازه می‌دهد موارد زیر را مشخص کنند:

   1. فهرست فروشندگان مجاز : مخاطبان سفارشی خریدار تنها در صورتی به payload اضافه می‌شوند که فراخوانی getAdSelectionData توسط فروشنده‌ای در فهرست مجاز آغاز شود. ما پیکربندی payload را به صورت روزانه دریافت می‌کنیم تا فهرست مجاز به‌روز بماند.
   2. محدودیت اندازه هر فروشنده : خریدار می‌تواند محدودیت اندازه هر فروشنده را برای تعیین اندازه داده‌ای که باید هنگام شروع حراج توسط یک فروشنده خاص در payload ارسال شود، تعیین کند. این امر در صورتی مفید خواهد بود که خریدار بخواهد منابع بیشتری را برای پردازش داده‌های حراج از فروشندگان خاص اختصاص دهد. SellerFrontendService فقط داده‌های خاص خریدار را به هر BuyerFrontendService ارسال می‌کند. بنابراین، با تعریف محدودیت اندازه هر فروشنده، یک خریدار می‌تواند به صراحت میزان داده‌های دریافتی و پردازش شده توسط BuyerFrontendService سرور Bidding and Auction خود را برای حراج‌هایی که توسط یک فروشنده اجرا می‌شود، کنترل کند.

3. پیکربندی فروشنده : ما در حال ارزیابی امکان‌سنجی پیکربندی حراج برای هر فروشنده هستیم که به فروشندگان اجازه می‌دهد پارامترهای حراج را برای کنترل اندازه بار مفید و شرکت‌کنندگان حراج تعریف کنند. در صورت امکان، در طول ثبت‌نام، تکنسین تبلیغات فروشنده می‌تواند نقطه پایانی را مشخص کند که از آنجا Protected Audience می‌تواند پیکربندی حراج برای هر فروشنده را با یک ریتم منظم دریافت کند. سپس از این پیکربندی برای تعیین ترکیب و محدودیت‌های adSelectionData تولید شده برای هر درخواست getAdSelectionData استفاده می‌شود.

   مشابه پیکربندی خریدار، پیکربندی هر فروشنده به فروشندگان این امکان را می‌دهد که مشخص کنند انتظار دارند کدام مجموعه از خریداران را در یک حراج ببینند و محدودیت‌هایی را برای سهم هر خریدار در اندازه بار مفید تعیین کنند.

   پیکربندی حراج فروشنده به فروشندگان اجازه می‌دهد موارد زیر را مشخص کنند:

   1. فهرست خریداران مجاز : برای مزایده‌هایی که توسط فروشنده‌ی مشخص آغاز می‌شوند، فقط خریداران موجود در فهرست مجاز می‌توانند مخاطبان سفارشی (CustomAudiences) را برای مزایده ارائه دهند. پیکربندی مزایده باید روزانه به‌روزرسانی شود تا فهرست مجاز با فهرست مجاز خریداران سمت سرور به‌روز باشد.
   2. محدودیت اندازه هر خریدار : فروشندگان می‌توانند برای تنظیم اندازه داده‌های آپلود شده توسط هر خریدار در payload ارسالی به SellerFrontendService، محدودیتی برای هر خریدار تعیین کنند. اگر خریدار از محدودیت اندازه هر خریدار تجاوز کند، اولویت CustomAudience که در پیکربندی payload خریدار تنظیم شده است، برای دریافت داده‌ها در محدوده مورد انتظار استفاده می‌شود.
   3. اولویت هر خریدار : به فروشندگان اجازه دهید اولویت هر خریدار را تعیین کنند. اولویت خریدار برای شناسایی اینکه داده‌های کدام خریدار باید در محموله نگهداری شود، در صورتی که اندازه محموله از حد مجاز بیشتر شود، استفاده می‌شود.
   4. محدودیت حداکثر اندازه برای بار مفید : فروشندگان مختلف ممکن است تخصیص منابع متفاوتی داشته باشند و ممکن است بخواهند حداکثر اندازه را برای بار مفید حراج به ازای هر درخواست تعیین کنند. محدودیت حداکثر اندازه، اندازه ثابت تعیین شده توسط API مخاطب محافظت شده را رعایت می‌کند.

4. تغییرات سفارشی مخاطبان

   1. اولویت مخاطب سفارشی را مشخص کنید : به خریداران اجازه دهید یک مقدار اولویت را در یک مخاطب سفارشی مشخص کنند. فیلد priority برای شناسایی مخاطبان سفارشی استفاده می‌شود که اگر مجموعه مخاطبان سفارشی خریدار از محدودیت‌های اندازه هر فروشنده یا هر خریدار تجاوز کند، باید در حراج گنجانده شوند. مقدار اولویت نامشخص در یک مخاطب سفارشی به طور پیش‌فرض 0.0 است.

5. تغییرات داده‌های بار مفید

   1. کاهش داده‌های ارسالی در بار داده : همانطور که در بهینه‌سازی بار داده سرویس‌های مزایده و مناقصه توضیح داده شده است، بار داده بالاتر توسط داده‌های ads مخاطبان سفارشی، سیگنال‌های مزایده کاربر و سیگنال‌های اندروید هدایت می‌شود. بار داده بالاتر را می‌توان با موارد زیر کاهش داد:
      1. اینکه کلاینت شناسه‌های رندر تبلیغ را (به جای اشیاء تبلیغ) در فایل ارسال کند.
      2. کلاینت هیچ داده تبلیغاتی در payload ارسال نمی‌کند.
      3. عدم ارسال سیگنال‌های پیشنهاد قیمت کاربر در payload کلاینت.

اگرچه این استراتژی‌ها به تکنسین‌های تبلیغات اجازه می‌دهند پیکربندی‌هایی را برای مدیریت ترکیب و محدودیت‌های بار adSelectionData تعریف کنند، اما می‌توانند با تغییر پارامترهای پیکربندی، به عاملی برای تعدیل اندازه adSelectionData نیز تبدیل شوند. برای جلوگیری از این امر، پیکربندی روزانه توسط Protected Audience از نقطه پایانی پیکربندی شده دریافت می‌شود.

بهینه‌سازی تأخیر

برای اینکه مزایده‌های سرور از سطح مطلوبی از کاربرد برخوردار باشند، باید مطمئن شویم که APIهای getAdSelectionData و persistAdSelectionResult تأخیر کمی در هر فراخوانی دارند. در حالی که هدف ما ارائه پشتیبانی از ویژگی‌ها برای APIها در سال 2023 است، نسخه بعدی ما بر معیارهای تأخیر و بهینه‌سازی APIها تمرکز خواهد داشت.

ما در حال بررسی استراتژی‌های زیر هستیم تا تأخیر را در محدوده قابل قبول نگه داریم:

1. پیش‌تولید داده‌های مخاطب محافظت‌شده برای هر فروشنده : از آنجایی که پیکربندی حراج فروشنده و پیکربندی بار داده خریدار برای مدت زمان قابل توجهی (روزانه) پایدار خواهد بود، پلتفرم می‌تواند داده‌های مخاطب محافظت‌شده واجد شرایط را از قبل محاسبه و ذخیره کند.

   این امر مستلزم آن است که پلتفرم مکانیزمی برای نظارت بر به‌روزرسانی‌های سفارشی مخاطبان و اصلاح داده‌های از پیش تولید شده‌ی مخاطبان محافظت‌شده بر اساس به‌روزرسانی‌ها ایجاد کند. این پلتفرم همچنین باید SLOها را در مورد تأخیر رقابتی که فناوری تبلیغات می‌تواند بین به‌روزرسانی‌های سفارشی مخاطبان و مشاهده‌ی تغییر در adSelectionData تولید شده برای حراج سرور انتظار داشته باشد، اعلام کند.

   از آنجایی که یک دستگاه، یک مدل محاسباتی با منابع محدود و اولویت‌های پردازشی متغیر ارائه می‌دهد، ما معتقدیم که ارائه این امکانات پیش از تولید باید با قابلیت اطمینان بالا و تضمین SLO همراه باشد.

   پیش‌تولید داده‌های مخاطب محافظت‌شده بر اساس موارد زیر خواهد بود:

   1. فروشنده برای تولید اولیه داده‌های مخاطب محافظت‌شده، اعلام آمادگی می‌کند.
   2. خریدارانی که واجد شرایط شرکت در حراجی هستند که توسط یک فروشنده خاص آغاز شده است.
   3. شناسایی مخاطبان سفارشی به ازای هر خریدار که بخشی از محتوای تبلیغ بر اساس موارد زیر خواهد بود:
      1. محدودیت‌های اندازه هر خریدار، اولویت هر خریدار و محدودیت‌های حداکثر اندازه که در پیکربندی فروشنده تعریف شده‌اند،
      2. محدودیت اندازه هر فروشنده، اولویت مخاطبان سفارشی در پیکربندی خریدار تعریف شده است.

2. اعمال مشتاقانه فیلترینگ منفی : در صورت تمایل فروشنده، پلتفرم می‌تواند با تولید اولیه داده‌های Protected Audience و اعمال فیلترینگ منفی در فراخوانی حیاتی getAdSelectionData adSelectionData را از قبل محاسبه کند. این امر به فروشندگان اجازه می‌دهد تا ضمن پذیرش بی‌ثباتی در فیلترینگ منفی، کاهش تأخیر را متعادل کنند.

   این پلتفرم می‌تواند این پشتیبانی را با ارائه یک گزینه پیش‌فرض در پیکربندی فروشنده با محدودیت ماندگاری و یک گزینه لغو در getAdSelectionData فراهم کند تا در صورت نیاز، امکان محاسبه تازه‌ترین محاسبات فراهم شود. از طرف دیگر، پلتفرم می‌تواند یک API مقداردهی اولیه اضافی ارائه دهد که قبل از getAdSelectionData برای گرم کردن حراج فراخوانی شود.

3. محاسبه‌ی بار مفید برای چندین مزایده : در سناریوهای خاص، ممکن است ترجیح داده شود که یک API با عملکرد تأخیری بالا داشته باشید، هرچند که این کار به قیمت افزایش زمان از دست رفته‌ی داده‌ها تمام می‌شود. برای فراهم کردن این امکان، پلتفرم می‌تواند یک API مقداردهی اولیه برای محاسبه‌ی کل بار مفید معرفی کند و مرجعی از بار مفید محاسبه‌شده را در اختیار فراخوانی‌کننده قرار دهد.

   برای فراخوانی‌های بعدی getAdSelectionData ، فراخوانی‌کننده می‌تواند به payload از پیش محاسبه‌شده‌ای که قرار است برای تولید adSelectionData استفاده شود، ارجاع دهد.

این سه استراتژی در مرحله‌ی اکتشاف اولیه هستند و هدفشان توصیف مسیری است که پلتفرم ممکن است برای بهینه‌سازی تأخیر در پیش بگیرد. با بررسی دقیق‌تر پروفایل‌های تأخیر API و الزامات فناوری تبلیغات، به پیشنهاد استراتژی‌های اضافی ادامه خواهیم داد.

کاهش و شناسایی سوءاستفاده

همانطور که در ملاحظات حریم خصوصی ذکر شد، adSelectionData با استفاده از تمام داده‌های خریدار موجود در دستگاه تولید می‌شود.

با این حال، اگر تمام داده‌های خریدار روی دستگاه برای تولید خروجی adSelectionData استفاده شود، یک نهاد مخرب می‌تواند خود را به عنوان خریدار جا بزند و داده‌های خریدار جعلی ایجاد کند تا عملکرد اندروید را کاهش دهد، حجم داده را افزایش دهد تا هزینه اجرای مزایده یا پیشنهاد قیمت برای یک فناوری تبلیغاتی افزایش یابد و غیره.

کاهش خطر

برخی از اقدامات ذکر شده در بخش ملاحظات اندازه، مانند پیکربندی محموله خریدار شامل فروشندگان مجاز و پیکربندی حراج فروشنده شامل خریداران مجاز، به حذف داده‌های غیرمنتظره در محموله کمک می‌کند.

سایر اقدامات مربوط به اندازه، مانند اجازه دادن به SSPها برای تعیین اولویت خریدار، قرار دادن سهمیه هر خریدار در payload تولید شده، و تعیین حداکثر اندازه برای هر payload حراج، نیز می‌تواند به کاهش تأثیر افزایش حجم payload مخرب کمک کند. این اقدامات به این منظور در نظر گرفته شده‌اند که به تکنسین‌های تبلیغات اجازه دهند تعریف کنند با کدام یک از شرکت‌های تبلیغاتی همکاری می‌کنند و محدودیت‌های قابل قبولی را برای payload مورد نیاز برای پردازش تعیین کنند.

همانطور که قبلاً ذکر شد، تمام اقدامات کاهش‌دهنده‌ی معرفی‌شده برای جلوگیری از سوءاستفاده و محدودیت‌های اندازه باید ملاحظات حریم خصوصی را رعایت کنند.

شناسایی موجودیت‌های مخرب

اگرچه این اقدامات کاهش‌دهنده از تولید adSelectionData برای مزایده‌های سرور محافظت می‌کنند، اما به شناسایی موجودیت‌های مخرب یا محافظت از پلتفرم در برابر سوءاستفاده‌هایی مانند ایجاد تعداد بی‌سابقه‌ای از مخاطبان سفارشی از یک خریدار کمکی نمی‌کنند.

برای تأیید پایداری و سلامت پلتفرم، باید سازوکاری برای شناسایی موجودیت‌های مخرب، شناسایی مسیرهای سوءاستفاده و شناسایی انگیزه حملات خاص پیدا کنیم. در نسخه‌های بعدی، توضیحاتی در مورد مسیرهای سوءاستفاده بالقوه و محافظت‌های موجود برای مقابله با آنها ارائه خواهیم داد.