User Deletion API - अनुमति देना

इस गाइड में बताया गया है कि कोई ऐप्लिकेशन, User Deletion API के अनुरोधों को कैसे अनुमति देता है.

अनुरोधों को अनुमति देना

उपयोगकर्ताओं को Google Analytics की वेब साइट पर अपने खाते की जानकारी देखने से पहले, अपने Google खाते में लॉग इन करना होगा. इसी तरह, जब उपयोगकर्ता पहली बार आपके ऐप्लिकेशन को ऐक्सेस करते हैं, तो उन्हें अपने डेटा को ऐक्सेस करने के लिए, आपके ऐप्लिकेशन को अनुमति देनी होगी.

आपका ऐप्लिकेशन, Analytics API को जो भी अनुरोध भेजता है उसमें अनुमति वाला टोकन शामिल होना चाहिए. इस टोकन से Google आपके ऐप्लिकेशन की पहचान भी करता है.

अनुमति देने के प्रोटोकॉल के बारे में जानकारी

अनुरोधों को अनुमति देने के लिए, आपके ऐप्लिकेशन में OAuth 2.0 का इस्तेमाल किया जाना चाहिए. अनुमति देने वाले दूसरे प्रोटोकॉल इस्तेमाल नहीं किए जा सकते. अगर आपका ऐप्लिकेशन Google से साइन इन करने की सुविधा इस्तेमाल करता है, तो अनुमति देने से जुड़े कुछ पहलुओं को Google आपके लिए खुद मैनेज करता है.

OAuth 2.0 से अनुरोधों को अनुमति देना

Analytics API को किए जाने वाले सभी अनुरोधों की अनुमति किसी ऐसे उपयोगकर्ता से होनी चाहिए जिसके पास पुष्टि हो.

OAuth 2.0 के लिए अनुमति देने की प्रक्रिया या "तरीका" अलग-अलग हो सकता है. यह इस बात पर निर्भर करता है कि ऐप्लिकेशन किस तरह का है. सभी तरह के ऐप्लिकेशन के लिए नीचे दी गई सामान्य प्रक्रिया लागू होती है:

1. ऐप्लिकेशन बनाने के बाद, उसे Google API (एपीआई) कंसोल का इस्तेमाल करके, रजिस्टर किया जाता है. इसके बाद, Google आपको क्लाइंट आईडी और क्लाइंट सीक्रेट जैसी जानकारी देगा. इस जानकारी की ज़रूरत आपको बाद में पड़ेगी.
2. Google API कंसोल में Analytics API चालू करें. (अगर एपीआई को 'API कंसोल' की सूची में नहीं जोड़ा गया है, तो यह चरण छोड़ दें.)
3. जब आपके ऐप्लिकेशन को उपयोगकर्ता के डेटा को ऐक्सेस करने की ज़रूरत होती है, तब वह Google से, डेटा के खास लिंक का अनुरोध करता है.
4. Google, उपयोगकर्ता को सहमति वाली स्क्रीन दिखाता है, जिसमें उनसे आपके ऐप्लिकेशन को उनके कुछ डेटा को ऐक्सेस करने की अनुमति मांगी जाती है.
5. अगर उपयोगकर्ता इसकी अनुमति दे देता है, तो Google आपके ऐप्लिकेशन को कुछ समय के लिए इस्तेमाल किए जा सकने वाला ऐक्सेस टोकन देता है.
6. आपका ऐप्लिकेशन, ऐक्सेस टोकन से उपयोगकर्ता के डेटा को ऐक्सेस करने का अनुरोध करता है.
7. अगर Google को पता चलता है कि आपका अनुरोध और टोकन मान्य है, तो वह आपके ऐप्लिकेशन को अनुरोध किए गए डेटा का ऐक्सेस दे देता है.

कुछ तरीकों में दूसरे चरण भी शामिल हो सकते हैं, जैसे कि रिफ़्रेश टोकन इस्तेमाल करके, नया ऐक्सेस टोकन पाना. अलग-अलग तरह के ऐप्लिकेशन के लिए डेटा ऐक्सेस करने के तरीकों के बारे में ज़्यादा जानकारी पाने के लिए, Google का OAuth 2.0 दस्तावेज़ पढ़ें.

Analytics API के लिए, OAuth 2.0 के दायरे की जानकारी यहां दी गई है:

स्कोप	मतलब
https://www.googleapis.com/auth/analytics.user.deletion	User Deletion API का इस्तेमाल करके डेटा मिटाएं.

