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

এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

রিপোর্টিং সেরা অভ্যাস

প্রথমে UI এ নতুন প্রতিবেদন তৈরি করুন

প্রতিবেদনগুলি প্রতিবেদনের ধরন, ফিল্টার, মাত্রা এবং মেট্রিক্স সম্পর্কিত অনেকগুলি বিধিনিষেধ এবং প্রয়োজনীয়তার সাপেক্ষে। এই সীমাবদ্ধতাগুলি API-এ প্রয়োগ করা হয়, একটি HTTP 400 ত্রুটি ফেরত দেয়৷ প্রতিবেদন তৈরি করার সময় ত্রুটি এড়াতে, আমরা আপনাকে প্রথমে Display & Video 360 UI-তে নতুন প্রতিবেদন তৈরি করার পরামর্শ দিই।

আপনার প্রতিবেদন তৈরি করার পরে, Query রিসোর্সের একটি queries.get সম্পাদন করতে রেফারেন্স ডক্স পৃষ্ঠায় "এই API ব্যবহার করে দেখুন" বৈশিষ্ট্যটিতে ক্লিক করুন৷ আপনি ভবিষ্যত প্রতিবেদন তৈরি করতে ফিরে আসা JSON ব্যবহার করতে পারেন।

রিপোর্টের প্রকারের জন্য নির্দিষ্ট মেট্রিক্স এবং ফিল্টার ব্যবহার করুন

কিছু মেট্রিক এবং ফিল্টার মান নির্দিষ্ট রিপোর্ট প্রকারের জন্য নির্দিষ্ট। প্রথমে UI-তে আপনার প্রতিবেদনগুলি তৈরি করার পাশাপাশি, আপনি নির্দিষ্ট ReportType মানগুলির সাথে সম্পর্কিত মেট্রিক এবং ফিল্টারগুলিকে তাদের বিড ম্যানেজার API মান দ্বারা চিহ্নিত করতে পারেন৷

এখানে প্রাসঙ্গিক বিড ম্যানেজার API ফিল্টার এবং মেট্রিক মান সনাক্ত করার কিছু উপায় রয়েছে৷ এই টেবিলটি এই ধরনের রিপোর্টে ব্যবহার করা যেতে পারে এমন ফিল্টার এবং মেট্রিক্সের একটি সম্পূর্ণ তালিকা নয়। একক প্রতিবেদনে সব মান একসাথে ব্যবহার করা যাবে না।

`ReportType`	প্রাসঙ্গিক ফিল্টার এবং মেট্রিক্স
`INVENTORY_AVAILABILITY`	`FILTER_TRUEVIEW_IAR` উপসর্গ সহ ফিল্টার।
`YOUTUBE`	`FILTER_TRUEVIEW` উপসর্গযুক্ত ফিল্টার, `FILTER_TRUEVIEW_IAR` উপসর্গ বাদ দিয়ে। `METRIC_TRUEVIEW` উপসর্গ সহ মেট্রিক।
`GRP`	`METRIC_GRP` উপসর্গ সহ মেট্রিক।
`YOUTUBE_PROGRAMMATIC_GUARANTEED`	`FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED` উপসর্গ সহ ফিল্টার। `METRIC_PROGRAMMATIC_GUARANTEED` উপসর্গ সহ মেট্রিক।
`REACH`	`METRIC_UNIQUE_REACH` উপসর্গ সহ মেট্রিক।
`UNIQUE_REACH_AUDIENCE`	`METRIC_UNIQUE_REACH` উপসর্গ সহ মেট্রিক।

প্রতিবেদনগুলি সংরক্ষণ করুন এবং পুনরায় ব্যবহার করুন

আমরা সুপারিশ করি যে আপনি নিয়মিতভাবে চালানো প্রশ্নের জন্য প্রতিবেদন তৈরি এবং সংরক্ষণ করুন কারণ একই প্রতিবেদন একাধিকবার সন্নিবেশ করা এবং মুছে ফেলা সম্পদের অপচয় করে। dataRange ফিল্ডে PREVIOUS_DAY বা LAST_7_DAYS এর মতো সেট Range মানগুলি ব্যবহার করা রিপোর্টগুলিকে আরও পুনঃব্যবহারযোগ্য করে তোলে৷

তফসিল রিপোর্ট

