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

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

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

הגדרות

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

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

משתתפים

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

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

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

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

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

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

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

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

1. לפני המכרז, המשתמש נוסף לקבוצת תחומי עניין באתר של מפרסם.
2. כשמשתמש מבקר בדף של בעל התוכן הדיגיטלי במועד מאוחר יותר, התכונה Prebid.js מפעילה מכרז לפי הקשר כדי לאסוף את התגובות להצעות המחיר ממגישי הצעות המחיר ב-header. במהלך השלב הזה, הקונים עשויים לספק את האותות, והמוכרים עשויים לספק הגדרות מכרז של רכיבים שישמשו במכרז Protected Audience שיוצג בהמשך. Prebid.js מספק מודול להפצת האותות וההגדרות האלה למכירה הפומבית של Protected Audience.
3. התגובות לבקשות להצעת מחיר שנאספו על ידי Prebid.js נשלחות לשרת המודעות של בעלי התוכן הדיגיטלי לצורך מכרז לפי הקשר בצד השרת.
4. שרת המודעות לבעלי תוכן דיגיטלי עשוי לשלב את תוצאות המכרז שלו, תוצאות הבידינג ב-header, מלאי שטחי הפרסום שנמכר ישירות ועוד, כדי לקבוע איזו מודעה תניב את ההכנסות הגבוהות ביותר לבעל התוכן הדיגיטלי. המודעה שתזכה במכרז תוחזר לספרייה בצד הלקוח בשרת המודעות של בעל התוכן הדיגיטלי.
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 ושרת המודעות של בעלי התוכן הדיגיטלי

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

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

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

1. אתחול מכרז לפי הקשר המשתמש מבקר בדף של בעל התוכן הדיגיטלי.
2. הדף של בעל התוכן הדיגיטלי טוען את הספרייה בצד הלקוח של שרת המודעות של בעל התוכן הדיגיטלי ומגדיר את מיקומי המודעות בדף.
3. הדף של בעל התוכן הדיגיטלי טוען את הצעת המחיר מראש ומתחיל את המכרז לפי הקשר של הבידינג ל-header.
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. שרת המודעות לבעלי תוכן דיגיטלי מפעיל מכרז לפי הקשר כדי לקבוע מהי המודעה הטובה ביותר בין קמפיינים במכירה ישירה, הצעות מחיר פרוגרמטיות, הצעות מחיר לפי הקשר של הצעת מחיר מוקדמת ומלאי אחר של שטחי פרסום.
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, ולוגיקת הציון עשויה להשוות את מחיר הצעת המחיר לפי הקשר בין הצעות המחיר במכרז לבין מחיר הצעת המחיר הזוכה במכרז של רכיב Protected Audience.

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

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

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

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

מה השלב הבא?

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

דיון על ה-API

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

התנסות עם ה-API

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