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

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

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

1. איסוף נתונים והצפנתם למכרז שרתים
2. שליחת בקשה לשירות של מוכר לא מהימן
3. קבלת תגובה משירות של מוכר לא מהימן
4. פענוח התגובה מהמכרז של Protected Audience וקבלת תוצאת המכרז

אנחנו משיקים שני ממשקי API חדשים ל-Protected Audience כדי לתמוך בהפעלת מכרזים בשרת:

1. ממשק ה-API getAdSelectionData אוסף נתונים למכרז השרת ויוצר עומס מוצפן (payload) שמכיל את נתוני המכרז. שרת הבידינג והמכרז משתמש בתוכן הייעודי הזה כדי להפעיל מכרז, ליצור את תוצאת המכרז ולהחזיר את תוצאת המכרז.
2. לקוחות טכנולוגיית פרסום במכשיר יכולים להפעיל את ה-API ‏persistAdSelectionResult כדי לפענח את התוצאה שנוצרה במכרז השרת ולקבל את כתובת ה-URL לעיבוד המודעה הזוכה.

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

1. איסוף והצפנה של נתונים עבור מוכר במכרזים בשרת: טכנולוגיית הפרסום צריכה להפעיל את getAdSelectionData API כדי לקבל את עומס העבודה המוצפן.
2. שליחת בקשה לשירות של מוכר לא מהימן: בקשת HTTP POST או PUT שמכילה את עומס העבודה המוצפן שנוצר על ידי getAdSelectionData API לשירות של המוכר הלא מהימן, ונתונים שנדרשים לשירות של המוכר הלא מהימן כדי ליצור תוצאות לפי הקשר.
3. קבלת תגובה משירות של מוכר לא מהימן: התגובה משירות של מוכר לא מהימן תכלול את התוצאה המוצפנת של המכרז של הקהל המוגן ואת התוצאה של המכרז לפי הקשר.
4. פענוח התשובה מהמכרז של Protected Audience וקבלת תוצאת המכרז: כדי לפענח את תוצאת המכרז של Protected Audience, טכנולוגיית הפרסום של המוכר צריכה לבצע קריאה ל-API‏ persistAdSelectionResult. התוצאה שנוצרת על ידי persistAdSelectionResult תעזור לטכנולוגיות הפרסום לקבוע אם מודעת הקשר או מודעת קהל מוגן ניצחו במכרז, ואת מזהה ה-URI של מודעת הקהל המוגן הזוכה, אם רלוונטי.

תכונות שנתמכות במכרזים בשרת

אנחנו שואפים לתמוך בכל התכונות שזמינות במכרז במכשיר. לוח הזמנים לתמיכה בתכונות האלה במכרזים של שרתים הוא:

הפעלת מכרזים בצד השרת באמצעות Protected Audience API

במסלול 'תצוגה מקדימה למפתחים', AdSelectionManager חושף שני ממשקי API חדשים: getAdSelectionData ו-persistAdSelectionResult. ממשקי ה-API האלה מאפשרים ל-SDK של טכנולוגיות הפרסום להתמזג עם שרתי הבידינג והמכרזים.

איסוף והצפנה של נתונים למכרז שרת

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

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

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. מבצע הקריאה החוזרת צריך להגדיר את השדה seller בבקשה, כי הוא משמש להרצת בדיקות ההרשמה לפני טיפול בבקשה.
2. השדה coordinatorOriginUri הוא אופציונלי.
   1. אם הערך מוגדר, הוא צריך להיות זהה לסכימה, לשם המארח וליציאה של כתובת ה-URL של התיאום שהוגדרה במהלך פריסה של שרת ה-B&A של המוכר.
   2. התיאום חייב להשתייך לרשימת התיאמים המורשים:

      ספק	URI	מקור ה-URI	ברירת מחדל
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	כן
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	לא

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

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

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

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome נוצר כתוצאה מ-API של getAdSelectionData. הוא מכיל את הפרטים הבאים:

1. adSelectionId: מספר שלם אטום לזיהוי ההפעלה הזו של getAdSelectionData. לקוח טכנולוגיית הפרסום צריך לשמור את הערך adSelectionId כי הוא משמש כמצביע לקריאה getAdSelectionData. המזהה הזה נדרש ל-persistAdSelectionResult API כדי לפענח את תוצאת המכרז משרת הבידינג ומשרת המכרז, והוא נדרש גם ל-reportImpression API ול-reportEvent API.
2. adSelectionData: אלה נתוני המכרזים המוצפנים שנדרשים לשרת הבידינג והמכרז כדי להפעיל מכרזים. השיטה הזו מכילה:
   1. נתונים מסוננים של קהלים מותאמים אישית על סמך מכסות תדירות, מסננים של התקנות אפליקציות ודרישות של מכרזים בשרתים לקהלים מותאמים אישית.
   2. בגרסה עתידית, הוא יכיל נתונים על התקנות של אפליקציות.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

שגיאות, חריגים וטיפול בכשלים

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

1. אם getAdSelectionData מופעל עם ארגומנטים לא חוקיים, הערך של AdServicesException מציין ש-IllegalArgumentException היא הסיבה.
2. כל שאר השגיאות מקבלות את הערך AdServicesException עם הערך IllegalStateException כסיבה.

שליחת בקשה לשירות של מוכר לא מהימן

באמצעות AdSelectionData, ערכת ה-SDK במכשיר יכולה לשלוח בקשה לשירות הפרסום של המוכר, על ידי הכללת הנתונים בבקשה מסוג POST או PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
...
})

