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

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 সার্ভার থেকে আপনি যে এন্টিটি বিবরণ ফেচ করেন, তা লোকাল ডেটাবেসে ক্যাশে করা উচিত। এর ফলে, যখনই আপনার ডেটার প্রয়োজন হবে, তখনই সার্ভার কল করতে হবে না। বিশেষ করে, যেসব এন্টিটি ঘনঘন অ্যাক্সেস করা হয় বা যেগুলি ঘনঘন পরিবর্তন হয় না, সেগুলির ক্ষেত্রে এটি প্রযোজ্য। আপনি শেষবার ফলাফল সিঙ্ক করার পর থেকে কোন অবজেক্ট পরিবর্তিত হয়েছে তা শনাক্ত করতে যেখানে সম্ভব সেখানে 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 কলামের ডেটা প্রতি ঘণ্টায় পরিবর্তিত হতে পারে। অন্যান্য সব কলাম খুব কমই আপডেট করা হয় বা একেবারেই করা হয় না, তাই প্রতি ঘণ্টায় সেগুলি ফেচ করা অত্যন্ত অদক্ষতার কাজ। আপনি এইসব ভ্যালু লোকাল ডেটাবেসে স্টোর করতে পারেন এবং দিনে একবার বা দুবার পরিবর্তন ডাউনলোড করার জন্য পরিবর্তন-ইভেন্ট বা পরিবর্তন-স্ট্যাটাস রিপোর্ট রান করতে পারেন।

কিছু ক্ষেত্রে, আপনি উপযুক্ত ফিল্টার প্রয়োগ করে ডাউনলোড করা সারির সংখ্যা কমাতে পারেন।

অব্যবহৃত অ্যাকাউন্ট ক্লিন-আপ করা

আপনার অ্যাপ্লিকেশন যদি থার্ড-পার্টি গ্রাহক অ্যাকাউন্ট ম্যানেজ করে, তাহলে আপনাকে গ্রাহক মন্থনের কথা মাথায় রেখে আপনার অ্যাপ্লিকেশন ডেভেলপ করতে হবে। আপনার অ্যাপ্লিকেশন আর ব্যবহার করেন না এমন গ্রাহকদের অ্যাকাউন্ট মুছে ফেলার জন্য, আপনাকে পর্যায়ক্রমে আপনার প্রসেস এবং ডেটাস্টোর ক্লিন-আপ করতে হবে। অব্যবহৃত Google Ads অ্যাকাউন্ট পরিষ্কার করার সময়, নিম্নলিখিত নির্দেশিকা মনে রাখবেন:

• আপনার গ্রাহক তার অ্যাকাউন্ট ম্যানেজ করার জন্য আপনার অ্যাপ্লিকেশনকে যে অনুমোদন দিয়েছেন তা প্রত্যাহার করুন।
• গ্রাহকের Google Ads অ্যাকাউন্টে API কল করা বন্ধ করুন। এটি বিশেষ করে ক্রন জব এবং ডেটা পাইপলাইনের মতো অফলাইন জবের ক্ষেত্রে প্রযোজ্য যা ব্যবহারকারীর হস্তক্ষেপ ছাড়াই চালানোর জন্য ডিজাইন করা হয়েছে।
• গ্রাহক তার অনুমোদন প্রত্যাহার করে নিলে, আপনার অ্যাপ্লিকেশনকে পরিস্থিতিটি সুন্দরভাবে সামলাতে হবে এবং Google-এর API সার্ভারে ভুল API কল পাঠানো এড়াতে হবে।
• গ্রাহক তার Google Ads অ্যাকাউন্ট বাতিল করে দিলে, আপনাকে বাতিল করা অ্যাকাউন্ট শনাক্ত করতে হবে এবং Google-এর API সার্ভারে ভুল API কল পাঠানো এড়াতে হবে।
• গ্রাহকের Google Ads অ্যাকাউন্ট থেকে ডাউনলোড করা ডেটা উপযুক্ত সময় পরে আপনার লোকাল ডেটাবেস থেকে মুছে দিন।