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

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

תהליך המכרז של Protected Audience API.

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

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

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

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

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

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

GetAdSelectionDataתוצאה

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

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

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

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

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

1. אם getAdSelectionData מתחיל עם ארגומנטים לא חוקיים, AdServicesException` מציין שהסיבה היא בלבול חריג.
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 API.

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

ממשק 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) {}

PersistAdSelectionAnswerRequest

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

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

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

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

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

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

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

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

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

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

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

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

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

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