Google Ads के ऐक्सेस मॉडल के बारे में जानकारी

Google Ads खाते दो तरह के होते हैं: Google Ads मैनेजर खाते और Google Ads विज्ञापन देने वाले व्यक्ति या कंपनी के खाते. इन्हें ग्राहक या क्लाइंट खाते भी कहा जाता है. मैनेजर खाते, अन्य Google Ads मैनेजर खातों या Google Ads विज्ञापन देने वाले लोगों या कंपनियों के खातों को मैनेज कर सकते हैं. विज्ञापन देने वाले व्यक्ति या कंपनी के खाते को मैनेजर खाते से लिंक किया जा सकता है. इसके बाद, मैनेजर खाते से विज्ञापन देने वाले व्यक्ति या कंपनी के खाते को मैनेज किया जा सकता है. लिंक किए गए खातों का पूरा स्ट्रक्चर, डायरेक्टेड एसाइक्लिक ग्राफ़ होता है. इसमें विज्ञापन देने वाले लोगों या कंपनियों के खाते, लीफ़ लेवल पर होते हैं.

आपके पास अलग-अलग उपयोगकर्ताओं या सेवा खातों को Google Ads खातों का ऐक्सेस देने का विकल्प होता है. उपयोगकर्ताओं को विज्ञापन देने वाले व्यक्ति या कंपनी के खाते का ऐक्सेस देने के दो तरीके हैं:

• उपयोगकर्ता को सीधे तौर पर विज्ञापन देने वाले व्यक्ति या कंपनी के खाते का ऐक्सेस दें. इसके लिए, उसे उस खाते का न्योता भेजें.
• उपयोगकर्ता को विज्ञापन देने वाले व्यक्ति या कंपनी के खाते का ऐक्सेस देने के लिए, उसे उस खाते से लिंक किए गए मैनेजर खाते में शामिल होने का न्योता दें. उपयोगकर्ता को विज्ञापन देने वाले व्यक्ति या कंपनी के खाते का ऐक्सेस मिल जाता है, क्योंकि मैनेजर खाते के पास उससे लिंक किए गए सभी खातों का ऐक्सेस होता है.

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

खातों के इस क्रम पर ध्यान दें. मान लें कि सभी उपयोगकर्ताओं के पास स्टैंडर्ड ऐक्सेस है.

नीचे दी गई टेबल में, इस खाते के स्ट्रक्चर की खास जानकारी दी गई है.

उपयोगकर्ता	इसके लिए सीधे तौर पर ऐक्सेस है	इसके पास इस डेटा का इनडायरेक्ट ऐक्सेस है
U1, SA1	M1	M2, A1, A2, A3
U2	M2, M3	A1, A2, A3, A4
U3	A4

लॉगिन ग्राहक आईडी

किसी उपयोगकर्ता के पास, एक से ज़्यादा खाता हाइरारकी का ऐक्सेस हो सकता है. ऐसे मामलों में एपीआई कॉल करते समय, आपको उस रूट खाते के बारे में बताना होगा जिसका इस्तेमाल, अनुमति और खाता ऐक्सेस करने के लेवल का सही तरीके से पता लगाने के लिए किया जाना है. इसके लिए, एपीआई अनुरोध के हिस्से के तौर पर login-customer-id हेडर तय किया जाता है.

नीचे दी गई टेबल में, पिछले उदाहरण में दी गई खाता हाइरारकी का इस्तेमाल किया गया है. इससे यह पता चलता है कि लॉगिन करने के लिए किन ग्राहक आईडी का इस्तेमाल किया जा सकता है. साथ ही, उन खातों की सूची भी दी गई है जिनसे कॉल किए जा सकते हैं.

उपयोगकर्ता	इस्तेमाल करने के लिए, लॉगिन ग्राहक आईडी	एपीआई कॉल करने के लिए खाते
U1, SA1	M1	M1, M2, A1, A2, A3
U2	M2	M2, A1, A2, A3
U2	M3	M3, A1, A4
U3	A4	A4

अगर उपयोगकर्ता के पास उस Google Ads खाते का ऐक्सेस है जिससे कॉल किए जा रहे हैं, तो login-customer-id हेडर की जानकारी देने की ज़रूरत नहीं है. उदाहरण के लिए, A4 को कॉल करने के लिए U3 क्रेडेंशियल का इस्तेमाल करते समय, आपको login-customer-id हेडर तय करने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि Google Ads सर्वर, ग्राहक आईडी (A4) से ऐक्सेस लेवल का सही तरीके से पता लगा सकते हैं.

उपयोगकर्ता की भूमिकाएं

Google Ads API का अपना कोई अलग ऐक्सेस मॉडल नहीं है. साथ ही, यह सुविधाओं को सीमित करने के लिए, OAuth 2.0 के अलग-अलग स्कोप का इस्तेमाल नहीं करता. उदाहरण के लिए, Google Ads API, सिर्फ़ पढ़ने और पढ़ने-लिखने की कार्रवाइयों के लिए एक ही स्कोप का इस्तेमाल करता है. इसके बजाय, Google Ads API में वही उपयोगकर्ता भूमिकाएं होती हैं जो Google Ads में होती हैं. जब किसी उपयोगकर्ता को मैनेजर लेवल पर किसी खाते के लिए भूमिका असाइन की जाती है, तो वह भूमिका, क्रम में मौजूद खातों को भी मिल जाती है. अगर किसी उपयोगकर्ता के पास किसी खाते के लिए अलग-अलग भूमिकाएं हैं, तो सही लेवल का फ़ैसला login-customer-id खाते के आधार पर किया जाता है. यह खाता, एपीआई अनुरोध में बताया गया होता है.

यहां दी गई टेबल में, पिछले उदाहरण में दी गई खाता हाइरार्की का इस्तेमाल किया गया है. इसमें दिखाया गया है कि उपयोगकर्ताओं को अलग-अलग भूमिकाएं असाइन करने से क्या असर पड़ता है.

उपयोगकर्ता	उपयोगकर्ता की भूमिका दी गई	login-customer-id	लागू ऐक्सेस लेवल
SA1	खाते M1 का स्टैंडर्ड ऐक्सेस	M1	M1, M2, A1, A2, A3 पर स्टैंडर्ड ऐक्सेस
U2	M2 पर स्टैंडर्ड ऐक्सेस M3 पर रीड-ओनली ऐक्सेस	M2	M2, A1, A2, A3 पर स्टैंडर्ड ऐक्सेस
U2	M2 पर स्टैंडर्ड ऐक्सेस M3 पर रीड-ओनली ऐक्सेस	M3	M3, A1, A4 पर रीड-ओनली ऐक्सेस