रिपोर्ट करने के सबसे सही तरीके

यूज़र इंटरफ़ेस (यूआई) में सबसे पहले नई रिपोर्ट बनाएं

रिपोर्ट पर कई तरह की पाबंदियां और ज़रूरी शर्तें लागू होती हैं. ये शर्तें, रिपोर्टिंग टाइप, फ़िल्टर, डाइमेंशन, और मेट्रिक से जुड़ी होती हैं. एपीआई में ये सीमाएं लागू होती हैं, जिससे HTTP 400 गड़बड़ी मिलती है. रिपोर्ट बनाते समय होने वाली गड़बड़ियों से बचने के लिए, हमारा सुझाव है कि आप पहले Display & Video 360 यूज़र इंटरफ़ेस (यूआई) में नई रिपोर्ट बनाएं.

अपनी रिपोर्ट बनाने के बाद, Query रिसॉर्स का queries.get करने के लिए, रेफ़रंस दस्तावेज़ पेज पर "यह एपीआई आज़माएं" सुविधा पर क्लिक करें. आने वाले समय में रिपोर्ट बनाने के लिए, दिखाई गई JSON फ़ाइल का इस्तेमाल किया जा सकता है.

चेतावनी: क्वेरी और उनसे बनने वाली रिपोर्ट को एपीआई में, सिर्फ़ वह उपयोगकर्ता ऐक्सेस कर सकता है जिसने उन्हें बनाया है. यूज़र इंटरफ़ेस (यूआई) की शेयर करने की सेटिंग के ज़रिए, क्वेरी चलाने और एपीआई का इस्तेमाल करके रिपोर्ट पाने की अनुमति नहीं दी जा सकती.

रिपोर्ट के हर टाइप की मेट्रिक और फ़िल्टर का इस्तेमाल करें

कुछ मेट्रिक और फ़िल्टर वैल्यू, खास तरह की रिपोर्ट के लिए खास होती हैं. पहले यूज़र इंटरफ़ेस (यूआई) में अपनी रिपोर्ट बनाने के अलावा, कुछ ReportType वैल्यू से जुड़ी मेट्रिक और फ़िल्टर की पहचान, बिड मैनेजर एपीआई की वैल्यू से भी की जा सकती है.

यहां काम के बिड मैनेजर एपीआई फ़िल्टर और मेट्रिक वैल्यू की पहचान करने के कुछ तरीके दिए गए हैं. यह टेबल उन फ़िल्टर और मेट्रिक की पूरी सूची नहीं है जिनका इस्तेमाल इस तरह की रिपोर्ट में किया जा सकता है. सभी वैल्यू को एक रिपोर्ट में एक साथ इस्तेमाल नहीं किया जा सकता.

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 प्रीफ़िक्स वाली मेट्रिक.

रिपोर्ट सेव करना और उनका फिर से इस्तेमाल करना

हम सुझाव देते हैं कि आप नियमित रूप से की जाने वाली क्वेरी के लिए रिपोर्ट बनाएं और सेव करें, क्योंकि एक ही रिपोर्ट को कई बार डालने और मिटाने से संसाधनों की बर्बादी होती है. dataRange फ़ील्ड में मौजूद सेट Range वैल्यू का इस्तेमाल करने से, रिपोर्ट को फिर से इस्तेमाल किया जा सकता है. जैसे, PREVIOUS_DAY या LAST_7_DAYS.

रिपोर्ट शेड्यूल करें

ऐड-हॉक या वन-ऑफ़ रिपोर्ट, संसाधनों की बर्बादी हो सकती हैं. ऐसा इसलिए होता है, क्योंकि इन्हें अलग-अलग चलाया जाता है और ये अधूरे डेटासेट पर काम कर सकती हैं. शेड्यूल की गई रिपोर्ट रिपोर्टिंग संसाधनों का सबसे बेहतर इस्तेमाल करती हैं, क्योंकि वे बल्क में चलाई जाती हैं. साथ ही, इस बात की गारंटी दी जाती है कि जब तक पिछले दिन का डेटा प्रोसेस नहीं हो जाता, तब तक ये काम नहीं करेंगे. ज़्यादा जानकारी के लिए, शेड्यूलिंग के लिए उपलब्ध फ़ील्ड देखें.

मिलती-जुलती रिपोर्ट एक साथ जोड़ें

