بيانات التشخيص

في ما يلي سير العمل المقترَح للتحقّق من صحة عمليات تحميل الأحداث وشرائح الجمهور وتحديد المشاكل في بياناتك.

  1. إصدار طلبات لإرسال الأحداث أو إرسال أو إزالة أفراد الجمهور

  2. الاطّلاع على الحالة العامة لكل طلب يتضمّن الطلب الناجح Status مع code يساوي 0 (قيمة التعداد OK، استجابة HTTP 200 OK)، ويعرض IngestEventsResponse أو IngestAudienceMembersResponse أو RemoveAudienceMembersResponse.

    إذا لم يتم تنفيذ الطلب بنجاح، عدِّل الطلب لمعالجة الخطأ وأرسِل الطلب مرة أخرى.

    إذا نجح الطلب، سجِّل request_id الرد حتى تتمكّن من استخدامه لاسترداد بيانات التشخيص في الخطوة التالية.

  3. أرسِل طلب RetrieveRequestStatus لكل request_id ناجح.

  4. راجِع كل RetrieveRequestStatusResponse للتأكّد من أنّ عمليات التحميل تعمل بشكل سليم وتحديد أي مشاكل في بياناتك.

  5. تصحيح المشاكل المتعلّقة بالبيانات

  6. ارجع إلى الخطوة 1 وكرِّرها إلى أن تحلّ جميع المشاكل المتعلّقة بعمليات التحميل.

إنشاء الطلبات

يحتوي RetrieveRequestStatusRequest على حقل request_id واحد. أرسِل طلبًا واحدًا لكل معرّف طلب ناجح تم تسجيله عند إرسال طلبات الاستيعاب.

مراجعة الردود

يحتوي request_status_per_destination في RetrieveRequestStatusResponse على إدخال منفصل لكل وجهة في طلب الاستيعاب ذي الصلة.

على سبيل المثال، إذا كان IngestAudienceMembersRequest يحتوي على 3 إدخالات في قائمة destinations لإرسال البيانات إلى 3 شرائح جمهور مختلفة، سيتضمّن ردّ الحالة 3 إدخالات في request_status_per_destination (إدخال واحد لكل شريحة جمهور).

التحقّق من الحالة العامة للوجهة

كخطوة أولى، تحقَّق من الحقل request_status لتحديد ما إذا كانت واجهة برمجة التطبيقات "إدارة بيانات إعلانات Google" قد انتهت من معالجة البيانات الخاصة بـ 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_countIngestUserDataStatus للتأكّد من أنّ إجمالي عدد السجلات التي تم تلقّيها يتطابق مع توقعاتك. يتضمّن 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_countIngestPairDataStatus للتأكّد من أنّ إجمالي عدد السجلات التي تم تلقّيها يتطابق مع توقعاتك. يتضمّن record_count السجلات الناجحة والمتعذّرة.

تحقَّق من pair_id_count للتأكّد من أنّ عدد أرقام تعريف PAIR التي تم تلقّيها يتوافق مع توقعاتك.

حالة إزالة أعضاء الجمهور

يتم ملء الحقل audience_members_removal_status إذا كان الطلب RemoveAudienceMembersRequest. في ما يلي حقل RemoveAudienceMembersStatus الذي يجب التحقّق منه لكل نوع من بيانات الجمهور. يتم ضبط حقل واحد فقط من هذه الحقول.

user_data_removal_status
حالة الإزالة لبيانات المستخدم
mobile_data_removal_status
حالة الإزالة لبيانات الجوّال
pair_data_removal_status
حالة الإزالة لبيانات PAIR

تحقَّق من record_count للتأكّد من أنّ إجمالي عدد السجلات التي تم تلقّيها يتطابق مع توقعاتك. يتضمّن record_count السجلات الناجحة والمتعذّرة.

بالإضافة إلى ذلك، راجِع user_identifier_count أو mobile_id_count أو pair_id_count للتأكّد من إجمالي عدد معرّفات المستخدمين أو معرّفات الأجهزة الجوّالة أو معرّفات PAIR التي تم تلقّيها.

التحقّق من التحذيرات والأخطاء

بالإضافة إلى حقول الحالة الخاصة بنوع الوجهة والطلب، يحتوي RetrieveRequestStatusResponse على تفاصيل حول التحذيرات والأخطاء المتعلّقة بالطلب.

  • يشير الخطأ إلى أنّ واجهة برمجة التطبيقات رفضت السجلّ بالكامل.
  • يشير التحذير إلى أنّ واجهة برمجة التطبيقات لم ترفض السجلّ، ولكن كان عليها تجاهل أجزاء من بيانات السجلّ.

على سبيل المثال، إذا كان 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 يشير إلى عدد السجلات التي تعذّر نقلها بسبب هذا النوع من الخطأ.