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

bookmark_border קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

הגדרות

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

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

משתתפים

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

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

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

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

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

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

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

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

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

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

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

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

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. הדפדפן מציג את המודעה למשתמש.