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

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

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

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

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

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

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

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

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

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

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

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

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

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

GetAdSelectionDataOutcome

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

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

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

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

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

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

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

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: אם יש מודעה מקהל מוגן שזכתה, מוחזרת כתובת URL של עיבוד המודעה הזו. אם אין מנצח ב-Protected Audience, הערך `Uri.EMPTY מוחזר.
• ‫adSelectionId: המזהה adSelectionId שמשויך להרצת המכרז בשרת הזה.

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

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

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

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

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

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

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

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

   ההגדרה הזו תשמש להערכת התרומה של הקונה לadSelectionData שנוצר עבור כל בקשת getAdSelectionData.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   ההנחה היא שנתוני Protected Audience שנוצרו מראש יתבססו על

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

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

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

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

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

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

צמצום ניצול לרעה וזיהוי

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

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

צמצום הפגיעה

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

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

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

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

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

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