ডায়গনিস্টিকস

আপনার ইভেন্ট ও দর্শক আপলোডের স্বাস্থ্য যাচাই করতে এবং আপনার ডেটার সমস্যা শনাক্ত করতে এখানে সাজেস্ট করা ওয়ার্কফ্লো দেওয়া হল।

1. ইভেন্ট পাঠাতে বা অডিয়েন্স মেম্বার পাঠাতে বা সরাতে অনুরোধ ইস্যু করুন।

2. প্রতিটি অনুরোধের সামগ্রিক স্ট্যাটাস চেক করুন। সফল অনুরোধে code, 0-এর সমান (এনাম ভ্যালু OK, HTTP রেসপন্স 200 OK) সহ একটি Status থাকে এবং IngestEventsResponse, IngestAudienceMembersResponse অথবা RemoveAudienceMembersResponse রিটার্ন করে।

   অনুরোধ সফল না হলে, সমস্যার সমাধান করতে অনুরোধটি পরিবর্তন করুন এবং আবার অনুরোধটি পাঠান।

   অনুরোধ সফল হলে, উত্তরের request_id ক্যাপচার করুন যাতে পরবর্তী ধাপে ডায়াগনস্টিকস ফিরিয়ে আনতে আপনি এটি ব্যবহার করতে পারেন।

   মনে রাখবেন: আপনি শুধুমাত্র সেইসব অনুরোধের জন্য ডায়াগনস্টিকস রিট্রিভ করতে পারবেন যেগুলি সফল হয়েছে এবং যেগুলিতে validate_only true হিসেবে সেট করা নেই।

3. ৩০ মিনিট অপেক্ষা করুন, তারপর প্রতিটি সফল request_id-এর জন্য RetrieveRequestStatus অনুরোধ পাঠান।

   প্রতিটি request_id-এর জন্য এই ধাপটি পর্যায়ক্রমে পুনরাবৃত্তি করুন যতক্ষণ না প্রতিটি গন্তব্যের জন্য গন্তব্যের স্ট্যাটাস SUCCESS, PARTIAL_SUCCESS, বা FAILURE-এ পৌঁছায়। প্রতিটি অনুরোধের মধ্যে অপেক্ষা করার জন্য এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম ব্যবহার করুন।

4. আপনার আপলোড সঠিকভাবে কাজ করছে কিনা তা কনফার্ম করতে এবং আপনার ডেটা সংক্রান্ত কোনও সমস্যা শনাক্ত করতে প্রতিটি RetrieveRequestStatusResponse পর্যালোচনা করুন।

5. ডেটা সংক্রান্ত সমস্যার সমাধান করুন।

6. ১ নম্বর ধাপে ফিরে যান এবং আপনার আপলোড করা কন্টেন্টের সব সমস্যার সমাধান না হওয়া পর্যন্ত এই ধাপগুলি আবার করুন।

অনুরোধ পাঠান

RetrieveRequestStatusRequest-এর জন্য একটি request_id ভ্যালু প্রয়োজন। সফল ইনজেশন অনুরোধ থেকে ক্যাপচার করা প্রতিটি অনুরোধ আইডির জন্য আলাদা স্ট্যাটাস অনুরোধ পাঠান।

পরামর্শ: API Explorer ব্যবহার করে আপনার ব্রাউজারে অনুরোধ করে দেখুন।

অনুমোদন

RetrieveRequestStatusRequest-এ গন্তব্য অ্যাকাউন্ট বা রিকোয়েস্ট হেডার গ্রহণ করা হয় না। পরিবর্তে, ডেটা ম্যানেজার API request_id-এর সাথে যুক্ত আসল ইনজেশন অনুরোধ থেকে ডেস্টিনেশন শনাক্ত করে এবং যাচাই করে যে কলারের প্রতিটি Destination-এ operating_account-এর অ্যাক্সেস আছে কিনা।