OAuth 2.0 का इस्तेमाल करके, डेटा ऐक्सेस करने का अनुरोध करने के लिए, आपके ऐप्लिकेशन को अनुरोध के तरीके की जानकारी देनी होगी. साथ ही, वह जानकारी भी देनी होगी जो आपको ऐप्लिकेशन रजिस्टर करते समय, Google से मिली थी, जैसे कि क्लाइंट आईडी और क्लाइंट सीक्रेट.

सलाह: Google API की क्लाइंट लाइब्रेरी आपके लिए अनुमति देने की कुछ प्रक्रियाएं खुद कर सकती है. ये लाइब्रेरी कई प्रोग्रामिंग भाषाओं के लिए उपलब्ध होती हैं. ज़्यादा जानकारी के लिए लाइब्रेरी और नमूनों वाला पेज देखें.

OAuth 2.0 के सामान्य फ़्लो

नीचे कुछ OAuth 2.0 फ़्लो के इस्तेमाल के सामान्य उदाहरण दिए गए हैं:

वेब सर्वर

यह फ़्लो, उपयोगकर्ता के Google Analytics डेटा के ऑटोमेटेड, ऑफ़लाइन या शेड्यूल किए गए ऐक्सेस के लिए बेहतर है.

उदाहरण:

• Google Analytics के नए डेटा से उपयोगकर्ता डैशबोर्ड अपने-आप अपडेट हो रहे हैं.

ध्यान दें: आपके ऐप्लिकेशन को अपने Google Analytics डेटा का ऑफ़लाइन ऐक्सेस देने के लिए, उपयोगकर्ता को एक बार किया जाने वाला पुष्टि करने का फ़्लो पूरा करना होगा. इसके बाद, नया ऐक्सेस टोकन पाने के लिए रीफ़्रेश टोकन का इस्तेमाल किया जा सकता है.

क्लाइंट-साइड

यह फ़्लो उन ऐप्लिकेशन के लिए बिलकुल सही है, जब उपयोगकर्ता किसी ब्राउज़र में अपने Google Analytics डेटा को ऐक्सेस करने के लिए, सीधे ऐप्लिकेशन से इंटरैक्ट करते हैं. इसका इस्तेमाल करने पर, सर्वर-साइड की सुविधाओं की ज़रूरत नहीं होती. हालांकि, इसकी वजह से ऑटोमेटेड, ऑफ़लाइन या शेड्यूल की गई रिपोर्टिंग को सही तरीके से इस्तेमाल नहीं किया जा सकता.

उदाहरण:

• ब्राउज़र पर आधारित रिपोर्टिंग टूल, जैसे कि Analytics क्वेरी एक्सप्लोरर.

इंस्टॉल किए गए ऐप्लिकेशन

यह फ़्लो उन ऐप्लिकेशन के लिए है जिन्हें पैकेज के तौर पर डिस्ट्रिब्यूट किया जाता है और उपयोगकर्ता ने इंस्टॉल किया होता है. इस फ़्लो के लिए ज़रूरी है कि ऐप्लिकेशन या उपयोगकर्ता के पास पुष्टि करने का फ़्लो पूरा करने के लिए ब्राउज़र का ऐक्सेस हो.

उदाहरण:

• पीसी या Mac पर डेस्कटॉप विजेट.
• कॉन्टेंट मैनेजमेंट सिस्टम के लिए प्लगिन — वेब सर्वर या क्लाइंट-साइड की तुलना में इस फ़्लो का यह फ़ायदा होता है कि आपके ऐप्लिकेशन के लिए, एक ही API Console प्रोजेक्ट का इस्तेमाल किया जा सकता है. इसकी मदद से, सभी खातों के लिए एक ही रिपोर्ट जनरेट होती है. साथ ही, उपयोगकर्ताओं के लिए ऐप्लिकेशन इंस्टॉल करना आसान हो जाता है.

सेवा खाते

सेवा खाते, आपके खाते में Google Analytics डेटा के ऑटोमेटेड, ऑफ़लाइन या शेड्यूल किए गए ऐक्सेस के लिए काम के होते हैं. उदाहरण के लिए, अपने Google Analytics डेटा का लाइव डैशबोर्ड बनाना और उसे अन्य उपयोगकर्ताओं के साथ शेयर करना.

Analytics API का इस्तेमाल शुरू करने से पहले, सेटअप टूल का इस्तेमाल करना ज़रूरी है. यह आपको Google API Console में प्रोजेक्ट बनाने, एपीआई की सुविधा चालू करने, और क्रेडेंशियल बनाने के बारे में जानकारी देता है.

