بررسی وضعیت درخواست و عیب‌یابی

درخواست‌های ارسال رویدادها یا اعضای مخاطب به‌صورت ناهمگام پردازش می‌شوند. پاسخ موفقیت‌آمیز دریافت request_id را برمی‌گرداند و نشان می‌دهد که درخواست همه الزامات را برآورده کرده و برای پردازش پذیرفته شده است. بااین‌حال، این نشان نمی‌دهد که آیا سوابق موجود در درخواست باموفقیت پردازش شده‌اند یا نه.

از request_id برگردانده‌شده با RetrieveRequestStatus استفاده کنید تا وضعیت بارگذاری‌تان را بررسی کنید و عیب‌یابی‌ها را مرور کنید.

در اینجا گردش کار توصیه‌شده برای بررسی وضعیت درخواست‌هایتان و درستی‌سنجی سلامت رویداد و بارگذاری‌های مخاطبانتان آورده شده است:

  1. درخواست‌های ارسال رویداد یا ارسال یا برداشتن اعضای مخاطب را صادر کنید.

  2. وضعیت کلی هر درخواست انتقال را بررسی کنید. درخواست موفق Status با code برابر با 0 (مقدار enum‏ OK، پاسخ HTTP‏ 200 OK) دارد و IngestEventsResponse، IngestAudienceMembersResponse، یا RemoveAudienceMembersResponse برمی‌گرداند.

    اگر درخواستی ناموفق بود، درخواست را اصلاح کنید تا خطا برطرف شود و درخواست را دوباره ارسال کنید.

    اگر درخواست موفقیت‌آمیز بود، request_id پاسخ را ضبط کنید تا بتوانید از آن برای بررسی وضعیت پردازش در مرحله بعد استفاده کنید.

  3. ‫۳۰ دقیقه صبر کنید، سپس برای هر request_id موفق، درخواست RetrieveRequestStatus ارسال کنید.

    RetrieveRequestStatusRequest به یک مقدار request_id واحد نیاز دارد. برای هر شناسه درخواستی که از درخواست انتقال موفقیت‌آمیز دریافت کرده‌اید، یک درخواست وضعیت جداگانه ارسال کنید.

    این مرحله را به‌طور دوره‌ای برای هر request_id تکرار کنید تا وضعیت مقصد برای هر مقصد به SUCCESS، PARTIAL_SUCCESS، یا FAILED برسد. راهبرد نظرسنجی توصیه‌شده را دنبال کنید تا بین هر درخواست منتظر بمانید.

  4. هر RetrieveRequestStatusResponse را مرور کنید تا مطمئن شوید بارگذاری‌هایتان به‌درستی کار می‌کند و مشکلات داده‌هایتان را شناسایی کنید.

  5. مشکلات داده‌ها را اصلاح کنید.

  6. به مرحله ۱ برگردید و این کار را تکرار کنید تا همه مشکلات مربوط به بارگذاری‌هایتان را برطرف کنید.

بررسی وضعیت کلی مقصد

request_status_per_destination در RetrieveRequestStatusResponse حاوی ورودی جداگانه‌ای برای هر مقصد در درخواست جذب مربوطه است.

برای مثال، اگر IngestAudienceMembersRequest شما حاوی ۳ ورودی در فهرست destinations برای ارسال داده به ۳ مخاطب مختلف باشد، پاسخ وضعیت حاوی ۳ ورودی در request_status_per_destination (یک ورودی برای هر مخاطب) است.

فیلد request_status را در هریک از RequestStatusPerDestination بررسی کنید تا ببینید آیا Data Manager API پردازش داده‌ها را برای آن مقصد به‌پایان رسانده است یا نه.

مقادیر احتمالی request_status در اینجا آمده است:

  • PROCESSING: داده‌های مقصد هنوز درحال پردازش است. در این مرحله، هشدارها و خطاها برای مقصد پر نشده است. نظرسنجی را تا زمانی که وضعیت به حالت نهایی برسد ادامه دهید.

  • ‫SUCCESS: پردازش درخواست برای مقصد بدون هیچ خطایی تکمیل شد. هشدارهای پرچم‌گذاری‌شده درطول پردازش را بررسی کنید.

  • FAILED: همه سوابق مقصد به‌دلیل خطا ناموفق بود. هشدارها و خطاها را بررسی کنید تا مشخص شود چرا همه سوابق ناموفق بوده‌اند. همچنین هشدارهای پرچم‌گذاری‌شده درطول پردازش را بررسی کنید.

  • PARTIAL_SUCCESS: برخی‌از رکوردهای مقصد موفقیت‌آمیز بود، اما برخی دیگر به‌دلیل خطا ناموفق بود. خطاها را بررسی کنید تا دلیل ناموفق بودن برخی‌از سوابق را مشخص کنید. همچنین هشدارهای پرچم‌گذاری‌شده درطول پردازش را بررسی کنید.

