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

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

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

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

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

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

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

فلوچارتی که سیگنال های برنامه محافظت شده و گردش کار انتخاب آگهی را در جعبه ایمنی حریم خصوصی در Android نشان می دهد.

در اینجا یک نمای کلی از نحوه عملکرد Protected App Signals برای پشتیبانی از تبلیغات نصب برنامه مربوطه ارائه شده است. بخش های بعدی این سند جزئیات بیشتری در مورد هر یک از این مراحل ارائه می دهد.

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

جدول زمانی

	پیش نمایش توسعه دهنده			بتا
ویژگی	Q4'23	Q1'24	Q2'24	Q3'24
Signal Curation APIs	APIهای ذخیره سازی روی دستگاه	منطق سهمیه ذخیره سازی روی دستگاه به روز رسانی روزانه منطق سفارشی روی دستگاه	N/A	برای دستگاه های T+ 1% موجود است
سرور بازیابی آگهی در یک TEE	MVP	در GCP موجود است پشتیبانی از Top K تولید UDF	در AWS موجود است اشکال زدایی، معیارها، و نظارت با موافقت
سرویس استنتاج در TEE پشتیبانی از اجرای مدل های ML و استفاده از آنها برای مناقصه در TEE	در توسعه	در GCP موجود است امکان استقرار و نمونه سازی مدل های استاتیک ML با استفاده از Tensorflow و PyTorch	در AWS موجود است استقرار مدل تولیدی برای مدل‌های تنسورفلو و PyTorch تله متری، اشکال زدایی موافق، و نظارت
مناقصه و پشتیبانی مزایده در TEE	در GCP موجود است	ادغام بازیابی تبلیغات PAS-B&A و TEE (با رمزگذاری gRPC و TEE<>TEE) پشتیبانی بازیابی آگهی از طریق مسیر متنی (شامل پشتیبانی B&A<>K/V در TEE)	در AWS موجود است گزارش اشکال زدایی اشکال زدایی، معیارها، و نظارت با موافقت

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

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

API Protected App Signals

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

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

• یک سیگنال اسکالر با کلید مقدار base64 " A1c " و مقدار " c12Z ". ذخیره سیگنال توسط com.google.android.game_app در 1 ژوئن 2023 راه اندازی شده است.
• لیستی از سیگنال ها با کلید " dDE " که توسط دو برنامه مختلف ایجاد شده اند.

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

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

API Protected App Signals از بخش‌های زیر تشکیل شده است:

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

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

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

برای افزودن سیگنال، فناوری‌های تبلیغاتی خریدار که SDK در برنامه‌ها حضور ندارند، باید با فناوری‌های تبلیغاتی که در دستگاه حضور دارند، مانند شرکای اندازه‌گیری تلفن همراه (MMP) و پلت‌فرم‌های طرف عرضه (SSP) همکاری کنند. API Protected App Signals با ارائه راه‌حل‌های منعطف برای مدیریت سیگنال برنامه محافظت‌شده با فعال کردن تماس‌گیرندگان دستگاه برای فراخوانی ایجاد سیگنال برنامه محافظت‌شده از طرف خریداران، از این فناوری تبلیغات پشتیبانی می‌کند. این فرآیند Delegation نامیده می شود و از 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 بیان می شوند.

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

سیگنال‌های ذخیره‌شده به‌طور خودکار با برنامه‌ای که درخواست واکشی را انجام می‌دهد، و پاسخ‌دهنده درخواست («سایت» یا «منبع» یک فناوری آگهی ثبت‌شده)، به اضافه زمان ایجاد درخواست مرتبط می‌شوند. همه سیگنال‌ها از طرف فناوری آگهی ثبت‌شده در جعبه ایمنی حریم خصوصی ذخیره می‌شوند، «سایت»/«منبع» URI باید با داده‌های فناوری آگهی ثبت‌شده مطابقت داشته باشد. اگر فناوری آگهی درخواستی ثبت نشده باشد، درخواست رد می شود.

سهمیه ذخیره سازی و تخلیه

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

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

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

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

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

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

