দক্ষতার সাথে ডেটা ম্যানেজ করা

ডেটা বিশ্লেষণ, গ্রাহকের কোয়েরি এবং নীতি মেনে চলা সংক্রান্ত চেকের মতো ব্যবহারের কেসের জন্য অ্যাকাউন্ট ডেটা রিট্রিভ করা হল অনেক Google Ads অ্যাপ্লিকেশনের একটি মূল ফাংশন। ডেটা ফেচ করার সময়, Google সার্ভারে অতিরিক্ত লোড না দেওয়া বা রেট লিমিট হওয়ার ঝুঁকি এড়াতে, আপনার ব্যবহার অপ্টিমাইজ করা উচিত। আরও জানতে, রেট-সীমিতকরণ এবং আপ-টু-ডেট যোগাযোগের ইমেল আইডি বজায় রাখার বিষয়ে নির্দেশিকা দেখুন।

রিপোর্টের জন্য রিসোর্স ব্যবহার সংক্রান্ত নীতি বোঝা

মনে রাখবেন: এই নীতি সম্পর্কে আরও জানতে রিসোর্স ব্যবহার সংক্রান্ত নীতি ব্লগ পোস্ট দেখুন।

এর সার্ভারের স্থিতিশীলতা নিশ্চিত করতে, Google Ads API থ্রটল GoogleAdsService.Search এবং GoogleAdsService.SearchStream কোয়েরি প্যাটার্ন যা অতিরিক্ত পরিমাণে API রিসোর্স ব্যবহার করে। কোনও নির্দিষ্ট কোয়েরি প্যাটার্ন থ্রটল করা হলে, অন্যান্য পরিষেবা, পদ্ধতি এবং কোয়েরি প্যাটার্ন প্রভাবিত না হয়ে কাজ করা চালিয়ে যায়। থ্রটল করা অনুরোধের জন্য নিম্নলিখিত সমস্যাগুলি দেখানো হয়:

সমস্যার কোড
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-এর মাধ্যমে কাজ না হওয়া অনুরোধ আবার করার আগে ৩০ মিনিট অপেক্ষা করুন।

আপনার ব্যয়বহুল রিপোর্ট শনাক্ত ও মনিটর করতে সাহায্য করার জন্য, আমরা প্রতিটি রিপোর্টের জন্য একটি খরচ মেট্রিকও প্রদান করি:

পদ্ধতি	খরচের ফিল্ড
GoogleAdsService.Search	SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream	SearchGoogleAdsStreamResponse.query_resource_consumption

এইসব ফিল্ডের মাধ্যমে রিটার্ন করা 'খরচ' মেট্রিক বিভিন্ন বিষয়ের উপর নির্ভর করে, যেমন:

• আপনার অ্যাকাউন্টের সাইজ
• আপনার রিপোর্টে যে ভিউ ও কলাম নিয়ে আসেন
• Google Ads API সার্ভারের উপর লোড

নিচের সারণীতে Google Ads API সার্ভারে বিভিন্ন কোয়েরি প্যাটার্নের রিসোর্স ব্যবহারের সংগ্রহ করা পরিসংখ্যান দেখানো হয়েছে। এর সাহায্যে আপনি বেশি খরচ হওয়া কোয়েরি ট্র্যাক ও ফাইন-টিউন করতে পারবেন:

টাইম উইন্ডো	গড় (p50)	P70 (মোটামুটি বেশি)	P95 (খুব বেশি)
স্বল্পমেয়াদী (৫ মিনিট)	6000	30000	1800000
দীর্ঘমেয়াদী (২৪ ঘণ্টা)	16000	90000	8400000

উদাহরণস্বরূপ, ধরুন আপনি নিম্নলিখিত কোয়েরি প্যাটার্ন চালাচ্ছেন, যা প্রতিটি রিপোর্টের জন্য ৬০০ ইউনিট রিসোর্স ব্যবহার করে:

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

