בהצעה לעיצוב שירותי בידינג ומכרזים ל-Android מפורט הפרטים של הפעלה וזרימת נתונים של מכרזים ב-Android באמצעות שיטת הבידינג המהימנה ושרת המכרזים. כדי להבטיח שהנתונים בזמן ההעברה יטופלו רק ממשקי API לשמירה על פרטיות ושרתים מהימנים, הנתונים מוצפנים בין לקוח ושרת באמצעות מפתח ציבורי היברידי דו-כיווני הצפנה.
כדי להפעיל את המכרז כפי שמפורט למעלה, טכנולוגיית המודעות של בית העסק במכשיר צריכה מבצעים את השלבים הבאים:
- איסוף והצפין של נתונים למכירה פומבית של שרתים
- שליחת בקשה לשירות בית עסק לא מהימן
- קבלת תשובה משירות בתי עסק לא מהימן
- פענוח התגובה מהמכרז של Protected Audience וקבלת תוצאת המכרז
Protected Audience API משיק שני ממשקי API חדשים כדי לתמוך בהרצה מכירות פומביות בשרת:
- ה-API של
getAdSelectionData
אוסף נתונים לצורך המכרז של השרת, יוצרת מטען ייעודי (payload) מוצפן שמכיל נתונים של מכרז. The Bidding (בידינג) שרת המכרז משתמש במטען הייעודי (payload) הזה כדי להפעיל מכרז, ליצור את המכרז ומחזירה את התוצאה של המכרז. - לקוחות טכנולוגיות פרסום במכשיר יכולים לקרוא ל-API של
persistAdSelectionResult
כדי לפענח את התוצאה שנוצרה מהמכרז בשרת ולקבל את המודעה הזוכה כתובת URL לעיבוד.
טכנולוגיית הפרסום של בית העסק במכשיר צריכה לשלב ולבנות את הרכיבים הבאים כדי להפעיל מכרז:
- לאסוף ולהצפין נתונים עבור בית העסק במכירה פומבית של שרתים: טכנולוגיית המודעות צריכה
קוראים ל-API
getAdSelectionData
כדי לקבל את המטען הייעודי (payload) המוצפן. - שליחת בקשה לשליחה של שירות בית עסק לא מהימן:
HTTP POST
אוPUT
בקשה שמכילה את המטען הייעודי (payload) המוצפן שנוצר על ידיgetAdSelectionData
ממשק API לשירות המוכר הלא מהימן ולנתונים הנדרשים על ידי המשתמשים הלא מהימנים שירות מפיץ כדי ליצור תוצאות הקשריות. - קבלת תגובה משירות בתי עסק לא מהימן: תשובה שהתקבלה ממקור לא מהימן שירות מפיץ יכיל את תוצאת המכרז המוצפנת של קהל מוגנת ותוצאת המכרז לפי ההקשר.
- מפענחים את התגובה מהמכרז של הקהל המוגן ומקבלים את תוצאת המכרז:
כדי לפענח את תוצאת המכרז של הקהל המוגן, צוות המודעות של בית העסק צריך להתקשר
ממשק ה-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
מפיק את הקלט הנדרש עבור 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
- מבצע הקריאה החוזרת צריך להגדיר את השדה
seller
בבקשה כפי שהוא משמש להרצה בדיקות רישום לפני מתן שירות לבקשה. - השדה
coordinatorOriginUri
הוא אופציונלי.- אם מוגדר, הערך צריך להיות שווה לסכימה, שם המארח והיציאה של שהוגדרה בזמן פריסת שרת ה-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) הסופי
מוצפן באמצעות הצפנה היברידית דו-כיוונית של מפתחות ציבוריים.
GetAdSelectionDataתוצאה
הפונקציה GetAdSelectionDataOutcome
נוצרה כתוצאה של getAdSelectionData
API. היא מכילה את הדברים הבאים:
adSelectionId
: מספר שלם אטום לזיהוי הפעלה שלgetAdSelectionData
. לקוח הפרסום הדיגיטלי צריך להמשיך כך הערך שלadSelectionId
מפני שהוא משמש כמצביע אל שיחתgetAdSelectionData
. המזהה הזה נדרשpersistAdSelectionResult
API לפענוח של תוצאת המכרז מהבידינג ושרת המכרזים, והיא נדרשת גם על ידיreportImpression
וגם ממשקי API שלreportEvent
.adSelectionData
: אלה נתוני המכרז המוצפנים שיהיו שנדרשות על ידי שרת 'בידינג' ו'מכרז' כדי להפעיל מכרזים. השיטה הזו כולל:- נתונים של קהלים בהתאמה אישית שסוננו לפי מכסת תדירות, התקנות של אפליקציה מסננים ודרישות של מכרזים בצד השרת עבור קהלים בהתאמה אישית.
- בגרסה עתידית היא תכלול נתונים לגבי התקנות של האפליקציה.
public class GetAdSelectionDataOutcome {
Public getAdSelectionId(long adSelectionId);
public byte[] getAdSelectionData();
}
שגיאות, חריגים וטיפול בכשלים
אם לא ניתן להשלים את יצירת הנתונים של בחירת המודעות עקב
סיבות כמו ארגומנטים לא חוקיים, זמנים קצובים לתפוגה או צריכת משאבים מוגזמת,
הקריאה החוזרת של OutcomeReceiver.onError()
מספקת AdServicesException
עם
התנהגויות:
- אם
getAdSelectionData
מתחיל עם ארגומנטים לא חוקיים,AdServicesException
` מציין שהסיבה היא בלבול חריג. - כל שאר השגיאות מקבלות
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);
}
adSelectionId
: המזהה האטום שנוצר על ידיgetAdSelectionData
השיחה שאת התוצאה שלה רוצים לפענח.seller
: צריך להגדיר את מזהה טכנולוגיית הפרסום של בית העסק בבקשה להפעלה בדיקות רישום לפני מתן שירות לבקשה.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
עם
התנהגויות:
- אם
getAdSelectionData
מתחיל עם ארגומנטים לא חוקיים,AdServicesException
מציין שהסיבה היאIllegalArgumentException
. - כל שאר השגיאות מקבלות
AdServicesException
עםIllegalStateException
הוא הסיבה.
שיקולי פרטיות
הפונקציה adSelectionData
מוצפנת כדי לוודא שאפשר לגשת רק לנתונים בזמן ההעברה
ל-PPAPI ולשרתים המהימנים.
למרות ההצפנה, ייתכן שדליפת נתונים תתרחש בגלל גודל של adSelectionData
.
הגודל של adSelectionData
יכול להשתנות בגלל:
- שינויים בנתונים של
CustomAudience
קיימים במכשיר. - שינויים בלוגיקת הסינון של
CustomAudience
. - שינויים בקלט של שיחת
getAdSelectionData
.
ניתן להשתמש בשינוי הגודל של adSelectionData
ליצירת אפליקציות שונות
כמו שצוין בדיון על דליפת ביט. הרבה
גם מיטיגציות שרלוונטיות לדליפה של 1 ביט רלוונטיות כאן.
כדי לנהל את ההדלפות, אנחנו מתכננים ליצור את אותו 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 יאחזר תצורת מטען ייעודי (payload) באופן קבוע מדי יום את הקצב. לחלופין, ממשקי API לשמירה על פרטיות יחשפו ממשק API שמאפשר של הקונים כדי לרשום את נקודת הקצה.
לאחר מכן נשתמש בהגדרה הזאת כדי להעריך את התרומה של קונה ערך
adSelectionData
שנוצר לכל בקשה שלgetAdSelectionData
.תצורת המטען הייעודי (payload) של הקונה תאפשר לקונים לציין:
- רשימת בתי עסק מורשים: קהלים מותאמים אישית של קונים יתווספו אל
מטען ייעודי (payload) רק אם הקריאה של
getAdSelectionData
נשלחה על ידי בית עסק ברשימת ההיתרים. אנחנו נאחזר את תצורת המטען הייעודי (payload) בכל יום כדי לשמור על העדכניות של רשימת ההיתרים. - מגבלת גודל לכל אתר מכירה: קונה יכול להגדיר מגבלת גודל לכל אתר מכירה כדי לקבוע את גודל הנתונים שיישלחו במטען הייעודי (payload) בזמן שהמכרז ביוזמת אתר מכירה מסוים. זה שימושי אם קונה רוצה להקדיש יותר משאבים לעיבוד נתוני מכרזים של אתרי מכירה מסוימים. sellersFrontendService מעביר רק נתונים ספציפיים לקונה לכל אחד מהם BuyerFrontendService. כך, באמצעות הגדרת מגבלת גודל לכל אתר מכירה, קונה יכול לשלוט במפורש בכמות הנתונים שיוטמעו ויעובדו BuyerFrontendService של שרת הבידינג ושרת המכרזים להפעלת מכרזים על ידי בית עסק.
- רשימת בתי עסק מורשים: קהלים מותאמים אישית של קונים יתווספו אל
מטען ייעודי (payload) רק אם הקריאה של
הגדרת העסק: אנחנו בודקים את ההיתכנות של כל מוכר לכל אתר מכירה הגדרת מכרז שתאפשר למוכרים להגדיר פרמטרים של מכרז כדי לשלוט בגודל המטען הייעודי (payload) ובמשתתפים במכרז. אם הדבר אפשרי, במהלך של בית העסק, טכנולוגיית הפרסום של בית העסק תוכל לציין את נקודת הקצה שבהם Protected Audience API יכול לאחזר את הגדרת המכרז לכל אתר מכירה ב- בקצב קבוע. נשתמש בתצורה הזו כדי לקבוע ההרכב והמגבלות של
adSelectionData
שנוצרו לכל אחד מהם בקשתgetAdSelectionData
.בדומה לתצורת הקונה, הגדרה לכל אתר מכירה תאפשר כדי לציין איזו קבוצת קונים הם מצפים לראות במכרז כדי לציין מגבלות על כל תרומה של קונה לגודל המטען הייעודי (payload).
הגדרת המכרז של בית העסק תאפשר למוכרים לציין:
- רשימת קונים מורשים: רק במכרזים שהופעלו על ידי אתר המכירה הנתון, הקונים ברשימת ההיתרים יוכלו לתרום קהלים בהתאמה אישית למכירה הפומבית. צריך לעדכן את הגדרת המכרז מדי יום כדי שרשימת ההיתרים תהיה מעודכנת עם רשימת ההיתרים של הקונים בצד השרת.
- מגבלת גודל לכל קונה: בתי העסק יכולים להגדיר מגבלה לכל קונה בסכום של להסדיר את גודל הנתונים שכל קונה מעלה למטען הייעודי (payload) נשלח אל SellerFrontendService. אם הקונה חורג מגודלו של כל קונה המגבלה, העדיפות של קהל מותאם אישית שהוגדרה בתצורה של המטען הייעודי (payload) של הקונה יכול לשמש לקבלת הנתונים במגבלות הצפויות.
- עדיפות לכל קונה: אתרי המכירה יכולים להגדיר עדיפות לכל קונה. קונים ישמשו לזיהוי נתוני הקונים שיישמרו בהם. המטען הייעודי (Payload) אם גודל המטען הייעודי חורג ממגבלת הגודל של המטען הייעודי (payload).
- מגבלת גודל מקסימלי של המטען הייעודי (payload): אתרי מכירה שונים יכולים הקצאת משאבים שונה, וייתכן שתרצו להגדיר מגבלת גודל מקסימלית המטען הייעודי (payload) של המכרז לכל בקשה. מגבלת הגודל המקסימלי תחול על קטגוריות בגודל קבוע שהוגדרו על ידי Protected Audience API.
שינויים בקהל בהתאמה אישית
- ציון עדיפות לקהל בהתאמה אישית: אפשר לקונים לציין עדיפות
בקהל מותאם אישית. השדה
priority
ישמש כדי לזהות קהלים בהתאמה אישית שכדאי לכלול במכרז, אם קבוצה של קהלים מותאמים אישית של קונים חורגות מהגודל לכל מוכר או לכל קונה מגבלות בפועל. כברירת מחדל, ערך עדיפות לא מוגדר בקהל בהתאמה אישית אל0.0
.
- ציון עדיפות לקהל בהתאמה אישית: אפשר לקונים לציין עדיפות
בקהל מותאם אישית. השדה
שינויים בנתונים של מטען ייעודי (payload)
- הפחתת הנתונים שנשלחים במטען הייעודי (payload): כפי שמפורט בבידינג ומכרזים.
אופטימיזציה של מטען ייעודי (payload) של שירותים, מבוסס על מטען ייעודי (payload) גבוה יותר
לפי נתוני קהל בהתאמה אישית
ads
, אותות לבידינג של משתמשים, אותות Android. כדי להפחית מטענים ייעודיים (payloads) גבוהים יותר:- לבקש מהלקוח לשלוח מזהים של עיבוד מודעות (במקום אובייקטים של מודעות) מטען ייעודי (payload).
- מצב שבו הלקוח לא שולח נתוני מודעות במטען הייעודי (payload).
- לא נשלחים אותות לבידינג של המשתמשים במטען הייעודי (payload) של הלקוח.
- הפחתת הנתונים שנשלחים במטען הייעודי (payload): כפי שמפורט בבידינג ומכרזים.
אופטימיזציה של מטען ייעודי (payload) של שירותים, מבוסס על מטען ייעודי (payload) גבוה יותר
לפי נתוני קהל בהתאמה אישית
האסטרטגיות שצוינו למעלה מאפשרות לטכנולוגיות הפרסום לקבוע הגדרות
לנהל את ההרכב והמגבלות של המטען הייעודי (payload) של adSelectionData
, הן יכולות גם להפוך
גורם לכוונון הגודל של adSelectionData
על ידי שינוי ההגדרות האישיות
. כדי למנוע זאת, ההגדרה תאוחזר מדי יום על ידי Protected
קהל מנקודת הקצה שהוגדרה.
אופטימיזציה של זמן האחזור
כדי שלמכרזי שרתים תהיה רמת שירות רצויה, אנחנו צריכים לוודא
ל-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
במכרזי שרת, הם לא עוזרים לזהות ישויות זדוניות או להגן
מניצול לרעה, כמו יצירת מספר חסר תקדים של מודעות מותאמות אישית
קהלים מקונים.
כדי להבטיח את היציבות והתקינות של הפלטפורמה, עלינו למצוא מנגנון ישויות זדוניות, לזהות וקטורים של ניצול לרעה ולזהות את המניע לפי ההתקפות הספציפיות. בגרסאות מאוחרות יותר, נציג הסברים פירוט של הווקטורים הפוטנציאליים של ניצול לרעה וההגנות שישמשו נגדם.