הגדרת מכרזים רצופים עם בידינג ב-header ומכרזים של Protected Audience API עם כמה מוכרים

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

לפני שמתחילים, מומלץ לקרוא את המאמר בנושא דף הנחיתה ובנושא בידינג בכותרת במסמכי התיעוד של Prebid.js.

הגדרות

מכירות פומביות

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

משתתפים

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

הגדרת מכרזים רצופיים

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

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

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

בדוגמה הזו להגדרת מכרזים ברצף, יכול להיות שיתבצעו בדף שלושה מכרזים גדולים בסדר הבא: 1) מכרז לפי הקשר על ידי ספריית הבידינג בכותרת, 2) מכרז לפי הקשר על ידי שרת המודעות של בעל התוכן הדיגיטלי ו-3) מכרז של קהל מוגן.

סקירה כללית של מכרז מרובה-מוכרים עם הגנה על קהל, עם מכרז לפי הקשר בבידינג ב-header.

תיאור מפורט של תרשים הסקירה הכללית:

1. לפני המכרז, המשתמש מתווסף לקבוצת תחומי עניין באתר של המפרסם.
2. כשהמשתמש נכנס לדף של בעל התוכן הדיגיטלי בשלב מאוחר יותר, המערכת של Prebid.js מפעילה מכרז לפי הקשר כדי לאסוף את תגובות הצעות המחיר ממגישי הצעות המחיר בכותרת. בשלב הזה, הקונים יכולים לספק את האותות והמוכרים יכולים לספק הגדרות של מכרז רכיב לשימוש במכרז שלאחר מכן לקהל מוגן. ב-Prebid.js יש מודול להעברת האותות וההגדרות האלה למכרז של קהלים מוגנים.
3. תגובות לבקשות להצעות מחיר שנאספות על ידי Prebid.js נשלחות לשרת המודעות של בעל התוכן הדיגיטלי כדי לקיים מכרז לפי הקשר בצד השרת.
4. שרת המודעות של בעלי התוכן הדיגיטלי עשוי לשלב תוצאות של מכרזים משלו, תוצאות של בידינג בכותרות, מלאי שטחי פרסום שנמכר ישירות ועוד, כדי לקבוע איזו מודעה תניב לבעלי התוכן הדיגיטלי את ההכנסה הגבוהה ביותר. המודעה הזוכה מוחזרת לספרייה בצד הלקוח של שרת המודעות של בעלי התוכן הדיגיטלי.
5. ספריית הצד הלקוח של שרת המודעות של בעל התוכן הדיגיטלי יכולה להעביר את מחיר הצעת המחיר המותאם של המנצח במכרז לפי הקשר, יחד עם האותות של הקונה (perBuyerSignals) והגדרות המכרז של הרכיב של המוכר שנאספו על ידי Prebid.js, למכרז של קהל מוגן.
6. המכרז עם מספר מוכרים של Protected Audience מבוצע על ידי המוכר ברמה העליונה. בשלב הניקוד של המוכר ברמה העליונה, המוכר ברמה העליונה יכול להשוות בין מחיר הצעת המחיר הזוכה בכל מכרז רכיב לבין מחיר הצעת המחיר הזוכה המותאם במכרז לפי הקשר. אם מחיר הצעת המחיר של הרכיב נמוך ממחיר הצעת המחיר במכרז לפי הקשר, המוכר ברמה העליונה מחזיר את דירוג הרצון של 0. אם כל הצעות המחיר מקבלות את הדירוג 0, הקריאה ל-runAdAuction() מחזירה את הערך null, שמציין שצריך להציג את המודעה הזוכה במכרז לפי הקשר.
7. הספרייה בצד הלקוח של שרת המודעות של בעל התוכן הדיגיטלי תיצור את המודעה הזוכה של Protected Audience או את המודעה לפי הקשר, על סמך מה שהוחזר מהקריאה ל-runAdAuction().
8. המודעה הזוכה תוצג למשתמש.

לפני המכרז

רצף זמן של קבוצת תחומי עניין בדף של מפרסם.

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

1. המשתמש מנווט לאתר של המפרסם.
2. האתר של המפרסם טוען את הסקריפט מכל קונה שמשתתף במכרז בשלב מאוחר יותר.
3. הסקריפט של הקונה מכיל את הקריאה joinAdInterestGroup() להוספת המשתמש לקבוצת האינטרס של הקונה.

מכרזים לפי הקשר עם Prebid.js ועם שרת המודעות של בעל האתר

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

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

בעלי האפליקציה מפעילים קודם מכרז לפי הקשר של בידינג בכותרת על ידי קריאה ל-Prebid.js עם דגל כדי לציין שמכרז של קהל מוגן יופעל לאחר מכן. לאחר מכן, הקוד Prebid.js אוסף את תגובות הצעות המחיר ושולח אותן לשרת המודעות של בעל התוכן הדיגיטלי כדי לקיים מכרז לפי הקשר בצד השרת. בשלב איסוף תגובות לבידינג, הקונים והמוכרים יכולים לספק הגדרות של מכרז רכיב ואותות של קונים (perBuyerSignals) לשימוש במכרז שלאחר מכן לקהל המוגן, אם הם רוצים להשתתף. הגדרת המכרז של הרכיב הזה תועבר בסופו של דבר למכרז הבא של Protected Audience API.

