ארכיטקטורה

מידע על ארכיטקטורת המכרז של שירותי בידינג ומכרזים

סקירה כללית

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

הגדרות

שירותים לקונים ולמוכרים

שירותי B&A מורכבים מארבעה שירותים לקונים ולמוכרים:

• לקונים, שירות הבידינג ושירות הקצה של הקונה (BFE) זמינים לשימוש.
• למוכרים, שירות המכרזים ושירות ממשק הקצה של המוכר (SFE) זמינים לשימוש.

הארכיטקטורה של מכרז PA B&A לאינטרנט

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

1. קוד ה-JavaScript של פלטפורמת ה-SSP בדף של בעל התוכן הדיגיטלי יוצר את נתוני המכרז המוצפנים של B&A על ידי קריאה ל-navigator.getInterestGroupAdAuctionData().
   • המטען הייעודי המוצפן הזה מכיל את נתוני הקונה, ואפשר לפענח אותו רק בתוך SFE בסביבת מחשוב אמינה (TEE).
2. קוד ה-JavaScript של פלטפורמת ה-SSP שולח בקשה מאוחדת למכרז אל שירות המודעות של אתר המכירה.
   • בקשה מאוחדת למכרז מכילה גם את מטען הייעודי (payload) של מכרז ORTB בהקשר וגם את מטען הייעודי (payload) של מכרז B&A מוצפן.
   • שרת המודעות של המוכר הוא שרת המודעות הקיים שלכם, והוא לא פועל בסביבת TEE.
3. שירות המודעות של המוכר קורא לשירות ה-RTB של ה-DSP כדי לבקש את הצעת המחיר במכרז ההקשרי ואת האותות של הקונה שיועברו למכרז הבא של PA.
   • זה יכול להיות שלב שבו הקונה מציין את הכוונה שלו להשתתף במכרז של PA.
4. אחרי שהמכרז ההקשרי מסתיים, SAS שולח את הבקשה SelectAd לשירות SFE.
   • הצעת המחיר הזוכה במכרז ההקשרי ואותות הקונה מתווספים למטען הייעודי (payload) של הבקשה SelectAd.
5. שירות ה-SFE של פלטפורמת ה-SSP קורא לשירות ה-BFE של פלטפורמת ה-DSP עם הבקשה GetBids.
6. ה-BFE של ה-DSP שולח קריאה ל-Bidding Service עם הבקשה GenerateBids.
7. אחרי ש-SFE מקבל את הצעת המחיר, מתבצעת קריאה ל-ScoreAd אל שירות המכרזים.
   • הצעת המחיר עם הציון הכי גבוה של רצון המשתמש מוחזרת ל-SAS ואז מועברת לקוד JavaScript בדף.
8. המכרז מסתיים בדפדפן על ידי העברת התוצאה המוצפנת של המכרז של B&A אל הקריאה navigator.runAdAuction().

הגדרות של מכרזים

אפשר להגדיר מכרז בשילוב עם Protected Audience API ועם שירותי B&A בדרכים הבאות:

• מכרז עם מוכר יחיד וקונים מ-B&A
• מכרז במצב משולב עם קונים במכשיר וקונים ב-B&A
• מכרז עם כמה מוכרים שיכול להתנהל במכשיר או בשרת

משתתפים

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

יש ארבע פלטפורמות DSP:

• ‫DSP-A ו-DSP-B משתתפים רק במכרזים במכשיר
• ‫DSP-X ו-DSP-Y משתתפים במכרזים במכשיר ובמכרזים של B&A

יש ארבע פלטפורמות SSP, ולכל מוכר יש הגדרת מכרז שונה:

• SSP-OD מריץ מכירה פומבית במכשיר בלבד
• SSP-BA מפעיל מכירה פומבית של מודעות בית בלבד
• מערכת SSP-MIX מפעילה מכרז במצב משולב
• ‫SSP-TOP מפעיל מכרז עם מספר אתרי מכירה:
  • SSP-OD/BA/MIX משתתפים כמוכרי רכיבים במכרז מרובה אתרי מכירה של SSP-TOP

מכרז יחיד של קנייה ומכירה

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

בהגדרה הקודמת, SSP-BA מפעיל מכרז B&A שבו DSP-X ו-DSP-Y משתתפים באמצעות חבילת השירותים של B&A Services לקונים. שירות המודעות של המוכר מריץ קודם מכרז הקשרי עבור DSP-X ו-DSP-Y, ואז מריץ מכרז של Protected Audience על ידי שליחת הבקשה SelectAd לשירות SFE של המוכר. הצעת המחיר המנצחת במכרז ההקשרי והאותות של כל קונה מועברים לקריאה SelectAd. לאחר מכן, שירות ה-SFE שולח בקשות GetBids אל ה-BFE של DSP-X ושל DSP-Y, שיפעיל את שירות הבידינג שלהם כדי ליצור הצעת מחיר.

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

await navigator.runAdAuction({
  seller: 'https://ssp-ba.example',
  requestId: 'g8312cb2-da2d-4e9b-80e6-e13dec2a581c',
  serverResponse: Uint8Array(560) [193, 120, 4, …] // Encrypted B&A auction result
})

הערך requestId מגיע מהקריאה getInterestGroupAdAuctionData() בצד הלקוח, והנתונים serverResponse מגיעים מהמכרז של B&A בצד השרת.

