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

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

תהליך המכרז של 'קהל מוגן'.

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

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

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

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

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

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

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

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

	מכרז במכשיר		מכירה פומבית של שרתים
	תצוגה מקדימה למפתחים	בטא	תצוגה מקדימה למפתחים	בטא
דיווח על זכיות ברמת האירוע	רבעון 1 2023	רבעון 3 של 2023	לא רלוונטי	רבעון 4 של 2023
תהליך בחירת הרשת (Mediation) ב-Waterfall	רבעון 1 2023	רבעון 4 של 2023	לא רלוונטי	רבעון 1 24
סינון של מכסת תדירות	רבעון 2 של 2023	רבעון 3 של 2023	לא רלוונטי	רבעון 4 של 2023
העברת מודעות לפי הקשר לתהליך העבודה של בחירת המודעות לצורך סינון	רבעון 2 של 2023	רבעון 1 2024	לא רלוונטי	לא רלוונטי
דיווח על אינטראקציות	רבעון 2 של 2023	רבעון 3 של 2023	לא רלוונטי	רבעון 4 של 2023
איך מצטרפים אל הקצאת הרשאות לניהול קהלים בהתאמה אישית	רבעון 3 של 2023	רבעון 4 של 2023	לא רלוונטי	רבעון 4 של 2023
חיוב לפי עלות לאלף חשיפות	רבעון 3 של 2023	רבעון 4 של 2023
דיווח על ניפוי באגים	רבעון 3 של 2023	רבעון 4 של 2023	רבעון 3 של 2023	רבעון 4 של 2023
תהליך בחירת הרשת (Mediation) ב-Open Bidding	לא רלוונטי	לא רלוונטי	לא רלוונטי	רבעון 1 2024
סינון מודעות להתקנת אפליקציות	רבעון 2 של 2023	רבעון 1 2024	לא רלוונטי	רבעון 1 2024
ניהול מטבעות	לא רלוונטי	לא רלוונטי	לא רלוונטי	רבעון 1 2024
שילוב K-anon	לא רלוונטי	רבעון 1 2024	לא רלוונטי	רבעון 1 2024
שילוב של צבירה פרטית	לא רלוונטי	לא רלוונטי	לא רלוונטי	רבעון 3 של 2024

הפעלת מכרזים של שרתים באמצעות ממשקי 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

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

public class GetAdSelectionDataRequest {
  Public setSeller(AdTechIdentifier seller);
}

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

GetAdSelectionDataOutcome

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

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

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

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

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

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

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

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

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

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

קבלת תשובה משירות לא מהימן של בית עסק

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

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

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

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

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

ממשק API של PersistAdSelectionResults

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

תגובה של AdSelection Results

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

• URI: אם קיימת מודעה זוכה במסגרת Protected Audience API, תוחזר כתובת URL של עיבוד מודעה למודעה הזוכה. אם אין מנצח מנצח ב-Protected Audience API, מוחזר '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 ליצירת מזהה בין אפליקציות, כפי שצוין בדיון בנושא דליפה ב-1 ביט. ניתן ליישם כאן גם הקלות רבות שרלוונטיות לדליפה של 1 ביט.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זיהוי וצמצום של התנהלות פוגעת

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

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

צמצום הפגיעה

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

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

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

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

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

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