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

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

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 ভ্যালু প্রয়োজন। সফল ইনজেশন অনুরোধ থেকে ক্যাপচার করা প্রতিটি অনুরোধ আইডির জন্য আলাদা স্ট্যাটাস অনুরোধ পাঠান।

অনুমোদন

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 (২৪ ঘণ্টা)

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

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

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

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 থাকে যা সেই ধরনের সমস্যার কারণে ব্যর্থ হওয়া রেকর্ডের সংখ্যা নির্দেশ করে।