گردش کار انتخاب آگهی

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

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

گردش کار انتخاب آگهی در جعبه ایمنی حریم خصوصی در Android.

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

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

گردش کار انتخاب آگهی را آغاز کنید

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

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

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

• محموله دریافتی از getAdSelectionData که حاوی سیگنال های برنامه محافظت شده است.

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

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

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

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

• لیست خریداران موجود در مزایده ها با استفاده از قسمت buyer_list .

اجرای منطقی انتخاب آگهی سمت خرید

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

منطق اجرای انتخاب آگهی سمت خرید در جعبه ایمنی حریم خصوصی در اندروید.

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

توجه: این جریان ترکیبی از کد چارچوب و توابع تعریف شده توسط کاربر (UDF) است که حاوی منطق تجاری خریدار است. این UDF ها در جاوا اسکریپت یا WASM پیاده سازی می شوند. در سطح بالا، جریان عبارت است از:

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

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

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

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

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

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

فاکتورسازی مدل

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

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

که طراحی زیر را ممکن می کند:

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

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

UDF prepareDataForAdRetrieval()

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

prepareDataForAdRetrieval() اطلاعات زیر را می گیرد:

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

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

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

prepareDataForAdRetrieval() برمی گرداند:

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

این درخواست به سرویس بازیابی آگهی ارسال می شود، که تطبیق نامزدها را انجام می دهد و سپس UDF getCandidateAds() اجرا می کند.

UDF getCandidateAds()

getCandidateAds() در سرویس بازیابی آگهی اجرا می شود. درخواست ایجاد شده توسط prepareDataForAdRetrieval() در سرویس مناقصه خریدار را دریافت می کند. این سرویس getCandidateAds() را اجرا می‌کند که با تبدیل درخواست به مجموعه‌ای از کوئری‌های مجموعه، واکشی داده‌ها، و اجرای منطق تجاری سفارشی و دیگر منطق بازیابی سفارشی، کاندیدهای top-k را برای مناقصه واکشی می‌کند.

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

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

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

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

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

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

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

getCandidateAds() برمی گرداند:

• تبلیغات کاندیدا : k تبلیغات برتر برای ارسال به generateBid() . هر آگهی از موارد زیر تشکیل شده است:
  • Render 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() که پلتفرم را برای ارسال گزارش‌های فروشنده و خریدار فعال می‌کند.

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

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

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

از نظر فنی ، نحوه کار این است:

1. فناوری های تبلیغاتی یک طرح را برای داده هایی که می خواهند انتقال دهند تعریف می کنند.
2. در generateBid() ، آنها بار خود را بار خود می سازند.
3. این پلتفرم بار اضافی را در برابر طرحواره تأیید می کند و محدودیت های اندازه را اعمال می کند.
4. این پلتفرم سر و صدایی را به بار اضافی اضافه می کند.
5. بار Egress در گزارش WIN در قالب سیم ، دریافت شده در سرورهای AD Tech ، رمزگشایی شده و برای آموزش مدل استفاده می شود.

تعریف طرح بار بارهای خروجی

برای اجرای این بستر برای اجرای الزامات در حال تحول در حریم خصوصی ، بارهای Egress باید به گونه ای ساخته شود که پلتفرم بتواند آن را درک کند. Techs AD با ارائه پرونده JSON SCHEMA ، ساختار بارهای خروجی خود را تعریف می کند. این طرحواره توسط این سکو پردازش می شود و با استفاده از همان مکانیسم های سایر منابع فناوری تبلیغاتی مانند UDF و مدل ها توسط سرویس های مناقصه و حراج محرمانه نگه داشته می شود.

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

به عنوان مثال ، یک بار اضافی که از یک ویژگی بولی تشکیل شده است و به دنبال آن یک سطل از اندازه دو چیزی شبیه است:

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

جزئیات مربوط به مجموعه انواع ویژگی های پشتیبانی شده در GitHub موجود است.

بارهای خروجی Egress را در generateBid()