অনুরোধের স্ট্যাটাস চেক করতে, RetrieveRequestStatusRequest-এ ব্যবহৃত ক্রেডেনশিয়ালকে অবশ্যই আসল ইনজেশন অনুরোধ থেকে প্রতিটি গন্তব্যের operating_account-এর জন্য নিম্নলিখিত প্রয়োজনীয়তা পূরণ করতে হবে:

• একই অ্যাক্সেস পাথ: ক্রেডেনশিয়ালের কাছে প্রতিটি operating_account-এর অ্যাক্সেস থাকতে হবে, যা আসল ইনজেশন অনুরোধে নির্দিষ্ট করা একই অ্যাক্সেস পাথ ব্যবহার করে।

  যেমন, Google Ads operating_account-এর জন্য ইনজেশন অনুরোধে login_account হিসেবে পেরেন্ট ম্যানেজার অ্যাকাউন্ট উল্লেখ করা থাকলে, ক্রেডেনশিয়ালেরও একই ম্যানেজার অ্যাকাউন্টের মাধ্যমে operating_account-এ অ্যাক্সেস থাকতে হবে। এমনকি, ক্রেডেনশিয়ালের সাথে যুক্ত Google অ্যাকাউন্টের যদি সন্তানের operating_account-এ সরাসরি অ্যাক্সেস থাকে, তাহলেও ইনজেশনের সময় উল্লেখ করা login_account ম্যানেজার অ্যাকাউন্টের মাধ্যমে অ্যাক্সেস না থাকলে, অনুরোধটি PERMISSION_DENIED সমস্যার সাথে ব্যর্থ হয়।

• পর্যাপ্ত অ্যাক্সেস লেভেল: ক্রেডেনশিয়ালের সাথে যুক্ত Google অ্যাকাউন্টের কাছে operating_account-এ ডেটা ইনজেস্ট করার অনুমতি সহ অ্যাক্সেস লেভেল বা ভূমিকা থাকতে হবে।

  যেমন, Google Ads-এ, Google অ্যাকাউন্টে অবশ্যই অ্যাডমিন বা স্ট্যান্ডার্ড অ্যাক্সেস লেভেল থাকতে হবে। শুধু পড়ার অ্যাক্সেস লেভেল সহ কোনও অ্যাকাউন্টের ক্রেডেনশিয়াল সহ অনুরোধ PERMISSION_DENIED সমস্যার কারণে ব্যর্থ হয়।

পোলিং স্ট্র্যাটেজি

আসল অনুরোধে প্রতিটি গন্তব্যের জন্য request_status-এর মান SUCCESS, FAILURE বা PARTIAL_SUCCESS-এ না পৌঁছানো পর্যন্ত এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম ব্যবহার করে নিয়মিতভাবে RetrieveRequestStatusRequest পাঠান। এতে ২৪ ঘণ্টা পর্যন্ত সময় লাগতে পারে, যদিও ডেটা ম্যানেজার API কিছু অনুরোধের প্রসেসিং ৩০ মিনিটের মধ্যেই শেষ করে ফেলতে পারে।

এখানে একটি যুক্তিসঙ্গত প্রাথমিক অপেক্ষা করার সময় এবং পুনরায় চেষ্টা করার কনফিগারেশনের উদাহরণ দেওয়া হল যা লাইভনেস এবং কোটা ব্যবহারকে ব্যালেন্স করে:

সেটিং	ভ্যালু
প্রথম ডায়াগনস্টিক অনুরোধের আগে অপেক্ষার সময় (মিনিট)	30
ব্যাকঅফ মাল্টিপ্লায়ার	1.3
সর্বাধিক ব্যাকঅফ (মিনিট)	60 (১ ঘণ্টা)
সর্বাধিক মোট সময় (মিনিট)	1440 (২৪ ঘণ্টা)

