سیگنال های برنامه محافظت شده برای پشتیبانی از تبلیغات نصب برنامه مرتبط

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

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

برای مثال، تبلیغ‌کننده‌ای که سعی دارد نصب‌های جدیدی را برای یک اپلیکیشن تحویل غذای موبایلی جدید در ایالات متحده هدایت کند، ممکن است تبلیغات خود را برای کاربرانی که در ایالات متحده هستند و قبلاً با سایر اپلیکیشن‌های تحویل غذا تعامل داشته‌اند، هدف قرار دهد.

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

APIهای زیر برای پشتیبانی از تبلیغات نصب اپلیکیشن مؤثر پیشنهاد شده‌اند که با حذف وابستگی به شناسه‌های کاربری بین‌حزبی، حریم خصوصی کاربر را بهبود می‌بخشند:

1. API سیگنال‌های برنامه محافظت‌شده : این API حول محور ذخیره‌سازی و ایجاد ویژگی‌های مهندسی‌شده توسط فناوری تبلیغات است که نشان‌دهنده علایق بالقوه کاربر است. فناوری‌های تبلیغات، سیگنال‌های رویداد تعریف‌شده برای هر برنامه، مانند نصب برنامه، اولین باز شدن، اقدامات کاربر (سطح‌بندی در بازی، دستاوردها)، فعالیت‌های خرید یا زمان حضور در برنامه را ذخیره می‌کنند. سیگنال‌ها برای محافظت در برابر نشت داده‌ها، روی دستگاه نوشته و ذخیره می‌شوند و فقط در طول یک حراج محافظت‌شده که در یک محیط امن اجرا می‌شود، در دسترس منطق فناوری تبلیغات قرار می‌گیرند که سیگنال داده‌شده را ذخیره کرده است.
2. API انتخاب آگهی : این API یک API برای پیکربندی و اجرای یک حراج محافظت‌شده در یک محیط اجرای قابل اعتماد (TEE) ارائه می‌دهد که در آن تکنسین‌های تبلیغات، نامزدهای تبلیغات را بازیابی می‌کنند، استنتاج را اجرا می‌کنند، پیشنهادات را محاسبه می‌کنند و برای انتخاب یک آگهی "برنده" با استفاده از سیگنال‌های برنامه محافظت‌شده و اطلاعات زمینه‌ای بلادرنگ ارائه شده توسط ناشر، امتیازدهی انجام می‌دهند.

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

• گزینش سیگنال : همزمان با استفاده کاربران از برنامه‌های تلفن همراه، متخصصان تبلیغات با ذخیره رویدادهای برنامه تعریف‌شده توسط متخصصان تبلیغات برای نمایش تبلیغات مرتبط با استفاده از API سیگنال‌های برنامه محافظت‌شده، سیگنال‌ها را گزینش می‌کنند. این رویدادها در فضای ذخیره‌سازی محافظت‌شده روی دستگاه، مشابه مخاطبان سفارشی ، ذخیره می‌شوند و قبل از ارسال به خارج از دستگاه رمزگذاری می‌شوند، به طوری که فقط سرویس‌های مناقصه و مزایده که در محیط‌های اجرای قابل اعتماد با کنترل امنیتی و حریم خصوصی مناسب اجرا می‌شوند، می‌توانند آنها را برای پیشنهاد قیمت و امتیازدهی به تبلیغات رمزگشایی کنند.
• رمزگذاری سیگنال : سیگنال‌ها طبق یک برنامه زمان‌بندی شده توسط منطق فناوری تبلیغات سفارشی آماده می‌شوند. یک کار پس‌زمینه اندروید این منطق را اجرا می‌کند تا رمزگذاری روی دستگاه را انجام دهد و مجموعه‌ای از سیگنال‌های برنامه محافظت‌شده تولید کند که بعداً می‌توانند به صورت بلادرنگ برای انتخاب تبلیغات در طول یک حراج محافظت‌شده استفاده شوند. این مجموعه تا زمان ارسال برای حراج، به طور ایمن روی دستگاه ذخیره می‌شود.
• انتخاب آگهی : برای انتخاب آگهی‌های مرتبط برای کاربر، SDKهای فروشنده یک payload رمزگذاری‌شده از Protected App Signals ارسال می‌کنند و یک حراج محافظت‌شده را پیکربندی می‌کنند. در حراج، منطق سفارشی خریدار، Protected App Signals را به همراه داده‌های زمینه‌ای ارائه شده توسط ناشر (داده‌هایی که معمولاً در یک درخواست آگهی Open-RTB به اشتراک گذاشته می‌شوند) آماده می‌کند تا ویژگی‌های در نظر گرفته شده برای انتخاب آگهی (بازیابی آگهی، استنتاج و تولید پیشنهاد) را مهندسی کند. مشابه Protected Audience ، خریداران آگهی‌ها را برای امتیازدهی نهایی در یک حراج محافظت‌شده به فروشنده ارسال می‌کنند.
  • بازیابی آگهی : خریداران از سیگنال‌های محافظت‌شده برنامه و داده‌های زمینه‌ای ارائه‌شده توسط ناشر برای مهندسی ویژگی‌های مرتبط با علایق کاربر استفاده می‌کنند. این ویژگی‌ها برای تطبیق تبلیغاتی که معیارهای هدف‌گذاری را برآورده می‌کنند، استفاده می‌شوند. تبلیغاتی که در محدوده بودجه نباشند، فیلتر می‌شوند. سپس k آگهی برتر برای پیشنهاد قیمت انتخاب می‌شوند.
  • پیشنهاد قیمت : منطق پیشنهاد قیمت سفارشی خریداران، داده‌های زمینه‌ای ارائه شده توسط ناشر و سیگنال‌های برنامه محافظت‌شده را برای مهندسی ویژگی‌هایی که به عنوان ورودی برای مدل‌های یادگیری ماشین خریدار استفاده می‌شوند، آماده می‌کند تا استنتاج و پیشنهاد قیمت روی تبلیغات کاندید در محدوده‌های قابل اعتماد حفظ حریم خصوصی انجام شود. سپس خریدار تبلیغ انتخابی خود را به فروشنده بازمی‌گرداند.
  • امتیازدهی فروشنده : منطق امتیازدهی سفارشی فروشندگان، تبلیغات ارسال شده توسط خریداران شرکت‌کننده را امتیازدهی می‌کند و یک تبلیغ برنده را برای ارسال به برنامه جهت رندر انتخاب می‌کند.