অ্যাডহক বা ওয়ান-অফ রিপোর্টগুলি সম্পদের অপচয় হতে পারে কারণ সেগুলি পৃথকভাবে চালানো হয় এবং একটি অসম্পূর্ণ ডেটাসেটের বিরুদ্ধে কার্যকর হতে পারে। নির্ধারিত প্রতিবেদনগুলি রিপোর্টিং সংস্থানগুলির সর্বোত্তম ব্যবহার করে কারণ সেগুলি প্রচুর পরিমাণে চালানো হয় এবং আগের দিনের ডেটা প্রক্রিয়াকরণ সম্পূর্ণ না হওয়া পর্যন্ত কার্যকর না হওয়ার গ্যারান্টি দেওয়া হয়। বিস্তারিত জানার জন্য উপলব্ধ সময়সূচী ক্ষেত্র দেখুন.

অনুরূপ রিপোর্ট একত্রিত

আপনি যদি নিয়মিতভাবে বিভিন্ন বিজ্ঞাপনদাতা বা অংশীদারদের জন্য অভিন্ন মেট্রিক্স এবং তারিখের ব্যাপ্তি সহ প্রতিবেদন তৈরি করেন, তাহলে আমরা সুপারিশ করি যে আপনি তাদের প্রতিবেদনের পরিমাণ অপ্টিমাইজ করতে প্রতিবেদনগুলিকে একত্রিত করুন৷

আপনি সমস্ত রিপোর্টের ফিল্টার যুক্ত করে এবং সমস্ত ফিল্টার প্রকারগুলিকে মাত্রা হিসাবে যোগ করে অনুরূপ রিপোর্টগুলিকে একত্রিত করতে পারেন৷ জেনারেশনের পর, আপনি আসল রিপোর্ট তৈরি করতে মূল ফিল্টার মান বরাবর ফলাফল রিপোর্টের সারি বিভক্ত করতে পারেন।

রিপোর্টিং কোটা বিবেচনা করুন

Display & Video 360 রিপোর্টিং বৈশিষ্ট্যের দায়িত্বশীল ব্যবহার নিম্নলিখিত পণ্য-ব্যাপী ব্যবহারের কোটার মাধ্যমে প্রয়োগ করা হয়।

প্রতিদিন অ্যাডহক রিপোর্ট মৃত্যুদন্ড

একজন ব্যবহারকারী 24-ঘণ্টা সময়ের মধ্যে চালাতে পারে এমন অ্যাডহক রিপোর্টের সংখ্যা সীমিত করে। এই কোটার অধীনে থাকতে:

রিপোর্ট ভলিউম কমাতে অনুরূপ রিপোর্ট একত্রিত করুন .
বিশেষভাবে অ্যাডহক রিপোর্ট ভলিউম কমাতে পুনরাবৃত্ত অ্যাডহক রিপোর্টের সময়সূচী করুন ।
অপ্রয়োজনীয় API স্ক্রিপ্ট নিষ্ক্রিয় করুন।

সক্রিয় নির্ধারিত প্রতিবেদন

একটি নির্দিষ্ট সময়ে একজন ব্যবহারকারী সক্রিয়ভাবে নির্ধারিত রিপোর্টের সংখ্যা সীমিত করে। এই কোটার অধীনে থাকতে:

নির্ধারিত রিপোর্টের সামগ্রিক সংখ্যা কমাতে অনুরূপ নির্ধারিত প্রতিবেদন একত্রিত করুন ।
অপ্রয়োজনীয় নির্ধারিত প্রতিবেদন নিষ্ক্রিয় করুন।
অপ্রয়োজনীয় API স্ক্রিপ্ট নিষ্ক্রিয় করুন।

সমসাময়িক প্রতিবেদন

একজন ব্যবহারকারী একই সাথে চালাতে পারে এমন রিপোর্টের সংখ্যা সীমিত করে। এই কোটার অধীনে থাকতে:

রিপোর্টের সময়সূচী করুন যা নিয়মিত চলে।
অপ্রয়োজনীয় API স্ক্রিপ্ট নিষ্ক্রিয় করুন।
এক্সপোনেনশিয়াল ব্যাকঅফ লজিক ব্যবহার করে পোলিং করে কখন আপনার রিপোর্টগুলি করা হয় তা ট্র্যাক করুন৷

আপনি যদি আপনার রিপোর্টিং বাস্তবায়ন অপ্টিমাইজ করে থাকেন এবং আপনি এখনও নিজেকে আপনার প্রদত্ত কোটা অতিক্রম করতে দেখেন, যোগাযোগ ফর্ম ব্যবহার করে Display & Video 360 সমর্থনের সাথে যোগাযোগ করুন।

রিপোর্ট স্ট্যাটাসের জন্য পোলিং করার সময় সূচকীয় ব্যাকঅফ ব্যবহার করুন

