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

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

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

קודם יוצרים דוחות חדשים בממשק המשתמש

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

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

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

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

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

`ReportType`	מסננים ומדדים רלוונטיים
`YOUTUBE`	מסננים עם הקידומת `FILTER_TRUEVIEW`. מדדים עם הקידומת `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 באמצעות טופס הפנייה.

שימוש בהשהיה מעריכית (exponential backoff) בזמן הבדיקה של סטטוס הדוח

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

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

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

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

התהליך להטמעת השהיה מעריכית פשוטה לפני ניסיון חוזר (exponential 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.