שירותי בידינג ומכרזים

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

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

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

Google תספק את הרכיבים של B&A, והם יהיו זמינים כקוד פתוח. ספקי טכנולוגיות פרסום יכולים לארח מכונות משלהם אצל ספקי ענן ציבורי נתמכים. מידע נוסף על ההצעה של B&A זמין ב-GitHub. חשוב לזכור שהתאריכים שמופיעים במסמך הזה משקפים את ההטמעה ב-Chrome, ואנחנו נעלה מידע נוסף על השילוב עם Android בעתיד. המסמך הזה משמש כהקדמה ל-B&A, ולממשקי ה-API החדשים שמערכת Android תספק כדי ליצור אינטראקציה עם B&A. נפרוס מידע טכני נוסף על השימוש בממשקי ה-API החדשים האלה בעדכונים עתידיים.

איפה נמצאים שירותי B&A

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

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

ההבדל העיקרי הוא המיקום שבו מתבצעת הלוגיקה של יצירת כתובות ה-URL לבידינג, למתן ניקוד ולדיווח. במקום להריץ את הלוגיקה של הבידינג, המכרז והדיווח במכשיר, הלוגיקה של generateBid(),‏ scoreAd(),‏ reportResult() ו-reportWin() מתבצעת ב-TEE. הלוגיקה של הבידינג של הקונה והלוגיקה של הניקוד של המוכר מתבצעות בסביבת ה-B&A שלהם, באמצע תהליך המכרז של הקהל המוגן:

הצפנת נתונים

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

הארכיטקטורה והתהליך של המכרז

ההצעה הזו כוללת צורך בכמה רכיבים חדשים שמפורטים ב-GitHub, כולל הזרימה של הנתונים מהמכשיר אל B&A.

באופן כללי, תהליך העברת הנתונים מתארך כך:

1. במכשיר, המוכרים אוספים מידע מ-Protected Audience באמצעות ה-API ‏getAdSelectionData.
2. ערכת ה-SDK במכשיר שולחת בקשה לשירות המודעות של המוכר. הבקשה הזו כוללת מטען ייעודי (payload) לפי הקשר ו-ProtectedAudienceInput מוצפן.
3. שירות המודעות של המוכר שולח בקשה לשירות הבידינג בזמן אמת (RTB) של הקונים שפועל מחוץ ל-TEE, כדי לקבל מועמדות למודעות לפי הקשר. לאחר מכן, המערכת מעניקה ניקוד למודעות האלה ובוחרת את המודעה לפי הקשר הזוכה.
4. שירות המודעות של המוכר שולח בקשה לשירות SellerFrontEnd שפועל בסביבת TEE.
5. השירות SellerFrontEnd שולח בקשות עם נתונים ספציפיים לקונה לשירותי BuyerFrontEnd.
6. הקונים משתמשים בשירות של מפתח/ערך ובשירות בידינג משלהם, שמניבים הצעות מחיר למודעות מועמדות שמקורן במכשיר לכל הקהלים המותאמים אישית שנלקחים בחשבון לצורך רימרקטינג.
7. השירות SellerFrontEnd קורא משירות המפתח/הערך ומעניק ניקוד למודעות המועמדות. התוצאה מוצפנת וחוזרת לשירות המודעות של המוכר.
8. שירות המודעות של המוכר מחזיר את התוצאה הזוכה המוצפנת, ואם רוצים גם תוצאה לפי הקשר, ל-SDK במכשיר.
9. במכשיר, המוכרים מאחזרים את המודעה הזוכה באמצעות ה-API ‏processAdSelectionResult, שמפענח את התגובה משירות המודעות של המוכר.

תיאור מפורט של כל שלב ושל אופן ההצפנה של הנתונים זמין ב-GitHub. הקוד של הרכיבים האלה יהיה זמין בקוד פתוח. הקוד שסופק יטפל באיחוד של בקשות מהשירות SellerFrontEnd לשירותים BuyerFrontEnd.

פריסה ב-Cloud

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

הרצת מכרז

