عیب‌یابی

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

  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 برای هر مقصد در درخواست اصلی برسد. این کار ممکن است تا ۲۴ ساعت طول بکشد، هرچند «میانای برنامه‌سازی کاربردی مدیر داده» ممکن است پردازش برخی‌از درخواست‌ها را در کمتر از ۳۰ دقیقه تکمیل کند.

در اینجا نمونه‌ای از زمان انتظار اولیه معقول و پیکربندی تلاش مجدد ارائه شده است که بین فعال بودن و استفاده از سهمیه تعادل برقرار می‌کند:

تنظیم مقدار
زمان انتظار قبل‌از اولین درخواست تشخیص خرابی (دقیقه) 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 را بررسی کنید تا مطمئن شوید تعداد «شناسه‌های ارائه‌دهنده خدمات پرداخت» دریافتی با انتظارات شما مطابقت دارد.

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 به‌طور کامل گزارش را رد کرده است.
  • هشدار نشان می‌دهد که API گزارش را رد نکرده است، اما مجبور شده است بخش‌هایی از داده‌های گزارش را نادیده بگیرد.

برای مثال، اگر Event حاوی داده‌های UserIdentifier رمزگذاری‌شده و AdIdentifiers مثل gclid باشد، و UserIdentifier داده‌ها رمزگشایی نشود، «میانای برنامه‌سازی کاربردی مدیر داده» همچنان گزارش را بااستفاده از AdIdentifiers پردازش می‌کند اما هشدار PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR را برمی‌گرداند.

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