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

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

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

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

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

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

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

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

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

ציר הזמן

בחירת אותות מוגנים מאפליקציות

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

Protected App Signals API

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

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

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

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

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

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

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

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

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

כדי להוסיף אות, ספקי טכנולוגיית פרסום לקונים שאין להם SDK באפליקציות צריכים לשתף פעולה עם ספקי טכנולוגיית פרסום שיש להם נוכחות במכשיר, כמו שותפים למדידה בנייד (MMP) ופלטפורמות לספקים (SSP). המטרה של Protected App Signals API היא לתמוך בטכנולוגיות פרסום דיגיטלי כאלה על ידי מתן פתרונות גמישים לניהול אותות מוגנים באפליקציות. לשם כך, הממשק מאפשר למי שקורא לו במכשיר להפעיל יצירה של אותות מוגנים באפליקציות בשם הקונים. התהליך הזה נקרא הענקת הרשאה, והוא מתבסס על fetchSignalUpdates() API. ‫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 ‏'site' (אתר) או 'origin' (מקור) לבין הנתונים של ספק טכנולוגיית פרסום רשום. אם ספק טכנולוגיית הפרסום ששולח את הבקשה לא רשום, הבקשה נדחית.

מכסת האחסון והסרת קבצים

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

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

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

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

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

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

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

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

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

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

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

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

כשאפליקציה מוכנה להצגת מודעה, ערכת ה-SDK של טכנולוגיית הפרסום (בדרך כלל פלטפורמות SSP) מתחילה את תהליך בחירת המודעה על ידי שליחת נתונים רלוונטיים מההקשר של בעל האתר ומטענים מוצפנים לכל קונה שייכללו בבקשה שתישלח למכירה הפומבית המוגנת באמצעות הקריאה getAdSelectionData. זהו אותו API שמשמש לתהליך העבודה של רימרקטינג, והוא מתואר בהצעה Bidding And Auction Integration for Android (שילוב של בידינג ומכרזים ב-Android).

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

המוֹכר מגדיר את הפרטים הבאים:

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

• האותות ההקשריים שמשמשים:

  • 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. שירות אחזור המודעות מפעיל את getCandidateAds() UDF, שמסנן את המודעות ומצמצם אותן לקבוצה של k המודעות המובילות הפוטנציאליות, שנשלחות לשירות הבידינג של הקונה.
4. שירות הבידינג של הקונה מריץ את generateBid() UDF, שבוחר את המועמד הטוב ביותר, מחשב את הצעת המחיר שלו ומחזיר אותה לשירות BuyerFrontEnd.
5. שירות BuyerFrontEnd מחזיר את המודעות ואת הצעות המחיר למוכר.

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

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

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

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

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

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

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

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

כך אפשר ליצור את העיצוב הבא:

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

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

הפונקציה prepareDataForAdRetrieval() UDF

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

‫prepareDataForAdRetrieval() מקבל את הפרטים הבאים:

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

‫prepareDataForAdRetrieval() עושה שני דברים:

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

החזרות: prepareDataForAdRetrieval()

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

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

הפונקציה getCandidateAds() UDF

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

‫getCandidateAds() מקבל את הפרטים הבאים:

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

‫getCandidateAds() מבצע את הפעולות הבאות:

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

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

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

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

החזרות: getCandidateAds()

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

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

הפונקציה generateBid() UDF

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

‫generateBid() מקבל את הפרטים הבאים:

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

ההטמעה של הקונה generateBid() מבצעת שלוש פעולות:

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

החזרות: generateBid()

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

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

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

הפיכת נתונים לתכונות

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

הסקת מסקנות

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

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

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

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

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

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

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

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

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

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

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

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

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

דיווח

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

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

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

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

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

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

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

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

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

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

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

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

יצירת מטען ייעודי (payload) ליציאה ב-generateBid()

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

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

אימות מטען הייעודי (payload) של התעבורה היוצאת

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

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

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

validate(payload, schema)

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

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

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

שיטת הוספת הרעש היא:

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

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

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

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

קביעת הגודל של מטען ייעודי (payload) של יציאה

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

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

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

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

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

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

1. קובעים את הארכיטקטורה של המודלים שישמשו אותם עם Protected App Signals. לדוגמה, הם יצטרכו להחליט אם להשתמש בפירוק לגורמים של מודל.
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 הוא הגודל של מטען הייעודי לאימון בביטים, וציר ה-Y הוא אחוז ההכנסה שהמודל הזה הניב בהשוואה לנתוני הבסיס.

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

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

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

אנחנו נחיל מספר אמצעי הגנה על נתונים שיוצאים, כולל:

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

הרשאות

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

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

הרשאות שניתנות לאפליקציה ושליטה בהן

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

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

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

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

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