সর্বোত্তম অনুশীলন

এই পৃষ্ঠাটি বিভিন্ন সর্বোত্তম অনুশীলনকে কভার করে যা Google Ad Manager API এর বিপরীতে অ্যাপ্লিকেশন বিকাশ করার সময় বিবেচনা করা উচিত।

একটি সম্পাদনের সময় পরিষেবা ক্লায়েন্ট/স্টাবগুলি পুনরায় ব্যবহার করুন

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

বস্তু আনার সময় পেজিং ব্যবহার করুন

সমস্ত পরিষেবা একটি get*ByStatement() পদ্ধতি সমর্থন করে, যা PQL সিনট্যাক্স ব্যবহার করে ফলাফল ফিল্টার করার অনুমতি দেয়। LIMIT এবং OFFSET ধারাগুলি বড় ফলাফল সেটগুলিকে পৃষ্ঠাগুলিতে বিভক্ত করতে ব্যবহার করা যেতে পারে, সময় শেষ হওয়া রোধ করতে এবং প্রতিক্রিয়া পৃষ্ঠার আকারগুলি যুক্তিসঙ্গত রাখতে। আপনার অবজেক্টের জটিলতার উপর নির্ভর করে প্রস্তাবিত পৃষ্ঠার আকার 200-500।

ব্যাচ আপডেট অনুরোধ

একই ধরণের একাধিক অবজেক্ট পরিবর্তন করার সময়, আপনি একই update*() অনুরোধে সমস্ত অবজেক্ট পাঠিয়ে আরও ভাল পারফরম্যান্স পেতে পারেন। প্রতিটি অনুরোধের জন্য ক্লায়েন্ট এবং সার্ভারে একটি প্রান্তিক ওভারহেড রয়েছে এবং ব্যাচিং অনুরোধের সংখ্যা হ্রাস করার একটি কার্যকর উপায় হতে পারে। উদাহরণস্বরূপ, প্রতিটি কলে একক অর্ডারের পরিবর্তে অর্ডারের একটি ব্যাচ আপডেট করতেupdateOrders ব্যবহার করুন।

PQL এ বাইন্ড প্যারামিটার ব্যবহার করুন

বাইন্ড প্যারামিটার হল একটি PQL ক্যোয়ারী স্টেটমেন্টে ভেরিয়েবল রাখার একটি উপায়। PQL একটি কোলন দিয়ে শুরু হওয়া স্পেস ছাড়া একটি নাম দ্বারা একটি বাঁধাই ভেরিয়েবলকে বোঝায়, যেমন, :name । PQL সিনট্যাক্স পৃষ্ঠায় একটি কোড উদাহরণ প্রদান করা হয়েছে।

আমরা বাইন্ড ভেরিয়েবলগুলি ব্যবহার করার পরামর্শ দিই কারণ তারা একটি ক্যোয়ারী স্টেটমেন্টে স্ট্রিং এবং ভেরিয়েবলকে সংযুক্ত করার প্রয়োজনীয়তাকে সরিয়ে কোড পঠনযোগ্যতা উন্নত করে। তারা পিকিউএল বিবৃতিগুলি পুনরায় ব্যবহার করা সহজ করে তোলে, যেহেতু বাইন্ড প্যারামিটার মানগুলি প্রতিস্থাপন করে নতুন প্রশ্ন করা যেতে পারে।

অল্প অল্প করে ব্যবহারকারীর সুযোগ-সুবিধা দিন

ব্যবহারকারীর ভূমিকা তৈরি/আপডেট করার জন্য UserService ব্যবহার করার সময়, ব্যবহারকারীদের তাদের প্রয়োজন নেই এমন বিশেষাধিকার না দেওয়ার বিষয়ে সতর্ক থাকুন। API-এর অনেক বৈশিষ্ট্য ব্যবহারকারীকে প্রশাসকের ভূমিকা অর্পণ করার পরিবর্তে ভূমিকার সংমিশ্রণে অ্যাক্সেস করা যেতে পারে। কোন ব্যবহারকারীকে কোন ভূমিকা বরাদ্দ করতে হবে তা সিদ্ধান্ত নেওয়ার সময় অনুগ্রহ করে অনুমতির ডকুমেন্টেশন দেখুন। এছাড়াও, তৃতীয় পক্ষের অ্যাপ্লিকেশন বিকাশকারী হিসাবে, আপনার জন্য একটি ব্যবহারকারী তৈরি করতে একটি নেটওয়ার্ককে জিজ্ঞাসা করার সময় আপনার অ্যাপ্লিকেশনের কোন স্তরের অ্যাক্সেস প্রয়োজন তা নির্ধারণ করতে ভুলবেন না; প্রশাসকের চেয়ে কম বিশেষাধিকার সহ একটি ভূমিকা যথেষ্ট হতে পারে।

কোটার সীমার মধ্যে থাকুন

অ্যাড ম্যানেজার API দৃঢ়তার জন্য বেশ কয়েকটি কোটা সীমা প্রয়োগ করে। আপনার অ্যাপ্লিকেশানগুলিকে এই সীমার মধ্যে রাখা গুরুত্বপূর্ণ এবং আপনি জানেন কিভাবে কোটা ত্রুটির যেকোনও এপিআই ফেরত দিতে পারে।

API কোটা

API অনুরোধে প্রয়োগ করা প্রথম কোটা হল একটি নেটওয়ার্ক-স্তরের কোটা। Ad Manager 360 অ্যাকাউন্টের জন্য, সীমা প্রতি সেকেন্ডে 8টি অনুরোধ, এবং Ad Manager অ্যাকাউন্টের জন্য, সীমা হল প্রতি সেকেন্ডে 2টি অনুরোধ। এই সীমা অতিক্রম করার ফলে একটি QuotaError.EXCEEDED_QUOTA ত্রুটি দেখা দেয়। আপনার নেটওয়ার্কে করা সমস্ত API অনুরোধগুলি এই কোটায় প্রযোজ্য, তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলি সহ যেগুলি আপনি বা আপনার কোম্পানির কেউ আপনার নেটওয়ার্কে API অ্যাক্সেস মঞ্জুর করেছেন৷

সিস্টেম-নির্দিষ্ট কোটা

অ্যাড ম্যানেজারের মধ্যে নির্দিষ্ট রিসোর্স-ইনটেনসিভ সিস্টেমগুলিকে পর্যাপ্তভাবে সুরক্ষিত করার জন্য শুধুমাত্র API কোটা যথেষ্ট নয়। রিপোর্টিং এবং পূর্বাভাস সিস্টেমগুলি তাদের নিজস্ব কোটা সংজ্ঞায়িত করে যার ফলে API ত্রুটি হতে পারে: যথাক্রমে QuotaError.REPORT_JOB_LIMIT এবং ForecastError.EXCEEDED_QUOTA ।

কোটার ত্রুটিগুলি পরিচালনা করা

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