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

דף זה תורגם על ידי Cloud Translation API.

שיטות מומלצות לדיווח

בונים דוחות חדשים קודם בממשק המשתמש

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

אחרי שיוצרים את הדוח, לוחצים על התכונה 'Try this API' בדף של מסמכי העזר כדי לבצע queries.get של משאב Query. תוכלו להשתמש בקובץ ה-JSON שהוחזר כדי ליצור דוחות עתידיים.

שימוש במדדים ובמסננים ספציפיים לסוג הדוח

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

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

`ReportType`	מסננים ומדדים רלוונטיים
`INVENTORY_AVAILABILITY`	מסננים עם הקידומת `FILTER_TRUEVIEW_IAR`.
`YOUTUBE`	מסננים עם הקידומת `FILTER_TRUEVIEW`, לא כולל מסננים עם הקידומת `FILTER_TRUEVIEW_IAR`. מדדים עם הקידומת `METRIC_TRUEVIEW`.
`GRP`	מדדים עם הקידומת `METRIC_GRP`.
`YOUTUBE_PROGRAMMATIC_GUARANTEED`	מסננים עם הקידומת `FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED`. מדדים עם הקידומת `METRIC_PROGRAMMATIC_GUARANTEED`.
`REACH`	מדדים עם הקידומת `METRIC_UNIQUE_REACH`.
`UNIQUE_REACH_AUDIENCE`	מדדים עם הקידומת `METRIC_UNIQUE_REACH`.

שמירה של דוחות ושימוש חוזר בהם

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

תזמון דוחות

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

שילוב דוחות דומים

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

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

כדאי לשקול מכסות לדיווח

שימוש אחראי בתכונת הדיווח של Display & Video 360 נאכף במסגרת מכסות השימוש הבאות ברמת המוצר.

הפעלות של דוחות אד-הוק ביום

הגבלת מספר הדוחות אד-הוק שמשתמש יכול להריץ בפרק זמן של 24 שעות. כדי לא לחרוג מהמכסה הזו:

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

דוחות מתוזמנים פעילים

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

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

דוחות בו-זמנית

האפשרות הזו מגבילה את מספר הדוחות שמשתמש יכול להריץ בו-זמנית. כדי לא לחרוג מהמכסה הזו:

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

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

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

לא ניתן לחזות כמה זמן יימשך הרצת הדוח. משך הזמן יכול לנוע בשניות עד שעות, בהתאם לגורמים רבים, כולל טווח התאריכים וכמות הנתונים לעיבוד. אין גם קשר בין זמן הריצה של הדוח לבין מספר השורות שהוחזרו בדוח. לכן, צריך לאחזר באופן קבוע את משאב הדוח באמצעות השיטה queries.reports.get ולבדוק אם השדה metadata.status.state של המשאב עודכן ועכשיו הוא DONE או FAILED, כדי לקבוע אם הוא הסתיים. זהו תהליך שנקרא 'הצבעות'.

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

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

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

כך מטמיעים השהיה מעריכית פשוטה:

שליחת בקשת queries.reports.get ל-API.
מאחזרים את אובייקט הדוח. אם השדה metadata.status.state אינו DONE או FAILED, המשמעות היא שהרצת הדוח לא הסתיימה.
ממתינים 5 שניות + מספר אקראי של אלפיות השנייה ומנסים שוב לשלוח את הבקשה.
מאחזרים את אובייקט הדוח. אם השדה metadata.status.state אינו DONE או FAILED, המשמעות היא שהרצת הדוח לא הסתיימה.
ממתינים 10 שניות + מספר אקראי של אלפיות השנייה ומנסים שוב לשלוח את הבקשה.
מאחזרים את אובייקט הדוח. אם השדה metadata.status.state אינו DONE או FAILED, המשמעות היא שהרצת הדוח לא הסתיימה.
ממתינים 20 שניות + מספר אקראי של אלפיות השנייה ומנסים שוב לשלוח את הבקשה.
מאחזרים את אובייקט הדוח. אם השדה metadata.status.state אינו DONE או FAILED, המשמעות היא שהרצת הדוח לא הסתיימה.
ממתינים 40 שניות + מספר אקראי של אלפיות השנייה ומנסים שוב לשלוח את הבקשה.
מאחזרים את אובייקט הדוח. אם השדה metadata.status.state אינו DONE או FAILED, המשמעות היא שהרצת הדוח לא הסתיימה.
ממתינים 80 שניות + מספר אקראי של אלפיות השנייה ומנסים שוב לשלוח את הבקשה.
ממשיכים את הדפוס הזה עד שאובייקט הדוח מתעדכן או מסתיים הזמן המקסימלי.

אם הרצת הדוח תסתיים במצב DONE, תוכלו לאחזר את קובץ הדוח שנוצר מ-Google Cloud Storage בנתיב שמופיע בשדה metadata.googleCloudStoragePath.