সমস্যার ধরন

আমরা নিম্নলিখিত বিস্তৃত বিভাগে ত্রুটিগুলি শ্রেণীবদ্ধ করেছি:

  • যাচাইকরণ
  • যেসব সমস্যার সমাধান করা যাবে
  • যাচাইকরণ
  • সিঙ্ক-সম্পর্কিত

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

  • সাধারণ সমস্যা বিকল্প থেকে নির্দিষ্ট সমস্যা সম্পর্কে আরও বিবরণ পাওয়া যায়।
  • google.rpc.Status API-এর ব্যবহার করা লজিক্যাল এরর মডেল সম্পর্কে বিস্তারিত তথ্য প্রদান করে।
  • ক্যানোনিকাল এরর কোড Google Ads API-এর প্রসঙ্গে gRPC এবং HTTP দ্বারা সংজ্ঞায়িত ক্যানোনিকাল এরর কোডের একটি তালিকা এবং ব্যাখ্যা প্রদান করে।

যাচাইকরণ সংক্রান্ত সমস্যা

যাচাইকরণ বলতে বোঝায় যে আপনার অ্যাপকে কোনও ব্যবহারকারী তার হয়ে Google Ads অ্যাক্সেস করার অনুমতি দিয়েছেন কিনা। OAuth2 ফ্লো-এর মাধ্যমে তৈরি করা ক্রেডেনশিয়ালের সাহায্যে যাচাইকরণ ম্যানেজ করা হয়।

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

একইভাবে, আপনার Google Cloud প্রোজেক্টে শুধুমাত্র টেস্ট অ্যাক্সেস লেভেল থাকলে এবং প্রোডাকশন (নন-টেস্ট) অ্যাকাউন্টের জন্য অনুরোধ করার চেষ্টা করলে, API একটি AuthorizationError রিটার্ন করে যার enum ভ্যালু API ভার্সনের উপর নির্ভর করে:

যেসব সমস্যার সমাধান করা যাবে

কিছু সমস্যা, যেমন TRANSIENT_ERROR বা INTERNAL_ERROR, সাময়িক সমস্যার ইঙ্গিত দিতে পারে যা কিছুক্ষণ পরে আবার অনুরোধ করলে সমাধান হয়ে যেতে পারে।

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

ব্যাকএন্ডে শুরু করা অনুরোধের জন্য, আপনার অ্যাপকে সর্বাধিক সংখ্যক বার অনুরোধটি অটোমেটিক আবার চেষ্টা করা উচিত।

অনুরোধ আবার করার সময়, র‍্যান্ডমাইজড জিটার সহ এক্সপোনেনশিয়াল ব্যাকঅফ নীতি ব্যবহার করুন। যেমন, প্রথমবার আবার চেষ্টা করার আগে আপনি যদি ৫ সেকেন্ডের জন্য পজ করেন, তাহলে দ্বিতীয়বার আবার চেষ্টা করার পরে ১০ সেকেন্ড এবং তৃতীয়বার আবার চেষ্টা করার পরে ২০ সেকেন্ডের জন্য পজ করতে পারেন, সিঙ্ক্রোনাইজ করা আবার চেষ্টা করার স্পাইক প্রতিরোধ করতে প্রতিটি বিরতিতে একটি ছোট র‍্যান্ডম বিলম্ব যোগ করুন। এক্সপোনেনশিয়াল ব্যাকঅফ নিশ্চিত করতে সাহায্য করে যে আপনি API-কে খুব বেশি আক্রমণাত্মকভাবে কল করছেন না। বারবার চেষ্টা করার পরেও সমস্যা থেকে গেলে, সমস্যার সমাধান করার জন্য রেসপন্স থেকে request-id লগ করুন।

যাচাইকরণ সংক্রান্ত সমস্যা

যাচাইকরণ সংক্রান্ত সমস্যা থেকে বোঝা যায় যে কোনও অপারেশনের ইনপুট গ্রহণযোগ্য ছিল না। উদাহরণ হিসেবে PolicyViolationError, DateError, DateRangeError, StringLengthError এবং UrlFieldError অন্তর্ভুক্ত।

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

অনেক Google Ads অ্যাপ তাদের Google Ads অবজেক্ট স্টোর করার জন্য একটি লোকাল ডেটাবেস বজায় রাখে। এই পদ্ধতির একটি চ্যালেঞ্জ হল যে স্থানীয় ডেটাবেস Google Ads-এর প্রকৃত অবজেক্টের সাথে সিঙ্ক নাও হতে পারে। যেমন, কোনও ব্যবহারকারী Google Ads-এ সরাসরি কোনও বিজ্ঞাপন গ্রুপ মুছে দিতে পারেন, কিন্তু অ্যাপ এবং লোকাল ডেটাবেস এই পরিবর্তনের ব্যাপারে অবগত থাকে না এবং বিজ্ঞাপন গ্রুপটি এখনও আছে বলে ধরে নিয়ে API কল ইস্যু করা চালিয়ে যায়। এইসব সিঙ্ক সংক্রান্ত সমস্যা বিভিন্ন ধরনের সমস্যার কারণ হতে পারে, যেমন DUPLICATE_CAMPAIGN_NAME, DUPLICATE_ADGROUP_NAME, AD_NOT_UNDER_ADGROUP, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD এবং আরও অনেক কিছু।

ব্যবহারকারীর শুরু করা অনুরোধের ক্ষেত্রে, একটি কৌশল হল সম্ভাব্য সিঙ্ক সমস্যা সম্পর্কে ব্যবহারকারীকে সতর্ক করা, অবিলম্বে এমন একটি কাজ শুরু করা যা Google Ads অবজেক্টের প্রাসঙ্গিক ক্লাস ফিরিয়ে আনে এবং স্থানীয় ডেটাবেস আপডেট করে, তারপর ব্যবহারকারীকে UI রিফ্রেশ করতে প্রম্পট করে।

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

পরবর্তী
API সংক্রান্ত সমস্যা বোঝা