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

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 (बहुत ज़्यादा)
कम अवधि (5 मिनट)	6000	30,000	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	3000
लंबी अवधि (24 घंटे)	26	150	14000

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

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

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

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

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

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

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

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

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

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