डेटा को बेहतर तरीके से मैनेज करना

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

रिपोर्ट के लिए, संसाधन के इस्तेमाल से जुड़ी नीति को समझना

**ध्यान दें:** इस नीति के बारे में ज़्यादा जानकारी पाने के लिए, संसाधन के इस्तेमाल से जुड़ी नीति का ब्लॉग पोस्ट देखें.

अपने सर्वर की स्थिरता बनाए रखने के लिए, Google Ads API, GoogleAdsService.Search और GoogleAdsService.SearchStream के क्वेरी पैटर्न पर दर की सीमा लागू करता है. ये क्वेरी पैटर्न, एपीआई के संसाधनों का बहुत ज़्यादा इस्तेमाल करते हैं. अगर किसी क्वेरी पैटर्न पर दर की सीमा लागू होती है, तो अन्य सेवाओं, तरीकों, और क्वेरी पैटर्न पर कोई असर नहीं पड़ता. दर की सीमा लागू होने वाले अनुरोधों के लिए, ये गड़बड़ियां दिखती हैं:

गड़बड़ी का कोड
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION या QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION . यह गड़बड़ी, संसाधन के ज़्यादा इस्तेमाल की अवधि के हिसाब से दिखती है.

अगर आपको ये गड़बड़ियां दिखती हैं, तो QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION की वजह से पूरे न हो पाने वाले अनुरोधों को फिर से भेजने से पहले पांच मिनट इंतज़ार करें. वहीं, QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION की वजह से पूरे न हो पाने वाले अनुरोधों को फिर से भेजने से पहले 30 मिनट इंतज़ार करें.

ज़्यादा लागत वाली रिपोर्ट की पहचान करने और उन पर नज़र रखने में आपकी मदद करने के लिए, हम हर रिपोर्ट के लिए लागत की मेट्रिक भी दिखाते हैं:

तरीका	लागत फ़ील्ड
GoogleAdsService.Search	SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream	SearchGoogleAdsStreamResponse.query_resource_consumption

इन फ़ील्ड से मिलने वाली लागत की मेट्रिक, कई चीज़ों पर निर्भर करती है. जैसे:

• आपके खातों का साइज़
• आपकी रिपोर्ट में फ़ेच किए गए व्यू और कॉलम
• Google Ads API के सर्वर पर लोड

यहां दी गई टेबल में, Google Ads API के सर्वर पर अलग-अलग क्वेरी पैटर्न के संसाधन के इस्तेमाल से जुड़े आंकड़े दिए गए हैं. इससे, ज़्यादा लागत वाली क्वेरी को ट्रैक करने और उनमें बदलाव करने में मदद मिलती है:

समयावधि	औसत (p50)	P70 (औसत से ज़्यादा)	P95 (बहुत ज़्यादा)
कम अवधि (पांच मिनट)	6000	30000	1800000
ज़्यादा अवधि (24 घंटे)	16000	90000	8400000

उदाहरण के लिए, मान लें कि आपने इस तरह का क्वेरी पैटर्न चलाया है, जो हर रिपोर्ट के लिए 600 यूनिट संसाधनों का इस्तेमाल करता है:

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = 'YYYY-MM-DD'

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

समयावधि	औसत	औसत से ज़्यादा	बहुत ज़्यादा
कम अवधि (पांच मिनट)	10	50	3000
ज़्यादा अवधि (24 घंटे)	26	150	14000

पांच मिनट में इस क्वेरी पैटर्न को 10 बार चलाने पर, इसे औसत इस्तेमाल माना जाएगा. वहीं, पांच मिनट में 3,000 रिपोर्ट चलाने पर, इसे बहुत ज़्यादा इस्तेमाल माना जाएगा.

अपनी रिपोर्ट के संसाधन के इस्तेमाल को ऑप्टिमाइज़ करने के कई तरीके हैं. इस गाइड के बाकी हिस्से में, इनमें से कुछ तरीकों के बारे में बताया गया है.

अपने डेटा को कैश करना

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

रिपोर्ट चलाने की फ़्रीक्वेंसी को ऑप्टिमाइज़ करना

Google Ads ने डेटा की नई जानकारी और डेटा को कितनी बार अपडेट किया जाता है, इसके बारे में दिशा-निर्देश पब्लिश किए हैं. रिपोर्ट को कितनी बार फ़ेच करना है, यह तय करने के लिए आपको इन दिशा-निर्देशों का इस्तेमाल करना चाहिए.