تمام سیگنال های برنامه محافظت شده برای یک خریدار معین در دسترس خود در UDF generateBid() هستند. پس از ظهور این موارد ، فناوری های تبلیغاتی بار خود را با فرمت JSON ایجاد می کنند. این بار اضافی در گزارش برنده خریدار برای انتقال به سرورهای فناوری تبلیغی گنجانده شده است.

جایگزینی برای این طرح برای محاسبه بردار خروجی در reportWin() به جای generateBid() است. برای هر رویکرد معاملات تجاری وجود دارد و ما این تصمیم را در پاسخ به بازخورد صنعت نهایی خواهیم کرد.

اعتبار بار خروجی را تأیید کنید

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

اگر یک بار اضافی بی اعتبار باشد ، از ورودی های ارسال شده به گزارش WIN به صورت سکوت دور می شود. این امر به این دلیل است که ما نمی خواهیم اطلاعات اشکال زدایی را به هر بازیگر بدی که در تلاش برای شکست اعتبار سنجی است ، ارائه دهیم.

ما یک API JavaScript را برای تکنیک های تبلیغاتی فراهم خواهیم کرد تا اطمینان حاصل شود که بار خروجی آنها در generateBid() اعتبار پلتفرم را تصویب می کند:

validate(payload, schema)

این API JavaScript کاملاً برای تماس گیرندگان است که آیا یک بار خاص از اعتبار پلتفرم عبور می کند یا خیر. اعتبار واقعی باید در این سکو انجام شود تا در برابر generateBid() UDF () محافظت کند.

سر و صدا بار اضافی

این پلتفرم قبل از اینکه آنها را در گزارش برنده قرار دهند ، بارهای خروج از آن را انجام می دهد. آستانه اولیه نویز 1 ٪ خواهد بود و این مقدار ممکن است با گذشت زمان تکامل یابد. این پلتفرم هیچ نشانه ای از این که آیا یک بار خاص از طریق بازپرداخت خاص یا عدم استفاده از آن استفاده نشده است ، ارائه نمی دهد.

روش NOISING:

1. این پلتفرم تعریف طرحواره را برای بار اضافی بارگذاری می کند.
2. 1 ٪ از بارهای Egress برای نوبت انتخاب می شود.
3. در صورت انتخاب بار خروجی ، کل مقدار اصلی حفظ می شود.
4. اگر یک بار اضافی انتخاب شود ، مقدار هر ویژگی با یک مقدار معتبر تصادفی برای آن نوع ویژگی جایگزین می شود (به عنوان مثال ، 0 یا 1 برای یک ویژگی بولی).

انتقال ، دریافت و رمزگشایی بار اضافی برای آموزش مدل

بار معتبر و بدون استفاده از Egress در آرگومان های reportWin() گنجانده شده است و به سرورهای فناوری تبلیغی خریدار در خارج از مرز حریم خصوصی برای آموزش مدل منتقل می شود. بار Egress در قالب سیم خود قرار خواهد گرفت.

جزئیات مربوط به فرمت سیم برای انواع ویژگی ها و برای بارگیری خود در Egress در GitHub موجود است.

اندازه بار اضافی را تعیین کنید

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

روش تعیین اندازه:

1. در ابتدا ، ما از دو بار بارهای خروجی در generateBid() پشتیبانی خواهیم کرد:
   1. egressPayload : بار محدود به اندازه محدود که تاکنون در این سند توضیح داده ایم. در ابتدا ، این اندازه بار زایمان 0 بیت خواهد بود (به این معنی که همیشه در طول اعتبار سنجی حذف می شود).
   2. temporaryUnlimitedEgressPayload : یک بار بازپرداخت موقت-محدود برای آزمایش های اندازه. قالب بندی ، ایجاد و پردازش این بار Egress از مکانیسم های مشابه egressPayload استفاده می کند.
