API সীমা এবং কোটা

গুগল অ্যাডস এপিআই, এপিআই অপারেশনগুলোর উপর সীমাবদ্ধতা আরোপ করে, যেমন একটি একক মিউটেট অনুরোধে পাঠানো যেতে পারে এমন অপারেশনের সংখ্যা। নিম্নলিখিত সারণিতে কিছু গুরুত্বপূর্ণ সীমাবদ্ধতা এবং কোটা সংক্ষেপে তুলে ধরা হলো, যেগুলো সম্পর্কে সচেতন থাকা প্রয়োজন।

অনুরোধের ধরণ, সীমাবদ্ধতা এবং ত্রুটি কোড
টেস্ট অ্যাক্সেস লেভেল সহ অপারেশন টেস্ট অ্যাকাউন্টগুলোর বিপরীতে প্রতিদিন ১৫,০০০ এপিআই অপারেশন RESOURCE_EXHAUSTED
এক্সপ্লোরার অ্যাক্সেস লেভেল সহ অপারেশন প্রোডাকশন অ্যাকাউন্টগুলোর বিপরীতে প্রতিদিন ২,৮৮০টি এপিআই অপারেশন পরিচালিত হয়।
টেস্ট অ্যাকাউন্টগুলোর বিপরীতে প্রতিদিন ১৫,০০০ এপিআই অপারেশন		 RESOURCE_EXHAUSTED
বেসিক অ্যাক্সেস লেভেল সহ অপারেশন টেস্ট এবং প্রোডাকশন উভয় অ্যাকাউন্টের বিপরীতে প্রতিদিন ১৫,০০০ এপিআই অপারেশন RESOURCE_EXHAUSTED
স্ট্যান্ডার্ড অ্যাক্সেস লেভেল সহ অপারেশন টেস্ট এবং প্রোডাকশন উভয় অ্যাকাউন্টের জন্য প্রতিদিন সীমাহীন এপিআই অপারেশন প্রযোজ্য নয়
পরিবর্তন অনুরোধ প্রতি অনুরোধে ১০,০০০ মিউটেট অপারেশন TOO_MANY_MUTATE_OPERATIONS
পরিকল্পনা পরিষেবা অনুরোধ ১ কিউপিএস RESOURCE_EXHAUSTED
রূপান্তর আপলোড পরিষেবা অনুরোধ প্রতি অনুরোধে ২,০০০ রূপান্তর TOO_MANY_CONVERSIONS_IN_REQUEST
বিলিং এবং অ্যাকাউন্ট বাজেট পরিষেবা অনুরোধ প্রতিটি পরিবর্তন অনুরোধের জন্য ১টি অপারেশন TOO_MANY_MUTATE_OPERATIONS

দৈনিক এপিআই পরিচালনার সীমা

দৈনিক এপিআই ব্যবহারের সীমা আপনার গুগল ক্লাউড প্রজেক্ট দ্বারা সম্পাদিত এপিআই অপারেশনের সংখ্যার উপর ভিত্তি করে নির্ধারিত হয়। এপিআই অপারেশন হলো Search ও SearchStream রিকোয়েস্ট, স্বতন্ত্র মিউটেট অপারেশন এবং অন্যান্য সার্ভিস রিকোয়েস্টের মোট যোগফল। দৈনিক এপিআই অপারেশনের সীমা আপনার গুগল ক্লাউড প্রজেক্টের এপিআই অ্যাক্সেস লেভেলের উপর নির্ভর করে। অ্যাক্সেস লেভেল এবং অনুমোদিত ব্যবহার নির্দেশিকায় প্রতিটি অ্যাক্সেস লেভেলের জন্য নির্দিষ্ট এপিআই অপারেশনের সীমা উল্লেখ করা আছে।

যেসব অনুরোধ এই সীমা লঙ্ঘন করে, সেগুলো RESOURCE_EXHAUSTED ত্রুটিসহ প্রত্যাখ্যান করা হয়।

