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

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

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

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 שלו, באמצע תהליך המכרז של Protected Audience:

תהליך המכרז של 'קהל מוגן'

הצפנת נתונים

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

זרימת ארכיטקטורה ומכרזים

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

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

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

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

הפעלת מכרז

השלב הראשון בהפעלת המכרז של 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.

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

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

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

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

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

שיקולי גודל

ה-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 בכמה קטגוריות קבועות כדי להגביל דליפת סיביות תוך צמצום גודל המטען הייעודי (payload).

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

שיקולים למניעת שימוש לרעה

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

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

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

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

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

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