सबसे सही तरीके

इस गाइड में, कुछ सबसे सही तरीके बताए गए हैं. इनकी मदद से, अपने ऐप्लिकेशन की परफ़ॉर्मेंस और काम करने की क्षमता को ऑप्टिमाइज़ किया जा सकता है.

अपने ऐप्लिकेशन को बनाए रखना

यह पक्का करने के लिए कि आपका ऐप्लिकेशन बिना किसी रुकावट के काम करता रहे, यह तरीका अपनाएं:

  • पक्का करें कि आपके Google Cloud प्रोजेक्ट के मालिकों और संपादकों की सूची अप-टू-डेट हो. हम इन उपयोगकर्ताओं से किसी भी आपातकालीन स्थिति या एपीआई के नियमों और शर्तों के पालन से जुड़े विषयों के बारे में संपर्क करेंगे. अगर हम एपीआई के नियमों और शर्तों के पालन के बारे में आपसे संपर्क नहीं कर पाते हैं, तो आपके एपीआई ऐक्सेस को कम किया जा सकता है या रद्द किया जा सकता है.

  • प्रॉडक्ट में हुए बदलाव, रखरखाव के लिए बंद होने की अवधि, और बंद होने की तारीखों जैसी समस्याओं के बारे में सूचना पाने के लिए, हमारी एपीआई ब्लॉग और प्रॉडक्ट ब्लॉग की सदस्यता लें.

  • यह पक्का करें कि आपका ऐप्लिकेशन, Google Ads API के नियमों और शर्तों (टीऐंडसी) का पालन करता हो. अगर ज़रूरी हुआ, तो एपीआई अनुपालन टीम, एपीआई ऐक्सेस वाले आपके Google Cloud प्रोजेक्ट के मालिकों और एडिटर से संपर्क करेगी. अगर आपको नियमों और शर्तों के बारे में कुछ पूछना है या कोई समस्या है, तो अनुपालन टीम से संपर्क करें. इसके लिए, उस ईमेल का जवाब दें जो उन्होंने आपको एपीआई ऐक्सेस के लिए किए गए आवेदन की समीक्षा के दौरान भेजा था.

ऑप्टिमाइज़ेशन

बैच ऑपरेशन चलाकर अपने ऐप्लिकेशन को ऑप्टिमाइज़ किया जा सकता है. साथ ही, अगर ज़रूरी हो, तो स्पार्स ऑब्जेक्ट भेजे जा सकते हैं.

बैच कार्रवाइयां

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

उदाहरण के लिए, मान लें कि आपको कई विज्ञापन ग्रुप वाले किसी कैंपेन में 50,000 कीवर्ड जोड़ने हैं. हर अनुरोध में एक कीवर्ड का इस्तेमाल करके 50,000 अनुरोध करने के बजाय, हर अनुरोध में 500 कीवर्ड का इस्तेमाल करके 100 अनुरोध करें या हर अनुरोध में 5,000 कीवर्ड का इस्तेमाल करके 10 अनुरोध करें. किसी अनुरोध में किए जा सकने वाले ऑपरेशन की संख्या सीमित होती है. इसलिए, आपको बेहतर परफ़ॉर्मेंस पाने के लिए, बैच के साइज़ में बदलाव करना पड़ सकता है.

स्पार्स ऑब्जेक्ट भेजना

जब ऑब्जेक्ट को एपीआई पर भेजा जाता है, तो फ़ील्ड को डीसीरियलाइज़ किया जाना चाहिए. साथ ही, उनकी पुष्टि की जानी चाहिए और उन्हें डेटाबेस में सेव किया जाना चाहिए. जब आपको सिर्फ़ कुछ फ़ील्ड अपडेट करने हों, तब पूरे ऑब्जेक्ट पास करने से, प्रोसेसिंग में ज़्यादा समय लग सकता है और परफ़ॉर्मेंस कम हो सकती है. इस समस्या को कम करने के लिए, Google Ads API में स्पार्स अपडेट की सुविधा उपलब्ध है. इससे आपको किसी ऑब्जेक्ट में सिर्फ़ उन फ़ील्ड की जानकारी भरने की अनुमति मिलती है जिन्हें आपको बदलना है या जिनकी ज़रूरत है. स्पार्स अपडेट तेज़ी से प्रोसेस होते हैं और इनमें गड़बड़ियां होने की संभावना कम होती है. update_mask (इसे FieldMask भी कहा जाता है) में मौजूद फ़ील्ड में कोई बदलाव नहीं किया जाता है.

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