gRPC সীমাবদ্ধতা

গুগল অ্যাডস এপিআই-এর সমস্ত ক্লায়েন্ট লাইব্রেরি রিকোয়েস্ট এবং রেসপন্স তৈরি করার জন্য gRPC ব্যবহার করে। ডিফল্টরূপে, gRPC-এর মেসেজ সাইজ ৪ মেগাবাইট, কিন্তু আমাদের ক্লায়েন্ট লাইব্রেরিগুলো কার্যকারিতা বাড়ানোর জন্য সর্বোচ্চ মেসেজ সাইজ ৬৪ মেগাবাইটে সেট করে।

রেসপন্স অবশ্যই এই সীমা অতিক্রম করবে না। উদাহরণস্বরূপ, অনেকগুলো ফিল্ডসহ একটি সার্চ রিকোয়েস্টের ফলে ৬৪ মেগাবাইটের বেশি আকারের একটি রেসপন্স তৈরি হতে পারে। এই সীমা এড়ানোর জন্য, আপনি নির্বাচিত ফিল্ডের সংখ্যা কমাতে পারেন, অথবা স্ট্রিমিং ব্যবহার করতে পারেন। মিউটেট-এর ক্ষেত্রে, প্রতি রিকোয়েস্টে কম অপারেশন পাঠান।

যে অনুরোধগুলি এই সীমাবদ্ধতা লঙ্ঘন করে, সেগুলি GoogleAdsError তৈরি করবে না , কিন্তু RESOURCE_EXHAUSTED (gRPC কোড 8 / HTTP 429 ) ত্রুটি তৈরি করবে। gRPC ত্রুটি কোড এবং বার্তাগুলির তালিকা দেখুন।

পরিবর্তন অনুরোধ

ব্যবহারকারীর দৈনিক অপারেশন কোটার অন্তর্ভুক্ত হওয়ার পাশাপাশি, একটি মিউটেট অনুরোধে প্রতি অনুরোধে ১০,০০০- এর বেশি মিউটেট অপারেশন থাকতে পারে না। যে অনুরোধগুলি এই সীমাবদ্ধতা লঙ্ঘন করে, সেগুলি TOO_MANY_MUTATE_OPERATIONS ত্রুটি সহ প্রত্যাখ্যান করা হয়।

নির্দিষ্ট পরিষেবা এবং অনুরোধের প্রকারভেদের জন্য অতিরিক্ত সীমাবদ্ধতা ও বিবেচ্য বিষয়গুলো পরবর্তীতে বর্ণনা করা হয়েছে।

অনুসন্ধানের অনুরোধ

একটি Search বা SearchStream অনুরোধ ব্যবহারকারীর দৈনিক অপারেশন কোটার বিপরীতে একটি অপারেশন হিসাবে গণ্য হয়। ব্যাচের সংখ্যা নির্বিশেষে একটি SearchStream অনুরোধকে একটি এপিআই অপারেশন হিসাবে গণনা করা হয়।

পৃষ্ঠাঙ্কিত অনুরোধ

পেজিনেটেড অনুরোধ (উদাহরণস্বরূপ, যে অনুরোধগুলিতে একটি বৈধ next_page_token থাকে) ব্যবহারকারীর দৈনিক অপারেশন কোটার মধ্যে গণনা করা হয় না। তবে, যে পেজিনেশন অনুরোধগুলিতে মেয়াদোত্তীর্ণ বা অবৈধ পেজ টোকেন থাকে, সেগুলি একটি ব্যতিক্রম তৈরি করবে এবং দৈনিক অপারেশন কোটার মধ্যে গণনা করা হবে।

পেজিনেশন সম্পর্কে আরও বিস্তারিত জানতে, "ফলাফলের মধ্যে পেজিং" দেখুন।

অন্যান্য ধরণের অনুরোধ

