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

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

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

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

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

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

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

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

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

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

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

इस क्वेरी पैटर्न को पांच मिनट में 10 बार चलाने पर, इसे औसत इस्तेमाल माना जाएगा. वहीं, पांच मिनट में 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 या change-status रिपोर्ट चलाएं.

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

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

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

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