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

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

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 এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম ব্যবহার করে মাঝে মাঝে পাঠান যতক্ষণ না মূল অনুরোধের প্রতিটি গন্তব্যের জন্য request_status পৌঁছে SUCCESS, FAILURE বা PARTIAL_SUCCESS যায়। এতে সর্বাধিক ২৪ ঘণ্টা সময় লাগতে পারে, যদিও Data Manager API হয়ত ৩০ মিনিটের মধ্যেই কিছু অনুরোধ প্রসেস করা সম্পূর্ণ করে ফেলবে।

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

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

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

গ্রাফ

ডেটা

চেষ্টা	ইনজেশন অনুরোধের পর থেকে সময় (ঘণ্টা:মিনিট)	চেষ্টা করার আগে বিলম্ব	নোট
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	৬০.০ মিনিট	২৪ ঘণ্টার সর্বাধিক মোট সময়ের আগে শেষ অনুরোধ

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

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

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

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

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

প্রথম ধাপ হিসেবে, request_status ফিল্ড চেক করে দেখুন যে RequestStatusPerDestination-এর destination-এর জন্য Data Manager 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 ব্যবহারকারী আইডির সংখ্যা মিলেছে কিনা তা নিশ্চিত করতে google_user_id_count চেক করুন ।

mobile_data_ingestion_status

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

আপনার প্রত্যাশা অনুযায়ী প্রাপ্ত মোবাইল আইডির সংখ্যা ঠিক আছে কিনা তা নিশ্চিত করতে mobile_id_count চেক করুন।

pair_data_ingestion_status

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

আপনি যতগুলি PAIR আইডি পাওয়ার আশা করেছিলেন, ততগুলি পেয়েছেন কিনা তা নিশ্চিত করতে pair_id_count চেক করুন।

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_count চেক করে নিশ্চিত করুন যে প্রাপ্ত PPID-এর সংখ্যা আপনার প্রত্যাশার সাথে মিলছে।

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

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

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

error_info

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