अगर अलग-अलग विज्ञापन देने वालों या पार्टनर के लिए, समय-समय पर एक जैसी मेट्रिक और तारीख की सीमाओं वाली रिपोर्ट जनरेट की जाती हैं, तो हमारा सुझाव है कि आप उनकी रिपोर्ट की संख्या को ऑप्टिमाइज़ करने के लिए रिपोर्ट को एक साथ जोड़ लें.

सभी रिपोर्ट के फ़िल्टर जोड़कर और सभी तरह के फ़िल्टर को डाइमेंशन के तौर पर जोड़कर, मिलती-जुलती रिपोर्ट को एक साथ जोड़ा जा सकता है. जनरेट होने के बाद, ओरिजनल रिपोर्ट बनाने के लिए, नतीजे वाली रिपोर्ट की लाइनों को ओरिजनल फ़िल्टर वैल्यू के साथ बांटा जा सकता है.

रिपोर्टिंग कोटा इस्तेमाल करें

Display & Video 360 रिपोर्टिंग सुविधा का ज़िम्मेदारी से इस्तेमाल करने के लिए, पूरे प्रॉडक्ट के इस्तेमाल के ये कोटा तय किए गए हैं.

हर दिन ऐड-हॉक रिपोर्ट लागू करना

इससे तय होता है कि उपयोगकर्ता 24 घंटे में ज़्यादा से ज़्यादा कितने ऐड-हॉक रिपोर्ट चला सकता है. इस कोटा के अंदर रहने के लिए:

• रिपोर्ट की संख्या कम करने के लिए, मिलती-जुलती रिपोर्ट को एक साथ जोड़ें.
• खास तौर पर, ऐड-हॉक रिपोर्ट की संख्या को कम करने के लिए, बार-बार बनने वाली ऐड-हॉक रिपोर्ट को शेड्यूल करें.
• गै़र-ज़रूरी एपीआई स्क्रिप्ट बंद करें.

शेड्यूल की गई चालू रिपोर्ट

उन रिपोर्ट की संख्या सीमित करता है जिन्हें उपयोगकर्ता किसी तय समय पर, सक्रिय तौर पर शेड्यूल कर सकता है. इस कोटा के अंदर रहने के लिए:

• शेड्यूल की गई रिपोर्ट की कुल संख्या को कम करने के लिए, शेड्यूल की गई रिपोर्ट से मिलती-जुलती रिपोर्ट जोड़ें.
• शेड्यूल की गई गैर-ज़रूरी रिपोर्ट को बंद करें.
• गै़र-ज़रूरी एपीआई स्क्रिप्ट बंद करें.

समवर्ती रिपोर्ट

उन रिपोर्ट की संख्या सीमित करता है जिन्हें उपयोगकर्ता एक साथ चला सकता है. इस कोटा के अंदर रहने के लिए:

• नियमित रूप से चलने वाली रिपोर्ट शेड्यूल करें.
• गै़र-ज़रूरी एपीआई स्क्रिप्ट बंद करें.
• एक्स्पोनेंशियल बैकऑफ़ लॉजिक का इस्तेमाल करके, पोल की मदद से अपनी रिपोर्ट तैयार किए जाने के समय को ट्रैक करें.

अगर आपने रिपोर्टिंग लागू करने के तरीके को ऑप्टिमाइज़ कर लिया है और फिर भी आपका तय कोटा पार हो गया है, तो संपर्क करने के लिए फ़ॉर्म का इस्तेमाल करके, Display & Video 360 की सहायता टीम से संपर्क करें.

रिपोर्ट की स्थिति जानने के लिए पोलिंग के दौरान, एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करें

यह अनुमान नहीं लगाया जा सकता कि रिपोर्ट को चलने में कितना समय लगेगा. यह समय कई बातों पर निर्भर करता है. जैसे, तारीख की सीमा और प्रोसेस किए जाने वाले डेटा की मात्रा. उदाहरण के लिए, यह समय सेकंड से लेकर घंटों तक का हो सकता है. साथ ही, रिपोर्ट के रन-टाइम और रिपोर्ट में दिखाई गई पंक्तियों की संख्या के बीच भी कोई संबंध नहीं होता है. इसलिए, आपको नियमित तौर पर queries.reports.get तरीके का इस्तेमाल करके, रिपोर्ट रिसॉर्स को वापस पाना होगा. साथ ही, यह देखना होगा कि रिसॉर्स के metadata.status.state फ़ील्ड को DONE या FAILED पर अपडेट किया गया है या नहीं. ऐसा करके, यह पता लगाया जा सकता है कि वह काम करना खत्म हुआ है या नहीं. इस प्रक्रिया को "पोलिंग" कहते हैं.

