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

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

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

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

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

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

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

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

1. איסוף והצפנה של נתונים עבור מוכר במכרזים בצד השרת: טכנולוגיית הפרסום צריכה להפעיל את getAdSelectionData API כדי לקבל את עומס העבודה המוצפן.
2. שליחת בקשה לשירות של מוכר לא מהימן: בקשת HTTP POST או PUT שמכילה את עומס העבודה המוצפן שנוצר על ידי getAdSelectionData API לשירות של המוכר הלא מהימן, ונתונים שנדרשים לשירות של המוכר הלא מהימן כדי ליצור תוצאות לפי הקשר.
3. קבלת תגובה משירות של מוכר לא מהימן: התגובה משירות של מוכר לא מהימן תכלול את התוצאה המוצפנת של המכרז לקהלים מוגנים ואת התוצאה של המכרז לפי הקשר.
4. פענוח התגובה של מכרז עם הגנה על קהל יעד וקבלת תוצאת המכרז: כדי לפענח את תוצאת המכרז עם הגנה על קהל יעד, טכנולוגיית הפרסום של המוכר צריכה לבצע קריאה ל-persistAdSelectionResult API. התוצאה שנוצרת על ידי 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 באמצעות קריאה ל-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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

צמצום הפגיעה

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

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

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

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

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

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