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

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

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

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

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

פריסת ענן

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

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

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

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

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

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

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

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