हालांकि, पोल कराना ज़रूरी है, लेकिन गलत तरीके से लागू करने पर रिपोर्ट लंबे समय तक चलने वाली रिपोर्ट का सामना करने पर, आपका कोटा तुरंत खत्म हो सकता है. इसलिए, हमारा सुझाव है कि आप बार-बार की जाने वाली कोशिशों को सीमित करने और कोटा बचाने के लिए, एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करें.

एक्सपोनेंशियल बैकऑफ़

एक्सपोनेन्शियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ियों को ठीक करने की एक स्टैंडर्ड रणनीति है. इसमें क्लाइंट समय-समय पर बढ़ती हुई समयावधि पर बार-बार अनुरोध करता है. एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल सही तरीके से किया जाता है. इससे बैंडविथ के इस्तेमाल में बढ़ोतरी होती है और कामयाब जवाब पाने के लिए ज़रूरी अनुरोधों की संख्या कम होती है. साथ ही, यह एक साथ काम करने वाली जगहों में अनुरोधों की संख्या को बढ़ाता है.

ध्यान दें: यह फ़्लो यह मानकर चलता है कि जिस रिपोर्ट पर पोल कराया जा रहा है उसका आईडी आपके पास है. अगर आपको किसी क्वेरी के लिए हाल ही में चलाई गई रिपोर्ट को पोल कराना है, तो orderBy पैरामीटर वैल्यू key.reportId desc का इस्तेमाल करके queries.reports.list को कॉल करें और सूची में दी गई पहली रिपोर्ट के reportId का इस्तेमाल करें.

सिंपल एक्सपोनेन्शियल बैकऑफ़ लागू करने का फ़्लो इस तरह है:

1. एपीआई से queries.reports.get के लिए अनुरोध करें.
2. रिपोर्ट ऑब्जेक्ट वापस पाएं. अगर metadata.status.state फ़ील्ड में DONE या FAILED नहीं है, तो इसका मतलब है कि रिपोर्ट अभी पूरी नहीं हुई है. इसलिए, पोलिंग जारी रखनी चाहिए.
3. 5 सेकंड और मिलीसेकंड की कोई रैंडम संख्या तक इंतज़ार करें और फिर से अनुरोध करें.
4. रिपोर्ट ऑब्जेक्ट वापस पाएं. अगर metadata.status.state फ़ील्ड में DONE या FAILED नहीं है, तो इसका मतलब है कि रिपोर्ट अभी पूरी नहीं हुई है. इसलिए, पोलिंग जारी रखनी चाहिए.
5. 10 सेकंड + रैंडम संख्या के मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
6. रिपोर्ट ऑब्जेक्ट वापस पाएं. अगर metadata.status.state फ़ील्ड में DONE या FAILED नहीं है, तो इसका मतलब है कि रिपोर्ट अभी पूरी नहीं हुई है. इसलिए, पोलिंग जारी रखनी चाहिए.
7. 20 सेकंड + रैंडम संख्या के मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
8. रिपोर्ट ऑब्जेक्ट वापस पाएं. अगर metadata.status.state फ़ील्ड में DONE या FAILED नहीं है, तो इसका मतलब है कि रिपोर्ट अभी पूरी नहीं हुई है. इसलिए, पोलिंग जारी रखनी चाहिए.
9. 40 सेकंड + रैंडम संख्या के मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
10. रिपोर्ट ऑब्जेक्ट वापस पाएं. अगर metadata.status.state फ़ील्ड में DONE या FAILED नहीं है, तो इसका मतलब है कि रिपोर्ट अभी पूरी नहीं हुई है. इसलिए, पोलिंग जारी रखनी चाहिए.
11. 80 सेकंड + रैंडम संख्या के मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
12. इस पैटर्न को तब तक जारी रखें, जब तक रिपोर्ट ऑब्जेक्ट अपडेट न हो जाए या तय सीमा तक न पहुंच जाए.

अगर रिपोर्ट चलती है और DONE स्थिति में खत्म होती है, तो जनरेट की गई रिपोर्ट फ़ाइल को Google Cloud Storage से metadata.googleCloudStoragePath फ़ील्ड में दिए गए पाथ पर वापस लाया जा सकता है.