אותות מוגנים של אפליקציות לצורך תמיכה במודעות רלוונטיות להתקנת אפליקציה

ההצעה הזו כפופה לתהליך הרישום לארגז החול לפרטיות וכן והאימות (attestation) . מידע נוסף על האימותים זמין כאן לקישור האימות שסופק. עדכונים עתידיים בהצעה הזו צריך לתאר את הדרישות לקבלת גישה למערכת הזו.

מודעות להתקנת אפליקציות לנייד, שנקראות גם מודעות לצירוף משתמשים, הן סוג של פרסום בנייד שמטרתו לעודד משתמשים להוריד אפליקציה לנייד. האלה מודעות מוצגות בדרך כלל למשתמשים על סמך תחומי העניין והמאפיינים הדמוגרפיים שלהם, הם מופיעים לעיתים קרובות באפליקציות אחרות לנייד, כמו משחקים, מדיה חברתית וחדשות באפליקציות. כשמשתמש לוחץ על מודעה להתקנת אפליקציה, הוא מועבר ישירות אל חנות אפליקציות כדי להוריד את האפליקציה.

לדוגמה, מפרסם שמנסה לעודד התקנות חדשות של מכשיר נייד חדש אפליקציה למשלוחי מזון בארצות הברית עשויה לטרגט את המודעות שלה למשתמשים המיקום נמצא בארה"ב וכבר היו מעורבים של משלוחי אוכל אחרים באפליקציות.

בדרך כלל אנחנו מיישמים את התובנות האלה באמצעות הקשרים, אותות צד בין טכנולוגיות פרסום כדי ליצור פרופילים של משתמשים על סמך מזהי פרסום. מודלים של למידת מכונה בתחום הפרסום הדיגיטלי מתבססים על המידע הזה בתור קלט לבחירת מודעות שרלוונטיות למשתמש ויש סבירות גבוהה ביותר שיניבו להמרה.

ממשקי ה-API הבאים מוצעים כדי לתמוך במודעות אפקטיביות להתקנת אפליקציות שיפור פרטיות המשתמשים על ידי הסרת ההסתמכות על מזהי משתמשים של צדדים שונים:

1. Protected App Signals API: הוא מתרכז סביב האחסון יצירה של פיצ'רים מותאמים אישית לפרסום, שמייצגים את הפוטנציאל של המשתמש תחומי עניין. טכנולוגיות הפרסום שומרות אותות של אירועים שהוגדרו בעצמכם בכל אפליקציה, כמו אפליקציה התקנות, פתיחות ראשונות, פעולות משתמש (שלבים במשחק, הישגים), פעילויות רכישה או משך זמן באפליקציה. האותות נכתבים ונשמרים ב- להגנה מפני דליפת נתונים, והם זמינים רק לוגיקה של פרסום דיגיטלי שאחסנה את האות הנתון במהלך מכרז מוגן שפועלות בסביבה מאובטחת.
2. Ad Selection API: ממשק API שמאפשר להגדיר ולהפעיל מכרז מוגן שפועל בסביבת הפעלה מהימנה (TEE) שבו טכנולוגיות הפרסום מאחזרות את המודעות הפוטנציאליות, מריצה מסקנות, מחשבת הצעות מחיר וניקוד כדי לבחור "מנצח" מודעה באמצעות 'אותות אפליקציות מוגנים' וגם מידע הקשרי בזמן אמת לבעלי התוכן הדיגיטלי.

תרשים זרימה שמציג את תהליך העבודה של בחירת אפליקציות מוגנים ותהליך בחירת המודעות בארגז החול לפרטיות ב-Android.

סקירה כללית ברמה גבוהה של האופן שבו 'אותות של אפליקציות מוגנים' פועלים לצורך תמיכה מודעות רלוונטיות להתקנת אפליקציות. בקטעים הבאים במסמך תמצאו מידע נוסף על על כל אחד מהשלבים האלה.

• איסוף אותות: כשמשתמשים באפליקציות לנייד, טכנולוגיות הפרסום אוספים אותות באמצעות אחסון אירועי אפליקציה בהגדרת טכנולוגיות פרסום לצורך הצגת מודעות רלוונטיות באמצעות Protected App Signals API. האירועים האלה מאוחסנים במכשירים מוגנים באחסון, בדומה לקהלים בהתאמה אישית, והם מוצפנים לפני נשלחו מהמכשיר, כך שרק שירותי בידינג ומכרזים פועלים בסביבות ביצוע מהימנות עם האבטחה המתאימה אמצעי הבקרה על הפרטיות יכולים לפענח את ההצפנה שלהם לצורך בידינג וקביעת דירוג של מודעות.
• קידוד אותות: האותות עוברים הכנה בקצב מתוזמן על ידי בלוגיקה של מודעות בהתאמה אישית. משימת רקע ב-Android מבצעת את הלוגיקה הזו כדי לבצע קידוד במכשיר כדי ליצור מטען ייעודי (payload) של אותות מוגנים של אפליקציות שישמשו מאוחר יותר בזמן אמת לבחירת מודעות במהלך מכרז. המטען הייעודי (Payload) מאוחסן באופן מאובטח במכשיר עד שנשלח במכרז.
• בחירת מודעות: כדי לבחור מודעות רלוונטיות למשתמש, ערכות SDK של אתרי מכירה שולחת מטען ייעודי (payload) מוצפן של אותות מוגנים של אפליקציות ומגדירה מכרז מוגן. במכרז, הלוגיקה המותאמת אישית של הקונה מכינה את אותות של אפליקציות יחד עם נתוני הקשר שסופקו על ידי בעל האפליקציה (נתונים שמשותף בדרך כלל בבקשה להצגת מודעה מסוג RTB פתוח) ומהנדסי תכונות שמיועדות לבחירת מודעות (אחזור מודעות, הסקת מסקנות והצעת מחיר גנרטיבית). בדומה ל-Protected Audience, קונים שולחים מודעות אל כדי לקבל דירוג סופי במכרז מוגן.
  • אחזור מודעות: הקונים משתמשים באותות מוגנים של אפליקציות וגם נתונים לפי הקשר שמספקים בעלי התוכן הדיגיטלי כדי ליצור תכונות מהנדסי תוכנה שרלוונטיות לתחומי העניין של המשתמש. התכונות האלה משמשות להתאמת מודעות שעומדים בקריטריונים לטירגוט. המערכת תסנן מודעות שלא נכללות בתקציב. לאחר מכן, K המודעות המובילות נבחרות לבידינג.
  • בידינג: הקונים הלוגיקה של בידינג בהתאמה אישית מכינה את נתונים לפי הקשר שמספקים בעלי תוכן דיגיטלי ואותות מוגנים של אפליקציות להנדסה שמשמשות כקלט למודלים של למידת מכונה של קונים הסקת מסקנות ובידינג על מודעות של מועמדים בבחירות במסגרת שמירה על פרטיות גבולות. לאחר מכן הקונה יחזיר את המודעה שבחר אל המפיץ.
  • ציון בית העסק: בתי עסק מודעות בנושא ציונים לוגיים בהתאמה אישית שנשלח על ידי קונים שמשתתפים בתוכנית ובוחר את המודעה הזוכה שתישלח חזרה לאפליקציה לעיבוד.
• דיווח: המשתתפים במכרז מקבלים דוחות רלוונטיים על הזכייה דיווחים על אובדן נתונים. אנחנו בוחנים מנגנונים לשמירה על הפרטיות כדי לכלול נתונים לאימון מודלים בדוח של הזכייה.