2. هر یک از این بارهای egress پرونده JSON SCHEMA خاص خود را دارند: egress_payload_schema.json و temporary_egress_payload_schema.json .
3. ما یک پروتکل آزمایش و مجموعه ای از معیارها را برای تعیین ابزار مدل در اندازه های مختلف بارگذاری Egress (به عنوان مثال ، 5 ، 10 ، ... بیت) ارائه می دهیم.
4. بر اساس نتایج آزمایش ، ما اندازه بار بارگیری Egress را با ابزار صحیح و تجارت حریم خصوصی تعیین می کنیم.
5. ما اندازه egressPayload را از 0 بیت به اندازه جدید تنظیم می کنیم.
6. پس از یک دوره مهاجرت تعیین شده ، ما temporaryUnlimitedEgressPayload را حذف می کنیم ، و تنها با اندازه جدید آن egressPayload می کنیم.

ما در حال بررسی نگهبان های فنی اضافی برای مدیریت این تغییر هستیم (به عنوان مثال ، رمزگذاری egressPayload وقتی اندازه آن را از 0 بیت افزایش می دهیم). این جزئیات - همراه با زمان بندی برای آزمایش و حذف temporaryUnlimitedEgressPayload - در به روزرسانی بعدی گنجانده می شود.

در مرحله بعد ، یک پروتکل آزمایش احتمالی را برای نهایی کردن اندازه egressPayload توضیح خواهیم داد. هدف ما این است که با صنعت همکاری کنیم تا اندازه ای را پیدا کنیم که به حداقل رساندن ابزار و به حداقل رساندن داده ها باشد. مصنوعی که این آزمایشات تولید می کند نمودار است که در آن محور X اندازه بار آموزش در بیت ها است و محور y درصد درآمد حاصل از یک مدل در آن اندازه در مقایسه با یک پایه محدود محدود است.

فرض خواهیم کرد که ما در حال آموزش یک مدل Pinstall هستیم و منابع آموزش ما مربوط به داده های ما و محتوای temporaryUnlimitedegressPayload است که هنگام پیروزی در حراج ها دریافت می کنیم. پروتکل برای فناوری های تبلیغاتی ابتدا شامل آزمایش های آفلاین است:

1. معماری مدلهایی را که آنها با سیگنال های برنامه محافظت شده استفاده می کنند ، تعیین کنید. به عنوان مثال ، آنها باید تعیین کنند که آیا آنها از فاکتورسازی مدل استفاده می کنند یا خیر.
2. یک متریک برای اندازه گیری کیفیت مدل تعریف کنید. معیارهای پیشنهادی از دست دادن AUC و از دست دادن ورود به سیستم هستند.
3. مجموعه ویژگی هایی را که در طول آموزش مدل استفاده می کنند تعریف کنید.
4. با استفاده از آن معماری مدل ، متریک با کیفیت و مجموعه ای از ویژگی های آموزشی ، مطالعات فرسایش را انجام دهید تا ابزار در هر بیت برای هر مدلی که می خواهند در PAS استفاده کنند ، کمک کند. پروتکل پیشنهادی برای مطالعه فرسایش:
   1. مدل را با تمام ویژگی ها آموزش دهید و ابزار اندازه گیری کنید. این پایه برای مقایسه است.
   2. برای هر ویژگی مورد استفاده برای تولید پایه ، مدل را با تمام ویژگی ها به جز آن ویژگی آموزش دهید.
   3. اندازه گیری ابزار حاصل. دلتا را به اندازه ویژگی در بیت تقسیم کنید. این ابزار مورد انتظار در هر بیت برای آن ویژگی است.
5. اندازه های بارگذاری آموزش را برای آزمایش تعیین کنید. ما پیشنهاد می کنیم [5 ، 10 ، 15 ، ... ، size_of_all_training_features_for_baseline ] بیت. هر یک از این موارد نشان دهنده اندازه ممکن برای egressPayload است که آزمایش ارزیابی خواهد کرد.
6. برای هر اندازه ممکن ، با استفاده از نتایج مطالعه فرسایش ، مجموعه ای از ویژگی های کمتر یا مساوی با اندازه را که حداکثر ابزار را در هر بیت به حداکثر می رساند ، انتخاب کنید.
7. یک مدل را برای هر اندازه ممکن آموزش دهید و ابزار آن را به عنوان درصدی از ابزار مدل پایه آموزش داده شده بر روی همه ویژگی ها ارزیابی کنید.
8. نتایج را بر روی نمودار قرار دهید که محور x اندازه بار آموزش در بیت ها باشد و محور y درصد درآمد حاصل از آن مدل در مقایسه با پایه است.

