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

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

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

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

שימוש חוזר ב-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() נמשכים זמן רב מדי.

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

מה השלב הבא?

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

דיון על ה-API

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

התנסות עם ה-API

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