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

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

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

הגדרות

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

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

משתתפים

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

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

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

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

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

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

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

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

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

לפני מכירה פומבית

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

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

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

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

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

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

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

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 באמצעות קריאה ל-runAdAuction().
4. מכירה פומבית של רכיבים בחשבון א'
   (פועל במקביל למכרז הרכיבים של מפיץ ב')
   הדפדפן קורא את קבוצות האינטרס של המשתמש עבור כל הקונים שמשתתפים במכרז הרכיבים של מפיץ א'.
5. הדפדפן מאחזר את הסקריפטים של הבידינג ואת האותות המהימנים לבידינג מהמיקומים שצוינו בקבוצות האינטרס של הקונים שמשתתפים במכרז של הרכיבים.
6. הדפדפן יוצר את הצעות המחיר על ידי הפעלת הלוגיקה ליצירת הצעות מחיר של כל קונה.
7. הדפדפן מאחזר את סקריפט הניקוד ואת אותות הציון המהימנים של כל מודעה ממפיץ א'.
8. הדפדפן מפעיל את לוגיקת הניקוד של מפיץ א' לכל הצעת מחיר.
9. הדפדפן בוחר את המודעה עם הציון הגבוה ביותר שנשלח על ידי לוגיקת הניקוד של מפיץ א'.
10. מכרז הרכיבים של בית עסק ב'
    (פועל במקביל למכרז הרכיבים של מפיץ א')
    הדפדפן קורא את קבוצות האינטרס של המשתמש עבור כל הקונים שמשתתפים במכירה הפומבית של הרכיבים של מוכר ב'.
11. הדפדפן מאחזר את הסקריפטים של הבידינג ואת האותות המהימנים לבידינג מהמיקומים שצוינו בקבוצות האינטרס של הקונים שמשתתפים במכרז של הרכיבים.
12. הדפדפן יוצר את הצעות המחיר על ידי הפעלת הלוגיקה ליצירת הצעות מחיר של כל קונה.
13. הדפדפן מאחזר את סקריפט הניקוד ואת אותות הציון המהימנים של כל מודעה ממפיץ ב'.
14. הדפדפן מפעיל את לוגיקת הניקוד של מפיץ ב' לכל הצעת מחיר.
15. הדפדפן בוחר את המודעה עם הציון הגבוה ביותר שנשלח לפי לוגיקת הניקוד של מפיץ ב'.

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

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

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

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

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

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

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

מה השלב הבא?

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

דיון על ה-API

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

התנסות עם ה-API

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