একটি রিপোর্ট চালানোর জন্য কত সময় লাগবে তা অনুমান করা সম্ভব নয়। সময়ের দৈর্ঘ্য সেকেন্ড থেকে ঘন্টা পর্যন্ত হতে পারে যেমন তারিখের ব্যাপ্তি এবং প্রসেস করা ডেটার পরিমাণ সহ অনেক কারণের উপর নির্ভর করে। রিপোর্ট রান-টাইম এবং রিপোর্টে ফিরে আসা সারির সংখ্যার মধ্যে কোন সম্পর্ক নেই। তাই আপনাকে নিয়মিতভাবে queries.reports.get পদ্ধতি ব্যবহার করে রিপোর্ট রিসোর্সটি পুনরুদ্ধার করতে হবে এবং রিসোর্সের metadata.status.state ফিল্ডটি DONE হয়েছে বা FAILED হয়েছে কিনা তা নির্ধারণ করতে আপডেট করা হয়েছে কিনা তা পরীক্ষা করতে হবে। এটি একটি প্রক্রিয়া যা "ভোলিং" নামে পরিচিত।

ভোটগ্রহণের প্রয়োজনীয়তা থাকাকালীন, একটি অদক্ষ বাস্তবায়ন একটি দীর্ঘ চলমান প্রতিবেদনের সম্মুখীন হওয়ার সময় আপনার কোটা দ্রুত শেষ করতে পারে। সুতরাং আমরা সুপারিশ করি যে আপনি পুনরায় চেষ্টা সীমিত করতে এবং কোটা সংরক্ষণ করতে সূচকীয় ব্যাকঅফ ব্যবহার করুন৷

সূচকীয় ব্যাকঅফ

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

সাধারণ সূচকীয় ব্যাকঅফ বাস্তবায়নের জন্য প্রবাহ নিম্নরূপ:

API-এ একটি queries.reports.get অনুরোধ করুন।
রিপোর্ট বস্তু পুনরুদ্ধার করুন. যদি metadata.status.state ক্ষেত্রটি DONE না হয় বা FAILED , তাহলে এটি ইঙ্গিত করে যে প্রতিবেদনটি চালানো শেষ হয়নি পোলিং চালিয়ে যাওয়া উচিত৷
5 সেকেন্ড অপেক্ষা করুন + মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা এবং অনুরোধটি পুনরায় চেষ্টা করুন।
রিপোর্ট বস্তু পুনরুদ্ধার করুন. যদি metadata.status.state ক্ষেত্রটি DONE না হয় বা FAILED , তাহলে এটি ইঙ্গিত করে যে প্রতিবেদনটি চালানো শেষ হয়নি পোলিং চালিয়ে যাওয়া উচিত৷
10 সেকেন্ড অপেক্ষা করুন + মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা এবং অনুরোধটি পুনরায় চেষ্টা করুন।
রিপোর্ট বস্তু পুনরুদ্ধার করুন. যদি metadata.status.state ক্ষেত্রটি DONE না হয় বা FAILED , তাহলে এটি ইঙ্গিত করে যে প্রতিবেদনটি চালানো শেষ হয়নি পোলিং চালিয়ে যাওয়া উচিত৷
20 সেকেন্ড অপেক্ষা করুন + মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা এবং অনুরোধটি পুনরায় চেষ্টা করুন।
রিপোর্ট বস্তু পুনরুদ্ধার করুন. যদি metadata.status.state ক্ষেত্রটি DONE না হয় বা FAILED , তাহলে এটি ইঙ্গিত করে যে প্রতিবেদনটি চালানো শেষ হয়নি পোলিং চালিয়ে যাওয়া উচিত৷
40 সেকেন্ড + মিলিসেকেন্ডের একটি এলোমেলো সংখ্যক অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
রিপোর্ট বস্তু পুনরুদ্ধার করুন. যদি metadata.status.state ক্ষেত্রটি DONE না হয় বা FAILED , তাহলে এটি ইঙ্গিত করে যে প্রতিবেদনটি চালানো শেষ হয়নি পোলিং চালিয়ে যাওয়া উচিত৷
80 সেকেন্ড অপেক্ষা করুন + মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা এবং অনুরোধটি পুনরায় চেষ্টা করুন।
রিপোর্ট অবজেক্ট আপডেট না হওয়া পর্যন্ত বা সর্বাধিক সময় অতিবাহিত না হওয়া পর্যন্ত এই প্যাটার্নটি চালিয়ে যান।

যদি রিপোর্টটি চলা শেষ হয় এবং একটি DONE অবস্থায় শেষ হয়, তাহলে আপনি metadata.googleCloudStoragePath ফিল্ডে দেওয়া পাথে Google ক্লাউড স্টোরেজ থেকে জেনারেট করা রিপোর্ট ফাইলটি পুনরুদ্ধার করতে পারেন।