• گزارش‌دهی : شرکت‌کنندگان در حراج، گزارش‌های برد و باخت مربوطه را دریافت می‌کنند. ما در حال بررسی سازوکارهای حفظ حریم خصوصی برای گنجاندن داده‌ها برای آموزش مدل در گزارش برد هستیم.

گاهشمار

سیگنال‌های برنامه محافظت‌شده را گزینش کنید

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

API سیگنال‌های برنامه محافظت‌شده

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

این مثال یک سیگنال اسکالر و یک سیگنال سری زمانی مرتبط با adtech1.com را نشان می‌دهد:

• یک سیگنال اسکالر با کلید مقدار base64 " A1c " و مقدار " c12Z ". ذخیره سیگنال توسط com.google.android.game_app در تاریخ ۱ ژوئن ۲۰۲۳ فعال شده است.
• فهرستی از سیگنال‌های دارای کلید « dDE » که توسط دو برنامه‌ی مختلف ایجاد شده‌اند.

به تکنسین‌های تبلیغات فضای مشخصی برای ذخیره سیگنال‌ها روی دستگاه اختصاص داده می‌شود. سیگنال‌ها حداکثر TTL مشخصی دارند که باید تعیین شود.

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

API سیگنال‌های برنامه‌ی محافظت‌شده از بخش‌های زیر تشکیل شده است:

• یک API جاوا و جاوا اسکریپت برای اضافه کردن، به‌روزرسانی یا حذف سیگنال‌ها.
• یک API جاوا اسکریپت برای پردازش سیگنال‌های پایدار به منظور آماده‌سازی آنها برای مهندسی بیشتر ویژگی‌ها به صورت بلادرنگ در طول یک حراج محافظت‌شده که در یک محیط اجرای قابل اعتماد ( TEE ) اجرا می‌شود.

اضافه کردن، به‌روزرسانی یا حذف سیگنال‌ها

