הצעת העיצוב של Bidding and Auction Services for Android מפרטת את הביצוע וזרימת הנתונים של מכרזים פעילים ב-Android באמצעות שרת המכרזים והבידינג המהימן. כדי לוודא שהנתונים במעבר יטופלו רק על ידי ממשקי API לשמירה על הפרטיות ושרתים מהימנים, הנתונים מוצפנים בין הלקוח לשרת באמצעות הצפנה דו-כיוונית של מפתח ציבורי היברידי.
כדי להפעיל את המכרז כפי שפירטנו קודם, טכנולוגיית המודעות של בית העסק במכשיר צריכה לבצע את השלבים הבאים:
- איסוף והצפין של נתונים למכירה פומבית של שרתים
- שליחת בקשה לשירות בית עסק לא מהימן
- קבלת תשובה משירות בתי עסק לא מהימן
- פענוח התגובה מהמכרז של Protected Audience וקבלת תוצאת המכרז
Protected Audience API פותח שני ממשקי API חדשים כדי לתמוך בהרצת מכרזים של שרתים:
- ה-API של
getAdSelectionData
אוסף נתונים למכירה הפומבית של השרת ויוצר מטען ייעודי (payload) מוצפן שמכיל את נתוני המכרז. שרת הבידינג והמכרז משתמש במטען הייעודי (payload) הזה כדי להפעיל מכרז, ליצור את התוצאה מהמכרז ולהחזיר את התוצאה של המכרז. - לקוחות בתחום טכנולוגיית הפרסום במכשיר יכולים לשלוח קריאה ל-API של
persistAdSelectionResult
כדי לפענח את התוצאה שנוצרה מהמכרז בשרת ולקבל את כתובת ה-URL הזוכה לעיבוד המודעות.
כדי להפעיל מכרז, טכנולוגיית הפרסום של בית העסק במכשיר צריכה לשלב ולבנות את הרכיבים הבאים:
- איסוף והצפנה של נתונים עבור בתי העסק שמשתתפים במכרזים של שרתים: טכנולוגיית הפרסום צריכה לקרוא ל-API
getAdSelectionData
כדי לקבל את המטען הייעודי (payload) המוצפן. - שליחת בקשה לשירות בית העסק הלא מהימן: בקשת
HTTP POST
אוPUT
שמכילה את המטען הייעודי (payload) המוצפן שנוצר על ידי API שלgetAdSelectionData
לשירות המכירה הלא מהימן, והנתונים שנדרשים על ידי שירות המוכר הלא מהימן כדי ליצור תוצאות לפי הקשר. - קבלת תגובה משירות בתי עסק לא מהימן: התשובה משירות אתרי מכירה לא מהימן תכיל את תוצאת המכרז המוצפנת של הקהל המוגן ואת תוצאת המכרז לפי ההקשר.
- להצפין את התגובה מהמכרז של הקהל המוגן ולקבל את תוצאת המכרז:
כדי לפענח את תוצאת המכרז של הקהל המוגן, טכנולוגיית המודעות של בית העסק צריכה להפעיל את ה-API
persistAdSelectionResult
. התוצאה שנוצרה על ידיpersistAdSelectionResult
תעזור לטכנולוגיות פרסום לקבוע אם מודעה לפי הקשר או מודעה שמוצגת לקהל מוגן זכו במכרז, וב-URI של המודעה שזכתה במכרז, אם רלוונטי.
תכונות שנתמכות במכרזי שרת
אנחנו משתדלים לתמוך בכל התכונות שזמינות כרגע במכרזים במכשיר. לוח הזמנים לתמיכה בתכונות האלה במכרז השרת:
מכרז במכשיר |
מכרז שרת |
|||
תצוגה מקדימה למפתחים |
בטא |
תצוגה מקדימה למפתחים |
בטא |
|
דוחות על זכייה ברמת האירוע |
רבעון 1 של שנת 2023 |
רבעון 3 של שנת 2023 |
לא רלוונטי |
רבעון 4 של שנת 2023 |
רבעון 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
- מבצע הקריאה החוזרת יצטרך להגדיר את השדה
seller
בבקשה, כי הוא משמש להרצת בדיקות הרשמה לפני שליחת הבקשה. - השדה
coordinatorOriginUri
הוא אופציונלי.- אם היא מוגדרת, הפרטים האלה צריכים להיות זהים לסכמה, לשם המארח וליציאה של כתובת ה-URL של המתאם שהוגדרו במהלך פריסת שרת ה-B&A של המוכר.
- המתאם חייב להשתייך לרשימת המתאמים שאושרו:
ספק 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 לא - אם לא צוין מקור מתאם, נעשה שימוש במתאם ברירת המחדל.
- למרות שלא סביר מאוד שכתובת ה-URL של המתאם תשתנה, מומלץ מאוד להטמיע מנגנון לניהול כתובת ה-URL הזו באופן דינמי. כך אפשר להבטיח ששינויים עתידיים בכתובת ה-URL יטופלו בלי שיהיה צורך במהדורה חדשה של SDK.
public class GetAdSelectionDataRequest {
public setSeller(AdTechIdentifier seller);
public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}
אחרי אימות הבקשה, נתוני הקונים במכשיר מורכבים מהשדות BuyerInput
ו-ProtectedAudienceInput
. לאחר מכן, אובייקט המטען הייעודי (Payload) הסופי מוצפן באמצעות הצפנה היברידית דו-כיוונית של מפתח ציבורי.
GetAdSelectionDataOutcome
הפונקציה GetAdSelectionDataOutcome
נוצרת כתוצאה של getAdSelectionData
API. היא מכילה את הדברים הבאים:
adSelectionId
: מספר שלם אטום לזיהוי ההפעלה שלgetAdSelectionData
. לקוח הפרסום הדיגיטלי צריך לשמור את הערך הזה שלadSelectionId
כי הוא משמש כסמן לקריאה שלgetAdSelectionData
. המזהה הזה נדרש על ידי ה-APIpersistAdSelectionResult
כדי לפענח את תוצאת המכרז מבידינג ומשרת המכרזים. הוא נדרש גם בממשקי ה-API שלreportImpression
ושלreportEvent
.adSelectionData
: אלה נתוני המכרז המוצפנים שנדרשים על ידי שרת הבידינג ושרת המכרז כדי להפעיל מכרזים. ה-method הזה מכיל:- נתוני קהלים מותאמים אישית מסוננים לפי מכסת תדירות, מסננים של התקנות אפליקציה ודרישות במכרזים של שרתים לקהלים בהתאמה אישית.
- בגרסה עתידית היא תכלול נתונים לגבי התקנות של האפליקציה.
public class GetAdSelectionDataOutcome {
Public getAdSelectionId(long adSelectionId);
public byte[] getAdSelectionData();
}
שגיאות, חריגים וטיפול בכשלים
אם אי אפשר להשלים את יצירת הנתונים של בחירת המודעות מסיבות כמו ארגומנטים לא חוקיים, זמנים קצובים לתפוגה או צריכת משאבים מופרזת, הקריאה החוזרת של OutcomeReceiver.onError()
מספקת AdServicesException
עם התנהגויות הבאות:
- אם הפקודה
getAdSelectionData
מתחילה עם ארגומנטים לא חוקיים, הערךAdServicesException
מציין שהסיבה היא DisallowArgumentexcepting. - כל שאר השגיאות מקבלות ערך
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);
}
adSelectionId
: המזהה האטום שנוצר על ידי הקריאהgetAdSelectionData
שאת התוצאה שלה הוא רוצה לפענח.seller
: צריך להגדיר את מזהה טכנולוגיית הפרסום של בית העסק בבקשה להרצת בדיקות הרשמה לפני שליחת הבקשה.adSelectionResult
: תוצאת המכרז המוצפנת שנוצרה על ידי שרת הבידינג והמכרזים שהקוראים רוצים לפענח.
תגובת AdSelectionתוצאה
אם יש מנצחת Protected Audience, אז AdSelectionOutcome
מחזיר את ה-URI של רינדור המודעה הזוכה.אחרי הפענוח של adSelectionResult
, נתוני הדיווח נשמרים באופן פנימי. הקריאה החוזרת של OutcomeReceiver.onResult()
מחזירה AdSelectionOutcome
שמכיל:
URI
: אם זוהתה מודעה מנצחת מסוג Protected Audience API, תוצג כתובת ה-URL של רינדור המודעה למודעה שזכתה במכרז. אם אין מנצחת Protected Audience, מוחזר הערך 'Uri.EMPTY'.adSelectionId
: השדהadSelectionId
המשויך למכרז השרת הזה.
שגיאות, חריגים וטיפול בכשלים
אם אי אפשר להשלים את יצירת הנתונים של בחירת המודעות מסיבות כמו ארגומנטים לא חוקיים, זמנים קצובים לתפוגה או צריכת משאבים מופרזת, הקריאה החוזרת של OutcomeReceiver.onError()
מספקת AdServicesException
עם התנהגויות הבאות:
- אם הפקודה
getAdSelectionData
מתחילה עם ארגומנטים לא חוקיים, הערךAdServicesException
מציין שהסיבה לכך היאIllegalArgumentException
. - כל שאר השגיאות מקבלות ערך
AdServicesException
עםIllegalStateException
כהסיבה.
שיקולי פרטיות
adSelectionData
מוצפן כדי לוודא שהנתונים במעבר יהיו נגישים רק ל-PPAPI ולשרתים המהימנים.
למרות ההצפנה, ייתכן שדליפת נתונים תתרחש בגלל גודל של adSelectionData
. הגודל של adSelectionData
יכול להשתנות בגלל:
- שינויים בנתונים של
CustomAudience
קיימים במכשיר. - שינויים בלוגיקת הסינון של
CustomAudience
. - שינויים בקלט של שיחת
getAdSelectionData
.
אפשר להשתמש בשינוי הגודל של adSelectionData
ליצירת מזהה בכל האפליקציות, כפי שמתואר בדיון בנושא דליפת ביט. גם הרבה מיטיגציות שרלוונטיות לדליפת ביט ביט רלוונטיות במקרה הזה.
כדי לנהל את ההדלפות, אנחנו מתכננים ליצור את אותו adSelectionData
לכל הקריאות ל-API של getAdSelectionData
. בגרסאות הראשוניות, כל ערכי ה-CustomAudiences
במכשיר משמשים ליצירת adSelectionData
, והמטען הייעודי (payload) המוצפן יותאם למגבלות הגודל השונות. בנוסף, נגביל את ההשפעה של GetAdSelectionData
פרמטרים של קלט על רכיבי adSelectionData
שנוצרו.
עם זאת, יצירת adSelectionData
זהה לכל טכנולוגיות הפרסום באמצעות כל נתוני המכרזים במכשיר יוצרת מטען ייעודי (payload) גדול שצריך להעביר עכשיו בכל קריאה לשרת טכנולוגיות הפרסום. השימוש בכל הקהלים המותאמים אישית במכשיר כדי ליצור מטען ייעודי (payload) של מכרזים גם פותח את הסביבה העסקית לניצול לרעה של ישויות זדוניות. עסקנו בחששות האלה בקטעים אופטימיזציות של גודל והקלות בהתנהלות פוגעת שבהמשך.
אופטימיזציות של גודל
ה-SDK של לקוח הפרסום הדיגיטלי צפוי לכלול את הבייטים המוצפנים של adSelectionData
בהפעלה של HTTP PUT/POST
לפי הקשר, שתועבר לשרת של טכנולוגיות הפרסום. כדי לצמצם את זמן האחזור והעלות של הנסיעה הלוך ושוב, חשוב להקטין עד כמה שאפשר את הגודל של adSelectionData
בלי להשפיע על התועלת.
אנחנו מתכננים לבדוק בגרסאות הבאות את האופטימיזציות הבאות ואולי גם להשיק אותן כדי להקטין את נפח האחסון של adSelectionData
:
המטען הייעודי (Payload) שנוצר בקבוצה קבועה של גדלים של קטגוריות עם מרווח פנימי: כדי לצמצם את הדליפה מוריאציות של גדלים ועדיין לאפשר מטענים ייעודיים (payloads) נמוכים יותר, מומלץ להשתמש בקטגוריות בגודל קבוע למטען הייעודי (payload) שנוצר. אם, למשל, מספר הקטגוריות יהיה קטן, 7 יהיה פחות מ-3 ביטים של אנטרופיה דלפה בכל קריאה ל-
getAdSelectionData
.אם הנתונים במכשיר חורגים מהגודל המקסימלי לקטגוריה, השיטות שמפורטות בהמשך, כמו ערכי עדיפות, ישמשו כדי להחליט אילו נתונים יושלמו.
הגדרת הקונה: אנחנו בודקים את ההיתכנות לאפשר לקונים להגדיר תצורת מטען ייעודי (payload) לכל קונה. בעזרת ההגדרה הזו אפשר לזהות לאילו מכירות פומביות קונה מעוניין להצטרף. אם זה אפשרי, במהלך ההרשמה, טכנולוגיית הפרסום של הקונה תוכל לרשום נקודת קצה שממנה Protected Audience API יאחזר הגדרות של מטען ייעודי (payload) בקצב קבוע מדי יום. לחלופין, ממשקי API לשמירה על הפרטיות יחשפו ממשק API כדי לאפשר לטכנולוגיות הפרסום של הקונים לרשום את נקודת הקצה.
ההגדרה הזאת תשמש אותנו כדי להעריך את התרומה של קונה ל-
adSelectionData
שנוצר לכל בקשתgetAdSelectionData
.תצורת המטען הייעודי (payload) של הקונה תאפשר לקונים לציין:
- רשימת בתי עסק מורשים: קהלים בהתאמה אישית של קונים יתווספו למטען הייעודי (Payload) רק אם הקריאה
getAdSelectionData
תופעל על ידי אתר מכירה שמופיע ברשימת ההיתרים. נאחזר את הגדרות המטען הייעודי (payload) בקצב יומי כדי לשמור על רשימת ההיתרים מעודכנת. - מגבלת גודל לכל אתר מכירה: הקונה יכול להגדיר מגבלת גודל לכל מוכר כדי לקבוע את גודל הנתונים שצריך לשלוח במטען הייעודי (Payload) כשמכרז ביוזמת אתר מכירה מסוים. האפשרות הזו שימושית אם קונה רוצה להקדיש יותר משאבים לעיבוד נתוני מכרזים של אתרי מכירה מסוימים. שירות SellerFrontendService מעביר רק נתונים ספציפיים לקונה לכל קונה של BuyerFrontendService. לכן, על ידי הגדרת מגבלת גודל לכל מוכר, קונה יכול לשלוט במפורש בכמות הנתונים שיטמיעו ויעובדו על ידי BuyerFrontendService שבשרת המכרזים ובשרת המכרזים, עבור מכרזים שיופעלו על ידי בית העסק.
- רשימת בתי עסק מורשים: קהלים בהתאמה אישית של קונים יתווספו למטען הייעודי (Payload) רק אם הקריאה
הגדרת אתר מכירה: אנחנו בודקים את ההיתכנות של הגדרת מכרז לכל מוכר, שתאפשר למוכרים להגדיר פרמטרים של מכרז כדי לשלוט בגודל המטען הייעודי (payload) ובמשתתפים במכרז. אם זה אפשרי, במהלך ההרשמה, טכנולוגיית הפרסום של המוכר תוכל לציין את נקודת הקצה שממנה Protected Audience יוכל לאחזר את הגדרות המכרז לכל אתר מכירה בקצב קבוע. לאחר מכן נשתמש בהגדרות האישיות האלה כדי לקבוע את ההרכבה והמגבלות של
adSelectionData
שנוצרו לכל בקשתgetAdSelectionData
.בדומה לתצורה של הקונים, הגדרה לכל מוכר מאפשרת לספקים לציין איזו קבוצת קונים הם מצפים לראות במכרז, ולציין מגבלות על התרומה של כל קונה לגודל המטען הייעודי (payload).
הגדרת המכרז של בית העסק תאפשר למוכרים לציין:
- רשימת קונים מותרים: במכרזים שיצרו אתר מכירה מסוים, רק הקונים ברשימת ההיתרים יוכלו לתרום קהלים בהתאמה אישית למכרז. צריך לעדכן את הגדרת המכרז מדי יום כדי שרשימת ההיתרים תהיה מעודכנת עם רשימת ההיתרים של הקונים בצד השרת.
- מגבלת גודל לכל קונה: בתי העסק יכולים להגדיר מגבלה לכל קונה כדי להסדיר את גודל הנתונים שכל קונה מעלה למטען הייעודי (Payload) שנשלח אל SellerFrontendService. אם הקונה חורג ממגבלת הגודל לכל קונה, עדיפות הקהל המותאם אישית שהוגדרה בהגדרת המטען הייעודי (payload) של הקונה תשמש כדי לקבל את הנתונים במגבלות הצפויות.
- עדיפות לכל קונה: אתרי המכירה יכולים להגדיר עדיפות לכל קונה. עדיפות הקונה תשמש כדי לזהות אילו נתוני קונים צריך לשמור במטען הייעודי (Payload) אם גודל המטען הייעודי (Payload) חורג ממגבלת הגודל של המטען הייעודי (payload).
- מגבלת גודל מקסימלי של המטען הייעודי (payload): לאתרי מכירה שונים יכולה להיות הקצאת משאבים שונה, והם ירצו להגדיר מגבלת גודל מקסימלי למטען הייעודי (payload) של המכרז לכל בקשה. מגבלת הגודל המקסימלי תחול על קטגוריות הגודל הקבועות שהוגדרו על ידי Protected Audience API.
שינויים בקהל בהתאמה אישית
- ציון עדיפות של קהל בהתאמה אישית: אפשר לקונים לציין ערך עדיפות בקהל בהתאמה אישית. השדה
priority
ישמש לזיהוי קהלים בהתאמה אישית שצריכים להיכלל במכרז, אם קבוצת הקהלים בהתאמה אישית של הקונים חורגת ממגבלות הגודל לכל מוכר או לכל קונה. ערך ברירת המחדל של ערך עדיפות לא מוגדר בקהל בהתאמה אישית יהיה0.0
.
- ציון עדיפות של קהל בהתאמה אישית: אפשר לקונים לציין ערך עדיפות בקהל בהתאמה אישית. השדה
שינויים בנתונים של מטען ייעודי (payload)
- הפחתת הנתונים שנשלחים במטען הייעודי (payload): כפי שמפורט במאמר אופטימיזציה של המטען הייעודי (payload) של שירותי בידינג ומכרזים, מטען ייעודי (payload) גבוה יותר נובע מנתונים של
ads
של קהלים בהתאמה אישית, אותות של בידינג של משתמשים ואותות Android. כדי להפחית מטענים ייעודיים (payloads) גבוהים יותר:- הנחיית הלקוח לשלוח מזהים של רינדור מודעות (במקום אובייקטים של מודעות) במטען הייעודי (Payload).
- מצב שבו הלקוח לא שולח נתוני מודעות במטען הייעודי (payload).
- לא נשלחים אותות לבידינג של המשתמשים במטען הייעודי (payload) של הלקוח.
- הפחתת הנתונים שנשלחים במטען הייעודי (payload): כפי שמפורט במאמר אופטימיזציה של המטען הייעודי (payload) של שירותי בידינג ומכרזים, מטען ייעודי (payload) גבוה יותר נובע מנתונים של
האסטרטגיות שצוינו למעלה מאפשרות לטכנולוגיות הפרסום לקבוע הגדרות אישיות כדי לנהל את ההרכבה והמגבלות של מטענים ייעודיים (payloads) של adSelectionData
, אבל הן גם יכולות להשפיע על כוונון הגודל של adSelectionData
על ידי שינוי הפרמטרים של ההגדרות. כדי למנוע זאת, ההגדרה תאחזר מדי יום על ידי Protected Audience API מנקודת הקצה שהוגדרה.
אופטימיזציה של זמן האחזור
כדי שלמכרזי שרתים תהיה רמת שירות רצויה, אנחנו צריכים לוודא של-API getAdSelectionData
ול-API של persistAdSelectionResult
יש זמן אחזור קצר לכל קריאה. אנחנו מתכננים לספק תמיכה בתכונות לממשקי API ב-2023, אבל הגרסה הבאה נתמקד בבנצ'מרקים ובאופטימיזציות של ממשקי ה-API בזמן אחזור.
אנחנו בוחנים את האסטרטגיות הבאות כדי לשמור על זמן האחזור במגבלות המקובלות:
יצירה מראש של נתוני Protected Audience לכל אתר מכירה: מכיוון שההגדרות של המכרז של אתר המכירה וההגדרה של המטען הייעודי (payload) של הקונים יהיו יציבות למשך זמן משמעותי (מדי יום), הפלטפורמה יכולה לחשב מראש ולאחסן את נתוני Protected Audience שעומדים בדרישות.
לשם כך, הפלטפורמה תצטרך לבנות מנגנון למעקב אחרי עדכונים של קהלים בהתאמה אישית, ולשנות את נתוני Protected Audience שנוצרו מראש על סמך העדכונים. הפלטפורמה תצטרך גם להצהיר על יעדי SLO במרוץ התהליכים של הפרסום הדיגיטלי בין עדכוני קהלים בהתאמה אישית לבין הצגת השינוי ב-
adSelectionData
שנוצר עבור המכרז של השרת.המכשיר מספק מודל מחשוב מוגבל של משאבים עם עדיפויות שונות של תהליכים, ולכן אנחנו מודעים לכך שמתן מתקן כזה ליצירה מראש חייב להיות מהימן ורמת הבטחה ל-SLO.
במקרה כזה, היצירה מראש של נתוני Protected Audience API תתבסס על
- בית העסק מביע הסכמה ליצירה מראש של נתוני Protected Audience.
- קונים שעומדים בדרישות להשתתף במכרז על ידי אתר מכירה מסוים.
- זיהוי קהלים בהתאמה אישית לכל קונה, שיהיו חלק ממטען הייעודי (Payload) על סמך:
- מגבלות גודל לקונה, עדיפות לכל קונה ומגבלות גודל מקסימלי שהוגדרו בתצורה של אתר המכירה,
- מגבלת גודל לכל מוכר, עדיפות קהל בהתאמה אישית מוגדרת בהגדרת הקונה.
יישום מקובל של סינון שלילי: אם המוכר מעדיפים את האפשרות הזו, הפלטפורמה יכולה לחשב מראש את הערך של
adSelectionData
על ידי יצירה מראש של נתוני Protected Audience והחלת סינון שלילי על הפעלת הקריאה הקריטיתgetAdSelectionData
. כך בתי העסק יוכלו לאזן את זמן האחזור של זמן אחזור קצר, ובמקביל לאפשר שימוש לא פעיל בסינון שלילי.הפלטפורמה יכולה לספק את התמיכה הזו על ידי מתן אפשרות ברירת מחדל בהגדרות בית העסק עם מגבלת חוסר פעילות ואפשרות לשנות מברירת המחדל ב-
getAdSelectionData
, כדי לאפשר חישוב עדכני ככל האפשר במקרה הצורך. לחלופין, הפלטפורמה יכולה לספק ממשק API נוסף לאתחול שיופעל לפניgetAdSelectionData
כדי לחמם את המכרז.חישוב מטען ייעודי (payload) במספר מכרזים: בתרחישים מסוימים, יכול להיות שעדיף להשתמש ב-API עם ביצועים טובים של זמן אחזור, כדי לשמור על חוסר הפעילות הגופנית של הנתונים. כדי לספק את זה, הפלטפורמה יכולה להציג ממשק API של אתחול כדי לחשב את כל המטען הייעודי (Payload) ולספק הפניה למטען הייעודי (payload) המחושב לקורא.
בקריאות הבאות ל-
getAdSelectionData
, מבצע הקריאה החוזרת יכול לספק הפניה למטען הייעודי (payload) המחושב מראש לשימוש בגנרציה שלadSelectionData
.
כל שלוש האסטרטגיות שצוינו למעלה נמצאות בשלב הניתוח הראשוני, והמטרה שלהן היא לתאר את הכיוון של הפלטפורמה כדי לבצע אופטימיזציה לזמן האחזור. אחרי שנבדוק פרופילים מפורטים יותר של זמן האחזור של הדרישות לגבי API וטכנולוגיות פרסום, נמשיך להציע אסטרטגיות נוספות.
צמצום וזיהוי של התנהלות פוגעת
כפי שצוין בשיקולי פרטיות, adSelectionData
נוצר באמצעות כל נתוני הקונה במכשיר.
עם זאת, אם כל נתוני הקונים במכשיר משמשים ליצירת הפלט של adSelectionData
, ישות זדונית עלולה להתחזות לקונה וליצור נתוני קונים שמקורם בתרמית כדי לפגוע בביצועים ב-Android, לגרום למטען הייעודי (payload) המלא כדי להגדיל את העלות של טכנולוגיית פרסום להפעלת מכרזים או הפעלת בידינג וכן הלאה.
צמצום הפגיעה
אמצעים מסוימים שהוזכרו בקטע 'שיקולי גודל', כמו הגדרת מטען ייעודי (payload) של קונה, שכוללת אתרי מכירה שנמצאים ברשימת ההיתרים והגדרות של מכרזים של אתרי מכירה שכוללים קונים שנמצאים ברשימת ההיתרים, יעזרו לכם להחריג נתונים לא צפויים במטען הייעודי (Payload).
גם מדדים אחרים של התעניינות ברכישה, כמו מתן אפשרות לספקי SSP לציין את סדר העדיפות של הקונה, הצבת מכסה לכל קונה במטען הייעודי (payload) שנוצר, והגדרת מטען ייעודי (payload) של גודל מקסימלי לכל מכרז, יכולים גם הם לצמצם את ההשפעה של ניפוח מטען ייעודי (payload) זדוני. האמצעים האלה נועדו לאפשר לטכנולוגיות הפרסום להגדיר עם אילו טכנולוגיות פרסום הם רוצים לעבוד, ולהגדיר מגבלות מקובלות על המטען הייעודי (Payload) שהם יצטרכו לעבד.
כפי שציינו קודם, כל ההקלות שנועדו למנוע ניצול לרעה והגבלות גודל חייבות לפעול בהתאם לשיקולים שקשורים לפרטיות.
זיהוי של ישויות זדוניות
ההקלות שצוינו למעלה מגינות על היצירה של adSelectionData
למכרזי שרתים, אבל הן לא עוזרות לזהות ישויות זדוניות או להגן על הפלטפורמה מפני ניצול לרעה כמו יצירת מספר חסר תקדים של קהלים בהתאמה אישית מקונה.
כדי לשמור על תקינות הפלטפורמה ויציבותה, עלינו למצוא מנגנון לזיהוי ישויות זדוניות, לזיהוי וקטורים של ניצול לרעה ולזיהוי המניע להתקפות הספציפיות. בגרסאות מאוחרות יותר נציג הסברים שמפרטים את הווקטורים הפוטנציאליים של התנהלות פוגעת ואת ההגנות הפוטנציאליות נגדם.