যে অনুরোধটি Mutate , Search , বা SearchStream অনুরোধ নয়, সেটি ব্যবহারকারীর দৈনিক অপারেশন কোটার বিপরীতে একটি অপারেশন হিসেবে গণ্য হয়।

এই ধরনের অনুরোধের কয়েকটি উদাহরণ হলো:

যে অনুরোধগুলি API ব্যতিক্রম ফেরত দেয়

GoogleAdsFailure এর কারণে প্রত্যাখ্যাত হওয়া অনুরোধগুলোও ব্যবহারকারীর দৈনিক অপারেশন কোটার অন্তর্ভুক্ত হয়।

যেসব অনুরোধ ব্যর্থ হয় কিন্তু GoogleAdsFailure দেখায় না, যেমন নেটওয়ার্ক স্তরের কোনো ত্রুটির কারণে, সেগুলো ব্যবহারকারীর দৈনিক অপারেশন কোটার মধ্যে গণনা করা হবে না, কারণ অনুরোধগুলো কখনোই পরিষেবা পর্যন্ত পৌঁছাবে না। এর একটি উদাহরণ হলো নেটওয়ার্ক সংযোগ ব্যর্থতা।

কীওয়ার্ড পরিকল্পনা পরিষেবা

খরচ এবং জটিলতার কারণে, নিম্নলিখিত কীওয়ার্ড প্ল্যানিং পরিষেবা পদ্ধতিগুলো অন্যান্য ধরনের অনুরোধ থেকে আলাদা সীমার অধীন।

কীওয়ার্ড পরিকল্পনা তৈরি করার সময় এই সীমাবদ্ধতাগুলো মনে রাখবেন।

কীওয়ার্ড প্ল্যান অবজেক্ট সর্বোচ্চ সংখ্যা
প্রতি অ্যাকাউন্টে KeywordPlan ১০,০০০
KeywordPlanAdGroup প্রতি KeywordPlan ২০০
KeywordPlanAdGroupKeyword KeywordPlan ১০,০০০
KeywordPlanCampaignKeyword (নেগেটিভ কীওয়ার্ড) প্রতি KeywordPlan ১,০০০
KeywordPlanCampaign প্রতি KeywordPlan ১

দর্শক অন্তর্দৃষ্টি পরিষেবা

AudienceInsightsService অন্তর্গত নিম্নলিখিত পদ্ধতিগুলো নির্দিষ্ট কোটা সীমার অধীন।

রূপান্তর আপলোড পরিষেবা

রূপান্তর সমন্বয় আপলোড পরিষেবা

রূপান্তর মান নিয়ম

  • প্রতি অ্যাকাউন্টে ১,০০,০০০টি রূপান্তর মূল্য নিয়মে সীমাবদ্ধ।

    যেসব অনুরোধ এই সীমা লঙ্ঘন করে, সেগুলো ResourceCountLimitExceededError.ACCOUNT_LIMIT ত্রুটিসহ প্রত্যাখ্যান করা হয়।

যদি অ্যাকাউন্টটির জন্য CUSTOMER attachment_type একটি ConversionValueRuleSet আগে থেকেই বিদ্যমান থাকে, তবে নতুন যেকোনো কনভার্সন ভ্যালু রুল সক্রিয় করার জন্য আপনাকে অবশ্যই সেই সেটে সেগুলো যোগ করতে হবে। যদি এই ধরনের কোনো কনভার্সন ভ্যালু রুল সেট না থাকে, তবে আপনাকে একটি তৈরি করতে হবে এবং 'রুল সেট তৈরি করুন' অংশে বর্ণিত পদ্ধতি অনুযায়ী আপনার কনভার্সন ভ্যালু রুলগুলো তাতে যোগ করতে হবে।