আপনি একাধিক গ্রাহক অ্যাকাউন্টের জন্য এই কোয়েরিটি একাধিক স্বতন্ত্র তারিখের জন্য চালান segments.date-এর জন্য আলাদা আলাদা ভ্যালু সাবস্টিটিউট করতে কোয়েরিটি পরিবর্তন করে ফিল্টার করুন। নিম্নলিখিত সারণীতে আপনি নির্দিষ্ট সময়সীমার মধ্যে কতগুলি রিপোর্ট চালাতে পারবেন তা দেখানো হয়েছে, যাতে আপনার রিসোর্স ব্যবহার বিভিন্ন রিসোর্স ব্যবহারের বাকেটে ফিট করে।

টাইম উইন্ডো	মোটামুটি	মোটামুটি বেশি	খুব বেশি
স্বল্প-মেয়াদী (৫ মিনিট)	10	50	৩০০০
দীর্ঘমেয়াদী (২৪ ঘণ্টা)	26	১৫০	14000

৫ মিনিটে এই কোয়েরি প্যাটার্ন ১০ বার রান করাকে গড় ব্যবহার হিসেবে ধরা হবে, যেখানে ৫ মিনিটে ৩০০০ রিপোর্ট রান করাকে খুব বেশি ব্যবহার হিসেবে ধরা হবে।

আপনার রিপোর্টের রিসোর্স ব্যবহার অপ্টিমাইজ করার জন্য বেশ কিছু কৌশল আছে। এই গাইডের বাকি অংশে এইসব কৌশলের কিছু কভার করা হয়েছে।

আপনার ডেটা ক্যাশে করা

প্রতিবার ডেটা প্রয়োজন হলেই API সার্ভারকে কল না করে, আপনার উচিত হল, API সার্ভার থেকে পাওয়া এন্টিটির বিবরণ লোকাল ডেটাবেসে ক্যাশে করা। বিশেষ করে, যেসব এন্টিটি ঘনঘন অ্যাক্সেস করা হয় অথবা যেসব এন্টিটি কখনও কখনও পরিবর্তিত হয় সেগুলির ক্ষেত্রে এটি করা উচিত। আপনি শেষবার ফলাফল সিঙ্ক করার পর থেকে কোন কোন অবজেক্টে পরিবর্তন হয়েছে তা শনাক্ত করতে, যেখানে সম্ভব সেখানে 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-এ প্রতিটি ক্যাম্পেনে সর্বাধিক ২০,০০০টি বিজ্ঞাপন গ্রুপ এবং প্রতিটি অ্যাকাউন্টে সর্বাধিক ১০,০০০টি ক্যাম্পেন তৈরি করা যায়। তাই, এই কোডটি কোনও বড় 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 অ্যাকাউন্টে API কল করা বন্ধ করুন। এটি বিশেষ করে অফলাইন জবের ক্ষেত্রে প্রযোজ্য, যেমন ক্রন জব এবং ডেটা পাইপলাইন যা ব্যবহারকারীর হস্তক্ষেপ ছাড়াই চালানোর জন্য ডিজাইন করা হয়েছে।
• গ্রাহক তার অনুমোদন প্রত্যাহার করে নিলে, আপনার অ্যাপ্লিকেশনকে পরিস্থিতিটি সুন্দরভাবে সামলাতে হবে এবং Google-এর API সার্ভারে ভুল API কল পাঠানো এড়াতে হবে।
• গ্রাহক তার Google Ads অ্যাকাউন্ট বাতিল করে দিলে, আপনাকে বাতিল করা অ্যাকাউন্ট শনাক্ত করতে হবে এবং Google-এর API সার্ভারে ভুল API কল পাঠানো এড়াতে হবে।
• উপযুক্ত সময়সীমা পেরিয়ে যাওয়ার পরে, আপনার লোকাল ডেটাবেস থেকে গ্রাহকের Google Ads অ্যাকাউন্ট থেকে ডাউনলোড করা ডেটা মুছে দিন।