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

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

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

ध्यान दें: यह सेक्शन, Google Ads API में होने वाले बदलाव के बारे में है. ज़्यादा जानने के लिए, ब्लॉग पोस्ट देखें.

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

एपीआई वर्शन	गड़बड़ी का कोड
<= वर्शन 16	QuotaError.RESOURCE_EXHAUSTED
वर्शन 17	ज़्यादा संसाधन इस्तेमाल की अवधि के आधार पर, QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION या QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

आपकी महंगी रिपोर्ट को पहचानने और उनकी निगरानी करने में आपकी मदद करने के लिए, हम अलग-अलग रिपोर्ट के लिए भी एक लागत मेट्रिक दिखाएंगे.

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

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

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

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

टाइम विंडो	औसत (p50).	P70 (कुछ हद तक ज़्यादा)	P95 (बहुत ज़्यादा)
कम समय के लिए (5 मिनट)	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 फ़िल्टर की अलग-अलग वैल्यू डाली जा सकती हैं. नीचे दी गई टेबल में बताया गया है कि किसी तय अवधि में कितनी रिपोर्ट चलाई जा सकती हैं. इस तरह, आपके संसाधन का इस्तेमाल अलग-अलग संसाधनों के इस्तेमाल के हिसाब से होता है.

टाइम विंडो	ठीक-ठाक	कुछ हद तक ज़्यादा	बहुत ज़्यादा
कम समय के लिए (5 मिनट)	10	50	3,000
लंबी अवधि (24 घंटे).	26	150	14000

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

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

अपना डेटा कैश मेमोरी में सेव करना

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

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

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

अगर आपको नियमित तौर पर खातों को अपडेट करना है, तो हमारा सुझाव है कि आप ऐसे खातों की संख्या को एक छोटे सेट में ही रखें. उदाहरण के लिए, सिर्फ़ सबसे ज़्यादा इस्तेमाल किए जाने वाले बीस 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(customer_id, query);

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

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (long adGroupId in memoryMap.Keys())
  {
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

इससे 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 कॉलम में बदलाव हो सकता है. अन्य सभी कॉलम कभी-कभी अपडेट होते हैं या कभी-कभी ही अपडेट होते हैं. इसलिए, उन्हें हर घंटे फ़ेच नहीं किया जा सकेगा. इन वैल्यू को स्थानीय डेटाबेस में सेव किया जा सकता है. साथ ही, दिन में एक या दो बार बदलावों को डाउनलोड करने के लिए, change-event या बदलाव की स्थिति रिपोर्ट चलाई जा सकती है.

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

इस्तेमाल न किए जाने वाले खातों को हटाएं

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

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