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

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

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

הגדרות

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

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

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

משתתפים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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