مرور عیب‌یابی

وقتی request_status برای مقصدی به SUCCESS، FAILED، یا PARTIAL_SUCCESS رسید، تشخیص‌های دقیق را در پاسخ مرور کنید تا تعداد را درستی‌سنجی کنید و مشکلات را عیب‌یابی کنید.

بررسی وضعیت رویداد یا مخاطب براساس مقصد

فیلد وضعیت مربوط به نوع درخواست جذب را بررسی کنید. فقط یکی از فیلدهای زیر در هر RequestStatusPerDestination تنظیم شده است:

وضعیت انتقال داده رویدادها

اگر درخواست از نوع IngestEventsRequest باشد، فیلد events_ingestion_status پر می‌شود.

record_count مربوط به IngestEventStatus را بررسی کنید تا مطمئن شوید تعداد کل سوابق دریافتی با انتظارات شما مطابقت دارد. record_count شامل هر دو سابقه موفق و ناموفق است.

وضعیت دریافت اعضای مخاطب

اگر درخواست از نوع IngestAudienceMembersRequest باشد، فیلد audience_members_ingestion_status پر می‌شود. در اینجا فیلد IngestAudienceMembersStatus برای بررسی هر نوع داده مخاطب آورده شده است. فقط یکی از این فیلدها تنظیم شده است.

composite_data_ingestion_status

record_count IngestCompositeDataStatus را بررسی کنید تا مطمئن شوید که تعداد کل سوابق دریافتی با انتظارات شما مطابقت دارد. record_count شامل رکوردهای موفق و ناموفق است.

data_type_counts را بررسی کنید تا مطمئن شوید تعداد شناسه‌ها با انتظارات شما مطابقت دارد. این فهرست تفکیک همه شناسه‌های دریافتی (مانند نشانی ایمیل، شماره تلفن، نشانی فیزیکی، و نشانی IP) را توسط DataType ارائه می‌دهد.

اگر درخواست تعداد کافی سابقه داشته باشد، upload_match_rate_range حاوی محدوده نرخ مطابقت برای سوابق موجود در درخواست است.

google_user_id_data_ingestion_status

record_count IngestGoogleUserIdDataStatus را بررسی کنید تا مطمئن شوید تعداد کل سوابق دریافتی با انتظارات شما مطابقت دارد. record_count شامل رکوردهای موفق و ناموفق است.

google_user_id_count را بررسی کنید تا مطمئن شوید تعداد شناسه‌های کاربر Google دریافتی با انتظارات شما مطابقت دارد.

mobile_data_ingestion_status

record_count IngestMobileDataStatus را بررسی کنید تا مطمئن شوید که تعداد کل سوابق دریافتی با انتظارات شما مطابقت دارد. record_count شامل رکوردهای موفق و ناموفق است.

mobile_id_count را بررسی کنید تا مطمئن شوید تعداد شناسه‌های تلفن همراه دریافتی با انتظارات شما مطابقت دارد.

pair_data_ingestion_status

record_count IngestPairDataStatus را بررسی کنید تا مطمئن شوید تعداد کل سوابق دریافتی با انتظارات شما مطابقت دارد. record_count شامل سوابق موفق و ناموفق است.

pair_id_count را بررسی کنید تا مطمئن شوید تعداد شناسه‌های PAIR دریافتی با انتظارات شما مطابقت دارد.

partner_provided_id_data_ingestion_status

record_count IngestPartnerProvidedIdDataStatus را بررسی کنید تا مطمئن شوید تعداد کل سوابق دریافتی با انتظارات شما مطابقت دارد. record_count شامل سوابق موفق و ناموفق است.

partner_provided_id_count را بررسی کنید تا مطمئن شوید تعداد شناسه‌های ارائه‌شده توسط شریک که دریافت شده است با انتظارات شما مطابقت دارد.

ppid_data_ingestion_status