1. הפעלת מכרז לפי הקשר המשתמש נכנס לדף של בעלי התוכן הדיגיטלי.
2. בדף של בעלי התוכן הדיגיטלי נטענת הספרייה בצד הלקוח של שרת המודעות של בעלי התוכן הדיגיטלי, ומוגדר בהם מיקומי המודעות.
3. דף בעל התוכן הדיגיטלי טוען את Prebid ומתחיל את המכרז לפי הקשר של בידינג בכותרת.
4. המכרז לפי הקשר של מוכר א'(הוא פועל במקביל למכרז לפי הקשר של מוכר ב'). הקוד Prebid.js שולח בקשת הצעת מחיר אל מוכר א'.
5. מוכר א' מאחזר מהקונים את תשובות הצעות המחיר perBuyerSignals ו-perBuyerSignals.
6. מוכר א' מפעיל מכרז לפי הקשר.
7. מוכר א' יוצר את הגדרת המכרז של הרכיב עם perBuyerSignals כלול.
8. מוכר א' משיב ל-Prebid.js עם הצעת המחיר הזוכה והגדרות המכרז של הרכיב.
9. המכרז לפי הקשר של מוכר ב' (מתבצע במקביל למכרז לפי הקשר של מוכר א'). הקוד Prebid.js שולח בקשת הצעת מחיר למוכר ב'.
10. מוכר ב' מאחזר את תגובות הצעות המחיר ו-perBuyerSignals מהקונים.
11. מוכר ב' מפעיל מכרז לפי הקשר.
12. מוכר ב' יוצר את הגדרות המכרז של הרכיב, כולל perBuyerSignals.
13. מוכר ב' משיב ל-Prebid.js עם הצעת המחיר הזוכה והגדרות המכרז של הרכיב.
14. המכרז לפי הקשר של שרת המודעות של בעל התוכן הדיגיטלי: תגובות לבקשות להצעות מחיר שנאספות על ידי Prebid.js נשלחות לשרת המודעות של בעל התוכן הדיגיטלי למכרז לפי הקשר.
15. הגדרות המכרז של הרכיבים עם אותות של קונים משותפות עם הספרייה בצד הלקוח של שרת המודעות של בעלי התוכן הדיגיטלי
16. שרת המודעות של בעל התוכן מפעיל מכרז לפי הקשר כדי לקבוע איזו מודעה תוצג – מבין קמפיינים שנמכרו ישירות, הצעות מחיר פרוגרמטיות, הצעות מחיר לפי הקשר של Prebid ומלאי אחר של שטחי פרסום.
17. שרת המודעות של בעל התוכן הדיגיטלי מחזיר את הצעת המחיר הזוכה המותאמת.

מכרז עם כמה מוכרים בשילוב עם Protected Audience

רצף הזמנים של מכרז Protected Audience בדף של בעל התוכן הדיגיטלי.

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

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