এই কনফিগারেশনের সাথে অনুরোধের ক্রম এবং অতিবাহিত সময় এখানে দেওয়া হল:

গ্রাফ

ডেটা

চেষ্টা	ইনজেশন অনুরোধের পর থেকে সময় (hh:mm)	চেষ্টা করার আগে বিলম্ব	নোট
1	00:30	৩০.০ মিনিট	প্রথমে স্ট্যাটাস উপলভ্য কিনা তা চেক করুন
2	01:09	৩৯.০ মিনিট
3	01:59	৫০.৭ মিনিট
4	02:59	৬০.০ মিনিট	দেরি হওয়ার সময় এখন ১ ঘণ্টা পর্যন্ত সীমাবদ্ধ করা হয়েছে
5	03:59	৬০.০ মিনিট
6	04:59	৬০.০ মিনিট
7	05:59	৬০.০ মিনিট
8	06:59	৬০.০ মিনিট
9	07:59	৬০.০ মিনিট
10	08:59	৬০.০ মিনিট
11	09:59	৬০.০ মিনিট
12	10:59	৬০.০ মিনিট
13	11:59	৬০.০ মিনিট	১২-ঘণ্টার চিহ্ন
14	12:59	৬০.০ মিনিট
15	13:59	৬০.০ মিনিট
16	14:59	৬০.০ মিনিট
১৭	15:59	৬০.০ মিনিট
18	16:59	৬০.০ মিনিট
১৯	17:59	৬০.০ মিনিট
20	18:59	৬০.০ মিনিট
21	19:59	৬০.০ মিনিট
22	20:59	৬০.০ মিনিট
23	21:59	৬০.০ মিনিট
24	22:59	৬০.০ মিনিট
25	23:59	৬০.০ মিনিট	২৪ ঘণ্টার সর্বাধিক মোট সময়ের আগে শেষ অনুরোধ

"থান্ডারিং হার্ড" সমস্যা প্রতিরোধ করতে ব্যাকঅফ ডিলেতে জিটার-এর একটি ছোট র‍্যান্ডম পরিমাণ যোগ করুন যেখানে অনেক ক্লায়েন্ট একই সাথে আবার চেষ্টা করে।

উত্তর পর্যালোচনা করুন

RetrieveRequestStatusResponse-এর request_status_per_destination-এ সংশ্লিষ্ট ইনজেশন অনুরোধে প্রতিটি গন্তব্যের জন্য আলাদা এন্ট্রি থাকে।

যেমন, আপনার IngestAudienceMembersRequest-এ ৩টি আলাদা অডিয়েন্সের কাছে ডেটা পাঠানোর জন্য destinations তালিকায় ৩টি এন্ট্রি থাকলে, স্ট্যাটাস সংক্রান্ত উত্তরে request_status_per_destination-এ ৩টি এন্ট্রি থাকবে (প্রতিটি অডিয়েন্সের জন্য একটি করে এন্ট্রি)।

গন্তব্যের সামগ্রিক স্ট্যাটাস চেক করুন

প্রথম ধাপ হিসেবে, request_status ফিল্ড চেক করে দেখুন যে RequestStatusPerDestination-এর destination-এর জন্য ডেটা ম্যানেজার API ডেটা প্রসেস করা শেষ করেছে কিনা।

request_status-এর সম্ভাব্য ভ্যালুগুলি এখানে দেওয়া হল:

• PROCESSING: গন্তব্যের ডেটা এখনও প্রসেস করা হচ্ছে। এই পর্যায়ে ডেস্টিনেশনের জন্য সতর্কতা ও সমস্যা পাওয়া যায় না।

• SUCCESS: কোনও সমস্যা ছাড়াই ডেস্টিনেশনের জন্য অনুরোধ প্রসেস করার কাজ সম্পূর্ণ হয়েছে। প্রসেস করার সময় ফ্ল্যাগ করা সতর্কতা চেক করুন।