अगर आपको खातों को नियमित तौर पर अपडेट करना है, तो हमारा सुझाव है कि ऐसे खातों की संख्या को सीमित रखें. उदाहरण के लिए, सिर्फ़ टॉप 20 Google Ads खाते. बाकी खातों को कम फ़्रीक्वेंसी पर अपडेट किया जा सकता है. जैसे, दिन में एक या दो बार.

अपनी रिपोर्ट के साइज़ को ऑप्टिमाइज़ करना

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

उदाहरण के लिए, यहां दिए गए कोड को देखें. यह कोड, खास विज्ञापन ग्रुप के आंकड़े खींचता है और आंकड़ों के डेटाबेस टेबल को अपडेट करता है:

  List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  foreach (long adGroupId in adGroupIds)
  {
    string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
        "metrics.cost_micros, metrics.impressions, segments.date FROM " +
        "ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
        $"ad_group.id = {adGroupId}";
    List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

यह कोड, छोटे टेस्ट खाते पर अच्छी तरह काम करता है. हालांकि, Google Ads में हर कैंपेन के लिए 20,000 विज्ञापन ग्रुप और हर खाते के लिए 10,000 कैंपेन हो सकते हैं. इसलिए, अगर यह कोड किसी बड़े Google Ads खाते के लिए चलाया जाता है, तो इससे Google Ads API के सर्वर पर ज़्यादा लोड पड़ सकता है. इससे अनुरोध संख्या सीमित करना लागू हो सकता है और थ्रॉटलिंग हो सकती है.

एक बेहतर तरीका यह होगा कि एक ही रिपोर्ट चलाई जाए और उसे स्थानीय तौर पर प्रोसेस किया जाए. इन-मेमोरी मैप का इस्तेमाल करके, ऐसा ही एक तरीका यहां दिखाया गया है:

  HashSet<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
      "metrics.cost_micros, metrics.impressions, segments.date FROM " +
      "ad_group WHERE segments.date DURING LAST_7_DAYS";
  List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  foreach (GoogleAdsRow row in rows)
  {
    long adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
  {
    InsertRowsIntoStatsTable(entry.Key, entry.Value);
  }

इससे, Google Ads API के सर्वर पर लोड कम हो जाता है, क्योंकि रिपोर्ट की संख्या कम होती है.

अगर आपको लगता है कि रिपोर्ट इतनी बड़ी है कि उसे मेमोरी में सेव नहीं किया जा सकता, तो क्वेरी को छोटे-छोटे ग्रुप में भी बांटा जा सकता है. इसके लिए, इस तरह LIMIT क्लॉज़ जोड़ा जा सकता है:

SELECT
  ad_group.id,
  ad_group.name,
  metrics.clicks,
  metrics.cost_micros,
  metrics.impressions,
  segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
  AND ad_group.id IN (id1, id2, ...)
LIMIT 100000

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

फ़ेच किए जाने वाले डेटा को ऑप्टिमाइज़ करना

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

SELECT
  customer.id,
  customer.currency_code,
  campaign.id,
  campaign.name,
  ad_group.id,
  ad_group.name,
  ad_group_criterion.keyword.match_type,
  ad_group_criterion.keyword.text,
  ad_group_criterion.criterion_id,
  ad_group_criterion.quality_info.creative_quality_score,
  ad_group_criterion.system_serving_status,
  ad_group_criterion.negative,
  ad_group_criterion.quality_info.quality_score,
  ad_group_criterion.quality_info.search_predicted_ctr,
  ad_group_criterion.quality_info.post_click_quality_score,
  metrics.historical_landing_page_quality_score,
  metrics.search_click_share,
  metrics.historical_creative_quality_score,
  metrics.clicks,
  metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS

हर घंटे बदलने की संभावना वाले कॉलम सिर्फ़ metrics.clicks और metrics.impressions हैं. अन्य सभी कॉलम को कम फ़्रीक्वेंसी पर या कभी भी अपडेट नहीं किया जाता. इसलिए, उन्हें हर घंटे फ़ेच करना बहुत ही खराब तरीका है. इन वैल्यू को स्थानीय डेटाबेस में सेव किया जा सकता है. साथ ही, बदलाव वाले इवेंट या बदलाव की स्थिति की रिपोर्ट चलाकर, दिन में एक या दो बार बदलाव डाउनलोड किए जा सकते हैं.

कुछ मामलों में, सही फ़िल्टर लागू करके, डाउनलोड की जाने वाली लाइनों की संख्या कम की जा सकती है.

जिन खातों का इस्तेमाल नहीं हो रहा है उन्हें मिटाना

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

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