1. אתר המוציא לאור טוען את הסקריפט של המוכר ברמה העליונה.
2. הספרייה בצד הלקוח של שרת המודעות של בעלי התוכן הדיגיטלי מספקת את מחיר הצעת המחיר במכרז לפי הקשר, הגדרות של מכרז רכיב עם אותות מהקונים אל המוכר ברמה העליונה. אפשר להעביר את מחיר הצעת המחיר הזוכה של המודעה במכרז לפי הקשר כאותות של מוכר (מחיר הצעת המחיר הזה הופך לזמין בפונקציה scoreAd() של המוכר ברמה העליונה).
3. המוכר ברמה העליונה מתחיל את המכרז של Protected Audience API באמצעות קריאה ל-runAdAuction().
4. מכרז רכישת רכיב של מוכר א' (הוא פועל במקביל למכרז רכישת הרכיב של מוכר ב'). הדפדפן קורא את קבוצות תחומי העניין של המשתמש לכל הקונים שמשתתפים במכרז הרכישה של הרכיב של מוכר א'.
5. הדפדפן מאחזר את סקריפט הבידינג ואת אותות הבידינג המהימנים מהמיקומים שצוינו בקבוצות העניין של הקונים שמשתתפים במכרז הרכישה של הרכיב.
6. הדפדפן יוצר את הצעות המחיר על ידי הפעלת הלוגיקה של כל קונה ליצירת הצעות מחיר.
7. הדפדפן מאחזר את סקריפט הדירוג ואת אותות הדירוג המהימנים של כל מודעה ממוכר א'.
8. הדפדפן מבצע את הלוגיקה של סולם הדירוג של מוכר א' לכל הצעת מחיר.
9. הדפדפן בוחר את המודעה עם הציון הגבוה ביותר שנשלח על ידי הלוגיקה של מערכת הדירוג של מוכר א'.
10. מכרז רכישת רכיב של מוכר ב (המתנהל במקביל למכרז רכישת הרכיב של מוכר א'). הדפדפן קורא את קבוצות תחומי העניין של המשתמש לכל הקונים שמשתתפים במכרז הרכישה של המוכר השני.
11. הדפדפן מאחזר את סקריפט הבידינג ואת אותות הבידינג המהימנים מהמיקומים שצוינו בקבוצות העניין של הקונים שמשתתפים במכרז הרכישה של הרכיב.
12. הדפדפן יוצר את הצעות המחיר על ידי הפעלת הלוגיקה של כל קונה ליצירת הצעות מחיר.
13. הדפדפן מאחזר את סקריפט הדירוג ואת אותות הדירוג המהימנים של כל מודעה ממוכר ב'.
14. הדפדפן מבצע את הלוגיקה של מערכת הדירוג של מוכר ב' לכל הצעה.
15. הדפדפן בוחר את המודעה עם הציון הגבוה ביותר שנשלח על ידי הלוגיקה של דירוג המוצרים של מוכר ב'.

ציון במכרז ברמה העליונה ורינדור של מודעות

רצף הטעינה של המודעות בדף של בעל התוכן הדיגיטלי.

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

אם מחיר הצעת המחיר הזוכה במכרז לפי הקשר גבוה ממחיר הצעת המחיר הזוכה במכרז הרכיבים, הפונקציה scoreAd() יכולה להחזיר את דירוג הרצון 0. אם אין מודעות עם ציון רצון גבוה מ-0, המשמעות היא שהמודעה הזוכה במכרז לפי הקשר היא בעלת ערך גבוה יותר מכל אחת מהמודעות הזוכות במכרז הרכיבים, והפונקציה runAdAuction() מחזירה את הערך null.

אם במכרז של הקהל המוגן אין זוכה והוא מחזיר את הערך null, הספרייה בצד הלקוח של שרת המודעות של בעל התוכן הדיגיטלי יכולה להציג את המודעה שזכתה במכרז לפי הקשר ב-iframe. אם המכרז בשילוב עם Protected Audience API מנצח במכרז לפי הקשר ומחזיר אובייקט FencedFrameConfig או URN אטום, אפשר להציג את המודעה הזוכה במכרז בשילוב עם Protected Audience API בפריים מגודר או ב-iframe.

1. הקצאת ציונים למודעות במכרז ברמה העליונה הדפדפן מאחזר את סקריפט הניקוד מהמוכר ברמה העליונה, יחד עם אותות מהימנים של ניקוד לכל מודעה.
2. הדפדפן מבצע את הלוגיקה של הניקוד של המוכר ברמה העליונה לכל הצעת מחיר מנצחת בכל מכרזי הרכיבים. בתוך הסקריפט scoreAd() של המוכר ברמה העליונה, ללוגיקת הסקריפט יש גישה למחיר של הצעת המחיר הזוכה שהותאמה במכרז לפי הקשר, שעשוי להיות מועבר כ-sellerSignals בתצורת המכרז. הסקריפט יכול להשוות בין מחיר הצעת המחיר הזוכה לפי הקשר לבין מחיר הצעת המחיר של הרכיב 'קהל מוגן', ולהחזיר ציון רצון של 0 אם מחיר הצעת המחיר לפי הקשר גבוה יותר. אחרת, הסקריפט מחשב את דירוג הרצון, כנראה על סמך מחיר הצעת המחיר של הרכיב 'קהל מוגן'.
3. הדפדפן בוחר את המודעה עם ציון הרצון הגבוה ביותר שהוגשה על ידי הלוגיקה של מערכת הדירוג של המוכר ברמה העליונה.
4. אם המכרז של Protected Audience מנצח המכרז של Protected Audience מחזיר אובייקט FencedFrameConfig או URN אטום לספרייה בצד הלקוח של שרת המודעות של בעל התוכן הדיגיטלי.
5. הספרייה בצד הלקוח מגדירה את המאפיין config של המסגרת המגודרת לאובייקט FencedFrameConfig, או מגדירה את המאפיין src של ה-iframe ל-URN האטום של המודעה הזוכה של הקהל המוגן.
6. הדפדפן מאחזר מהקונה את המודעה הזוכה במכרז של Protected Audience API.
7. הדפדפן מציג את המודעה למשתמש.
8. אם המכרז לפי הקשר זוכה המכרז של Protected Audience API מחזיר את הערך null.
9. הדפדפן מגדיר את המאפיין src של ה-iframe למודעה הזוכה לפי הקשר.
10. הדפדפן מאחזר מהקונה את המודעה שזכתה במכרז לפי הקשר.
11. הדפדפן מציג את המודעה למשתמש.

יצירת מעורבות ושיתוף משוב

מה השלב הבא?

אנחנו רוצים להיות מעורבים בשיחות כדי לוודא שאנחנו מפתחים API שעובד עבור כולם.

דיון על ה-API

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

התנסות עם ה-API

אתם יכולים לערוך ניסויים ולהשתתף בשיחה על Protected Audience API.