אופטימיזציה של מכסה

כל אפליקציה שמשתמשת ב-Display & Video 360 API חיונית לאופטימיזציה של המכסות. אופטימיזציה של השימוש במכסות משפרת את הביצועים: היא מייעלת את הבקשות ל-API ועוזרת להימנע משגיאות שהוחזרו עקב חריגה ממגבלות הקצב שהוגדרו.

בדף הזה מפורטות שיטות מומלצות כלליות והדגשה של תכונות נוספות ב-Display & Video 360 API שיכולות לעזור לצמצם את השימוש במכסות.

הגשת בקשות במקביל למפרסמים שונים

ברוב השיטות ב-Display & Video 360 API מצוין מפרסם בכתובת ה-URL. בנוסף למכסה ברמת הפרויקט, השיטות האלה נאכפות מגבלות קצב של 'לכל מפרסם לפרויקט' מגבילות יותר כשיוצרים קריאות שמציינות את אותו מפרסם.

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

שימוש בפרמטרים של `filter` ו-`orderBy`

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

הפרמטר filter מאפשר להגביל את המשאבים שמאוחזרים על ידי הקריאה list לאלה שהמאפיינים שלהם תואמים לביטויים נתונים. הפרמטר הזה שימושי כשמנסים לאחזר:

משאב ספציפי עם מזהה לא ידוע אבל מאפיינים ידועים. אם מחפשים משאב ספציפי, אפשר לסנן את הרשימה שהוחזרה לפי מאפיינים ידועים של המשאב הרצוי. לדוגמה, סינון פריטים לפי displayName ידוע, נכסי קריאייטיב לפי creativeType צפויים ומקורות מלאי לפי exchange הרלוונטי.
משאבים משויכים. לעיתים קרובות, משאבים ב-Display & Video 360 משויכים זה לזה. אפשר להשתמש במסננים כדי להגביל את המשאבים שמוחזרים למשאבים שיש להם קשר ספציפי אחד עם השני. לדוגמה, אחזור כל הזמנות ההוספה מתחת לcampaignId ספציפי, וכל נכסי הקריאייטיב שהוקצו לפריט שורה.
רק משאבים שיש להם נכסים שמאפשרים פעולה. הפונקציונליות של ה-API מאפשרת לבדוק בקלות את הסטטוס של המשאבים ולהגיב באופן פרוגרמטי. בעזרת מסננים אפשר להשתמש בקריאות list כדי לקבל משאבים רק במקרים שבהם צריך לבצע פעולה. לדוגמה, אחזור של כל הפריטים שמציגים lineItemWarningMessage שניתן לבצע בהם פעולה, את כל הזמנות ההוספה שעודכנו מאז תאריך ושעה מסוימים, או את כל נכסי הקריאייטיב שנכשלו approvalStatus.

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

שימוש בפונקציות בכמות גדולה או ברמת המשאבים

ב-Display & Video 360 API יש כמה פונקציות בכמות גדולה ובכל המשאבים, שמבצעות מספר פעולות באמצעות בקשה אחת. דוגמאות לפונקציות מהסוג הזה:

עריכה בכמות גדולה של אתרים השייכים לערוץ יחיד. לערוצים יכולים להיות מוקצים אלפי אתרים. במקום לנהל את רשימת האתרים של ערוץ עם בקשות create או delete נפרדות, אפשר להשתמש בבקשת bulkEdit או replace יחידה כדי להוסיף ולהסיר מספר אתרים או להחליף את כל התוכן של הערוץ, בהתאמה.
ניהול כל חבילת הטירגוט של מפרסם. חבילת טירגוט של משאב מוקצית במספר סוגי טירגוט. פונקציות טירגוט ברמת המשאב, כמו listAssignedTargetingOptions ו-editAssignedTargetingOptions בשירות advertisers, מאפשרות לאחזר, ליצור ולהסיר הגדרות טירגוט בכמה סוגי טירגוט בבקשה אחת. כך מפחיתים את עלות המכסה של הגדרת חבילת טירגוט של מפרסם לבקשה יחידה.
הגדרה של אותה הגבלת טירגוט במספר פריטים. אם אתם צריכים לבצע את אותם שינויי טירגוט במספר פריטים בבת אחת, אפשר להשתמש בבקשת advertisers.lineItems.bulkEditAssignedTargetingOptions אחת.
הפעלה או השהיה של מספר פריטים. צריך להפעיל את הפריטים אחרי שיוצרים אותם, ורק לאחר מכן ניתן להתחיל להציג מודעות. אם אתם יוצרים כמה פריטים ברצף, אפשר להפעיל את כולם באמצעות בקשת advertisers.lineItems.bulkUpdate אחת. אפשר להשתמש באותה שיטה כדי להשהות מספר פריטים כדי להפסיק את הצגתם.

שמירה במטמון ובדיקה של מזהים שנעשה בהם שימוש לעיתים קרובות

פעולות רבות ב-Display & Video 360 API מחייבות שימוש במזהי משאבים שמאוחזרים דרך ה-API עצמו, כולל מזהים של אפשרויות טירגוט, מזהי קהלים של Google ועוד. כדי לא לאחזר את המזהים מה-API בכל שימוש, מומלץ לאחסן את המזהים האלה באופן מקומי.

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

הטמעת השהיה מעריכית לפני ניסיון חוזר (exponential backoff) לפעולות ממושכות

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

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

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

שולחים בקשת sdfdownloadtasks.operations.get ל-API.
מאחזרים את אובייקט הפעולה.
- אם השדה done לא נכון, המשמעות היא שצריך לנסות שוב את הבקשה.
- צריך להמתין 5 שניות + מספר אקראי של אלפיות השנייה ולנסות שוב את הבקשה.
מאחזרים את אובייקט הפעולה.
- אם השדה done לא נכון, המשמעות היא שצריך לנסות שוב את הבקשה.
- ממתינים 10 שניות + מספר אקראי של אלפיות השנייה ומנסים שוב את הבקשה.
מאחזרים את אובייקט הפעולה.
- אם השדה done לא נכון, המשמעות היא שצריך לנסות שוב את הבקשה.
- ממתינים 20 שניות + מספר אקראי של אלפיות השנייה ומנסים שוב את הבקשה.
מאחזרים את אובייקט הפעולה.
- אם השדה done לא נכון, המשמעות היא שצריך לנסות שוב את הבקשה.
- ממתינים 40 שניות + מספר אקראי של אלפיות השנייה ומנסים שוב את הבקשה.
מאחזרים את אובייקט הפעולה.
- אם השדה done לא נכון, המשמעות היא שצריך לנסות שוב את הבקשה.
- ממתינים 80 שניות + מספר אקראי של אלפיות השנייה ומנסים שוב את הבקשה.
ממשיכים את הדפוס הזה עד שאובייקט השאילתה יעודכן או עד שיחלוף הזמן המקסימלי.