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

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

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

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

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

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

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

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

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

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

ציר הזמן

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

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

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

Protected App Signals API

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

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

• אות סקלרי עם מפתח ערך בסיס 64 '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).

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

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

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

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

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

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

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

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

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

המפיץ מגדיר את ההגדרות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

רוויזציה

אפשר להכין את אותות המכרז על ידי generateBid() לתכונות. ניתן להשתמש בתכונות האלה במהלך הֶקֵּשׁ כדי לחזות דברים כמו שיעור קליקים ושיעורי המרות. אנחנו גם בודקים מנגנונים להבטחת שמירה על פרטיות, כדי להעביר חלק מהם בדוח הזכייה לשימוש באימון מודלים.

מסקנות

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

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

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

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

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

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

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

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

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

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

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

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

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

דיווח

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

validate(payload, schema)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הרשאות

בקרת משתמשים

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