हमारे प्रॉडक्ट के बारे में चर्चा करने और सुझाव देने के लिए, Google विज्ञापन और मेज़रमेंट कम्यूनिटी सर्वर में Google Ads के आधिकारिक Discord चैनल से जुड़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

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

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

समय अवधि	औसत	कुछ हद तक ज़्यादा	बहुत ज़्यादा
कुछ समय के लिए (पांच मिनट)	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(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 के API सर्वर को अमान्य API कॉल भेजने से बचना चाहिए.
अगर ग्राहक ने अपना Google Ads खाता रद्द कर दिया है, तो आपको इसका पता लगाना चाहिए. साथ ही, Google के एपीआई सर्वर को अमान्य एपीआई कॉल भेजने से बचना चाहिए.
ग्राहक के Google Ads खातों से डाउनलोड किए गए डेटा को, तय समय के बाद अपने लोकल डेटाबेस से मिटा दें.