ציר הזמן

	תצוגה מקדימה למפתחים			בטא
תכונה	רבעון 4 של שנת 2023	רבעון 1 של שנת 2024	רבעון 2 של שנת 2024	רבעון 3 של שנת 2024
ממשקי API לאיסוף אותות	ממשקי API לאחסון במכשיר	לוגיקה של מכסת האחסון במכשיר עדכונים יומיים של לוגיקה מותאמת אישית במכשיר	לא רלוונטי	זמין ליותר מ-1% מכשירים של T+
שרת לאחזור מודעות ב-TEE	ה-MVP	זמינה ב-GCP תמיכה ברמת K המובילות ייצור UDF	זמין ב-AWS ניפוי באגים, מדדים ומעקב אחרי הסכמה
שירות ההסקה בסביבת TEE תמיכה בהרצת מודלים של למידת מכונה ושימוש בהם לבידינג ב-TEE	בפיתוח	זמינה ב-GCP יכולת לפרוס ליצור אב טיפוס של מודלים של למידת מכונה סטטית באמצעות Tensorflow ו-PyTorch	זמין ב-AWS פריסת מודל בסביבת ייצור למודלים של Tensorflow ו-PyTorch טלמטריה, ניפוי באגים שמשתמשים הסכימו לשתף ומעקב
תמיכה בבידינג ובמכרז בקמפיין TEE	זמינה ב-GCP	שילוב של PAS-B&A לאחזור מודעות TEE (עם gRPC ו-TEE<>הצפנת TEE) תמיכה באחזור מודעות דרך נתיב הקשרי (כולל תמיכה ב-B&A <>K/V ב-TEE)	זמין ב-AWS ניפוי באגים בדיווח ניפוי באגים, מדדים ומעקב אחרי הסכמה

איסוף של אותות אפליקציות מוגנים

אות מייצג אינטראקציות שונות של משתמשים באפליקציה נקבעים לפי טכנולוגיות פרסום כמועילות להצגת מודעות רלוונטיות. אפליקציה או ערכת ה-SDK המשולבת עשויה לאחסן או למחוק אותות מוגנים של אפליקציות שהוגדרו על ידי טכנולוגיות המודעות על סמך פעילות המשתמשים, כמו פתיחת אפליקציות, הישגים, פעילות רכישות או הזמן באפליקציה. אותות מוגנים של אפליקציות מאוחסנים באופן מאובטח במכשיר, מוצפן לפני שליחתם מהמכשיר, כך שרק 'בידינג ומכרז' שירותים שפועלים בסביבות ביצוע מהימנות עם אבטחה מתאימה ואמצעי הבקרה על הפרטיות יכולים לפענח את ההצפנה לצורך הצגת הצעות מחיר וניקוד למודעות. דומה ל- Custom Audience API, לא ניתן לקרוא או לבדוק את האותות ששמורים במכשיר לפי אפליקציות או ערכות SDK. אין ממשק API לקריאת ערכי אותות, וממשקי API במטרה למנוע דליפת הנוכחות של האותות. הלוגיקה המותאמת אישית של הפרסום הדיגיטלי גישה מוגנת לאותות שנאספו כדי לפתח פיצ'רים שמשמשים בסיס לבחירת מודעות במכרז מוגן.

Protected App Signals API

Protected App Signals API תומך בניהול אותות באמצעות מנגנון הענקת גישה, בדומה למנגנון שמשמש לקהלים בהתאמה אישית. Protected App Signals API מאפשר אחסון אותות בצורת סקלר יחיד או כסדרת זמן. אפשר להשתמש באותות של סדרות זמנים כדי לאחסן פרטים כמו משך הסשן של המשתמש. אותות של סדרות זמנים מציעים כלי עזר לאכיפת באמצעות כלל הפינוי הראשון (First-Party). סוג הנתונים של סקלר אות, או כל אחד מהרכיבים של אות של סדרת זמנים, הוא מערך בייטים. כל אחד מועשר בשם החבילה של האפליקציה שאחסנה את ואת חותמת הזמן של יצירת הקריאה ל-API של אות החנות. התוספת הזו זמין ב-JavaScript לקידוד האותות. הדוגמה הזו שבו מוצג המבנה של האותות שבבעלות טכנולוגיית פרסום מסוימת:

הדוגמה הזו מציגה אות סקלרי ואות של סדרת זמנים המשויך עם adtech1.com:

• אות סקלר עם מפתח ערך base64 'A1c' ואת הערך 'c12Z'. האות החנות מופעלת על ידי com.google.android.game_app ב-1 ביוני 2023.
• רשימת אותות עם המפתח "dDE" שנוצרו על ידי שני מושגים תרגום מכונה.

לטכנולוגיות הפרסום מוקצה נפח מסוים של אחסון אותות במכשיר. לאותות יהיה אורך מקסימלי של TTL, והוא ייקבע.

אותות מוגנים של אפליקציות יוסרו מהאחסון אם האפליקציה שיוצרת את האפליקציה הוסרה, חסימת השימוש ב-Protected App Signals API או נתוני האפליקציה נמחק על ידי המשתמש.

Protected App Signals API מורכב מהחלקים הבאים:

• API של Java ו-JavaScript כדי להוסיף, לעדכן או להסיר אותות.
• JavaScript API כדי לעבד את האותות הקבועים ולהכין אותם הנדסה נוספת של תכונות בזמן אמת במהלך מכרז מוגן שהופעל בסביבת ביצוע מהימנה (TEE).

הוספה, עדכון או הסרה של אותות

טכנולוגיות הפרסום יכולות להוסיף, לעדכן או להסיר אותות באמצעות ה-API של fetchSignalUpdates(). ה-API הזה תומך בהענקת גישה הדומה לקהל מותאם אישית של Protected Audience API בהענקת גישה.

כדי להוסיף אות, טכנולוגיות המודעות של קונים שאין להן נוכחות SDK באפליקציות צריכות לשתף פעולה עם טכנולוגיות פרסום שיש להן נוכחות במכשיר, כמו מכשירים ניידים שותפי מדידה (MMP) ופלטפורמות לספקים (SSP). האפליקציה מוגנת המטרה של Signals API היא לתמוך בטכנולוגיית הפרסום הזו באמצעות פתרונות גמישים ניהול מוגן של אותות אפליקציות באמצעות הפעלה של מתקשרים במכשיר יצירה של אות אפליקציה מוגן בשם הקונים. התהליך הזה נקרא את הגישה ל-API והם משתמשים ב-API של fetchSignalUpdates(). fetchSignalUpdates() לוקח URI ומאחזר רשימה של עדכוני אותות. לצורך המחשה, fetchSignalUpdates() מנפיק בקשת GET ל-URI הנתון כדי לאחזר את רשימת העדכונים שיש להחיל על אחסון האותות המקומי. נקודת הקצה של כתובת ה-URL, בבעלות הקונה משיב עם רשימת פקודות JSON.

פקודות ה-JSON הנתמכות הן:

• username: מוסיפה או משנה ערך סקלרי למפתח הנתון.
• pull_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 "site"/"origin" הנתונים צריכים להיות זהים לנתונים של טכנולוגיית פרסום רשומה. אם הבקשה של טכנולוגיית הפרסום לא רשומה, ולכן הבקשה נדחית.

מכסת אחסון ופינוי מקום