در مرحله بعد ، فناوری های تبلیغاتی می توانند با استفاده از داده های ویژگی ارسال شده از طریق temporaryUnlimitedEgressPayload ، مراحل 5-8 را در آزمایش های ترافیک زنده تکرار کنند. Ad-Techs می توانند نتایج آزمایش های آفلاین و ترافیک زنده خود را با ماسه حریم خصوصی به اشتراک بگذارند تا تصمیم در مورد اندازه egressPayload را مطلع کنند.

جدول زمانی برای این آزمایشات و همچنین جدول زمانی برای تعیین اندازه egressPayload به مقدار حاصل ، فراتر از محدوده این سند است و در بروزرسانی بعدی به وجود می آید.

اقدامات حفاظت از داده ها

ما تعدادی محافظت را برای داده های egresed اعمال خواهیم کرد ، از جمله:

1. هر دو egressPayload و temporaryUnlimitedEgressPayload مورد استفاده قرار می گیرد.
2. برای به حداقل رساندن داده ها و حفاظت temporaryUnlimitedEgressPayload فقط برای مدت زمان آزمایش های اندازه در دسترس خواهد بود ، جایی که ما اندازه صحیح را برای egressPayload تعیین خواهیم کرد.

مجوزها

کنترل کاربر

• این پیشنهاد قصد دارد تا به کاربران در لیست برنامه های نصب شده که حداقل یک سیگنال برنامه محافظت شده یا مخاطب سفارشی را ذخیره کرده اند ، دید.
• کاربران می توانند برنامه ها را از این لیست مسدود و حذف کنند. بلوک و حذف موارد زیر را انجام می دهد:
  • تمام سیگنال های برنامه محافظت شده و مخاطبان سفارشی مرتبط با برنامه را پاک می کند.
  • مانع از ذخیره برنامه ها سیگنال های جدید برنامه محافظت شده و مخاطبان سفارشی می شود
• کاربران توانایی تنظیم مجدد سیگنال های برنامه محافظت شده و API مخاطبان محافظت شده را به طور کامل دارند. هنگامی که این اتفاق می افتد ، هر سیگنال برنامه محافظت شده موجود و مخاطبان سفارشی در دستگاه پاک می شوند.
• کاربران این توانایی را دارند که از ماسهبازی حریم خصوصی در Android کاملاً امتناع ورزند ، که شامل API سیگنال های برنامه محافظت شده و API مخاطبان محافظت شده است. در این صورت ، مخاطبان محافظت شده و سیگنال های برنامه محافظت شده API یک پیام استثناء استاندارد را برمی گردانند: SECURITY_EXCEPTION .

مجوزهای برنامه و کنترل

این پیشنهاد قصد دارد برنامه ها را کنترل کند تا سیگنال های برنامه محافظت شده خود را کنترل کند:

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

کنترل پلت فرم فناوری تبلیغی

این پیشنهاد روش هایی را برای تکنیک های تبلیغاتی برای کنترل سیگنال های برنامه محافظت شده خود بیان می کند:

• همه فناوری های تبلیغاتی باید با ماسهبازی حریم خصوصی ثبت نام کنند و دامنه "سایت" یا "مبدا" را ارائه دهند که مطابق با تمام URL ها برای سیگنال های برنامه محافظت شده است.
• فناوری های تبلیغاتی می توانند با برنامه ها یا SDK ها همکاری کنند تا نشانه های تأیید را برای تأیید ایجاد سیگنال های برنامه محافظت شده ارائه دهند. هنگامی که این فرآیند به شریک زندگی واگذار شود ، می توان ایجاد سیگنال برنامه محافظت شده را پیکربندی کرد تا توسط فناوری تبلیغی به تأیید نیاز داشته باشد.