השלב הראשון להפעלת המכרז של B&A הוא לאסוף את הנתונים מקהלים מותאמים אישית במכשיר ולהצפין אותם כדי לשלוח אותם למכרזים בצד השרת. כדי לעשות זאת, משתמשים ב-API ‏getAdSelectionData:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

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

ה-API הזה מחזיר אובייקט AdSelectionData:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

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

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

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

לאחר שליחת הבקשה, השירות Seller Ad מעביר אותה לשירות SellerFrontEnd שפועל בסביבת TEE. כשמגדירים שירות SellerFrontEnd, בעלי עסקים מספקים רשימה של כתובות דומיין שתואמות לשירותי BuyerFrontEnd שמנוהלים על ידי הקונים שהם עובדים איתם. הבקשות ימוזגו לשירותים השונים של BuyerFrontEnd שהמוכר סיפק, כדי שהקונים יוכלו ליצור הצעות מחיר על המודעות שנבחרו. לקונה ספציפי, B&A תשלח רק מידע על קהלים מותאמים אישית שבבעלות הקונה, כדי למנוע זליגת נתונים בין קונים. אחרי יצירת הצעות המחיר, רשימת המודעות המועמדות חוזרת לשירות SellerFrontEnd, שבו נבחרת המודעה הזוכה. לבסוף, השירות SellerFrontEnd מחזיר למכשיר את המודעה הזוכה המוצפנת.

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

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

דיווח

כתובות ה-URL לדיווח ייווצרו בשירותי B&A. עדיין תצטרכו להפעיל במכשיר את הפינגים לכתובות ה-URL האלה כדי לדווח על חשיפות ועל אינטראקציות במכרזים. עדיין תצטרכו להפעיל את ממשקי ה-API של reportImpression() ו-reportInteraction() באמצעות ה-SDK במכשיר באמצעות AdSelectionId שנוצר במהלך תהליך ה-B&A. האיתותים שנוצרו לדיווח על אינטראקציות וכתובות ה-URL התואמות נכללים בתגובה המוצפנת, כך שבמהלך פענוח התגובה, האירועים ומיפויי כתובות ה-URL מאוחסנים במכשיר.

שיקולים בנושא פרטיות

במאמר בנושא ההצעה ל-Browser Bidding & Auction API ב-GitHub מוסבר איך התייחסנו לשיקולי הפרטיות. ההצעה הזו מבוססת על מונחי Chrome, אבל אותם עקרונות חלים גם על Android.

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

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

שיקולים לגבי גודל

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

1. הוספת ad_render_id ב-CustomAudience כדי שהיא תישלח באמצעות adSelectionData במקום באמצעות URI של עיבוד מודעות ומטא-נתונים. טכנאי הפרסום יכולים לשפר את האופטימיזציה של הנתונים האלה על ידי אי שליחת נתוני מודעות ב-adSelectionData. האפשרות הזו תהיה נתמכת ב-CustomAudience API בגרסאות עתידיות.
2. חשוב לוודא ש-user_bidding_signals לא נשלחים ב-adSelectionData. במקום זאת, טכנולוגיות הפרסום יכולות לאחזר את user_bidding_signals מהשרת שלהן למפתח/ערך.
3. מאפשרים לקונים לתעדף את CustomAudience.
4. לאפשר לקונה לציין את העדיפות של המוכר.
5. יצירת adSelectionData בכמה קטגוריות קבועות כדי להגביל את זליגת הביטים תוך צמצום גודל המטען הייעודי.

נבצע אופטימיזציה של הגודל תוך התחשבות בחששות שצוינו בנושאי פרטיות.

שיקולי מאבקים בשימוש לרעה

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

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

כדי למנוע ניצול לרעה של adSelectionData, נציג את הפעולות הבאות

• מתן הרשאה ל-CustomAudience לציין באופן מפורש את המוכרים המאושרים ואת תעדוף המוכרים
• מתן הרשאה ל-SSP לציין במפורש את הקונה, את העדיפות של הקונה ואת המכסה לכל קונה בתוכן שנוצר
• לספק מנגנון ל-SSPs כדי להגדיר מספר מקסימלי של קונים לכל קריאה או גודל מקסימלי לכל קונה.

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

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