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

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

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

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

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

एपीआई वर्शन	गड़बड़ी का कोड
<= वर्शन 17	QuotaError.RESOURCE_EXHAUSTED
>= वर्शन 18	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	3000
लंबी अवधि (24 घंटे).	26	150	14000

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

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

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

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