অনুরোধের স্ট্যাটাস ও ডায়াগনস্টিক চেক করা

ইভেন্ট বা অডিয়েন্স মেম্বারদের পাঠানোর অনুরোধ অ্যাসিঙ্ক্রোনাসভাবে প্রসেস করা হয়। ইনজেশন সংক্রান্ত অনুরোধ সফল হলে request_id রিটার্ন করে এবং এটি বোঝায় যে অনুরোধটি সব প্রয়োজনীয়তা পূরণ করেছে এবং প্রসেস করার জন্য গ্রহণ করা হয়েছে। তবে, অনুরোধে থাকা রেকর্ডগুলি সফলভাবে প্রসেস করা হয়েছে কিনা তা এটি নির্দেশ করে না।

আপনার আপলোডের স্ট্যাটাস চেক করতে এবং ডায়াগনস্টিক পর্যালোচনা করতে RetrieveRequestStatus-এর সাথে ফেরত আসা request_id ব্যবহার করুন।

আপনার অনুরোধের স্ট্যাটাস চেক করা এবং আপনার ইভেন্ট ও অডিয়েন্স আপলোডের স্বাস্থ্য যাচাই করার জন্য এখানে সাজেস্ট করা ওয়ার্কফ্লো দেওয়া হল:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

প্রতিটি RequestStatusPerDestination-এর request_status ফিল্ড চেক করে দেখুন যে ডেটা ম্যানেজার API সেই ডেস্টিনেশনের জন্য ডেটা প্রসেস করা শেষ করেছে কিনা।

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

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

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

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

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

ডায়াগনস্টিকস পর্যালোচনা করুন

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

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

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

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

অনুমোদন সংক্রান্ত প্রয়োজনীয়তা

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 সমস্যার কারণে ব্যর্থ হয়।