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

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

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

הגדרות

בטבלאות הבאות מפורטים כמה מונחים שמופיעים במסמך הזה.

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

משתתפים

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

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

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

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

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

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

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

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

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

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

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

התחשבות בביקוש למודעות בהקשר מסוים עם ביקוש למודעות ב-Protected Audience

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

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