לכל טכנולוגיית פרסום יש שטח מוגבל לאחסון אותות במכשיר של המשתמש. המכסה הזו מוגדרת לכל טכנולוגיית פרסום, כך שאותות שנאספו מאפליקציות שונות משתפים במכסה. במקרה של חריגה מהמכסה, המערכת תפנה מקום על ידי הסרת קבצים קודמים לאותת ערכים על בסיס כניסה ראשונה ויוצאת. כדי למנוע פינוי מתבצעת בתדירות גבוהה מדי, המערכת מיישמת לוגיקת אצווה כדי לאפשר חריגה מהמכסה של המכסה ולפנות עוד מקום לאחר לוגיקת הפינוי מופעלת.

קידוד במכשיר להעברת נתונים

כדי להכין אותות לבחירת מודעות, ללוגיקה מותאמת אישית של כל קונה יש גישה מוגנת לאותות ולאירועים שמאוחסנים לפי אפליקציה. פועלת משימה ברקע של מערכת Android מדי שעה להפעלת לוגיקת קידוד מותאמת אישית לכל קונה, שהורדתם אל במכשיר. לוגיקת הקידוד המותאם אישית לכל קונה מקודדת את האותות עבור כל אפליקציה, וכן ואז דוחס את האותות לכל אפליקציה למטען ייעודי (payload) שעומד בדרישות של מכסה לכל קונה. לאחר מכן המטען הייעודי (Payload) מוצפן בתוך גבולות של אחסון מוגן במכשיר, שמועברים לשירותי בידינג ומכרזים.

טכנולוגיות הפרסום מגדירות את רמת עיבוד האותות שמטופל על ידי בלוגיקה. לדוגמה, אתם יכולים לשנות את הפתרון שלכם קודם לכן וצבירת אותות דומים או מחזקים ממודעות אפליקציות לאותות חדשים שמשתמשים בפחות מקום.

אם קונה לא רשם מקודד אות, האותות לא מוכנים, והאותות שנאספו במכשיר לא נשלחים לבידינג ולמכרז שירותים שונים.

פרטים נוספים על נפח אחסון, מטען ייעודי (payload) ומכסות של בקשות יהיו זמינים עדכון עתידי. בנוסף, נספק מידע נוסף על לספק פונקציות מותאמות אישית.

תהליך עבודה לבחירת מודעות

במסגרת ההצעה הזו, קוד מותאם אישית של טכנולוגיית פרסום יכול לגשת רק לאפליקציה מוגנת אותות בתוך מכרז מוגן (Ad Selection API) שפועלים בסביבת TEE. שפת תרגום תמיכה נוספת בצרכים של התרחיש לדוגמה של התקנת אפליקציה, מודעות מועמדים שאוחזרו במהלך המכרז המוגן בזמן אמת. ההגדרה הזו מנוגדת תרחיש לדוגמה לשימוש ברימרקטינג, שבו המודעות של המועמדים ידועות לפני המכרז.

ההצעה הזו משתמשת בתהליך עבודה דומה לבחירת מודעות כמו Protected Audience API הצעה עם עדכונים שיתמכו בתרחיש לדוגמה של התקנת אפליקציה. כדי לתמוך ודרישות מחשוב להנדסת פיצ'רים (feature engineering) ולבחירת מודעות בזמן אמת, מכרזים של מודעות להתקנת אפליקציה נדרשים כדי לפעול במסגרת בידינג ומכרז שירותים שפועלים בסביבות TEE. גישה לאותות מוגנים של אפליקציות במהלך מצב מוגן אין תמיכה במכרז במכרזים במכשיר.

תהליך העבודה לבחירת מודעות בארגז החול לפרטיות ב-Android.

תהליך העבודה לבחירת מודעות הוא:

1. ה-SDK של המוכר שולח את המטען הייעודי (payload) המוצפן של המכשיר מוגן אותות מהאפליקציה.
2. השרת של המוכר יוצר הגדרת מכרז ושולח אותה אל שירות 'בידינג מהימן ומכרז' של המוכר, יחד עם מטען ייעודי (payload), להתחלת תהליך עבודה לבחירת מודעות.
3. שירות 'בידינג ומכרזים' של המוכר מעביר את המטען הייעודי (payload) אל השרתים הקדמיים של הקונים המהימנים שמשתתפים בתוכנית.
4. שירות הבידינג של הקונה מפעיל לוגיקה של בחירת מודעות בצד הקונה
   1. הפעלת הלוגיקה של אחזור מודעות בצד הקונה.
   2. ביצוע לוגיקת בידינג בצד הקונה.
5. מתבצעת הרצה של לוגיקת הדירוג בצד המוכר.
6. המודעה מוצגת והדיווח מופעל.

התחלת תהליך העבודה לבחירת מודעות

כשהאפליקציה מוכנה להצגת מודעה, ה-SDK של הפרסום הדיגיטלי (בדרך כלל SSPs) מפעיל את תהליך העבודה של בחירת מודעות על-ידי שליחת נתונים הקשריים רלוונטיים מתוך את בעל התוכן הדיגיטלי ואת מטענים ייעודיים (payloads) המוצפנים לכל קונה שייכללו בבקשה יישלחו למכרז מוגן באמצעות הקריאה getAdSelectionData. הדבר שאותו API משמש לתהליך העבודה של הרימרקטינג ומתואר בקטע בידינג הצעה לשילוב מכרזים ב-Android.

כדי להתחיל בבחירת מודעות, אתר המכירה מעביר את המשתמשים לרשימה של קונים שמשתתפים בתוכנית ומטען ייעודי (payload) מוצפן של אותות אפליקציות מוגנים במכשיר. עכשיו אפשר מידע, שרת המודעות בצד המוכר מכין SelectAdRequest עבור שירות sellersFrontEnd מהימן.

בית העסק מגדיר את הפרטים הבאים:

• המטען הייעודי (Payload) שהתקבל מה-getAdSelectionData, ומכיל את האובייקט אותות מוגנים של אפליקציות.

