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

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

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

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

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

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

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

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

ویژگی های پشتیبانی شده برای مزایده سرور

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

	مزایده روی دستگاه		مزایده سرور
	پیش نمایش توسعه دهنده	بتا	پیش نمایش توسعه دهنده	بتا
گزارش پیروزی در سطح رویداد	Q1 '23	Q3 '23	N/A	Q4 '23
میانجی گری آبشار	Q1 '23	Q4 '23	N/A	Q1 24
فیلتر درب فرکانس	Q2 '23	Q3 '23	N/A	Q4 '23
تبلیغات متنی را برای فیلتر کردن به گردش کار انتخاب آگهی ارسال کنید	Q2 '23	Q1 '24	N/A	N/A
گزارش تعامل	Q2 '23	Q3 '23	N/A	Q4 '23
به هیئت مخاطبان سفارشی بپیوندید	Q3 '23	Q4 '23	N/A	Q4 '23
صورت‌حساب غیر CPM	Q3 '23	Q4 '23
اشکال زدایی گزارش دهی	Q3 '23	Q4 '23	Q3 '23	Q4 '23
میانجیگری مناقصه باز	N/A	N/A	N/A	Q1 '24
فیلتر کردن تبلیغات نصب برنامه	Q2 '23	Q1 '24	N/A	Q1 '24
مدیریت ارز	N/A	N/A	N/A	Q1 '24
ادغام K-anon	N/A	Q1 '24	N/A	Q1 '24
ادغام تجمیع خصوصی	N/A	N/A	N/A	Q3 '24

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

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

داده ها را برای مزایده سرور جمع آوری و رمزگذاری کنید

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

برای دسترسی به API، دسترسی به 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. اگر تنظیم شود، این باید با طرح، نام میزبان، و پورت URL هماهنگ‌کننده که هنگام استقرار سرور B&A فروشنده پیکربندی شده است، برابر باشد.
   2. هماهنگ کننده باید به لیست هماهنگ کننده های تایید شده تعلق داشته باشد:

      ارائه دهنده	URI	منبع URI	پیش فرض
      Google Cloud	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 به عنوان نتیجه API getAdSelectionData ایجاد می شود. این شامل موارد زیر است:

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

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

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

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

API PersistAdSelectionResult

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

برای دسترسی به API، تماس‌گیرنده باید دسترسی به 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 : نتیجه مزایده رمزگذاری شده ایجاد شده توسط سرور Bidding and Auction که تماس گیرنده می خواهد رمزگشایی کند.

پاسخ AdSelectionOutcome

اگر برنده مخاطب محافظت‌شده وجود داشته باشد، 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 را می توان برای ایجاد شناسه بین برنامه ای همانطور که در بحث نشت 1 بیتی ذکر شد استفاده کرد. بسیاری از اقدامات کاهشی قابل اعمال برای نشت 1 بیتی نیز در اینجا قابل اجرا هستند.

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

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

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

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

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

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

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

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

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

   پیکربندی محموله خریدار به خریداران اجازه می دهد تا مشخص کنند:

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

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

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

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

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

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

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

5. تغییرات داده های بار

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

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

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

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

ما در حال بررسی راهبردهای زیر برای حفظ تأخیر در محدوده قابل قبول هستیم:

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

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

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

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

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

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

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

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

   برای تماس‌های بعدی با getAdSelectionData ، تماس‌گیرنده می‌تواند ارجاع به بار از پیش محاسبه‌شده برای تولید adSelectionData ارائه دهد.

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

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

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

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

کاهش

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

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

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

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

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

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