ארכיטקטורה

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

סקירה כללית

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

הגדרות

מונח	תיאור
מכרז בשילוב עם Protected Audience API	מכרז מודעות שכולל נתונים מכמה אתרים
מכרז לפי הקשר	מכרז מודעות שלא כולל נתונים מאתרים שונים. המכרז הזה פועל לפי נתיב המכרז הקיים של בידינג בזמן אמת (RTB).
בקשה למכרז מאוחד	בקשה שנשלחת מהדפדפן על ידי קוד ה-JavaScript של המוכר, וכוללת את המטען הייעודי (payload) גם למכרז של קהל מוגן וגם למכרז לפי הקשר.
שירות מודעות של מוכרים (SAS)	השירות שאחראי לטיפול בבקשה למכרז המאוחד מהדפדפן. יכול להיות שזהו שרת המודעות הקיים של המפיץ ב-RTB. מערכת SAS אחראית על תזמור המכרזים לפי הקשר ועל המכרזים של קהלים מוגנים.
שירות מודעות לקונה	השירות שאחראי לשליחת הצעת מחיר במכרז לפי הקשר. יכול להיות שזהו שרת המודעות הקיים של הרוכש ב-ORTB.

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

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

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

משתתף	שירות	תיאור
קונים	שירות ממשק קצה של קונה (BFE)	השירות מטפל בבקשה GetBids מSFE של המוכר. הוא אחראי על פענוח של עומס העבודה, אחזור האותות של K/V וקריאה ל-GenerateBids של Bidding Service.
	Bidding Service	השירות מטפל בבקשה GenerateBids מ-BFE. הוא אחראי להפעלת הלוגיקה של הבידינג של הקונה וליצור הצעת מחיר.
מפיץ	שירות ממשק קצה של מוכר (SFE)	השירות מטפל בבקשה SelectAd מ-Seller Ad Service. הוא אחראי על פענוח של נתוני העומס, קריאה לפעולה GetBids של BFE, אחזור של אותות K/V, קריאה לפעולה ScoreAd של Auction Service ואז החזרת התוצאה המוצפנת של מכרז B&A ל-SAS. כשהשירות הוא חלק מהסטאק של המוכר ברמה העליונה במכרז של מספר מוכרים שמנוהל על ידי שרת, השירות מטפל גם בבקשה GetComponentAuctionCiphertexts מ-SAS.
	Auction Service	השירות מטפל בבקשה ScoreAd מ-SFE. הוא אחראי להרצת הלוגיקה של הניקוד של המוכר ולמתן דירוג הרצון להגיש הצעת מחיר.

הארכיטקטורה של מכרז B&A של מודעות לרשת המדיה ב-PA

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

(תרשים בגודל מלא)

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

הגדרות מכרז

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

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

משתתפים

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

משתתף	תיאור
DSP-A	קונה במכשיר
DSP-B	קונה במכשיר
DSP-X	קונה של B&A
DSP-Y	קונה של B&A
SSP-TOP	מוכר ברמה העליונה
SSP-OD	מוכר שמציע מוצרים במכשיר בלבד
SSP-BA	מוכר של מוצרים לבית ולגן בלבד
SSP-MIX	בית עסק שמציע שילוב של אמצעי תשלום

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

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

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

• SSP-OD מפעיל מכירה פומבית במכשיר בלבד
• SSP-BA מפעיל מכירה פומבית של מודעות B&A בלבד
• SSP-MIX מפעיל מכרז במצב משולב
• SSP-TOP מפעיל מכרז עם מספר מוכרים:
  • SSP-OD/BA/MIX משתתפים כספקים של רכיבים במכרז של SSP-TOP עם כמה מוכרים

מכרז B&A של מוכר יחיד

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

(תרשים בגודל מלא)

בהגדרה הקודמת, SSP-BA מפעיל מכרז B&A שבו DSP-X ו-DSP-Y משתתפים באמצעות סטאק הקונה של שירותי B&A. שירות המודעות של המוכר מפעיל קודם מכרז לפי הקשר עבור DSP-X ו-DSP-Y, ולאחר מכן מפעיל מכרז של קהל מוגן על ידי שליחת הבקשה 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, המוכר יוצר nonce של UUID שמוגדר בכותרת התגובה Ad-Auction-Result-Nonce כשהנתונים של המכרז לפי הקשר מועברים בסטרימינג לדפדפן. אותו מספר חד-פעמי משמש בקריאה SelectAd ל-SFE במכרז B&A, והוא נכלל בתשובה SelectAd שמוחזרת מ-SFE. במהלך שלב המכרז בצד הלקוח, הדפדפן מאמת שה-nonce בכותרת התגובה Ad-Auction-Result-Nonce תואם ל-nonce בתוכן המשא של תוצאת המכרז המוצפן.

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

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

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

יש שתי דרכים להפעיל מכרז פתוח עם מספר מוכרים עם בידינג בזמן אמת:

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

מכרז עם כמה מוכרים שמנוהל על ידי המכשיר

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

(תרשים בגודל מלא)

בהגדרה הזו, SSP-TOP, שהוא המוכר ברמה העליונה, מפעיל מכרז עם מספר מוכרים שבו משתתפים SSP-OD,‏ SSP-BA ו-SSP-MIX:

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

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

await navigator.runAdAuction({
  seller: 'https://ssp-top.example',
  decisionLogicURL: 'https://ssp-top.example/score-ad.js',
  componentAuctions: [
    // SSP-BA's B&A-only auction
    {
      seller: 'https://ssp-ba.example',
      requestId: 'g8312cb2-da2d-4e9b-80e6-e13dec2a581c',
      serverResponse: Uint8Array(560) [193, 120, 4, …] // Encrypted B&A auction result
    },
    // SSP-MIX's B&A auction of mixed-mode
    {
      seller: 'https://ssp-mix.example',
      requestId: 'f5135cb2-da2d-4e9b-80e6-e13dec2a581c',
      serverResponse: Uint8Array(560) [133, 20, 4, …] // Encrypted B&A auction result
    }.
    // SSP-MIX's on-device auction of mixed-mode
    {
      seller: 'https://ssp-mix.example',
      interestGroupBuyers: ['https://dsp-a.example', 'https://dsp-b.example'],
      decisionLogicURL: 'https://ssp-mix.example/score-ad.js',
    }
    // SSP-OD's on-device auction
    {
      seller: 'https://ssp-od.example',
      interestGroupBuyers: ['https://dsp-a.example', 'https://dsp-b.example'],
      decisionLogicURL: 'https://ssp-od.example/score-ad.js',
    }
  ]
})

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

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

(תרשים בגודל מלא)

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

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

הגדרות ה-proto לבקשה ולתגובה של 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;
}

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

השלבים הבאים

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

מידע נוסף

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

יש לך שאלות?

• כדי לשאול שאלות על שירותי בידינג ומכרזים, פותחים פנייה במאגר של שירותי בידינג ומכרזים.
• כדי לשאול שאלות כלליות על ארגז החול לפרטיות, אפשר לפתוח פנייה במאגר privacy-sandbox-dev-support .