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

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

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

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

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

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

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

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

במסלול של התצוגה המקדימה למפתחים, 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	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. המזהה הזה נדרש על ידי ה-API persistAdSelectionResult כדי לפענח את תוצאת המכרז מבידינג ומשרת המכרזים. הוא נדרש גם בממשקי ה-API של reportImpression ושל reportEvent.
2. adSelectionData: אלה נתוני המכרז המוצפנים שנדרשים על ידי שרת הבידינג ושרת המכרז כדי להפעיל מכרזים. ה-method הזה מכיל:
   1. נתוני קהלים מותאמים אישית מסוננים לפי מכסת תדירות, מסננים של התקנות אפליקציה ודרישות במכרזים של שרתים לקהלים בהתאמה אישית.
   2. בגרסה עתידית היא תכלול נתונים לגבי התקנות של האפליקציה.

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

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

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

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

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

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

ממשק API של PersistAdSelectionRecommendation

כדי לפענח את התוצאה 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תוצאה

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

• URI: אם זוהתה מודעה מנצחת מסוג Protected Audience API, תוצג כתובת ה-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 לכל הקריאות ל-API של getAdSelectionData. בגרסאות הראשוניות, כל ערכי ה-CustomAudiences במכשיר משמשים ליצירת adSelectionData, והמטען הייעודי (payload) המוצפן יותאם למגבלות הגודל השונות. בנוסף, נגביל את ההשפעה של GetAdSelectionData פרמטרים של קלט על רכיבי adSelectionData שנוצרו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   במקרה כזה, היצירה מראש של נתוני Protected Audience API תתבסס על

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

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