• FAILURE: সমস্যার কারণে গন্তব্যের সব রেকর্ড ব্যর্থ হয়েছে। কেন সব রেকর্ড ফেল করেছে তা নির্ধারণ করতে সতর্কতা ও সমস্যা চেক করুন। এছাড়াও, প্রসেস করার সময় ফ্ল্যাগ করা সতর্কতা চেক করুন।

• PARTIAL_SUCCESS: গন্তব্যের জন্য কিছু রেকর্ড সফল হয়েছে, কিন্তু সমস্যার কারণে অন্যান্য রেকর্ড সফল হয়নি। কিছু রেকর্ড কেন ব্যর্থ হয়েছে তা নির্ধারণ করতে ত্রুটিগুলি পরীক্ষা করুন। এছাড়াও, প্রসেস করার সময় ফ্ল্যাগ করা সতর্কতা চেক করুন।

প্রতিটি গন্তব্য অনুযায়ী ইভেন্ট বা অডিয়েন্স স্ট্যাটাস চেক করুন

ইনজেশন অনুরোধের ধরনের সাথে সম্পর্কিত স্ট্যাটাস ফিল্ডটি ভাল করে দেখুন। প্রতিটি RequestStatusPerDestination-এ নিম্নলিখিত ফিল্ডের মধ্যে শুধুমাত্র একটি সেট করা আছে:

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

ইভেন্ট ইনজেশন স্ট্যাটাস

অনুরোধটি IngestEventsRequest হলে, events_ingestion_status ফিল্ডটি পূরণ করা হয়।

প্রাপ্ত মোট রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে IngestEventStatus-এর record_count চেক করুন। record_count-এ সফল ও ব্যর্থ, দুই ধরনের রেকর্ডই অন্তর্ভুক্ত থাকে।

অডিয়েন্স মেম্বার ইনজেশন স্ট্যাটাস

অনুরোধটি IngestAudienceMembersRequest হলে, audience_members_ingestion_status ফিল্ডটি পূরণ করা হয়। এখানে IngestAudienceMembersStatus ফিল্ড দেওয়া হল যা প্রতিটি ধরনের দর্শক ডেটার জন্য চেক করতে হবে। এইসব ফিল্ডের মধ্যে শুধু একটি সেট করা আছে।

composite_data_ingestion_status

প্রাপ্ত রেকর্ডের মোট সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে, IngestCompositeDataStatus-এর record_count চেক করুন। record_count-এ সফল ও ব্যর্থ, দুই ধরনের রেকর্ডই অন্তর্ভুক্ত থাকে।

data_type_counts চেক করে দেখে নিন যে শনাক্তকারীর সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা। এই তালিকায় DataType-এর মাধ্যমে পাওয়া সব শনাক্তকারীর (যেমন ইমেল আইডি, ফোন নম্বর, আসল ঠিকানা এবং IP অ্যাড্রেস) ব্রেকডাউন দেওয়া আছে।

অনুরোধে পর্যাপ্ত সংখ্যক রেকর্ড থাকলে, upload_match_rate_range-এ অনুরোধে থাকা রেকর্ডের জন্য ম্যাচ রেট রেঞ্জ থাকে।

google_user_id_data_ingestion_status

প্রাপ্ত মোট রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে IngestGoogleUserIdDataStatus-এর record_count চেক করুন। record_count-এ সফল ও ব্যর্থ, দুই ধরনের রেকর্ডই অন্তর্ভুক্ত থাকে।

google_user_id_count চেক করে দেখে নিন যে আপনি যতগুলি Google ব্যবহারকারীর আইডি পেয়েছেন তা আপনার প্রত্যাশার সাথে মিলছে কিনা।

mobile_data_ingestion_status

প্রাপ্ত রেকর্ডের মোট সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে, IngestMobileDataStatus-এর record_count চেক করুন। record_count-এ সফল ও ব্যর্থ, দুটি রেকর্ডই অন্তর্ভুক্ত থাকে।