गड़बड़ी ठीक करना और उसे मैनेज करना

डेवलपमेंट के दौरान, आपको गड़बड़ियां दिख सकती हैं. इस सेक्शन में, आपके ऐप्लिकेशन में गड़बड़ी को मैनेज करने के तरीके और रणनीतियों के बारे में बताया गया है. गड़बड़ियों को मैनेज करने के बारे में ज़्यादा जानकारी के लिए, इस सेक्शन के अलावा समस्या हल करने की गाइड पर जाएं.

अनुरोध के सोर्स में अंतर करना

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

उपयोगकर्ता की ओर से किए गए अनुरोधों के लिए, आपकी मुख्य प्राथमिकता यह होनी चाहिए कि उपयोगकर्ताओं को अच्छा अनुभव मिले. यूज़र इंटरफ़ेस (यूआई) में, उपयोगकर्ता को ज़्यादा से ज़्यादा जानकारी देने के लिए, हुई गड़बड़ी के बारे में बताएं. गड़बड़ी को ठीक करने के लिए, उन्हें साफ़ तौर पर निर्देश दें (यहां दिए गए सुझाव देखें).

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

गड़बड़ियों के टाइप में अंतर करना

गड़बड़ी को ठीक करने के लिए बेहतर सिस्टम बनाने के लिए, Google Ads API में गड़बड़ी के टाइप के बीच अंतर जानना ज़रूरी है. गड़बड़ी के कुछ सामान्य टाइप ये हैं:

ज़्यादा जानकारी के लिए, गड़बड़ी के टाइप और सामान्य गड़बड़ियां देखें.

सिंक बैकएंड

अगर आपके ऐप्लिकेशन के उपयोगकर्ताओं के पास Google Ads खातों का मैन्युअल ऐक्सेस है, तो वे ऐसे बदलाव कर सकते हैं जिनके बारे में आपके ऐप्लिकेशन को पता नहीं होता. इससे आपके ऐप्लिकेशन का लोकल डेटाबेस सिंक नहीं हो पाता. गड़बड़ी के टाइप के बारे में हमारी गाइड में बताया गया है कि सिंक करने से जुड़ी गड़बड़ियां होने पर, उन्हें ठीक किया जा सकता है. हालांकि, उन्हें पहले से रोकने की कोशिश भी की जा सकती है. एक बेहतर रणनीति यह है कि समय-समय पर सिंक करने की प्रोसेस को चालू रखा जाए. इससे आपके खातों में मौजूद Google Ads ऑब्जेक्ट के साथ, आपके लोकल डेटाबेस को फिर से मिलाया जा सकेगा. बड़े खाता स्ट्रक्चर के लिए, हर खाते से हर रात सभी ऑब्जेक्ट पुल न करें. इससे हर दिन का कोटा खत्म हो सकता है. इसके बजाय, हाल ही में बदली गई इकाइयों के लिए क्वेरी ChangeStatus करें या उन्हें फ़िल्टर करें, ताकि बदलावों को धीरे-धीरे सिंक किया जा सके.

लॉग से जुड़ी गड़बड़ियां

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

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

डेवलेपमेंट

डेवलपमेंट के दौरान टेस्ट खातों का इस्तेमाल करें.

टेस्ट खातों का इस्तेमाल करना

टेस्ट खाते ऐसे Google Ads खाते होते हैं जो असल में विज्ञापन नहीं दिखाते. टेस्ट खाते का इस्तेमाल करके, Google Ads API को आज़माया जा सकता है. साथ ही, यह जांच की जा सकती है कि आपके ऐप्लिकेशन की कनेक्टिविटी, कैंपेन मैनेजमेंट लॉजिक या अन्य प्रोसेसिंग उम्मीद के मुताबिक काम कर रही है या नहीं. टेस्ट खाते पर इस्तेमाल करने के लिए, आपके Google Cloud प्रोजेक्ट को सिर्फ़ टेस्ट ऐक्सेस की ज़रूरत होती है. इसलिए, Google Ads API का इस्तेमाल करके तुरंत डेवलपमेंट शुरू किया जा सकता है. इस दौरान, Google आपके आवेदन की समीक्षा करेगा, ताकि आपको एपीआई के ज़्यादा ऐक्सेस लेवल मिल सकें.

आगे बढ़ें
एपीआई की सीमाएं और कोटा