در اینجا گردش کار پیشنهادی برای تأیید سلامت رویداد و آپلودهای مخاطبان و شناسایی مشکلات مربوط به دادههای شما آمده است.
درخواستهایی برای ارسال رویدادها یا ارسال یا حذف اعضای مخاطب صادر کنید.
وضعیت کلی هر درخواست را بررسی کنید. یک درخواست موفق،
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
است که تعداد رکوردهایی را که به دلیل آن نوع خطا با شکست مواجه شدهاند، نشان میدهد.