কারণ নির্ণয়

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

  1. ইভেন্ট পাঠাতে অথবা দর্শক যুক্ত করতে বা অপসারণ করতে অনুরোধ জারি করুন।

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

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

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

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

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

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

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

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

অনুরোধ পাঠান

একটি RetrieveRequestStatusRequest জন্য একটিমাত্র request_id ভ্যালু প্রয়োজন। সফল ইনজেশন রিকোয়েস্ট থেকে সংগ্রহ করা প্রতিটি রিকোয়েস্ট আইডির জন্য আলাদা স্ট্যাটাস রিকোয়েস্ট পাঠান।

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

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

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

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

গ্রাফ

ভোটগ্রহণ কৌশল

ডেটা

প্রচেষ্টা ইনজেশন অনুরোধের পর থেকে সময় (ঘণ্টা:মিনিট) চেষ্টার আগে বিলম্ব নোট
১ ০০:৩০ ৩০.০ মিনিট প্রথমে স্ট্যাটাসের প্রাপ্যতা যাচাই করুন।
২ ০১:০৯ ৩৯.০ মিনিট
৩ ০১:৫৯ ৫০.৭ মিনিট
৪ ০২:৫৯ ৬০.০ মিনিট বিলম্বের সর্বোচ্চ সীমা এখন ১ ঘণ্টা।
৫ ০৩:৫৯ ৬০.০ মিনিট
৬ ০৪:৫৯ ৬০.০ মিনিট
৭ ০৫:৫৯ ৬০.০ মিনিট
৮ ০৬:৫৯ ৬০.০ মিনিট
৯ ০৭:৫৯ ৬০.০ মিনিট
১০ ০৮:৫৯ ৬০.০ মিনিট
১১ ০৯:৫৯ ৬০.০ মিনিট
১২ ১০:৫৯ ৬০.০ মিনিট
১৩ ১১:৫৯ ৬০.০ মিনিট ১২-ঘন্টার চিহ্ন
১৪ ১২:৫৯ ৬০.০ মিনিট
১৫ ১৩:৫৯ ৬০.০ মিনিট
১৬ ১৪:৫৯ ৬০.০ মিনিট
১৭ ১৫:৫৯ ৬০.০ মিনিট
১৮ ১৬:৫৯ ৬০.০ মিনিট
১৯ ১৭:৫৯ ৬০.০ মিনিট
২০ ১৮:৫৯ ৬০.০ মিনিট
২১ ১৯:৫৯ ৬০.০ মিনিট
২২ ২০:৫৯ ৬০.০ মিনিট
২৩ ২১:৫৯ ৬০.০ মিনিট
২৪ ২২:৫৯ ৬০.০ মিনিট
২৫ ২৩:৫৯ ৬০.০ মিনিট সর্বোচ্চ ২৪ ঘন্টা সময়সীমার আগে শেষ অনুরোধ।

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

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

একটি RetrieveRequestStatusResponse এর request_status_per_destination অংশে সংশ্লিষ্ট ইনজেশন রিকোয়েস্টের প্রতিটি ডেস্টিনেশনের জন্য একটি পৃথক এন্ট্রি থাকে।

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

সামগ্রিক গন্তব্যের অবস্থা পরীক্ষা করুন

