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

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

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

שליחת בקשות בו-זמנית לגבי מפרסמים שונים

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

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

שימוש בפרמטרים pageSize,‏ filter ו-orderBy

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

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

אם אתם צריכים לאחזר רק קבוצת משנה של התגובה המלאה של הרשימה, תוכלו לבצע אופטימיזציה של השימוש במכסה באמצעות הפרמטרים האופציונליים 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) מוטמעת בספריות הלקוח, בדוגמאות הקוד להורדת SDF. התהליך המפורט להטמעת השהיה מעריכית פשוטה לפני ניסיון חוזר (exponential backoff) הוא:

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