در اینجا گردش کار پیشنهادی برای تأیید سلامت رویداد و آپلودهای مخاطبان و شناسایی مشکلات مربوط به دادههای شما آمده است.
درخواستهایی برای ارسال رویدادها یا ارسال یا حذف اعضای مخاطب صادر کنید.
وضعیت کلی هر درخواست را بررسی کنید. یک درخواست موفق،
Statusباcodeبرابر با0دارد (مقدار شمارشیOK، پاسخ HTTP200 OK) و یکی از گزینههایIngestEventsResponse،IngestAudienceMembersResponseیاRemoveAudienceMembersResponseبرمیگرداند.اگر درخواستی موفقیتآمیز نبود، درخواست را اصلاح کنید تا خطا برطرف شود و دوباره درخواست را ارسال کنید.
اگر درخواستی با موفقیت انجام شد،
request_idپاسخ را ثبت کنید تا بتوانید در مرحله بعدی از آن برای بازیابی عیبیابی استفاده کنید.برای هر
request_idموفق، یک درخواستRetrieveRequestStatusارسال کن.هر
RetrieveRequestStatusResponseرا بررسی کنید تا تأیید کنید که آپلودهای شما به درستی کار میکنند و هرگونه مشکلی را در مورد دادههای خود شناسایی کنید.مشکلات مربوط به دادهها را اصلاح کنید.
به مرحله ۱ برگردید و تا زمانی که تمام مشکلات مربوط به آپلودهایتان را برطرف نکردهاید، تکرار کنید.
درخواستهای ساخت
یک RetrieveRequestStatusRequest یک فیلد request_id دارد. برای هر شناسه درخواست موفقی که هنگام ارسال درخواستهای مصرف (ingestion request) دریافت کردهاید، یک درخواست ارسال کنید.
پاسخها را مرور کنید
تابع 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را بررسی کنید.
وضعیت حذف اعضای مخاطب
فیلد audience_members_removal_status در صورتی پر میشود که درخواست از نوع RemoveAudienceMembersRequest باشد. در اینجا فیلد RemoveAudienceMembersStatus برای بررسی هر نوع داده مخاطب وجود دارد. فقط یکی از این فیلدها تنظیم شده است.
-
user_data_removal_status - وضعیت حذف دادههای کاربر
-
mobile_data_removal_status - وضعیت حذف داده تلفن همراه .
-
pair_data_removal_status - وضعیت حذف برای دادههای PAIR
برای اطمینان از اینکه تعداد کل رکوردهای دریافتی با انتظارات شما مطابقت دارد، record_count بررسی کنید. record_count شامل رکوردهای موفق و ناموفق میشود.
علاوه بر این، برای تأیید تعداد کل شناسههای کاربر، شناسههای تلفن همراه یا شناسههای PAIR دریافتی، user_identifier_count ، mobile_id_count یا pair_id_count را بررسی کنید.
بررسی هشدارها و خطاها
علاوه بر فیلدهای وضعیت برای مقصد و نوع درخواست، 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 داشته باشد.
در اینجا فیلدهای پاسخی که حاوی اطلاعات هشدار و خطا هستند، آمده است.
-
warning_info - لیستی از اشیاء
WarningCount. هرWarningCountشامل یکreasonبا نوع هشدار و یکrecord_countاست که تعداد رکوردهایی را که هشدارهایی از آن نوع داشتهاند، نشان میدهد. -
error_info - لیستی از اشیاء
ErrorCount. هرErrorCountشامل یکreasonبه همراه نوع خطا و یکrecord_countاست که تعداد رکوردهایی را که به دلیل آن نوع خطا با شکست مواجه شدهاند، نشان میدهد.