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

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

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

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

איפה שירותי B&A משתלבים

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

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

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

הצפנת נתונים

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

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

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

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

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

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

פריסה בענן

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

הפעלת מכרז

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

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 במכשיר אחראי לקידוד הנתונים האלה. מומלץ להשתמש בפתרון שחוסך מקום, כמו שליחת הבקשה לשירות Seller Ad בתור multipart/form-data.

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

אחרי שהתגובה מהבקשה לשירות Seller Ad חוזרת למכשיר, הפלטפורמה מציעה 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 האלה כדי לדווח על חשיפות ואינטראקציות במכרזים. ערכת ה-SDK במכשיר עדיין תצטרך להפעיל את ממשקי ה-API‏ reportImpression() ו-reportInteraction() באמצעות AdSelectionId שנוצר במהלך תהליך ההסכמה והאימות. ה-Beacons שנוצרו לצורך דיווח על אינטראקציות וכתובות ה-URL התואמות כלולים בתגובה המוצפנת, כך שבמהלך הפענוח של התגובה, המיפויים של האירועים וכתובות ה-URL נשמרים במכשיר.

שיקולי פרטיות

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

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

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

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

ה-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 נוצר באמצעות כל נתוני הקונים במכשיר.

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

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

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

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

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