বিলিং এবং অ্যাকাউন্ট বাজেট পরিষেবা

  • শুধুমাত্র মাসিক ইনভয়েসিংয়ের জন্য কনফিগার করা অ্যাকাউন্টগুলোর ক্ষেত্রেই পরিবর্তন (Mutate) করা যাবে।

    যেসব অনুরোধ এই সীমাবদ্ধতা লঙ্ঘন করে, সেগুলো MUTATE_NOT_ALLOWED ত্রুটিসহ প্রত্যাখ্যান করা হয়।

  • পরিবর্তন অনুরোধের জন্য শুধুমাত্র ১টি অপারেশন অনুমোদিত।

    যেসব অনুরোধ এই সীমাবদ্ধতা লঙ্ঘন করে, সেগুলো TOO_MANY_MUTATE_OPERATIONS ত্রুটিসহ প্রত্যাখ্যান করা হয়।

  • একই অ্যাকাউন্টের বাজেট ( AccountBudget বা AccountBudgetProposal ) পরিবর্তনের মধ্যে কমপক্ষে ১২ ঘন্টা অপেক্ষা করা উচিত। ১২ ঘন্টা অতিবাহিত হওয়ার আগে পরিবর্তন করলে অপূরণীয় ব্যর্থতা ঘটতে পারে, যা শুধুমাত্র আপনার Google Ads অ্যাকাউন্ট প্রতিনিধি সমাধান করতে পারবেন।

গ্রাহক অ্যাকাউন্টে আমন্ত্রণ

CustomerUserAccessInvitationService ব্যবহার করে বিদ্যমান ক্লায়েন্ট অ্যাকাউন্টগুলিতে নতুন ব্যবহারকারীদের আমন্ত্রণ জানানো যেতে পারে। যেহেতু এই বৈশিষ্ট্যটি অন্যান্য ব্যবহারকারীদের কাছে আমন্ত্রণ ইমেল পাঠায়, তাই এর অপব্যবহারের সম্ভাবনা রয়েছে এবং সেই কারণে এর কার্যকারিতার কিছু সীমাবদ্ধতা রয়েছে:

  • ব্যবহারকারীরা একই ক্লায়েন্ট অ্যাকাউন্টের জন্য একাধিক অপেক্ষাধীন আমন্ত্রণ গ্রহণ করতে পারবেন না। যদি এমন কোনো ব্যবহারকারীকে আমন্ত্রণ পাঠানোর জন্য পরবর্তীকালে অনুরোধ করা হয় যার কাছে ইতিমধ্যেই একটি অপেক্ষাধীন আমন্ত্রণ রয়েছে, তাহলে এই ত্রুটিটি প্রদর্শিত হবে: EMAIL_ADDRESS_ALREADY_HAS_PENDING_INVITATION ।

  • ক্লায়েন্ট অ্যাকাউন্টগুলিতে একই সময়ে ৭০টির বেশি আমন্ত্রণ অমীমাংসিত থাকতে পারে না। যদি এমন কোনো অনুরোধ পাঠানো হয় যার ফলে এই সংখ্যাটি অতিক্রম করে, তাহলে এই ত্রুটিটি প্রদর্শিত হয়: PENDING_INVITATIONS_LIMIT_EXCEEDED ।

ব্যবহারকারীর ডেটা

ব্যবহারকারীর ডেটা UserDataService এবং OfflineUserDataJobService এর মাধ্যমে পরিচালনা করা হয়।

create বা remove অপারেশনের প্রতিটি UserData অবজেক্ট একজন একক ব্যবহারকারীর সাথে সম্পর্কিত। একটি UserData অবজেক্টের মধ্যে থাকা user_identifiers ফিল্ডটি সর্বোচ্চ ২০টি আইডেন্টিফায়ারের মধ্যে সীমাবদ্ধ। একটি UserData অবজেক্টে এই সীমা অতিক্রম করলে OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS অথবা UserDataError.TOO_MANY_USER_IDENTIFIERS ত্রুটি দেখা দেবে।

২০টির বেশি শনাক্তকারীযুক্ত ব্যবহারকারীদের পরিচালনা করুন