• האותות לפי הקשר כוללים:

  • auction_config.auction_signals (למשך מידע על המכרז)

  • auction_config.seller_signals (לאותות של בית העסק

  • auction_config.per_buyer_config["buyer"].buyer_signals (עבור קונים אותות)

• רשימת הקונים שנכללים במכרזים שמשתמשים בהם שדה buyer_list.

ביצוע לוגיקה של בחירת מודעות בצד הקונה

באופן כללי, הלוגיקה המותאמת אישית של הקונה משתמשת בנתונים הקשריים שסופקו על ידי בעלי תוכן דיגיטלי ואותות של אפליקציות מוגנים כדי לבחור ולהגיש הצעת מחיר על מודעות רלוונטיות לבקשה להצגת מודעה. הפלטפורמה מאפשרת לקונים לצמצם מאגר גדול של הזמינות של המודעות הרלוונטיות ביותר (K) שלגביהן מחושבות הצעות המחיר לפני שהמודעות יוחזרו למפיץ לצורך בחירה סופית.

לוגיקת הביצוע של בחירת המודעות בצד הקונה בארגז החול לפרטיות ב-Android.

לפני שמגישים הצעות מחיר, הקונים מתחילים עם מאגר גדול של מודעות. איטי מדי לחשב הצעת מחיר לכל מודעה, כך שקודם כל הקונים צריכים לבחור את K המועמדים המובילים מהמאגר הגדול. בשלב הבא, הקונים צריכים לחשב את הצעות המחיר לכל אחד מה-K מועמדים בבחירות. לאחר מכן, המודעות והצעות המחיר האלה מוחזרות למפיץ בחירה.

הערה: התהליך הזה הוא שילוב של קוד framework ופונקציות בהגדרת המשתמש (UDF) שכולל את הלוגיקה העסקית של הקונים. רכיבי ה-UDF האלה מוטמעים ב-JavaScript או WASM. ברמה הכללית, התהליך הוא:

1. שירות BuyerFrontEnd מקבל בקשה להצגת מודעה.
2. שירות BuyerFrontEnd שולח בקשה לשירות הבידינג של הקונה. שירות הבידינג של הקונה מריץ UDF בשם prepareDataForAdRetrieval(), שיוצר בקשה לקבל את K המועמדים המובילים מאחזור המודעות שירות. שירות הבידינג שולח את הבקשה הזו לאחזור שהוגדר נקודת הקצה של השרת.
3. שירות אחזור המודעות מריץ את ה-UDF getCandidateAds(), שמסננים למטה לקבוצת K המודעות המועמדות המובילות, שנשלחות שירות להגשת הצעות מחיר.
4. שירות הבידינג של הקונה מפעיל את ה-UDF generateBid(), שבוחר את המועמד הטוב ביותר, מחשב את הצעת המחיר שלו ואז מחזיר אותה לאחר השיפור.
5. שירות BuyerFrontEnd מחזיר את המודעות ואת הצעות המחיר למפיץ.

יש כמה פרטים חשובים לגבי התהליך הזה, במיוחד בכל מה שקשור איך החלקים משוחחים זה עם זה, ואיך הפלטפורמה מספקת תכונות כמו היכולת ליצור חיזויים של למידת מכונה לאחזור k המודעות המובילות. וחישוב הצעות המחיר שלהן.

לפני שנבחן לעומק חלקים אלו, יש כמה הערות ארכיטקטוניות על אזורי ה-TEE בתרשים שלמעלה.

שירות הבידינג של הקונה מכיל שירות הסקה באופן פנימי. פרסום דיגיטלי יכול להעלות מודלים של למידת מכונה לשירות הבידינג של הקונה. אנחנו לספק ממשקי API של JavaScript לטכנולוגיות פרסום כדי לבצע תחזיות או ליצור הטמעות מהמודלים האלה מתוך פונקציות ה-UDF שפועלים בשירות הבידינג של הקונה. בניגוד לשירות אחזור מודעות, לשירות הבידינג של הקונה אין שירות למפתחות הצפנה לשמירת מטא-נתונים של מודעות.

השירות לאחזור מודעות כולל באופן פנימי שירות מפתח/ערך. טכנולוגיות הפרסום ליצור צמדי מפתח/ערך בשירות הזה מהשרתים שלהם, מחוץ גבולות הפרטיות. אנחנו נספק JavaScript API כדי שהטכנולוגיות של מודעות יוכלו לקרוא שירות מפתח-ערך זה מתוך פונקציות ה-UDF שפועלות בשירות אחזור המודעות. בניגוד לשירות הבידינג של הקונה, שירות אחזור המודעות לא כולל שירות הסקת מסקנות.

אחת מהשאלות המרכזיות בעיצוב הזה היא איך לבצע זמן אחזור חיזויים בזמן הבידינג. התשובה לשתיהן יכולה לכלול פתרון שנקרא פירוק לגורמים של מודלים.

פירוק לגורמים של מודלים

פירוק לגורמים של מודלים היא שיטה שמאפשרת לפרוץ מודל אחד את המודל לכמה חלקים, ואז לשלב את החלקים האלה לחיזוי. לחשבון בתרחיש לדוגמה של התקנת אפליקציה, מודלים משתמשים בדרך כלל בשלושה סוגי נתונים: נתונים, נתונים הקשריים ונתוני מודעות.

במקרה ללא פקטורים, מודל אחד מאומן על כל שלושת הסוגים . במקרה של הפירוק לגורמים, אנחנו מחלקים את המודל לכמה חלקים. רק שהחלק שמכיל נתוני משתמש הוא רגיש. כלומר רק המודל עם החלק של המשתמש צריך לפעול בתוך גבולות האמון, בבידינג של הקונה שירות ההסקה של השירות.

זה מאפשר את העיצוב הבא:

1. מפצלים את המודל לחלק פרטי (נתוני המשתמש) ולחלק אחד או יותר חלקים לא פרטיים (נתוני ההקשר ונתוני המודעות).
2. לחלופין, מעבירים את כל החלקים הלא פרטיים או חלק מהם כארגומנטים ל-UDF שצריך להפיק חיזויים. לדוגמה, הטמעות לפי הקשר מועברים לפונקציות UDF ב-per_buyer_signals.
3. לחלופין, טכנולוגיות הפרסום יכולות ליצור מודלים לפריטים לא פרטיים, ואז להטמיע הטמעות מהמודלים האלה מאגר מפתח/ערך. פונקציות UDF בשירות אחזור מודעות יכולים לאחזר את ההטמעות האלה בזמן ריצה.
4. כדי לבצע חיזוי במהלך UDF, צריך לשלב הטמעות פרטיות שירות הסקת מסקנות עם הטמעות לא פרטיות מארגומנטים של פונקציות UDF מאגר ערך המפתח באמצעות פעולה כמו מכפלה סקלרית. זה האחרון צפי.

לאחר שההסבר הזה מוסבר, אנחנו יכולים לבחון כל UDF בצורה מפורטת יותר. נסביר מה איך הם פועלים, איך הם משתלבים ואיך הם יכולים לבצע את החיזויים הדרושים כדי לבחור את K המודעות המובילות ולחשב את הצעות המחיר שלהן.

ערך ה-UDF של prepareDataForAdRetrieval()

prepareDataForAdRetrieval() שפועל בשירות הבידינג של הקונה הוא אחראי ליצירת המטען הייעודי (payload) של הבקשה שיישלח למודעה שירות אחזור כדי לאחזר את K המודעות המובילות.

prepareDataForAdRetrieval() לוקח את הפרטים הבאים:

• המטען הייעודי (payload) לכל קונה שהתקבל מ-getAdSelectionData. המטען הייעודי (Payload) הזה מכיל את Protected App Signals.
• אותות לפי הקשר auction_signals (למידע על המכרז) וגם buyer_signals (עבור קונים Signals).

prepareDataForAdRetrieval() עושה שתי פעולות:

• ייצוג: אם צריך להסיק מסקנות בזמן האחזור, היא משתנה אותות נכנסים לתכונות לשימוש במהלך שיחות לשירות ההסקה כדי לקבל הטמעות פרטיות לאחזור.
• חישוב הטמעות פרטיות לאחזור: אם חיזויים של אחזור ונדרש, הוא מבצע קריאה נגד שירות ההסקה באמצעות ומקבלים הטמעה פרטית לחיזויים בזמן אחזור.

אפשרות החזרה באמצעות prepareDataForAdRetrieval():

• Protected App Signals: מטען ייעודי (payload) של אותות שנאספו על ידי טכנולוגיות פרסום.
• אותות ספציפיים למכרז: אותות בצד המוכר שספציפיים לפלטפורמה, וכן מידע לפי הקשר כמו auction_signals וגם per_buyer_signals (כולל הטמעות לפי הקשר) מ-SelectAdRequest. התוצאה הזו דומה ל: Protected Audiences (קהלים מוגנים).
• אותות נוספים: מידע נוסף, כמו הטמעות פרטיות שאוחזרו משירות ההסקה.

הבקשה הזו נשלחת לשירות אחזור המודעות, שמבצע התאמות של מועמדויות ואז מריץ את ה-UDF getCandidateAds().

ערך ה-UDF של getCandidateAds()

getCandidateAds() פועל בשירות אחזור המודעות. הוא מקבל את הבקשה נוצר על ידי prepareDataForAdRetrieval() בשירות הבידינג של הקונה. מפעיל את השירות getCandidateAds() שמאחזר את המועמדים המובילים להגיש הצעות מחיר על ידי המרת הבקשה לסדרה של שאילתות מוגדרות, אחזור נתונים, וביצוע לוגיקה עסקית מותאמת אישית ולוגיקה מותאמת אישית לאחזור.

getCandidateAds() לוקח את הפרטים הבאים:

• Protected App Signals: מטען ייעודי (payload) של אותות שנאספו על ידי טכנולוגיות פרסום.
• אותות ספציפיים למכרז: אותות בצד המוכר שספציפיים לפלטפורמה, וכן מידע לפי הקשר כמו auction_signals וגם per_buyer_signals (כולל הטמעות לפי הקשר) מ-SelectAdRequest. התוצאה הזו דומה ל: Protected Audiences (קהלים מוגנים).
• אותות נוספים: מידע נוסף, כמו הטמעות פרטיות שאוחזרו משירות ההסקה.

getCandidateAds() עושה את הפעולות הבאות:

1. אחזור קבוצה ראשונית של מועמדים למודעות: אחזור באמצעות קריטריונים של טירגוט כגון שפה, מיקום גיאוגרפי, סוג מודעה, גודל מודעה או תקציב, כדי לסנן את המועמדים.
2. אחזור הטמעה של נתוני הטמעה: אם ההטמעות משירות המפתח-ערך הן כדי לבצע חיזוי בזמן האחזור של הבחירה המובילות, הן חייבות להיות מאוחזר משירות key-value.
3. בחירת המועמדים המובילים: מחשבים ציון קליל בסינון קבוצה של מועמדים למודעות על סמך מטא-נתונים של מודעות שאוחזרו ממאגר מפתחות/ערך, ומידע שנשלח משירות הבידינג של הקונה על סמך הציון הזה. לדוגמה, הדירוג עשוי להיות סיכוי במהלך ההתקנה של אפליקציה ספציפית במודעה.
4. אחזור הטמעת בידינג: אם ההטמעות (embeddings) משירות מפתח-ערך הן שנדרשים באמצעות קוד הבידינג כדי לבצע תחזיות בזמן הבידינג, ייתכן שהם מאוחזר משירות key-value.

שימו לב שהציון של מודעה עשוי להיות פלט של מודל חיזוי, דוגמה לחיזוי ההסתברות שמשתמש יתקין אפליקציה. הציון הזה כרוכה בסוג של פירוק לגורמים של מודל: כי getCandidateAds() פועל בשירות אחזור המודעות, ומאז שאחזור המודעות לשירות אין שירות הסקה, ייתכן שהחיזויים ייווצרו על ידי שילוב של:

• הטמעות לפי הקשר שמועברות באמצעות אותות שספציפיים למכרז מהקלט.
• הטמעות פרטיות שמועברות באמצעות הקלט של אותות נוספים.
• כל טכנולוגיית פרסום של הטמעות לא פרטיות שהתבססה על השרתים שלה לשירות אחזור המודעות של שירות אחזור המודעות.

חשוב לשים לב שה-UDF generateBid() שפועל בשירות הבידינג של הקונה עשוי להחיל גם פילוח לפי מודל משלו כדי לבצע את הבידינג ויצירת חיזויים. אם נדרשות הטמעות של שירות מפתח/ערך כדי לעשות זאת, צריך לאחזר אותם עכשיו.

אפשרות החזרה באמצעות getCandidateAds():

• מודעות מועמדים: K המודעות המובילות שיועברו אל generateBid(). כל מודעה מורכב מ:
  • כתובת URL לעיבוד: נקודת הקצה לעיבוד הקריאייטיב של המודעה.
  • מטא-נתונים: מטא-נתונים של מודעות בצד הקונה, שספציפיים לטכנולוגיה של מודעות. לדוגמה, עשוי לכלול מידע על קמפיין הפרסום וקריטריונים לטירגוט כמו מיקום ושפה. מטא-נתונים יכולים לכלול שדות אופציונליים הטמעות שבהן צריך לבצע פירוק לגורמים של מודל כדי להריץ מסקנות במהלך הבידינג.
• אותות נוספים: באופן אופציונלי, שירות אחזור המודעות יכול לכלול מידע נוסף, כמו הטמעות נוספות או אותות ספאם שאפשר להשתמש בהם ב-generateBid().

אנחנו בודקים שיטות אחרות למתן ציון למודעות, כולל הופך אותו לזמין כחלק מהשיחה של SelectAdRequest. המודעות האלה יכולות להיות אחזור באמצעות בקשה להצעת מחיר ב-RTB. לתשומת ליבכם: במקרים כאלה, המודעות חייבות אחזור ללא אותות מוגנים של אפליקציות. אנחנו צופים שטכנולוגיות הפרסום להעריך את האיזונים לפני בחירת האפשרות הכי טובה, כולל מטען ייעודי (payload) של תגובה הגודל, זמן האחזור, העלות והזמינות של האותות.

ערך ה-UDF של generateBid()

אחרי אחזור של קבוצת המודעות המועמדות וההטמעות במהלך אחזור, אתם מוכנים להמשיך לבידינג, שמופעל בבידינג של הקונה לאחר השיפור. השירות הזה מפעיל את generateBid() באספקת הקונה UDF כדי לבחור את המודעה שעליה רוצים להגיש הצעת מחיר מה-K המובילים, ואז להחזיר אותה עם הצעת המחיר שלה.

generateBid() לוקח את הפרטים הבאים:

• מודעות מועמדים: K המודעות המובילות שהוחזרו על ידי אחזור המודעות לאחר השיפור.
• אותות ספציפיים למכרז: אותות בצד המוכר שספציפיים לפלטפורמה, וכן מידע לפי הקשר כמו auction_signals וגם per_buyer_signals (כולל הטמעות לפי הקשר) מ-SelectAdRequest.
• אותות נוספים: מידע נוסף לשימוש בזמן הבידינג.

ההטמעה של generateBid() על ידי הקונה כוללת שלוש פעולות:

• Featurization: הופכת אותות לתכונות לשימוש במהלך מסיקה.
• הֶקֵּשׁ: יוצר חיזויים באמצעות מודלים של למידת מכונה כדי לחשב ערכים כמו שיעורי הקליקים הצפויים ושיעורי ההמרות הצפויים.
• בידינג: שילוב של ערכים שהוסקו עם מקורות מידע אחרים, כדי לחשב להגיש הצעת מחיר על מודעה אפשרית.

אפשרות החזרה באמצעות generateBid():

• המודעה המועמדת.
• סכום הצעת המחיר המחושב שלה.

לתשומת ליבך, השדה generateBid() משמש למודעות להתקנת אפליקציה והוא משמש לצורך יש הבדל בין מודעות רימרקטינג.

בקטעים הבאים מתוארים ייצוגים, הסקת מסקנות ובידינג מפורט.

ייצוג דיגיטלי

אפשר להוסיף לתכונות את האותות מהמכרזים על ידי generateBid(). התכונות האלה יכול לשמש במהלך הסקת מסקנות כדי לחזות דברים כמו קליקים בשיעורי ההמרות. אנחנו גם בוחנים מנגנונים לשמירה על הפרטיות כדי להעביר חלק מהם בדוח של הזכייה לצורך אימון מודלים.

הֶקֵּשׁ,

במהלך חישוב הצעת מחיר, מקובל להסיק מסקנות לפי מודלים של למידת מכונה. לדוגמה, כדי לחשב את העלות בפועל לאלף חשיפות, לרוב משתמשים כדי לחזות שיעורי קליקים ושיעורי המרות.

לקוחות יכולים לספק כמה מודלים של למידת מכונה יחד הטמעת generateBid(). נספק גם ממשק API של JavaScript בתוך generateBid() כדי שלקוחות יוכלו לבצע מסקנות בזמן הריצה.

ההסקה מופעלת בשירות הבידינג של הקונה. זה יכול להשפיע על ההסקה זמן אחזור ועלות, במיוחד כי מאיצים עדיין לא זמינים בסביבת TEE. חלק מהלקוחות יענו על הצרכים שלהם בעזרת מודלים נפרדים שפועלים שירות הבידינג של הקונה. חלק מהלקוחות – למשל לקוחות גדולים מאוד מומלץ לשקול אפשרויות כמו פירוק לגורמים של מודלים כדי לצמצם מסקנות את העלות ואת זמן האחזור בזמן הצעת המחיר.

מידע נוסף על יכולות הסקת מסקנות, כמו פורמטים נתמכים של מודלים גדלים מקסימליים יסופקו בעדכון עתידי.

הטמעת פירוק לגורמים של מודלים

מוקדם יותר הסברנו על פירוק לגורמים של מודל. בזמן הבידינג, המודל היא:

1. מפצלים את המודל היחיד לחלק פרטי (נתוני המשתמש) ולחלק אחד או חלקים יותר לא פרטיים (נתוני ההקשר ונתוני המודעות).
2. מעבירים אל generateBid() חלקים לא פרטיים. המקור יכול להיות per_buyer_signals, או מהטמעות שטכנולוגיות הפרסום מחשבים באופן חיצוני, ממשיכים למאגר מפתח/ערך של שירות השליפה, מאחזרים בזמן האחזור זמן מסוים ולהחזיר אותו כחלק מהאותות הנוספים. הדוגמאות הבאות הן לא תוכן מהסוג הזה: הטמעות פרטיות, כי לא ניתן להגיע אליהן מחוץ לפרטיות תחום.
3. באמצעות generateBid():
   1. לבצע הסקת מסקנות על סמך מודלים כדי לקבל הטמעות פרטיות של משתמשים.
   2. לשלב הטמעות פרטיות של משתמשים עם הטמעות לפי הקשר per_buyer_signals או הטמעות של מודעות לא פרטיות והטמעות לפי הקשר שירות אחזור באמצעות פעולה כמו מכפלה סקלרית. כאן התחזית הסופית שדרכה אפשר לחשב הצעות מחיר.

באמצעות הגישה הזו, אפשר לבצע הסקת מסקנות בזמן הבידינג מול שאחרת יהיו גדולים או איטיים מדי להפעלה שירות להגשת הצעות מחיר.

לוגיקת ניקוד בצד המוכר

בשלב הזה, המודעות עם הצעות המחיר שהתקבלו מכל הקונים המשתתפים קיבלו ציון. הפלט של generateBid() מועבר לשירות המכרז של המוכר כדי להפעיל את scoreAd() ו-scoreAd() מתייחס רק למודעה אחת בכל פעם. מבוסס בדירוג, המוכר בוחר מודעה מנצחת שתחזיר את המכשיר ברינדור.

לוגיקת הציון זהה לזו של רימרקטינג מסוג Protected Audience API ויכול לבחור את הגרסה המנצחת ברימרקטינג ובהתקנת האפליקציה מועמדים.הפונקציה תופעל פעם אחת עבור כל מודעה מועמדת שנשלחה מכרז מוגן. אפשר לעיין בהסבר על בידינג ומכרז עבור פרטים.

זמן ריצה של קוד בחירת המודעות

בהצעה, הקוד לבחירת המודעה להתקנת אפליקציה מצוין באותו כמו בתהליך הרימרקטינג Protected Audience API. פרטים נוספים זמינים במאמר הגדרת בידינג ומכרז. קוד הבידינג יהיה באותו מיקום של אחסון בענן שבו אתם משתמשים. לרימרקטינג.

דיווח

בהצעה הזו נעשה שימוש באותם ממשקי API לדיווח כמו Protected Audience Reporting API הצעה (לדוגמה, reportImpression(), שגורם לפלטפורמה לשלוח דוחות מפיצים וקונים).

אחד המקרים הנפוצים לדיווח בצד הקונה הוא קבלת נתוני האימון למודלים ששימשו לבחירת המודעות. נוסף לממשקי ה-API הקיימים, הפלטפורמה תספק מנגנון ספציפי לתעבורת נתונים יוצאת (egressing) ברמת האירוע מפלטפורמה לשרתי פרסום דיגיטלי. מטענים ייעודיים (payloads) של תעבורת נתונים יוצאת (egress) יכולים לכלול משתמשים מסוימים .

לטווח הארוך, אנחנו בודקים פתרונות לשמירה על הפרטיות כדי לטפל אימון מודלים עם נתונים שנעשה בהם שימוש במכרזים מוגנות בלי לשלוח נתונים ברמת האירוע נתוני משתמשים מחוץ לשירותים שפועלים במכשירי TEE. נספק פרטים נוספים בעדכון מאוחר יותר.

בטווח הקצר, נספק דרך זמנית לנתונים עם רעשי תעבורת נתונים יוצאת (egress) מ: generateBid() ההצעה הראשונית שלנו בנושא הזה מפורטת בהמשך, ובהמשך נרחיב אותה (כולל שינויים אפשריים שאינם תואמים לאחור) בתגובה לתעשייה משוב.

מבחינה טכנית, כך זה עובד:

1. טכנולוגיות הפרסום מגדירות סכימה לנתונים שהם רוצים להעביר.
2. ב-generateBid(), הם יוצרים את המטען הייעודי (Payload) הרצוי לתעבורת נתונים יוצאת (egress).
3. הפלטפורמה מאמתת את המטען הייעודי (Payload) של תעבורת נתונים יוצאת (egress) לפי הסכימה ואוכפת מגבלות גודל.
4. הפלטפורמה מוסיפה רעש למטען הייעודי (Payload) של תעבורת נתונים יוצאת.
5. המטען הייעודי (Payloads) של תעבורת הנתונים היוצאת (egress) נכלל בדוח הזכייה בפורמט כבל, שהתקבל בתאריך שרתי פרסום דיגיטלי, מפוענחים ומשמשים לאימון מודלים.

הגדרת הסכימה של מטענים ייעודיים (payloads) של תעבורת נתונים יוצאת

כדי שהפלטפורמה תאכוף דרישות פרטיות ההולכות וגדלות, מטענים ייעודיים (payloads) של תעבורת נתונים יוצאת (egress) צריכים. באופן שהפלטפורמה יכולה להבין. טכנולוגיות הפרסום יגדירו של מטענים ייעודיים (payloads) של תעבורת נתונים יוצאת (egress), באמצעות קובץ JSON עם סכימה. את הסכימה הזו יטופל על ידי הפלטפורמה, והם יישמרו בסודיות על ידי הבידינג ושירותי מכרזים שמשתמשים באותם מנגנונים כמו משאבים אחרים בתחום הפרסום הדיגיטלי כמו פונקציות UDF ודגמים.

אנחנו נספק קובץ CDDL שמגדיר את המבנה של אותו JSON. קובץ CDDL יכלול קבוצת סוגי תכונות נתמכים (לדוגמה, תכונות שהם בוליאניים, מספרים שלמים, קטגוריות וכן הלאה). גם קובץ ה-CDDL וגם תקבל גרסאות.

לדוגמה, מטען ייעודי (payload) של תעבורת נתונים יוצאת (egress) שמכיל תכונה בוליאנית אחת ולאחר מכן תכונת הקטגוריה בגודל 2 תיראה כך:

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

פרטים על קבוצת סוגי התכונות הנתמכים זמינים ב-GitHub.

פיתוח מטענים ייעודיים (payloads) של תעבורת נתונים יוצאת ב-generateBid()

כל אותות האפליקציות המוגנים של קונה נתון זמינים generateBid() UDF. ברגע שהן יהיו מאוזנות, טכנולוגיות הפרסום יוצרות את המטען הייעודי (Payload) שלהן בפורמט JSON. המטען הייעודי (payload) של תעבורת הנתונים היוצאת (egress) ייכלל בדוח הזכייה של הקונה עבור לשרתים של פרסום דיגיטלי.

חלופה לעיצוב הזה היא שחישוב וקטור של תעבורת נתונים יוצאת (egress) יתרחש reportWin() במקום generateBid(). יש יתרונות מרכזיים לכל אחד מהם ונסיים את ההחלטה הזו בתגובה למשוב שמתקבל מהתעשייה.

אימות המטען הייעודי (Payload) של תעבורת נתונים יוצאת (egress)

הפלטפורמה תוודא שמטען ייעודי (payload) של תעבורת נתונים יוצאת (egress) שנוצר על ידי טכנולוגיית הפרסום. אימות מוודא שערכי התכונות תקפים לסוגים שלהם, העמידה במגבלות הגודל ושגורמים זדוניים לא מנסים לעקוף את אמצעי הבקרה על הפרטיות באמצעות לרכז מידע נוסף במטענים ייעודיים (payloads) של תעבורת נתונים יוצאת.

אם מטען ייעודי (payload) של תעבורת נתונים יוצאת (egress) לא תקין, הוא יימחק באופן שקט מקלט באמצעות נשלחו לדוח המנצח. הסיבה לכך היא שאנחנו לא רוצים לספק ניפוי באגים. מידע לגורם זדוני שמנסה לעקוף את האימות.

אנחנו נספק JavaScript API לטכנולוגיות פרסום כדי להבטיח את המטען הייעודי (payload) של תעבורת הנתונים היוצאת (egress). יצירה ב-generateBid() תעבור אימות פלטפורמה:

validate(payload, schema)

ממשק JavaScript API הזה מיועד אך ורק למתקשרים לקבוע אם מטען ייעודי (payload) ספציפי יעבור אימות של הפלטפורמה. צריך לבצע את האימות בפועל בפלטפורמה כדי להגן מפני פונקציות UDF זדוניות של generateBid().

רעשי רקע במטען הייעודי (Payload) של תעבורת הנתונים היוצאת (egress)

הפלטפורמה תרעש מטענים ייעודיים (payloads) של תעבורת נתונים יוצאת לפני הכללתם בדוח המנצח. סף הרעש הראשוני יהיה 1%, והערך הזה עשוי להשתנות עם הזמן. הפלטפורמה לא תספק אינדיקציה אם מטען ייעודי (payload) ספציפי של תעבורת נתונים יוצאת (egress) נשמע רעש.

שיטת הרעש היא:

1. הפלטפורמה טוענת את הגדרת הסכימה של המטען הייעודי (Payload) של תעבורת נתונים יוצאת.
2. 1% מהמטענים הייעודיים של תעבורת הנתונים היוצאת (egress) ייבחרו לצורך רעש.
3. אם לא בוחרים מטען ייעודי (payload) של תעבורת נתונים יוצאת (egress), הערך המקורי כולו נשמר.
4. אם נבחר מטען ייעודי (payload) של תעבורת נתונים יוצאת (egress), הערך של כל מאפיין יוחלף ב- ערך תקין אקראי לסוג הישות (לדוגמה, 0 או 1 עבור תכונה בוליאנית).

העברה, קבלה ופענוח של המטען הייעודי (Payload) של תעבורת נתונים יוצאת (egress) לאימון מודלים

המטען הייעודי (payload) של תעבורת נתונים יוצאת (egress) המאומת והמושמע ייכלל בארגומנטים reportWin(), שמועברים לשרתים של טכנולוגיית פרסום דיגיטלי (ATP) של קונים מחוץ לפרטיות לתחום לאימון מודלים. המטען הייעודי של תעבורת הנתונים היוצאת (egress) יהיה בפורמט החוט שלו.

פרטים על הפורמט של כבלים לכל סוגי התכונות ולמטען הייעודי (payload) של תעבורת נתונים יוצאת (egress) עצמו זמין ב-GitHub.

קביעת גודל המטען הייעודי של תעבורת נתונים יוצאת (egress)

גודל המטען הייעודי (payload) של תעבורת הנתונים היוצאת (egress) במאזן ביטים בין התועלת לצמצום הנתונים. נעבוד עם התעשייה כדי לקבוע את הגודל המתאים באמצעות לבצע במהירות ניסויים, בזמן שנריץ את הניסויים האלה, תעבורת נתונים יוצאת (egress) ללא מגבלת גודל בביט. את נתוני תעבורת הנתונים היוצאת (egress) הנוספים בלי הגבלת הגודל תוסר אחרי שהניסויים יושלמו.

השיטה לקביעת הגודל היא:

1. בשלב הראשון, נתמוך בשני מטענים ייעודיים של תעבורת נתונים יוצאת (egress) ב-generateBid():
   1. egressPayload: המטען הייעודי (payload) של תעבורת נתונים יוצאת (egress) עם גודל מוגבל, שתיארנו עד עכשיו במסמך הזה. בהתחלה, הגודל של המטען הייעודי של תעבורת הנתונים היוצאת (egress) יהיה 0 ביט (כלומר, היא תמיד תוסר במהלך האימות).
   2. temporaryUnlimitedEgressPayload: תעבורת נתונים יוצאת (egress) זמנית ללא הגבלה מטען ייעודי (payload) לניסויי גודל. העיצוב, היצירה והעיבוד במטען הייעודי (Payload) של תעבורת הנתונים היוצאת (egress) משתמשים באותם מנגנונים כמו egressPayload.
2. לכל אחד מהמטענים הייעודיים של תעבורת הנתונים היוצאת (egress) יהיה קובץ JSON עם סכימה משלו: egress_payload_schema.json וגם temporary_egress_payload_schema.json
3. אנחנו מספקים פרוטוקול ניסוי וקבוצה של מדדים לקביעת המודל של מטען ייעודי (payload) במגוון גדלים של תעבורת נתונים יוצאת (לדוגמה, 5, 10, ... ביטים).
4. על סמך תוצאות הניסוי, אנחנו קובעים את גודל המטען הייעודי של תעבורת הנתונים היוצאת (egress) באמצעות הפשרה הנכונה על התועלת והפרטיות.
5. הגדרנו את הגודל של egressPayload מ-0 ביטים לגודל החדש.
6. לאחר תקופת העברה מוגדרת, אנחנו מסירים את temporaryUnlimitedEgressPayload, נשאר רק egressPayload בגודל החדש.

אנחנו בודקים שכבות הגנה טכניות נוספות לניהול השינוי הזה (לדוגמה, הצפנת egressPayload כשמגדילים את הגודל מ-0 ביטים). הפרטים האלה -- לצד תזמון הניסוי וההסרה של temporaryUnlimitedEgressPayload – ייכלל בעדכון מאוחר יותר.

בשלב הבא נסביר על פרוטוקול ניסוי אפשרי להשלמת הגודל של egressPayload המטרה שלנו היא לעבוד עם התעשייה כדי למצוא מידה מאוזנת להגבלה על איסוף המידע והתועלת. פריט המידע שהניסויים האלה ייצרו הוא שבו ציר ה-X הוא גודל המטען הייעודי (payload) של האימון בביטים, ציר ה-y הוא אחוז ההכנסות שהתקבלו ממודל בגודל הזה עד לערכי בסיס ללא הגבלה.

נניח שאנחנו מאמנים מודל pInstall, ואת המקורות של נתוני האימון שלנו הם היומנים שלנו והתוכן של temporaryUnlimitedegressPayload שאנחנו מקבלים כשאנחנו זוכים במכרזים. קודם כל, הפרוטוקולים לטכנולוגיות מודעות כוללים אופליין ניסויים:

1. קביעת הארכיטקטורה של המודלים שישמשו באפליקציה מוגנת אותות. לדוגמה, עליהם להחליט אם הם להשתמש בפירוק לגורמים של מודל.
2. להגדיר מדד למדידת איכות המודל. המדדים המומלצים הם הפסד של AUC ואובדן יומנים.
3. להגדיר את קבוצת התכונות שבהן הם ישתמשו במהלך אימון המודל.
4. באמצעות ארכיטקטורת המודל, מדד האיכות ומאפייני האימון, להריץ מחקרי אבלציה כדי לברר איזו תועלת תרמה לכל ביט שבו הם רוצים להשתמש ב-PAS. הפרוטוקול המוצע למחקר האבלציה היא:
   1. לאמן את המודל עם כל התכונות ולמדוד את היעילות. זה ערך הבסיס להשוואה.
   2. לגבי כל תכונה שמשמשת ליצירת הבסיס, צריך לאמן את המודל עם כל חוץ מהתכונה הזו.
   3. מודדים את התועלת שמתקבלת. חלק את הדלתא בגודל של התכונה בביטים; זו התועלת הצפויה לביט של התכונה הזו.
5. מצאו את הגדלים של המטען הייעודי (payload) הרלוונטי לאימון לצורך ניסוי. רביעי הצעה [5, 10, 15, ..., size_of_all_training_features_for_baseline] ביטים. כל אחד מהגדלים האלה מייצג גודל אפשרי של egressPayload שהניסוי יבצע הערכה.
6. לכל גודל אפשרי, בוחרים קבוצת תכונות שהגודל שלה נמוך או שווה לו כדי להגדיל את התועלת המרבית לכל ביט, על סמך התוצאות של מחקר האבלציה.
7. מאמנים מודל לכל גודל אפשרי ומעריכים עד כמה הוא מועיל אחוז התועלת של מודל הבסיס שאומן על כל התכונות.
8. הציגו את התוצאות בתרשים שבו ציר ה-X הוא הגודל של האימון המטען הייעודי (payload) בביטים, וציר ה-Y הוא אחוז ההכנסה שמתקבלת של המודל בהשוואה לערך הבסיס.

בשלב הבא, טכנולוגיות הפרסום יכולות לחזור על שלבים 5-8 בניסויים בתנועה בזמן אמת, תוך שימוש בתכונה נתונים שנשלחו דרך temporaryUnlimitedEgressPayload. טכנולוגיות הפרסום יכולות לבחור לשתף את התוצאות של ניסויי התנועה אופליין ובתנועה פעילה באמצעות ארגז החול לפרטיות כדי לקבל החלטה לגבי הגודל של egressPayload.

לוח הזמנים לניסויים האלה ולוח הזמנים להגדרת הגודל בסך egressPayload לערך שהתקבל, לא חורג מהיקף המסמך הזה ויהיה עדכון מאוחר יותר.

אמצעים להגנה על הנתונים

אנחנו ניישם כמה הגנות על נתונים של תעבורת נתונים יוצאת (egress), כולל:

1. יהיה רעש גם ב-egressPayload וגם ב-temporaryUnlimitedEgressPayload.
2. לצורך צמצום נתונים והגנה על נתונים, temporaryUnlimitedEgressPayload: יהיו זמינים רק במהלך הניסויים למדידת גדלים, שבהם לקבוע את הגודל הנכון עבור egressPayload.

הרשאות

שליטת משתמשים

• מטרת ההצעה היא לתת למשתמשים חשיפה לרשימת האפליקציות המותקנות שאחסנו לפחות אות אפליקציה מוגן אחד או קהל בהתאמה אישית.
• המשתמשים יכולים לחסום אפליקציות מהרשימה הזו ולהסיר אותן. חסימה והסרה מבצעת את הפעולות הבאים:
  • ניקוי כל אותות האפליקציה המוגנים והקהלים בהתאמה אישית שמשויכים אל את האפליקציה.
  • ההגדרה מונעת מהאפליקציות לאחסן אותות מוגנים חדשים של אפליקציות ואותות מותאמים אישית קהלים
• המשתמשים יכולים לאפס את הנתונים 'מוגנים של אפליקציות' ואת הנתונים 'מוגנים' ממשק ה-API של Audience API לגמרי. במקרה כזה, כל אפליקציה מוגנת קיימת אותות וקהלים בהתאמה אישית במכשיר נמחקים.
• המשתמשים יכולים לבטל את ההסכמה שלהם לגמרי ל'ארגז החול לפרטיות' ב- Android, שכולל את Protected App Signals API ואת Protected Audience API. במקרה כזה, הנתונים של Protected Audience ו-Protected App Signals ממשקי API מחזירים הודעת חריגה רגילה: SECURITY_EXCEPTION.

הרשאות לאפליקציות ואמצעי בקרה

מטרת ההצעה היא לספק לאפליקציות שליטה באותות מוגנים של אפליקציות:

• אפליקציה יכולה לנהל את השיוכים שלה לאותות מוגנים של אפליקציות.
• אפליקציה יכולה להעניק הרשאות לניהול של פלטפורמות טכנולוגיות פרסום של צד שלישי אותות של אפליקציות מוגנים מטעמה.

בקרה על פלטפורמות פרסום דיגיטלי

בהצעה הזו מפורטות הדרכים שבהן טכנולוגיות הפרסום יכולות לשלוט באותות מוגנים של אפליקציות:

• כל טכנולוגיות הפרסום חייבות להירשם לארגז החול לפרטיות ולספק 'אתר' או "origin" דומיין שתואם לכל כתובות ה-URL של 'אותות אפליקציות מוגנים'.
• טכנולוגיות הפרסום יכולות לשתף פעולה עם אפליקציות או ערכות SDK כדי לספק אסימוני אימות משמשים לאימות היצירה של אותות מוגנים של אפליקציות. כשהתהליך הזה אם הוענקה לכם גישה לשותף, אפשר להגדיר יצירה של אות אפליקציה מוגנת כך: דורשים אישור מטכנולוגיות הפרסום.