تشخیص

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

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

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

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

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

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

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

  4. هر RetrieveRequestStatusResponse را بررسی کنید تا تأیید کنید که آپلودهای شما به درستی کار می‌کنند و هرگونه مشکلی را در مورد داده‌های خود شناسایی کنید.

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

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

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

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

به صورت دوره‌ای، درخواست بازیابی RetrieveRequestStatusRequest را با استفاده از یک الگوریتم بازگشت نمایی ارسال کنید تا زمانی که request_status برای هر مقصد در درخواست اصلی به SUCCESS ، FAILURE یا PARTIAL_SUCCESS برسد. این ممکن است تا ۲۴ ساعت طول بکشد، اگرچه API مدیریت داده (Data Manager API) ممکن است پردازش برخی از درخواست‌ها را در کمتر از ۳۰ دقیقه به پایان برساند.

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

تنظیم ارزش
زمان انتظار قبل از اولین درخواست تشخیص (دقیقه) 30
ضریب برگشت 1.3
حداکثر زمان برگشت (دقیقه) 60 (۱ ساعت)
حداکثر زمان کل (دقیقه) 1440 (۲۴ ساعت)

در اینجا توالی درخواست‌ها و زمان سپری‌شده با این پیکربندی آمده است:

نمودار

استراتژی نظرسنجی

داده‌ها

تلاش زمان سپری شده از درخواست مصرف (ساعت:میلی‌متر) تأخیر قبل از تلاش یادداشت‌ها
۱ ۰۰:۳۰ ۳۰.۰ دقیقه ابتدا وضعیت در دسترس بودن را بررسی کنید
۲ ۰۱:۰۹ ۳۹.۰ دقیقه
۳ ۰۱:۵۹ ۵۰.۷ دقیقه
۴ ۰۲:۵۹ ۶۰.۰ دقیقه اکنون حداکثر زمان تأخیر ۱ ساعت است
۵ ۰۳:۵۹ ۶۰.۰ دقیقه
۶ ۰۴:۵۹ ۶۰.۰ دقیقه
۷ ۰۵:۵۹ ۶۰.۰ دقیقه
۸ ۰۶:۵۹ ۶۰.۰ دقیقه
۹ ۰۷:۵۹ ۶۰.۰ دقیقه
۱۰ ۰۸:۵۹ ۶۰.۰ دقیقه
۱۱ ۰۹:۵۹ ۶۰.۰ دقیقه
۱۲ ۱۰:۵۹ ۶۰.۰ دقیقه
۱۳ ۱۱:۵۹ ۶۰.۰ دقیقه علامت ۱۲ ساعته
۱۴ ۱۲:۵۹ ۶۰.۰ دقیقه
۱۵ ۱۳:۵۹ ۶۰.۰ دقیقه
۱۶ ۱۴:۵۹ ۶۰.۰ دقیقه
۱۷ ۱۵:۵۹ ۶۰.۰ دقیقه
۱۸ ۱۶:۵۹ ۶۰.۰ دقیقه
۱۹ ۱۷:۵۹ ۶۰.۰ دقیقه
۲۰ ۱۸:۵۹ ۶۰.۰ دقیقه
۲۱ ۱۹:۵۹ ۶۰.۰ دقیقه
۲۲ ۲۰:۵۹ ۶۰.۰ دقیقه
۲۳ ۲۱:۵۹ ۶۰.۰ دقیقه
۲۴ ۲۲:۵۹ ۶۰.۰ دقیقه
۲۵ ۲۳:۵۹ ۶۰.۰ دقیقه آخرین درخواست قبل از حداکثر زمان کل ۲۴ ساعته

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

پاسخ‌ها را مرور کنید

تابع request_status_per_destination در یک RetrieveRequestStatusResponse شامل یک ورودی جداگانه برای هر مقصد در درخواست مصرف مربوطه است.

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

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

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

مقادیر ممکن برای request_status شرح زیر است:

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

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

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

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

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

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

وضعیت دریافت رویدادها

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

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

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

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

user_data_ingestion_status

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

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

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

mobile_data_ingestion_status

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

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

pair_data_ingestion_status

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

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

ppid_data_ingestion_status

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

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

user_id_data_ingestion_status

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

برای اطمینان از اینکه تعداد شناسه‌های کاربری دریافتی با انتظارات شما مطابقت دارد، user_id_count را بررسی کنید.

وضعیت حذف اعضای مخاطب

فیلد audience_members_removal_status در صورتی پر می‌شود که درخواست از نوع RemoveAudienceMembersRequest باشد. در اینجا فیلد RemoveAudienceMembersStatus برای بررسی هر نوع داده مخاطب وجود دارد. فقط یکی از این فیلدها تنظیم شده است.

user_data_removal_status
وضعیت حذف داده‌های کاربر
mobile_data_removal_status
وضعیت حذف داده تلفن همراه .
pair_data_removal_status
وضعیت حذف برای داده‌های PAIR
ppid_data_removal_status
وضعیت حذف برای داده‌های PPID
user_id_data_removal_status
وضعیت حذف برای داده‌های شناسه کاربری

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

علاوه بر این، برای تأیید تعداد کل شناسه‌های کاربر، شناسه‌های تلفن همراه یا شناسه‌های PAIR دریافتی user_identifier_count ، mobile_id_count یا pair_id_count را بررسی کنید.

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

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

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

برای مثال، اگر یک Event برای تبدیل آفلاین تبلیغات گوگل شامل داده‌های رمزگذاری‌شده‌ی UserIdentifier و AdIdentifiers مانند gclid باشد و داده‌های UserIdentifier قابل رمزگشایی نباشند، رابط برنامه‌نویسی کاربردی (API) مدیریت داده همچنان رکورد را با استفاده از AdIdentifiers پردازش می‌کند اما هشدار PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR را برمی‌گرداند.

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