যদি একজন ব্যবহারকারীর ২০টির বেশি আইডেন্টিফায়ার থাকে যা আপনাকে আপলোড করতে হবে, তবে আপনার উচিত এই আইডেন্টিফায়ারগুলোকে একাধিক UserData অবজেক্টে ভাগ করে দেওয়া। গুগল যাতে এই সমস্ত আইডেন্টিফায়ারকে একই ব্যবহারকারীর সাথে যুক্ত করতে পারে, তা নিশ্চিত করার জন্য সেই ব্যবহারকারীর প্রতিটি UserData অবজেক্টে অবশ্যই অন্তত একটি সাধারণ user_identifier অন্তর্ভুক্ত থাকতে হবে, যেমন একই hashed_email , hashed_phone_number , বা third_party_user_id । গুগল এই সাধারণ আইডেন্টিফায়ারগুলো ব্যবহার করে আলাদা UserData অপারেশনগুলো থেকে প্রাপ্ত তথ্যকে সঠিক ব্যবহারকারীর প্রোফাইলের সাথে লিঙ্ক ও একত্রিত করে।

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

উদাহরণস্বরূপ, যদি কোনো ব্যবহারকারীর ৩০টি ইমেল ঠিকানা থাকে, তাহলে আপনি দুটি UserData অবজেক্ট পাঠাতে পারেন যেগুলোর একটি সাধারণ third_party_user_id থাকবে (২০টি আইডেন্টিফায়ারের সীমা মেনে চলার জন্য প্রথম অবজেক্টটিতে thirdPartyUserId এবং ১ থেকে ১৯ পর্যন্ত ইমেলগুলো রাখবেন, এবং দ্বিতীয়টিতে thirdPartyUserId এবং ২০ থেকে ৩০ পর্যন্ত ইমেলগুলো রাখবেন):

{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_1" },
    // Hashed emails 2 through 18 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_19" }
  ]
}

{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_20" },
    // Hashed emails 21 through 29 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_30" }
  ]
}

একটি একক AddOfflineUserDataJobOperationsRequest সমস্ত অপারেশন জুড়ে user_identifiers এর মোট সীমা হল ১০০,০০০ (একটি OfflineUserDataJob একাধিক AddOfflineUserDataJobOperationsRequest কল গ্রহণ করতে পারে, প্রতি জবে প্রস্তাবিত সর্বোচ্চ ১,০০০,০০০ অপারেশন পর্যন্ত)। UploadUserDataRequest ( UserDataService.UploadUserData ) ব্যবহার করে সিনক্রোনাস আপলোডের জন্য, প্রতিটি অনুরোধ সর্বোচ্চ ১০টি অপারেশন এবং সম্পূর্ণ অনুরোধ জুড়ে ১০০টি user_identifiers মধ্যে সীমাবদ্ধ।

অন্যান্য ধরণের সীমা

একটি অনুরোধে অপারেশন তালিকার মতো পুনরাবৃত্ত ফিল্ডে অতিরিক্ত আইটেম থাকলে REQUEST_SIZE_LIMIT_EXCEEDED ত্রুটিটি দেখা দিতে পারে। এই একই ত্রুটি বার্তা অন্যান্য সমস্যার কারণেও হতে পারে।

আপনি যদি এই সীমাবদ্ধতার সম্মুখীন হন এবং পুনরাবৃত্ত ফিল্ড ব্যবহার করে অনুরোধ করেন, তাহলে অপারেশনগুলির তালিকাটিকে একাধিক মিউটেট অনুরোধে ভাগ করে পুনরাবৃত্ত ফিল্ডের আইটেমের সংখ্যা কমানোর চেষ্টা করুন।

GAQL কোয়েরি করার সময়, একটি IN ক্লজের মধ্যে আইটেমের সর্বোচ্চ সংখ্যা হলো ২০,০০০। এই সীমা অতিক্রম করলে FILTER_HAS_TOO_MANY_VALUES ত্রুটি প্রদর্শিত হয়।

পূর্ববর্তী
ওভারভিউ
পরবর্তী
সিস্টেম সীমা