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

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

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

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

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

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

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

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

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

ציר הזמן

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

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

Protected App Signals API

‫Protected App Signals API תומך בניהול אותות באמצעות מנגנון העברה שדומה למנגנון שמשמש לקהלים מותאמים אישית. ‫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.

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

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

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

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

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

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

אם הקונה לא רשם מקודד אותות, האותות לא מוכנים ואף אחד מהאותות שנאספו במכשיר לא נשלח לשירותים Bidding ו-Auction.

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

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

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

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

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

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

‫prepareDataForAdRetrieval() מקבל את המידע הבא:

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

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

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

החזרות: prepareDataForAdRetrieval()

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

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

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

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

‫getCandidateAds() מקבל את המידע הבא:

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

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

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

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

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

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

החזרות: getCandidateAds()

• מודעות מועמדות: k המודעות המובילות שיועברו אל generateBid(). כל מודעה מורכבת מהרכיבים הבאים:
  • כתובת URL של רכיב rendering: נקודת קצה ל-rendering של הקריאייטיב של המודעה.
  • מטא-נתונים: מטא-נתונים של מודעות שספציפיים לטכנולוגיית פרסום בצד הקונה. לדוגמה, יכול להיות שהמידע יכלול פרטים על הקמפיין הפרסומי וקריטריונים לטירגוט כמו מיקום ושפה. המטא-נתונים יכולים לכלול הטמעות אופציונליות שמשמשות כשצריך פירוק מודל כדי להפעיל הסקה במהלך הבידינג.
• אותות נוספים: באופן אופציונלי, שירות אחזור המודעות יכול לכלול מידע נוסף כמו הטמעות נוספות או אותות ספאם לשימוש ב-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) של התנועה היוצאת נכלל בדוח הזכייה בפורמט wire, מתקבל בשרתים של טכנולוגיית הפרסום, מפוענח ומשמש לאימון המודל.

הגדרת הסכימה של מטען ייעודי (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.

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

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

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

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

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

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

אנחנו נספק JavaScript API לטכנולוגיות פרסום כדי לאמת את מטען ה-payload של היציאה שהן יוצרות ב-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) של היציאה יהיה בפורמט שלו להעברה.

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

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

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

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

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, ומקורות נתוני האימון שלנו הם היומנים והתוכן של temporaryUnlimitedegressPayloads שאנחנו מקבלים כשאנחנו זוכים במכרזים. הפרוטוקול לטכנולוגיות פרסום כולל קודם ניסויים אופליין:

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 כדי לספק אסימוני אימות שמשמשים לאימות של יצירת אותות מוגנים של אפליקציות. כשמייפים את התהליך הזה לשותף, אפשר להגדיר את יצירת האותות המוגנים מהאפליקציה כך שיידרש אישור מטכנולוגיית הפרסום.