প্রথম ধাপ হিসেবে, ` RequestStatusPerDestination এর destination জন্য ডেটা ম্যানেজার এপিআই ডেটা প্রসেসিং শেষ করেছে কিনা তা জানতে request_status ফিল্ডটি পরীক্ষা করুন।

request_status এর সম্ভাব্য মানগুলো হলো:

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

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

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

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

গন্তব্য অনুযায়ী ইভেন্ট বা দর্শকের অবস্থা যাচাই করুন

ইনজেশন অনুরোধের ধরনের সাথে সঙ্গতিপূর্ণ স্ট্যাটাস ফিল্ডটি পরীক্ষা করুন। প্রতিটি RequestStatusPerDestination এ নিম্নলিখিত ফিল্ডগুলির মধ্যে কেবল একটি সেট করা থাকে:

ইভেন্ট গ্রহণের অবস্থা

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

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

শ্রোতাদের গ্রহণের অবস্থা

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

user_data_ingestion_status

প্রাপ্ত মোট রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা নিশ্চিত করতে IngestUserDataStatus এর record_count পরীক্ষা করুন। record_count মধ্যে সফল এবং ব্যর্থ উভয় রেকর্ডই অন্তর্ভুক্ত থাকে।

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

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

mobile_data_ingestion_status

প্রাপ্ত মোট রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা নিশ্চিত করতে IngestMobileDataStatus এর record_count পরীক্ষা করুন। record_count মধ্যে সফল এবং ব্যর্থ উভয় রেকর্ডই অন্তর্ভুক্ত থাকে।

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

pair_data_ingestion_status

প্রাপ্ত মোট রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা নিশ্চিত করতে IngestPairDataStatus এর record_count পরীক্ষা করুন। record_count মধ্যে সফল এবং ব্যর্থ উভয় রেকর্ডই অন্তর্ভুক্ত থাকে।

প্রাপ্ত PAIR ID-এর সংখ্যা আপনার প্রত্যাশার সাথে মেলে কিনা তা নিশ্চিত করতে pair_id_count পরীক্ষা করুন।

ppid_data_ingestion_status

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

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

user_id_data_ingestion_status

প্রাপ্ত মোট রেকর্ডের সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা নিশ্চিত করতে IngestUserIdDataStatus এর record_count পরীক্ষা করুন। record_count মধ্যে সফল এবং ব্যর্থ উভয় রেকর্ডই অন্তর্ভুক্ত থাকে।

প্রাপ্ত ইউজার আইডির সংখ্যা আপনার প্রত্যাশার সাথে মেলে কিনা তা নিশ্চিত করতে user_id_count পরীক্ষা করুন।

composite_data_ingestion_status

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

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

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

দর্শক সদস্যদের অপসারণের অবস্থা

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

user_data_removal_status
ব্যবহারকারীর ডেটা অপসারণের অবস্থা।
mobile_data_removal_status
মোবাইল ডেটা অপসারণের অবস্থা।
pair_data_removal_status
PAIR ডেটার অপসারণের অবস্থা।
ppid_data_removal_status
PPID ডেটা অপসারণের অবস্থা।
user_id_data_removal_status
ব্যবহারকারী আইডি ডেটার অপসারণের অবস্থা
composite_data_removal_status
যৌগিক ডেটার জন্য অপসারণের অবস্থা

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

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

যৌগিক ডেটার ক্ষেত্রে, শনাক্তকারীর সংখ্যা আপনার প্রত্যাশার সাথে মিলছে কিনা তা নিশ্চিত করতে data_type_counts পরীক্ষা করুন। এই তালিকাটি DataType অনুযায়ী প্রাপ্ত সমস্ত শনাক্তকারীর (যেমন ইমেল ঠিকানা, ফোন নম্বর, ভৌতিক ঠিকানা এবং আইপি ঠিকানা) একটি বিশদ বিবরণ প্রদান করে।

সতর্কতা এবং ত্রুটিগুলি পরীক্ষা করুন

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

  • একটি ত্রুটি নির্দেশ করে যে এপিআই রেকর্ডটি সম্পূর্ণরূপে প্রত্যাখ্যান করেছে।
  • একটি সতর্কবার্তা নির্দেশ করে যে এপিআই রেকর্ডটি প্রত্যাখ্যান করেনি, কিন্তু রেকর্ডটির ডেটার কিছু অংশ উপেক্ষা করতে হয়েছে।

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

তবে, যদি Event AdIdentifiers না থাকে এবং UserIdentifier ডেটা ডিক্রিপ্ট করা না যায়, তাহলে ডেটা ম্যানেজার 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 থাকে।