عیب‌یابی

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

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

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

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

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

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

    این مرحله را به‌طور دوره‌ای برای هر request_id تکرار کنید تا وضعیت مقصد برای هر مقصد به SUCCESS، PARTIAL_SUCCESS، یا FAILURE برسد. از الگوریتم عقب‌گرد نمایی برای انتظار بین هر درخواست استفاده کنید.

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

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

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

ارسال درخواست

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

صدور مجوز

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 ناموفق می‌شود.

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

به‌طور دوره‌ای 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 ‫۶۰٫۰ دقیقه
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 ‫۶۰٫۰ دقیقه آخرین درخواست قبل‌از حداکثر زمان کل ۲۴ ساعت

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

مرور پاسخ‌ها

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

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

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

به‌عنوان اولین گام، فیلد request_status را بررسی کنید تا مشخص شود آیا «میانای برنامه‌سازی کاربردی مدیر داده» پردازش داده‌های destination مربوط به RequestStatusPerDestination را تکمیل کرده است یا نه.

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

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

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

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

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

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

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

  • خطا نشان می‌دهد که میانای برنامه‌سازی کاربردی سابقه را کاملاً رد کرده است.
  • هشدار نشان می‌دهد که API گزارش را رد نکرده است، اما مجبور شده است بخش‌هایی از داده‌های گزارش را نادیده بگیرد.

برای مثال، اگر Event حاوی داده‌های UserIdentifier رمزگذاری‌شده و AdIdentifiers مثل gclid باشد، و UserIdentifier داده‌ها رمزگشایی نشود، «میانای برنامه‌سازی کاربردی مدیر داده» همچنان گزارش را بااستفاده از 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 است که نشان‌دهنده تعداد رکوردهایی است که آن نوع هشدار را داشته‌اند.

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

error_info

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