কতগুলি মোবাইল আইডি পাওয়া গেছে তা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে mobile_id_count চেক করুন।

pair_data_ingestion_status

মোট প্রাপ্ত রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে, IngestPairDataStatus-এর record_count চেক করুন। record_count সফল ও ব্যর্থ, দুটি রেকর্ডই অন্তর্ভুক্ত করে।

pair_id_count চেক করে দেখে নিন যে আপনি যতগুলি PAIR আইডি পেয়েছেন তা আপনার প্রত্যাশার সাথে মিলছে কিনা।

partner_provided_id_data_ingestion_status

মোট প্রাপ্ত রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে IngestPartnerProvidedIdDataStatus-এর record_count চেক করুন। record_count-এ সফল ও ব্যর্থ, দুই ধরনের রেকর্ডই অন্তর্ভুক্ত থাকে।

পার্টনারের দেওয়া আইডি আপনি যতগুলি পাবেন বলে আশা করেছিলেন, ততগুলিই পেয়েছেন কিনা তা কনফার্ম করতে partner_provided_id_count চেক করুন।

ppid_data_ingestion_status

মোট রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে IngestPpidDataStatus-এর record_count চেক করুন। record_count-এ সফল ও ব্যর্থ, দুই ধরনের রেকর্ডই অন্তর্ভুক্ত থাকে।

প্রাপ্ত PPID-এর সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে ppid_count চেক করুন।

user_data_ingestion_status

মোট রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে IngestUserDataStatus-এর record_count চেক করুন। record_count সফল ও ব্যর্থ, দুটি রেকর্ডই অন্তর্ভুক্ত করে।

user_identifier_count চেক করে দেখে নিন যে আপনি যতগুলি ইউজার আইডেন্টিফায়ার পেয়েছেন, তা আপনার প্রত্যাশার সাথে মিলছে কিনা।

অনুরোধে পর্যাপ্ত সংখ্যক রেকর্ড থাকলে, upload_match_rate_range-এ অনুরোধে থাকা রেকর্ডের জন্য ম্যাচ রেট রেঞ্জ থাকে।

user_id_data_ingestion_status

মোট রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে IngestUserIdDataStatus-এর record_count চেক করুন। record_count সফল ও ব্যর্থ, দুটি রেকর্ডই অন্তর্ভুক্ত করে।

কতগুলি ব্যবহারকারীর আইডি পাওয়া গেছে তা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে user_id_count চেক করুন।

অডিয়েন্স মেম্বারদের সরানোর স্ট্যাটাস

অনুরোধটি যদি একটি RemoveAudienceMembersRequest হয়, তাহলে audience_members_removal_status ফিল্ডটি পূরণ করা হয়। প্রতিটি ধরনের দর্শক ডেটা চেক করার জন্য RemoveAudienceMembersStatus ফিল্ড এখানে দেওয়া হল। এইসব ফিল্ডের মধ্যে শুধু একটি সেট করা আছে।

composite_data_removal_status

কম্পোজিট ডেটা সরানোর স্ট্যাটাস

google_user_id_data_removal_status

Google ব্যবহারকারীর আইডি ডেটা সরানোর স্ট্যাটাস

mobile_data_removal_status

মোবাইল ডেটা সরানোর স্ট্যাটাস।

pair_data_removal_status

PAIR ডেটা সরানোর স্ট্যাটাস।

partner_provided_id_data_removal_status

পার্টনারের দেওয়া আইডি ডেটা সরানোর স্ট্যাটাস

ppid_data_removal_status

PPID ডেটা সরানোর স্ট্যাটাস।

user_data_removal_status

ব্যবহারকারীর ডেটা সরানোর স্ট্যাটাস।

user_id_data_removal_status

ব্যবহারকারীর আইডি ডেটা সরানোর স্ট্যাটাস