record_count IngestPpidDataStatus را بررسی کنید تا مطمئن شوید تعداد کل سوابق دریافتی با انتظارات شما مطابقت دارد. record_count شامل سوابق موفق و ناموفق است.

ppid_count را بررسی کنید تا مطمئن شوید تعداد PPIDهای دریافتی با انتظارات شما مطابقت دارد.

user_data_ingestion_status

record_count IngestUserDataStatus را بررسی کنید تا مطمئن شوید تعداد کل سوابق دریافتی با انتظارات شما مطابقت دارد. record_count شامل سوابق موفق و ناموفق است.

user_identifier_count را بررسی کنید تا مطمئن شوید تعداد شناسه‌های کاربر دریافتی با انتظارات شما مطابقت دارد.

اگر درخواست تعداد کافی سابقه داشته باشد، upload_match_rate_range حاوی محدوده نرخ مطابقت برای سوابق موجود در درخواست است.

user_id_data_ingestion_status

record_count IngestUserIdDataStatus را بررسی کنید تا مطمئن شوید تعداد کل سوابق دریافتی با انتظارات شما مطابقت دارد. 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
وضعیت برداشتن داده‌های شناسه شخصی.
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 را بررسی کنید تا مطمئن شوید تعداد شناسه‌ها با انتظارات شما مطابقت دارد. این فهرست تفکیک همه شناسه‌های دریافتی (مانند نشانی ایمیل، شماره تلفن، نشانی فیزیکی، و نشانی IP) را براساس DataType ارائه می‌دهد.

بررسی هشدارها و خطاها

علاوه‌بر فیلدهای وضعیت برای مقصد و نوع درخواست، 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، یا FAILED می‌رسد، این فیلدها پر می‌شوند.

warning_info

شیء WarningInfo. فیلد warning_counts آن حاوی فهرستی از اشیای WarningCount است. هر WarningCount حاوی یک reason با نوع هشدار، و یک record_count است که نشان‌دهنده تعداد رکوردهایی است که آن نوع هشدار را داشته‌اند.

warning_info را بررسی کنید، حتی اگر وضعیت کلی مقصد SUCCESS باشد.

error_info

شیء ErrorInfo. فیلد error_counts آن حاوی فهرستی از اشیاء ErrorCount است. هر ErrorCount حاوی یک reason با نوع خطا، و یک record_count است که تعداد ردیف‌هایی را نشان می‌دهد که به‌دلیل آن نوع خطا ناموفق بوده‌اند.

راهبرد نظرسنجی

به‌طور دوره‌ای RetrieveRequestStatusRequest را بااستفاده از الگوریتم عقب‌گرد نمایی ارسال کنید تا request_status برای هر مقصد در درخواست اصلی به SUCCESS، FAILED، یا 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 ‫۶۰٫۰ دقیقه
17 15:59 ‫۶۰٫۰ دقیقه
18 16:59 ‫۶۰٫۰ دقیقه
19 17:59 ‫۶۰٫۰ دقیقه
20 18:59 ‫۶۰٫۰ دقیقه
21 19:59 ‫۶۰٫۰ دقیقه
22 20:59 ‫۶۰٫۰ دقیقه
23 21:59 ‫۶۰٫۰ دقیقه
24 22:59 ‫۶۰٫۰ دقیقه
25 23:59 ‫۶۰٫۰ دقیقه آخرین درخواست قبل‌از حداکثر زمان کل ۲۴ ساعت

مقدار تصادفی کوچکی از لرزش به تأخیرهای عقب‌نشینی اضافه کنید تا از مشکل «گله رعدآسا» که در آن بسیاری از مشتریان به‌طور هم‌زمان دوباره امتحان می‌کنند، جلوگیری شود.

الزامات صدور مجوز

RetrieveRequestStatusRequest حساب‌های مقصد یا سرایندهای درخواست را نمی‌پذیرد. درعوض، Data Manager API مقصدهای درخواست دریافت اصلی مرتبط با request_id را شناسایی می‌کند و تأیید می‌کند که تماس‌گیرنده به operating_account در هر Destination دسترسی دارد.

برای بررسی وضعیت درخواست، اطلاعات اعتباری استفاده‌شده در 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 ناموفق می‌شود.

قبلی
رمزگذاری داده‌های کاربر
بعدی
آشنایی با خطاهای میانای برنامه‌سازی کاربردی