تکنسین‌های تبلیغات می‌توانند سیگنال‌ها را با استفاده از رابط برنامه‌نویسی کاربردی (API fetchSignalUpdates() اضافه، به‌روزرسانی یا حذف کنند. این API از واگذاری اختیارات مشابه با واگذاری اختیارات سفارشی مخاطبان Protected Audience پشتیبانی می‌کند.

برای افزودن سیگنال، تکنسین‌های تبلیغات خریدار که در برنامه‌ها SDK ندارند، باید با تکنسین‌های تبلیغاتی که در دستگاه حضور دارند، مانند شرکای اندازه‌گیری موبایل (MMP) و پلتفرم‌های سمت عرضه (SSP) همکاری کنند. API سیگنال‌های برنامه محافظت‌شده (Protected App Signals API) با ارائه راه‌حل‌های انعطاف‌پذیر برای مدیریت سیگنال برنامه محافظت‌شده، با فعال کردن فراخوانی‌کنندگان دستگاه برای فراخوانی ایجاد سیگنال برنامه محافظت‌شده از طرف خریداران، از این فناوری‌های تبلیغاتی پشتیبانی می‌کند. این فرآیند واگذاری نامیده می‌شود و از API fetchSignalUpdates() استفاده می‌کند. fetchSignalUpdates() یک URI می‌گیرد و لیستی از به‌روزرسانی‌های سیگنال را بازیابی می‌کند. برای مثال، fetchSignalUpdates() یک درخواست GET به URI داده شده ارسال می‌کند تا لیست به‌روزرسانی‌ها را برای اعمال در ذخیره‌سازی سیگنال محلی بازیابی کند. نقطه پایانی URL، که متعلق به خریدار است، با لیستی از دستورات JSON پاسخ می‌دهد.

دستورات JSON پشتیبانی شده عبارتند از:

• put: یک مقدار اسکالر را برای کلید داده شده وارد یا بازنویسی می‌کند.
• put_if_not_present: اگر مقداری از قبل ذخیره نشده باشد، یک مقدار اسکالر برای کلید داده شده وارد می‌کند. این گزینه می‌تواند برای مثال برای تنظیم یک شناسه آزمایش برای کاربر داده شده و جلوگیری از لغو آن در صورتی که قبلاً توسط برنامه دیگری تنظیم شده باشد، مفید باشد.
• append: یک عنصر به سری زمانی مرتبط با کلید داده شده اضافه می‌کند. پارامتر maxSignals حداکثر تعداد سیگنال‌ها در سری زمانی را مشخص می‌کند. اگر اندازه از حد مجاز بیشتر شود، عناصر قبلی حذف می‌شوند. اگر کلید حاوی یک مقدار اسکالر باشد، به طور خودکار به یک سری زمانی تبدیل می‌شود.
• remove: محتوای مرتبط با کلید داده شده را حذف می‌کند.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

تمام کلیدها و مقادیر به صورت Base64 بیان می‌شوند.

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

سیگنال‌های ذخیره‌شده به‌طور خودکار با برنامه‌ای که درخواست واکشی را انجام می‌دهد و پاسخ‌دهنده درخواست ("سایت" یا "مبدا" یک فناوری تبلیغاتی ثبت‌شده) به علاوه زمان ایجاد درخواست مرتبط می‌شوند. همه سیگنال‌ها منوط به ذخیره شدن از طرف یک فناوری تبلیغاتی ثبت‌شده در Privacy Sandbox هستند، URI "سایت"/"مبدا" باید با داده‌های یک فناوری تبلیغاتی ثبت‌شده مطابقت داشته باشد. اگر فناوری تبلیغاتی درخواست‌کننده ثبت نشده باشد، درخواست رد می‌شود.

سهمیه انبار و تخلیه

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

رمزگذاری روی دستگاه برای انتقال داده

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

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

اگر خریداری رمزگذار سیگنال ثبت نکرده باشد، سیگنال‌ها آماده نمی‌شوند و هیچ یک از سیگنال‌های انتخاب‌شده روی دستگاه به سرویس‌های مزایده و مناقصه ارسال نمی‌شوند.

جزئیات بیشتر در مورد فضای ذخیره‌سازی، حجم بار و سهمیه درخواست‌ها در به‌روزرسانی‌های آینده در دسترس خواهد بود. علاوه بر این، اطلاعات بیشتری در مورد نحوه ارائه توابع سفارشی ارائه خواهیم داد.

گردش کار انتخاب تبلیغ

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

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

روند انتخاب آگهی به شرح زیر است:

1. SDK فروشنده، فایل رمزگذاری شده‌ی سیگنال‌های برنامه‌ی محافظت‌شده را روی دستگاه ارسال می‌کند.
2. سرور فروشنده یک پیکربندی حراج ایجاد می‌کند و آن را به همراه بار داده رمزگذاری شده، برای شروع گردش کار انتخاب آگهی ، به سرویس Trusted Bidding and Auction فروشنده ارسال می‌کند.
3. سرویس مناقصه و مزایده فروشنده، بار داده را به سرورهای فرانت‌اند خریداران مورد اعتماد شرکت‌کننده منتقل می‌کند.
4. سرویس پیشنهاد قیمت خریدار، منطق انتخاب تبلیغات سمت خرید را اجرا می‌کند.
   1. اجرای منطق بازیابی تبلیغات سمت خرید .
   2. اجرای منطق مناقصه سمت خرید .
5. منطق امتیازدهی سمت فروش اجرا می‌شود .
6. آگهی نمایش داده می‌شود و گزارش‌دهی آغاز می‌شود.

شروع گردش کار انتخاب تبلیغ

وقتی یک برنامه آماده نمایش تبلیغ است، SDK فناوری تبلیغات (معمولاً SSPها) با ارسال هرگونه داده زمینه‌ای مرتبط از ناشر و بارهای رمزگذاری شده برای هر خریدار که باید در درخواست ارسال به حراج محافظت‌شده با استفاده از فراخوانی getAdSelectionData گنجانده شوند، گردش کار انتخاب تبلیغ را آغاز می‌کند. این همان API است که برای گردش کار بازاریابی مجدد استفاده می‌شود و در پیشنهاد ادغام پیشنهاد و حراج برای اندروید شرح داده شده است.

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

فروشنده موارد زیر را تعیین می‌کند:

• بار داده‌ای که از getAdSelectionData دریافت شده و شامل Protected App Signals است.

• سیگنال‌های زمینه‌ای با استفاده از:

  • auction_config.auction_signals (برای اطلاعات مربوط به حراج )

  • auction_config.seller_signals (برای سیگنال‌های فروشنده)

  • auction_config.per_buyer_config["buyer"].buyer_signals (برای سیگنال‌های خریداران )

• فهرست خریدارانی که در مزایده‌ها شرکت دارند با استفاده از فیلد buyer_list .

اجرای منطق انتخاب تبلیغات سمت خرید

در سطح بالا، منطق سفارشی خریدار از داده‌های زمینه‌ای ارائه شده توسط ناشر و Protected App Signals برای انتخاب و اعمال پیشنهاد قیمت به تبلیغات مرتبط با درخواست تبلیغ استفاده می‌کند. این پلتفرم به خریداران این امکان را می‌دهد که مجموعه بزرگی از تبلیغات موجود را به مرتبط‌ترین آنها (k مورد برتر) محدود کنند، که قبل از بازگشت تبلیغات به فروشنده برای انتخاب نهایی، پیشنهادهای قیمت برای آنها محاسبه می‌شود.

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

1. سرویس BuyerFrontEnd یک درخواست تبلیغ دریافت می‌کند.
2. سرویس BuyerFrontEnd درخواستی را به سرویس پیشنهاد قیمت خریدار ارسال می‌کند. سرویس پیشنهاد قیمت خریدار یک UDF به نام prepareDataForAdRetrieval() اجرا می‌کند که درخواستی برای دریافت k کاندیدای برتر از سرویس بازیابی تبلیغات ایجاد می‌کند. سرویس پیشنهاد قیمت این درخواست را به نقطه پایانی سرور بازیابی پیکربندی شده ارسال می‌کند.
3. سرویس بازیابی آگهی، تابع UDF مربوط به getCandidateAds() را اجرا می‌کند که مجموعه k آگهی برتر را فیلتر می‌کند و به سرویس پیشنهاد قیمت خریدار ارسال می‌کند.
4. سرویس پیشنهاد قیمت خریدار، UDF مربوط به generateBid() را اجرا می‌کند که بهترین کاندید را انتخاب، پیشنهاد قیمت آن را محاسبه و سپس آن را به سرویس BuyerFrontEnd بازمی‌گرداند.
5. سرویس BuyerFrontEnd تبلیغات و پیشنهادات را به فروشنده برمی‌گرداند.

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

قبل از اینکه به بخش‌هایی از این مطلب با جزئیات بیشتری بپردازیم، نکات معماری مهمی در مورد TEEهای این نمودار وجود دارد.

سرویس پیشنهاد قیمت خریدار به صورت داخلی شامل یک سرویس استنتاج است. تکنسین‌های تبلیغات می‌توانند مدل‌های یادگیری ماشین را در سرویس پیشنهاد قیمت خریدار آپلود کنند. ما APIهای جاوا اسکریپت را برای تکنسین‌های تبلیغات فراهم خواهیم کرد تا پیش‌بینی‌هایی انجام دهند یا از این مدل‌ها، از درون UDFهایی که روی سرویس پیشنهاد قیمت خریدار اجرا می‌شوند، جاسازی‌هایی ایجاد کنند. برخلاف سرویس بازیابی تبلیغات، سرویس پیشنهاد قیمت خریدار سرویس کلید-مقدار برای ذخیره فراداده‌های تبلیغات ندارد .

سرویس بازیابی آگهی (Ad Retrieval Service) به صورت داخلی شامل یک سرویس کلید-مقدار (key-value) است. تکنسین‌های تبلیغات می‌توانند جفت‌های کلید-مقدار را از سرورهای خود، خارج از مرز حریم خصوصی، در این سرویس پیاده‌سازی کنند. ما یک API جاوا اسکریپت برای تکنسین‌های تبلیغات ارائه خواهیم داد تا از طریق UDFهایی که در سرویس بازیابی آگهی اجرا می‌شوند، این سرویس کلید-مقدار را بخوانند. برخلاف سرویس پیشنهاد قیمت خریدار، سرویس بازیابی آگهی (Ad Retrieval Service) حاوی سرویس استنتاج (inference service) نیست .

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

تجزیه مدل

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

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

این امر طراحی زیر را ممکن می‌سازد:

1. مدل را به یک بخش خصوصی (داده‌های کاربر) و یک یا چند بخش غیرخصوصی (داده‌های زمینه‌ای و تبلیغاتی) تقسیم کنید.
2. به صورت اختیاری، می‌توانید برخی یا همه قطعات غیرخصوصی را به عنوان آرگومان به یک UDF که نیاز به پیش‌بینی دارد، ارسال کنید. برای مثال، جاسازی‌های متنی به UDFهای موجود در per_buyer_signals ارسال می‌شوند.
3. به صورت اختیاری، متخصصان تبلیغات می‌توانند مدل‌هایی برای قطعات غیرخصوصی ایجاد کنند، سپس جاسازی‌ها را از آن مدل‌ها در مخزن کلید-مقدار سرویس بازیابی تبلیغات (Ad Retrieval Service) پیاده‌سازی کنند. UDFهای سرویس بازیابی تبلیغات می‌توانند این جاسازی‌ها را در زمان اجرا دریافت کنند.
4. برای انجام پیش‌بینی در طول یک UDF، جاسازی‌های خصوصی از سرویس استنتاج را با جاسازی‌های غیرخصوصی از آرگومان‌های تابع UDF یا مخزن کلید-مقدار با عملیاتی مانند ضرب نقطه‌ای ترکیب کنید. این پیش‌بینی نهایی است.

با این توضیح، می‌توانیم هر UDF را با جزئیات بیشتری بررسی کنیم. توضیح خواهیم داد که آنها چه کاری انجام می‌دهند، چگونه ادغام می‌شوند و چگونه می‌توانند پیش‌بینی‌های لازم برای انتخاب k تبلیغ برتر و محاسبه پیشنهادات آنها را انجام دهند.

تابع UDF مربوط به prepareDataForAdRetrieval()

prepareDataForAdRetrieval() که روی سرویس پیشنهاد قیمت خریدار اجرا می‌شود، مسئول ایجاد درخواستی است که برای دریافت k تبلیغ برتر به سرویس بازیابی تبلیغات ارسال خواهد شد.

prepareDataForAdRetrieval() اطلاعات زیر را دریافت می‌کند:

• بار داده‌ای که به ازای هر خریدار از getAdSelectionData دریافت می‌شود. این بار داده شامل سیگنال‌های برنامه محافظت‌شده است.
• فیلدهای auction_signals مربوط به سیگنال‌های زمینه‌ای (برای اطلاعات مربوط به حراج ) و buyer_signals (برای سیگنال‌های خریداران ).

prepareDataForAdRetrieval() دو کار انجام می‌دهد:

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

prepareDataForAdRetrieval() خروجی زیر را برمی‌گرداند:

• سیگنال‌های برنامه محافظت‌شده : سیگنال‌های گردآوری‌شده توسط فناوری تبلیغات.
• سیگنال‌های مختص حراج : سیگنال‌های سمت فروش مختص پلتفرم و اطلاعات زمینه‌ای مانند auction_signals و per_buyer_signals (شامل جاسازی‌های زمینه‌ای) از SelectAdRequest . این مشابه Protected Audiences است.
• سیگنال‌های اضافی : اطلاعات اضافی مانند جاسازی‌های خصوصی که از سرویس استنتاج بازیابی می‌شوند.

این درخواست به سرویس بازیابی تبلیغات (Ad Retrieval Service) ارسال می‌شود که تطبیق کاندیدا را انجام داده و سپس تابع getCandidateAds() UDF را اجرا می‌کند.

تابع UDF مربوط به getCandidateAds()

getCandidateAds() روی سرویس بازیابی آگهی (Ad Retrieval Service) اجرا می‌شود. این تابع درخواست ایجاد شده توسط prepareDataForAdRetrieval() را روی سرویس پیشنهاد قیمت خریدار دریافت می‌کند. این سرویس تابع getCandidateAds() را اجرا می‌کند که با تبدیل درخواست به مجموعه‌ای از پرس‌وجوهای تنظیم‌شده، واکشی داده‌ها و اجرای منطق تجاری سفارشی و سایر منطق‌های بازیابی سفارشی، k کاندیدای برتر برای پیشنهاد قیمت را واکشی می‌کند.

تابع getCandidateAds() اطلاعات زیر را دریافت می‌کند:

• سیگنال‌های برنامه محافظت‌شده : سیگنال‌های گردآوری‌شده توسط فناوری تبلیغات.
• سیگنال‌های مختص حراج : سیگنال‌های سمت فروش مختص پلتفرم و اطلاعات زمینه‌ای مانند auction_signals و per_buyer_signals (شامل جاسازی‌های زمینه‌ای) از SelectAdRequest . این مشابه Protected Audiences است.
• سیگنال‌های اضافی : اطلاعات اضافی مانند جاسازی‌های خصوصی که از سرویس استنتاج بازیابی می‌شوند.

getCandidateAds() موارد زیر را انجام می‌دهد:

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

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

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

توجه داشته باشید که UDF تابع generateBid() که روی سرویس پیشنهاد قیمت خریدار اجرا می‌شود، ممکن است نوع فاکتورگیری مدل خاص خود را نیز برای پیش‌بینی‌های پیشنهاد قیمت خود اعمال کند. اگر برای انجام این کار به جاسازی‌هایی از یک سرویس کلید-مقدار نیاز باشد، باید اکنون آنها را دریافت کرد.

getCandidateAds() خروجی زیر را برمی‌گرداند:

• تبلیغات کاندید : k تبلیغ برتر که باید به تابع generateBid() ارسال شوند. هر تبلیغ از اجزای زیر تشکیل شده است:
  • رندر URL : نقطه پایانی برای رندر کردن تبلیغ خلاقانه.
  • فراداده : فراداده‌های تبلیغاتی مختص فناوری‌های تبلیغاتی و سمت خریدار. به عنوان مثال، این ممکن است شامل اطلاعاتی در مورد کمپین تبلیغاتی و معیارهای هدف‌گذاری مانند مکان و زبان باشد. فراداده‌ها می‌توانند شامل جاسازی‌های اختیاری باشند که در صورت نیاز به تجزیه مدل برای اجرای استنتاج در طول مناقصه، مورد استفاده قرار می‌گیرند.
• سیگنال‌های اضافی : به صورت اختیاری، سرویس بازیابی تبلیغات می‌تواند شامل اطلاعات اضافی مانند جاسازی‌های اضافی یا سیگنال‌های اسپم باشد که در generateBid() استفاده می‌شوند.

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

تابع UDF generateBid()

پس از بازیابی مجموعه تبلیغات کاندید و جاسازی‌ها در طول بازیابی، آماده‌ی شروع پیشنهاد قیمت هستید که در سرویس پیشنهاد قیمت خریدار اجرا می‌شود. این سرویس UDF generateBid() ارائه شده توسط خریدار را اجرا می‌کند تا تبلیغ مورد نظر برای پیشنهاد قیمت را از بین k تبلیغ برتر انتخاب کند و سپس آن را به همراه پیشنهاد قیمتش برگرداند.

generateBid() اطلاعات زیر را دریافت می‌کند:

• تبلیغات کاندید : k تبلیغ برتر که توسط سرویس بازیابی تبلیغات بازگردانده می‌شوند.
• سیگنال‌های مختص حراج : سیگنال‌های سمت فروش مختص پلتفرم، و اطلاعات زمینه‌ای مانند auction_signals و per_buyer_signals (شامل جاسازی‌های زمینه‌ای) از SelectAdRequest .
• سیگنال‌های اضافی : اطلاعات اضافی که در زمان پیشنهاد قیمت استفاده می‌شوند.

پیاده‌سازی generateBid() توسط خریدار سه کار انجام می‌دهد:

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

generateBid() خروجی می‌دهد:

• تبلیغ کاندیدا.
• مبلغ پیشنهادی محاسبه شده آن.

توجه داشته باشید که تابع generateBid() که برای تبلیغات نصب اپلیکیشن استفاده می‌شود با تابعی که برای تبلیغات ریمارکتینگ استفاده می‌شود، متفاوت است.

بخش‌های بعدی، ویژگی‌سازی، استنتاج و پیشنهاد قیمت را با جزئیات بیشتری شرح می‌دهند.

ویژگی‌سازی

سیگنال‌های حراج را می‌توان با استفاده از generateBid() به ویژگی‌ها تبدیل کرد. این ویژگی‌ها می‌توانند در طول استنتاج برای پیش‌بینی مواردی مانند نرخ کلیک و تبدیل استفاده شوند. ما همچنین در حال بررسی مکانیسم‌های حفظ حریم خصوصی هستیم تا برخی از آنها را در گزارش برد برای استفاده در آموزش مدل منتقل کنیم.

استنتاج

هنگام محاسبه‌ی یک پیشنهاد، معمولاً از یک یا چند مدل یادگیری ماشینی برای استنتاج استفاده می‌شود. به عنوان مثال، محاسبات مؤثر eCPM اغلب از مدل‌هایی برای پیش‌بینی نرخ کلیک و تبدیل استفاده می‌کنند.

کلاینت‌ها می‌توانند تعدادی از مدل‌های یادگیری ماشین را به همراه پیاده‌سازی generateBid() خود ارائه دهند. ما همچنین یک API جاوا اسکریپت را در generateBid() ارائه خواهیم داد تا کلاینت‌ها بتوانند در زمان اجرا استنتاج انجام دهند.

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

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

پیاده‌سازی تجزیه مدل

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

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

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

منطق امتیازدهی سمت فروش

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

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

زمان اجرای کد انتخاب تبلیغ

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

گزارش‌دهی

این پیشنهاد از همان APIهای گزارش‌دهیِ پیشنهاد گزارش‌دهیِ مخاطبِ محافظت‌شده استفاده می‌کند (برای مثال، reportImpression() که باعث می‌شود پلتفرم گزارش‌های فروشنده و خریدار را ارسال کند).

One common use case for reporting on the buy-side is getting the training data for models used during ad selection. In addition to existing APIs, the platform will provide a specific mechanism for egressing event-level data from the platform to ad tech servers. These egress payloads can include certain user data.

In the long term, we are investigating privacy-preserving solutions to address model training with data used in Protected Auctions without sending event-level user data outside services running on TEEs. We will provide additional details in a later update.

In the short term, we will provide a temporary way to egress noised data from generateBid() . Our initial proposal for this follows, and we will evolve it (including possible backward-incompatible changes) in response to industry feedback.

Technically, the way this works is:

1. Ad techs define a schema for the data they want to transmit.
2. In generateBid() , they build their chosen egress payload.
3. The platform validates the egress payload against the schema and enforces size limits.
4. The platform adds noise to the egress payload.
5. The egress payload is included in the win report in wire format, received on ad tech servers, decoded, and used for model training.

Defining the schema of egress payloads

For the platform to enforce evolving privacy requirements, egress payloads must be structured in a way the platform can understand. Ad techs will define the structure of their egress payloads by providing a schema JSON file. That schema will be processed by the platform, and will be kept confidential by the Bidding and Auction services using the same mechanisms as other ad tech resources like UDFs and models.

We will provide a CDDL file that defines the structure of that JSON. The CDDL file will include a set of supported feature types (for example, features that are booleans, integers, buckets, and so on). Both the CDDL file and the provided schema will be versioned.

For example, an egress payload that consists of a single boolean feature followed by a bucket feature of size two would look something like:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Details on the set of supported feature types are available on GitHub .

Build egress payloads in generateBid()

All Protected App Signals for a given buyer are available to their generateBid() UDF. Once these are featurized, ad techs create their payload in JSON format. This egress payload will be included in the buyer's win report for transmission to ad tech servers.

An alternative to this design is for egress vector calculation to happen in reportWin() instead of generateBid() . There are trade-offs for each approach, and we'll finalize this decision in response to industry feedback.

Validate the egress payload

The platform will validate any egress payload created by the ad tech. Validation verifies that feature values are valid for their types, size constraints are met, and that malicious actors are not attempting to defeat privacy controls by packing additional information into their egress payloads.

If an egress payload is invalid, it will be silently discarded from the inputs sent to the win report. This is because we don't want to provide debugging information to any bad actor attempting to defeat validation.

We will provide a JavaScript API for ad techs to verify the egress payload they create in generateBid() will pass platform validation:

validate(payload, schema)

This JavaScript API is entirely for callers to determine if a particular payload will pass platform validation. Actual validation must be done in the platform to guard against malicious generateBid() UDFs.

Noise the egress payload

The platform will noise egress payloads before including them in the win report. The initial noise threshold will be 1%, and this value may evolve over time. The platform will provide no indication whether or not a particular egress payload has been noised.

The noising method is:

1. The platform loads the schema definition for the egress payload.
2. 1% of egress payloads will be chosen for noising.
3. If an egress payload is not chosen, the entire original value is retained.
4. If an egress payload is chosen, each feature's value will be replaced with a random valid value for that feature type (for example, either 0 or 1 for a boolean feature).

Transmitting, receiving, and decoding the egress payload for model training

The validated, noised egress payload will be included in the arguments to reportWin() , and transmitted to buyer ad tech servers outside the privacy boundary for model training. The egress payload will be in its wire format.

Details on the wire format for all feature types and for the egress payload itself are available on GitHub .

Determine the size of the egress payload

The size of the egress payload in bits balances utility and data minimization. We will work with industry to determine the appropriate size via experimentation. While we are running those experiments, we will temporarily egress data with no bit size limitation. That additional egress data with no bit size limitation will be removed once experiments are complete.

The method for determining size is:

1. Initially, we will support two egress payloads in generateBid() :
   1. egressPayload : the size-limited egress payload we've described so far in this document. Initially, this egress payload's size will be 0 bits (meaning it will always be removed during validation).
   2. temporaryUnlimitedEgressPayload : a temporary size-unlimited egress payload for size experiments. The formatting, creation, and processing of this egress payload uses the same mechanisms as egressPayload .
2. Each of these egress payloads will have its own schema JSON file: egress_payload_schema.json and temporary_egress_payload_schema.json .
3. We provide an experiment protocol and set of metrics for determining model utility at various egress payload sizes (for example, 5, 10, ... bits).
4. Based on experiment results, we determine the egress payload size with the correct utility and privacy trade-offs.
5. We set the size of egressPayload from 0 bits to the new size.
6. After a set migration period, we remove temporaryUnlimitedEgressPayload , leaving only egressPayload with its new size.

We are investigating additional technical guardrails for managing this change (for example, encrypting egressPayload when we increase its size from 0 bits). Those details -- along with timing for the experiment and the removal of temporaryUnlimitedEgressPayload -- will be included in a later update.

Next we'll explain a possible experiment protocol for finalizing the size of egressPayload . Our goal is to work with industry to find a size that balances utility and data minimization. The artifact these experiments will produce is a graph where the x-axis is the size of the training payload in bits, and the y-axis is the percentage of revenue generated by a model at that size compared to a size-unlimited baseline.

We'll assume we're training a pInstall model, and our sources of training data are our logs and the contents of the temporaryUnlimitedegressPayload s we receive when we win auctions. The protocol for ad-techs first involves offline experiments:

1. Determine the architecture of the models they will use with Protected App Signals. For example, they will need to determine whether or not they will use model factorization .
2. Define a metric for measuring model quality. Suggested metrics are AUC loss and log loss.
3. Define the set of features they will use during model training.
4. Using that model architecture, quality metric, and set of training features, run ablation studies to determine the utility contributed per bit for each model they want to use in PAS. The suggested protocol for the ablation study is:
   1. Train the model with all features and measure utility; this is the baseline for comparison.
   2. For each feature used to produce the baseline, train the model with all features except that feature.
   3. Measure resulting utility. Divide the delta by the size of the feature in bits; this is the expected utility per bit for that feature.
5. Determine the training payload sizes of interest for experimentation. We suggest [5, 10, 15, ..., size_of_all_training_features_for_baseline ] bits. Each of these represents a possible size for egressPayload that the experiment will evaluate.
6. For each possible size, select a set of features less than or equal to that size that maximize utility per bit, using the results of the ablation study.
7. Train a model for each possible size and evaluate its utility as a percentage of the utility of the baseline model trained on all features.
8. Plot the results on a graph where the x-axis is the size of the training payload in bits, and the y-axis is the percentage of revenue generated by that model compared to baseline.

Next, ad-techs can repeat steps 5-8 in live traffic experiments, using feature data sent via temporaryUnlimitedEgressPayload . Ad-techs can choose to share the results of their offline and live traffic experiments with Privacy Sandbox to inform the decision about the size of egressPayload .

The timeline for these experiments, as well as the timeline for setting the size of egressPayload to the resulting value, is beyond the scope of this document and will come in a later update.

Data protection measures

We will apply a number of protections to egressed data, including:

1. Both egressPayload and temporaryUnlimitedEgressPayload will be noised.
2. For data minimization and protection temporaryUnlimitedEgressPayload will be available only for the duration of size experiments, where we will determine the correct size for egressPayload .

مجوزها

User control

• The proposal intends to give users visibility to the list of installed apps that have stored at least one Protected App Signal or a custom audience.
• Users can block and remove apps from this list. Block and removal does the following:
  • Clears all Protected App Signals and custom audiences associated with the app.
  • Prevents the apps from storing new Protected App Signals and custom audiences
• Users have the ability to reset the Protected App Signals and Protected Audience API completely. When this happens, any existing Protected App Signals and custom audiences on the device are cleared.
• Users have the ability to opt out completely from the Privacy Sandbox on Android, which includes the Protected App Signals API and Protected Audience API. When this is the case, the Protected Audience and Protected App Signals APIs return a standard exception message: SECURITY_EXCEPTION .

App permissions and control

The proposal intends to provide apps control over its Protected App Signals:

• An app can manage its associations with Protected App Signals.
• An app can grant third party ad tech platforms permissions to manage Protected App signals on its behalf.

Ad tech platform control

This proposal outlines ways for ad techs to control their Protected App Signals:

• All ad techs must enroll with the Privacy Sandbox and provide a "site" or "origin" domain which matches all URLs for Protected App Signals.
• Ad techs can partner with apps or SDKs to provide verification tokens that are used to verify creation of Protected App Signals. When this process is delegated to a partner, Protected App Signal creation can be configured to require acknowledgement by the ad tech.