মোট যতগুলি রেকর্ড পাওয়া গেছে তা আপনার প্রত্যাশার সাথে মিলছে কিনা তা কনফার্ম করতে record_count চেক করুন। record_count-এ সফল ও ব্যর্থ উভয় রেকর্ডই অন্তর্ভুক্ত।

এছাড়াও, প্রাপ্ত শনাক্তকারীর মোট সংখ্যা কনফার্ম করতে user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count বা partner_provided_id_count চেক করুন।

কম্পোজিট ডেটার ক্ষেত্রে, শনাক্তকারীর সংখ্যা আপনার প্রত্যাশা মতো হয়েছে কিনা তা কনফার্ম করতে data_type_counts চেক করুন। DataType-এর পাওয়া সব পরিচয়সূচক (যেমন, ইমেল আইডি, ফোন নম্বর, আসল ঠিকানা এবং IP অ্যাড্রেস) এই তালিকায় ভেঙে দেখানো হয়েছে।

সতর্কতা ও সমস্যা চেক করা

গন্তব্য ও অনুরোধের ধরনের স্ট্যাটাস ফিল্ড ছাড়াও, RetrieveRequestStatusResponse-এ অনুরোধের জন্য সতর্কতা ও সমস্যার ব্রেকডাউন থাকে।

• সমস্যা হলে বুঝতে হবে যে API রেকর্ডটি সম্পূর্ণভাবে প্রত্যাখ্যান করেছে।
• সতর্কতা দেখানোর অর্থ হল, API রেকর্ডটি বাতিল করেনি, তবে রেকর্ডের ডেটার কিছু অংশ এড়িয়ে গেছে।

যেমন, কোনও Event-এ এনক্রিপ্ট করা UserIdentifier ডেটা এবং AdIdentifiers যেমন gclid থাকলে এবং UserIdentifier ডেটা ডিক্রিপ্ট করা না গেলে, Data Manager API এখনও AdIdentifiers ব্যবহার করে রেকর্ড প্রসেস করে, কিন্তু সতর্কতা PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR দেখায়।

তবে, Event-এ AdIdentifiers না থাকলে এবং UserIdentifier ডেটা ডিক্রিপ্ট করা না গেলে, Data Manager API সম্পূর্ণ রেকর্ড বাতিল করে দেয় এবং PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR সমস্যার কথা জানায় কারণ সঠিক Event-এ ad_identifiers বা user_data-এর মধ্যে অন্তত একটি থাকতেই হবে।

এখানে এমন কিছু ফিল্ডের উত্তর দেওয়া হল যেখানে সতর্কতা ও সমস্যা সংক্রান্ত তথ্য রয়েছে। সামগ্রিক গন্তব্যের স্ট্যাটাস SUCCESS, PARTIAL_SUCCESS বা FAILURE-এ পৌঁছালে এইসব ফিল্ড অটো-ফিল হয়ে যায়।

warning_info

WarningInfo অবজেক্ট। এর warning_counts ফিল্ডে WarningCount অবজেক্টের একটি তালিকা থাকে। প্রতিটি WarningCount-এ সতর্কতার ধরন সহ একটি reason এবং সেই ধরনের সতর্কতা সহ রেকর্ডের সংখ্যা নির্দেশ করে এমন একটি record_count থাকে।

গন্তব্যের সামগ্রিক স্ট্যাটাস SUCCESS হলেও warning_info চেক করুন।

error_info

ErrorInfo অবজেক্ট। এর error_counts ফিল্ডে ErrorCount অবজেক্টের একটি তালিকা রয়েছে। প্রতিটি ErrorCount-এ একটি reason থাকে যেখানে সমস্যার ধরন উল্লেখ করা থাকে এবং একটি record_count থাকে যা সেই ধরনের সমস্যার কারণে ব্যর্থ হওয়া রেকর্ডের সংখ্যা নির্দেশ করে।