שיפור זמן האחזור במכרז של 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().

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

סינון קבוצות של משתמשים שהביעו עניין מהגשת הצעות מחיר בשירות המפתחות/הערכים

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

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

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

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

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

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

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

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

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

שימוש חוזר trustedBiddingSignalsUrls

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

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

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

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

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

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

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

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

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

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

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

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

שיטות מומלצות למוכרים

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

הפעלת מכרזים במקביל

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

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

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

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

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

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

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

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

מה השלב הבא?

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

דיון על ה-API

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

התנסות עם ה-API

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