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

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

לפני שמתחילים, מומלץ לקרוא את המאמר Protected Audience ואת המאמר header bidding בתיעוד של Prebid.js כדי להבין את העקרונות הבסיסיים של ה-API.

הגדרות

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

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

משתתפים

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

הגדרת מכרז רציף

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

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

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

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

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

לפני המכרז

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

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

מכרזים הקשריים עם Prebid.js ו-Publisher Ad Server

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

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

1. הפעלת מכרז בהקשר
   המשתמש נכנס לדף של בעל התוכן הדיגיטלי.
2. הדף של בעל התוכן הדיגיטלי טוען את הספרייה בצד הלקוח של שרת המודעות של בעל התוכן הדיגיטלי ומגדיר מיקומי מודעות.
3. הדף של בעל התוכן הדיגיטלי טוען את Prebid ומתחיל את המכרז ההקשרי של בידינג על מיקומי מודעות בכותרת.
4. מכרז קונטקסטואלי של מוכר א'
   (פועל במקביל למכרז הקונטקסטואלי של מוכר ב')
   ‫Prebid.js שולח בקשה להצעת מחיר למוכר א'.
5. מוכר א' מאחזר את התשובות להצעות המחיר ואת 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 API

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

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

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

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

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

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

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

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

אינטראקציה ושיתוף משוב

מה השלב הבא?

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

דיון על ה-API

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

התנסות עם ה-API

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