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

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

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

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

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

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

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

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

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

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

ציר הזמן

עריכה של אותות של אפליקציות מוגנות

אות הוא ייצוג של אינטראקציות שונות של משתמשים באפליקציה, שהטכנולוגיה של מודעות קובעת שהן מועילות להצגת מודעות רלוונטיות. אפליקציה או ה-SDK המובנה יכולים לאחסן או למחוק אותות מוגנים של אפליקציות שמוגדרים על ידי טכנולוגיות פרסום על סמך פעילות המשתמשים, כמו פתיחת אפליקציות, הישגים, פעילות רכישה או זמן שהייה באפליקציה. אותות מוגנים של אפליקציות מאוחסנים באופן מאובטח במכשיר ומאובטחים לפני שהם נשלחים מהמכשיר, כך שרק שירותי בידינג ומכרזים שפועלים בסביבות של Trusted Execution Environments עם אמצעי אבטחה ובקרה מתאימים על הפרטיות יכולים לפענח אותם לצורך בידינג וסיווג מודעות. בדומה ל-Custom Audience API, לאפליקציות או ל-SDKs אין אפשרות לקרוא או לבדוק את האותות ששמורים במכשיר. אין ממשק 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 מורכב מהחלקים הבאים:

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

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

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

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

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

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

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

כל המפתחות והערכים מפורטים ב-Base64.

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

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

מכסת אחסון והוצאה משימוש

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • auction_config.seller_signals (לאותות של המוכר

  • auction_config.per_buyer_config["buyer"].buyer_signals (לאותות של הקונים)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פונקציית ה-UDF‏ prepareDataForAdRetrieval()

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

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

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

prepareDataForAdRetrieval() מבצעת שתי פעולות:

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

הפונקציה prepareDataForAdRetrieval() מחזירה:

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

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

פונקציית ה-UDF‏ getCandidateAds()

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

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

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

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

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

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

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

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

הפונקציה getCandidateAds() מחזירה:

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

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

פונקציית ה-UDF‏ generateBid()

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

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

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

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

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

הפונקציה generateBid() מחזירה:

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

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

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

הוספת תכונות

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

מסקנה

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

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

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

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

הטמעת גורם מודל

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

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

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

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

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

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

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

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

דיווח

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

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

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

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

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

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

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

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

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

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

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

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

יצירת עומסי נתונים יוצאים ב-generateBid()

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

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

אימות של עומס העבודה (payload) היוצא

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

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

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

validate(payload, schema)

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

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

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

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

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

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

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

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

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

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

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

1. בשלב הראשון נתמוך בשני עומסי נתונים יוצאים ב-generateBid():
   1. egressPayload: עומס התעבורה היוצאת (egress) מוגבל בגודל, כפי שתיארנו עד עכשיו במסמך הזה. בהתחלה, גודל המטען הייעודי (payload) של תעבורת הנתונים היוצאת יהיה 0 ביט (כלומר, הוא תמיד יוסר במהלך האימות).
   2. temporaryUnlimitedEgressPayload: עומס נתונים יוצא זמני ללא הגבלת גודל לניסויים בגודל. הפורמט, היצירה והעיבוד של עומס העבודה הזה בתעבורת נתונים יוצאת מתבצעים באמצעות אותם מנגנונים כמו egressPayload.
2. לכל אחד מנתוני העומס היוצאים האלה יהיה קובץ 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 הוא גודל המטען הייעודי לצורכי אימון בביטים, וציר ה-y הוא אחוז ההכנסה שהניב מודל בגודל הזה בהשוואה לקו בסיס ללא הגבלת גודל.

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

1. לקבוע את הארכיטקטורה של המודלים שבהם הם ישתמשו עם אותות של אפליקציות מוגנות. לדוגמה, הם יצטרכו לקבוע אם הם ישתמשו בגורם מודל או לא.
2. מגדירים מדד למדידת איכות המודל. המדדים המוצעים הם אובדן AUC ואובדן ביומן.
3. מגדירים את קבוצת המאפיינים שבהם הם ישתמשו במהלך אימון המודל.
4. בעזרת ארכיטקטורת המודל, מדד האיכות וקבוצת מאפייני האימון האלה, אפשר להריץ מחקרים של הסרה (ablation) כדי לקבוע את התועלת שמניב כל ביט בכל מודל שרוצים להשתמש בו ב-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 כדי לספק אסימוני אימות שמשמשים לאימות היצירה של אותות מוגנים מאפליקציות. כשהתהליך הזה מוקצה לשותף, אפשר להגדיר את היצירה של אותות של אפליקציות מוגנות כך שתחייב אישור מצד חברת טכנולוגיית הפרסום.