ה-SDK במכשיר אחראי לקידוד הנתונים האלה. מומלץ להשתמש בפתרון יעיל מבחינת נפח, כמו שליחת הבקשה לשירות המודעות של המוכר כ-multipart/form-data.

קבלת תגובה משירות של מוכר לא מהימן

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

שירות המוכר הלא מהימן מעביר את adSelectionData ו-AuctionConfig המוצפנים לשירות SellerFrontEnd של שרת הבידינג והמכרזים שפועל ב-TEE.

כשהמכרז של Protected Audience מסתיים, השירות SellerFrontEnd מצפין את תוצאת המכרז ומחזיר אותה בתגובה לשירות של המוכר הלא מהימן.

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

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

PersistAdSelectionResult API

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

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

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

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

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: המזהה האטום שנוצר על ידי הקריאה getAdSelectionData, שהמבצע רוצה לפענח את התוצאה שלה.
2. seller: צריך להגדיר בבקשה את מזהה הטכנולוגיה של מודעות של המוכר כדי להריץ בדיקות הרשמה לפני טיפול בבקשה.
3. adSelectionResult: תוצאת המכרז המוצפנת שנוצרה על ידי שרת הבידינג והמכרז, והמבצע רוצה לפענח אותה.

התגובה של AdSelectionOutcome

אם יש זוכה של Protected Audience, הפונקציה AdSelectionOutcome מחזירה את ה-URI של עיבוד המודעה הזוכה.אחרי פענוח ה-adSelectionResult, נתוני הדיווח נשמרים באופן פנימי. פונקציית הקריאה החוזרת OutcomeReceiver.onResult() מחזירה AdSelectionOutcome שמכיל את הפרטים הבאים:

• URI: אם יש מודעה מנצחת עם הגדרת Protected Audience, המערכת מחזירה כתובת URL לעיבוד מודעה של המודעה הזו. אם אין מנצח בקהל המוגן, המערכת מחזירה את הערך Uri.EMPTY.
• adSelectionId: ה-adSelectionId שמשויך להרצה הזו של מכרז השרת.

שגיאות, חריגים וטיפול בכשלים

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

1. אם getAdSelectionData מופעלת עם ארגומנטים לא חוקיים, הערך של AdServicesException יהיה IllegalArgumentException.
2. כל שאר השגיאות מקבלות את הערך AdServicesException עם הערך IllegalStateException כסיבה.

שיקולים בנושא פרטיות

השדה adSelectionData מוצפן כדי לוודא שרק ל-PPAPI ולשרתים המהימנים תהיה גישה לנתונים במעבר.

למרות ההצפנה, יכולה להתרחש דליפת נתונים בגלל הגודל של adSelectionData. גודל השדה adSelectionData עשוי להשתנות בגלל:

1. שינויים בנתוני CustomAudience שנמצאים במכשיר.
2. שינויים בלוגיקה של סינון CustomAudience.
3. שינויים בקלט של קריאה ל-getAdSelectionData.

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

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

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

אופטימיזציה של גודל

ה-SDK של לקוח טכנולוגיית הפרסום אמור לארוז את הבייטים המוצפנים של adSelectionData בקריאה לפי הקשר HTTP PUT/POST שנשלחת לשרת של טכנולוגיית הפרסום. כדי לצמצם את זמן האחזור ואת העלות של זמן הנסיעה הלוך ושוב, צריך לצמצם את הגודל של adSelectionData ככל האפשר בלי להשפיע על התועלת.

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

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

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

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

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

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

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

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

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

   הגדרת המכרז של המוכר תאפשר למוכרים לציין:

   1. רשימת הקונים המורשים: במכרזים שהמוכר התחיל, רק הקונים ברשימת ההיתרים יוכלו לתרום קהלים מותאמים אישית למכרז. צריך לעדכן את הגדרות המכרז מדי יום כדי שרשימה ההיתרים תהיה מעודכנת עם רשימת הרוכשים המורשים בצד השרת.
   2. מגבלת גודל לכל קונה: המוכרים יכולים לציין מגבלה לכל קונה כדי לקבוע את גודל הנתונים שיועלו על ידי כל קונה בעומס הייעודי שנשלח אל SellerFrontendService. אם הקונה חורג מהמגבלה של הגודל לכל קונה, המערכת תשתמש בעדיפות של CustomAudience שהוגדרה בהגדרות של נתוני העומס של הקונה כדי לקבל את הנתונים במסגרת המגבלות הצפויות.
   3. עדיפות לכל קונה: מאפשרת למוכרים להגדיר עדיפות לכל קונה. אם גודל המטען הייעודי יחרוג מהמגבלה, המערכת תשתמש בעדיפות של הקונה כדי לזהות אילו נתוני קונה יישמרו במטען הייעודי.
   4. מגבלת גודל מקסימלית למטען הייעודי (payload): למוכרים שונים יכולה להיות הקצאה שונה של משאבים, ויכול להיות שהם ירצו להגדיר מגבלת גודל מקסימלית למטען הייעודי (payload) של המכרז לכל בקשה. מגבלת הגודל המקסימלי תהיה בהתאם לקטגוריות הגודל הקבועות שהוגדרו על ידי Protected Audience API.

4. שינויים בקהל בהתאמה אישית

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

5. שינויים בנתוני המטען הייעודי (payload)

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

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

אופטימיזציה של זמן האחזור

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

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

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

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

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

   לאחר מכן, הנתונים של Protected Audience ייוצרו מראש על סמך

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

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

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

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

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

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

זיהוי וניכוי של ניצול לרעה

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

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

צמצום הפגיעה

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

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

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

זיהוי ישויות זדוניות

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

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