नया सेवा खाता सेट अप करने के लिए, यह तरीका अपनाएं:

1. क्रेडेंशियल बनाएं > सेवा खाते की कुंजी पर क्लिक करें.
2. चुनें कि सेवा खाते की सार्वजनिक/निजी कुंजी को स्टैंडर्ड P12 फ़ाइल के तौर पर डाउनलोड करना है या JSON फ़ाइल के तौर पर, जिसे Google API क्लाइंट लाइब्रेरी से लोड किया जा सकता है.

आपके नए सार्वजनिक/निजी पासकोड को कंप्यूटर में बनाया और डाउनलोड किया जाता है. यह पासकोड की इकलौती कॉपी होती है. इसे सुरक्षित तरीके से सेव करने की ज़िम्मेदारी आपकी है.

ध्यान दें: आपको जिस व्यू (प्रोफ़ाइल) को ऐक्सेस करना है उसके आधिकारिक उपयोगकर्ता के तौर पर, सेवा खाते का ईमेल पता जोड़ना होगा.

समस्या हल करना

आपकी अनुमति इन स्थितियों में काम नहीं करती:

• अगर आपके access_token की समयसीमा खत्म हो गई है या एपीआई के लिए गलत स्कोप का इस्तेमाल किया जा रहा है, तो आपको 401 स्टेटस कोड मिलेगा.

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

OAuth 2.0 प्लेग्राउंड

इस टूल की मदद से, वेब इंटरफ़ेस के ज़रिए अनुमति देने की पूरी प्रोसेस पूरी की जा सकती है. यह टूल, अनुमति वाली क्वेरी बनाने के लिए ज़रूरी सभी एचटीटीपी अनुरोध के हेडर भी दिखाता है. अगर आपको अपने ऐप्लिकेशन में काम करने की अनुमति नहीं मिल रही है, तो आपको इसे OAuth 2.0 प्लेग्राउंड से काम करने की कोशिश करनी चाहिए. इसके बाद आप HTTP हेडर की तुलना करके प्लेग्राउंड से यह अनुरोध कर सकते हैं कि आपका ऐप्लिकेशन Google Analytics को क्या भेज रहा है. इस जांच की मदद से, आसानी से यह देखा जा सकता है कि आपके अनुरोधों का फ़ॉर्मैट सही है.

अमान्य अनुमति

रीफ़्रेश टोकन का इस्तेमाल करने पर, ये चीज़ें आपको invalid_grant गड़बड़ी दिखाती हैं:

• आपके सर्वर की घड़ी नेटवर्क टाइम प्रोटोकॉल - NTP के साथ सिंक नहीं है.
• रीफ़्रेश टोकन की सीमा पार हो गई है.

किसी एक Google Analytics खाते को ऐक्सेस करने के लिए, ऐप्लिकेशन कई रीफ़्रेश टोकन का अनुरोध कर सकते हैं.

उदाहरण के लिए, अगर कोई उपयोगकर्ता एक से ज़्यादा मशीनों पर कोई ऐप्लिकेशन इंस्टॉल करके एक ही Google Analytics खाते को ऐक्सेस करना चाहता है, तो हर मशीन के लिए एक अलग टोकन की ज़रूरत होगी. जब रीफ़्रेश टोकन की संख्या तय सीमा से ज़्यादा हो जाती है, तो पुराने टोकन अमान्य हो जाते हैं. अगर ऐप्लिकेशन किसी अमान्य रीफ़्रेश टोकन का इस्तेमाल करने की कोशिश करता है, तो invalid_grant गड़बड़ी का रिस्पॉन्स मिलता है.

OAuth 2.0 क्लाइंट और Google Analytics खाते के हर यूनीक पेयर के लिए, 25 रीफ़्रेश टोकन इस्तेमाल किए जा सकते हैं. अगर ऐप्लिकेशन एक ही क्लाइंट/खाते की जोड़ी के लिए रीफ़्रेश टोकन का अनुरोध करना जारी रखता है, तो 26वां टोकन जारी होने के बाद, पहले जारी किया गया पहला रीफ़्रेश टोकन अमान्य हो जाएगा. अनुरोध किए गए 27वें रीफ़्रेश टोकन से, पहले जारी किया गया दूसरा टोकन अमान्य हो जाएगा. साथ ही, यह अन्य टोकन भी अमान्य हो जाएगा.

ध्यान दें: 25 रीफ़्रेश टोकन की सीमा बदला जा सकता है.