מכרז במצב מעורב

בשיטת ההגדרה המשולבת, הקונים יכולים להשתתף במכרז של המוכר מתוך המכשיר או מ-B&A. החיצים הכחולים מייצגים את הנתיב של המכרז במכשיר, והחיצים האדומים מייצגים את הנתיב של המכרז של B&A:

בהגדרה הזו, DSP-A ו-DSP-B הם קונים ששולחים את הצעות המחיר שלהם במכשיר, ו-DSP-X ו-DSP-Y הם קונים ששולחים את הצעות המחיר שלהם באמצעות B&A. הקונים במכשיר משתתפים במכרז PA במכשיר בדפדפן, והקונים ב-B&A משתתפים במכרז B&A שמתואר בקטע מכרז של מוכר יחיד.

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

הגדרת מכירה פומבית במצב משולב עם מוכר יחיד בחלק של המכירה הפומבית שמתבצע במכשיר נראית כך:

await navigator.runAdAuction({
  seller: 'https://ssp-mix.example',
  decisionLogicURL: 'https://ssp-ba.example/score-ad.js',
  componentAuctions: [
    // B&A auction
    {
      seller: 'https://ssp-mix.example',
      requestId: 'f5135cb2-da2d-4e9b-80e6-e13dec2a581c',
      serverResponse: Uint8Array(560) [133, 20, 14, …]
    },
    // On-device auction
    {
      seller: 'https://ssp-mix.example',
      interestGroupBuyers: ['https://dsp-a.example', 'https://dsp-b.example'],
      decisionLogicURL: 'https://ssp-mix.example/on-device-score-ad.js',
    }
  ]
})

הפעלה מקבילה של מכרזים במכשיר ומכרזים של B&A

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

קוד ה-JavaScript בלקוח שולח את הבקשה למכרז המאוחד אל SAS, ו-SAS מתחיל את המכרז ההקשרי ואת המכרז של PA B&A. כש-SAS מקבל תגובה משרת ה-RTB של הקונה, אפשר להזרים חזרה לדפדפן את האותות של הקונה לגבי המכרז במכשיר, יחד עם המשתתף שזכה במכרז ההקשרי אחרי שכל הצעות המחיר מתקבלות. אותות הקונים שמוזרמים משמשים ליצירת הצעת מחיר במכשיר, והזוכה במכרז ההקשרי משמש כהצעה מינימלית כשמדרגים את הצעות המחיר.

ב-SAS, המוכר יוצר UUID nonce שמוגדר בכותרת התגובה Ad-Auction-Result-Nonce כשנתוני המכרז ההקשרי מועברים בסטרימינג לדפדפן. אותו מספר חד-פעמי משמש בקריאה SelectAd אל SFE למכרז B&A, והמספר החד-פעמי הזה נכלל בתגובה SelectAd שמוחזרת מ-SFE. במהלך שלב המכרז בצד הלקוח, הדפדפן מוודא שה-nonce בכותרת התגובה Ad-Auction-Result-Nonce תואם ל-nonce במטען הייעודי (payload) של תוצאת המכרז המוצפנת.

במאמר הזה מוסבר על מקביליות במצב מעורב.

מכרז עם כמה מוכרים

יש שתי דרכים להריץ מכרז PA עם כמה מוכרים באמצעות B&A:

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

מכרז עם מספר אתרי מכירה שמתנהל במכשיר

במכרז עם כמה אתרי מכירה שמתנהל במכשיר, כל אתר מכירה יכול להגדיר את המכרז שלו איך שהוא רוצה. כל המוכרים במכשיר, מוכרי B&A ומוכרים במצב מעורב יכולים להשתתף במכרז ברמה העליונה.

בתרשים הזה, SSP-TOP מפעיל מכירה פומבית של מוכרים מרובים שמתנהלת בשרת, וSSP-BA-X ו-SSP-BA-Y משתתפים בה.

בקשה אחת מאוחדת למכרז שמכילה את מטען הייעוד של המכרזים ההקשריים ומכרזי PA עבור כל המשתתפים נשלחת מהדפדפן לשירות המודעות של המוכר ברמה העליונה. לאחר מכן, SAS מבצעת קריאה ל-SFE עם מטען הייעודי (payload).GetComponentAuctionCiphertexts הפונקציה SFE תפענח את מטען הנתונים, תפריד את מטען הנתונים לפי כל מוכר רכיבים ותחזיר את מטען הנתונים המוצפן מחדש אל ה-SAS של המוכר ברמה העליונה.

הגדרות הפרוטו לבקשת GetComponentAuctionCiphertexts ולתגובה הן:

// Request sent from the top-level seller's ad service to SFE
message GetComponentAuctionCiphertextsRequest {
  bytes protected_auction_ciphertext = 1; // Generated in the browser
  repeated string component_sellers = 2; // The list of all component sellers
}

// Response returned from SFE to the top-level seller's ad service
message GetComponentAuctionCiphertextsResponse {
  // A map of component sellers and their re-encrypted payloads
  map<string, bytes> seller_component_ciphertexts = 1;
}

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

השלבים הבאים

אחרי שתקראו את המדריך הזה, תוכלו לבצע את השלבים הבאים:

מידע נוסף

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

יש לך שאלות?

• כדי לשאול שאלות לגבי שירותי בידינג ומכרזים, פותחים בעיה במאגר B&A Services.