फ़िलहाल, हम रिपोर्ट टाइप के सबसेट को ऑफ़लाइन से झटपट रिपोर्टिंग में माइग्रेट कर रहे हैं. उपयोगकर्ता के माइग्रेट हो जाने के बाद, queries.list जवाबों में मौजूदा इंस्टैंट रिपोर्ट शामिल होंगी. ज़्यादा जानकारी के लिए, हमारी ब्लॉग पोस्ट देखें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हर दिन ऐड-हॉक रिपोर्ट के रन

यह तय करता है कि कोई उपयोगकर्ता, 24 घंटे की अवधि में कितनी ऐड-हॉक रिपोर्ट चला सकता है. इस कोटे में बने रहने के लिए:

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

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

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

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

एक साथ चलने वाली रिपोर्ट

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

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

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

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

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

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

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

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

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

एपीआई से queries.reports.get अनुरोध करें.
रिपोर्ट ऑब्जेक्ट को वापस पाएं. अगर metadata.status.state फ़ील्ड में DONE या FAILED नहीं है, तो इसका मतलब है कि रिपोर्ट पूरी तरह से नहीं चली है और उसे फिर से चलाना होगा.
पांच सेकंड और कुछ मिलीसेकंड इंतज़ार करें. इसके बाद, फिर से कोशिश करें.
रिपोर्ट ऑब्जेक्ट को वापस पाएं. अगर 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 फ़ील्ड में दिए गए पाथ पर वापस पाया जा सकता है.