שיפור זמן האחזור במכרז של Protected Audience API

כדאי לוודא ש-Protected Audience API פועל באופן יעיל לכולם:

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

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

שיטות מומלצות לקונים (מגיש הצעות מחיר)

כדי לוודא שאתם מבצעים אופטימיזציה ליעילות המכרז של Protected Audience API, כדאי לפעול לפי השיטות המומלצות הבאות.

פחות בעלים של קבוצות אינטרס

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

על מנת לצמצם את ההוצאות של המשאבים היקרים מאוד האלה, חשוב מאוד שיהיו בעלי מספר קטן יותר של בעלים של קבוצות אינטרס. הימנעו משימוש בקבוצות עניין שונות שנמצאות בבעלות של תת-דומיינים שונים. לדוגמה, אם ל-adtech.example היו קבוצות של תחומי עניין בבעלות cats.adtech.example ו-dogs.adtech.example, סביר להניח שהדפדפן ישתמש בשני תהליכים נפרדים כדי להריץ את הסקריפטים של הבידינג.

בידינג על פחות קבוצות של תחומי עניין

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

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

סינון קבוצות של תחומי עניין מבידינג בשירות מפתח/ערך

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

שימוש חוזר בסביבת הביצוע של JavaScript

כדי שהדפדפן יוכל להפעיל את generateBid(), הוא צריך להפעיל סביבת הפעלה חדשה של JavaScript. הפעולה הזו עשויה להימשך זמן רב, בהשוואה למשך הזמן המינימלי שנדרש לביצוע ב-generateBid(). ניתן לשמור את הזמן הזה באמצעות מצבי הביצוע 'קיבוץ לפי מקור' או 'הקשר קפוא'.

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

שימוש חוזר בסקריפטים של בידינג

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

שימוש חוזר ב-trustedBiddingSignalsUrls

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

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

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

אחזורים קטנים יותר של אותות מהימנים לצורך בידינג בזמן אמת

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

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

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

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

מתן עדיפות לקבוצות אינטרס

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

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

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

שיטות מומלצות לאתרי מכירה

חשוב לבצע מעקב אחרי יעילות המכרז של Protected Audience API ומתבצעת אופטימיזציה שלו.

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

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

מעקב אחר המכרזים

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

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

הגנה מפני סקריפטים של הצעות מחיר איטיות

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

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

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

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

מה השלב הבא?

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

דיון על ה-API

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

התנסות עם ה-API

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