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

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

1. أرسِل طلبات لإرسال الأحداث أو إرسال أعضاء الجمهور أو إزالتهم.

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

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

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

3. انتظِر لمدة 30 دقيقة، ثم أرسِل طلب RetrieveRequestStatus لكل ناجح request_id.

   كرِّر هذه الخطوة بشكل دوري لكل request_id إلى أن تصل حالة الوجهة لكل وجهة إلى SUCCESS أو PARTIAL_SUCCESS أو FAILURE. استخدِم خوارزمية الرقود الأسي الثنائي للانتظار بين كل طلب.

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

5. أصلِح مشاكل البيانات.

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

أرسِل الطلبات

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

أرسِل RetrieveRequestStatusRequest بشكل دوري باستخدام خوارزمية الرقود الأسي الثنائي إلى أن تصل request_status إلى SUCCESS أو FAILURE أو PARTIAL_SUCCESS لكل وجهة في الطلب الأصلي. قد يستغرق ذلك ما يصل إلى 24 ساعة، على الرغم من أنّ واجهة برمجة تطبيقات Data Manager API قد تُنهي معالجة بعض الطلبات في مدة قصيرة لا تتجاوز 30 دقيقة.

في ما يلي مثال على وقت انتظار أولي معقول وإعدادات إعادة المحاولة التي تحقّق التوازن بين النشاط واستخدام الحصص:

الإعداد	القيمة
وقت الانتظار قبل أول طلب لبيانات التشخيص (بالدقائق)	30
مُضاعِف الرقود	1.3
الحد الأقصى للرقود (بالدقائق)	60 (ساعة واحدة)
الحد الأقصى للوقت الإجمالي (بالدقائق)	1440 (24 ساعة)

في ما يلي تسلسل الطلبات والوقت المنقضي باستخدام هذه الإعدادات:

أضِف مقدارًا صغيرًا عشوائيًا من التذبذب إلى حالات التأخير في الرقود لمنع مشكلة "القطيع الصاخب" حيث يعيد العديد من العملاء المحاولة في الوقت نفسه.

مراجعة الإجابات

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

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

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

كخطوة أولى، تحقَّق من الحقل request_status لتحديد ما إذا كانت واجهة برمجة تطبيقات "إدارة البيانات" قد انتهت من معالجة البيانات الخاصة بـ destination في RequestStatusPerDestination.

في ما يلي القيم المحتمَلة لـ request_status:

• PROCESSING: لا تزال تتم معالجة البيانات الخاصة بالوجهة. لا يتم ملء التحذيرات والأخطاء للوجهة في هذه المرحلة.

• SUCCESS: اكتملت معالجة الطلب للوجهة بدون أي أخطاء. تحقَّق من التحذيرات التي تم وضع علامة عليها أثناء المعالجة.

• FAILURE: تعذّرت جميع السجلات الخاصة بالوجهة بسبب حدوث أخطاء. تحقَّق من التحذيرات والأخطاء لتحديد سبب تعذُّر جميع السجلات. تحقَّق أيضًا من التحذيرات التي تم وضع علامة عليها أثناء المعالجة.

• PARTIAL_SUCCESS: نجحت بعض السجلات الخاصة بالوجهة، ولكن تعذّرت سجلات أخرى بسبب حدوث أخطاء. تحقَّق من الأخطاء لتحديد سبب تعذُّر بعض السجلات. تحقَّق أيضًا من التحذيرات التي تم وضع علامة عليها أثناء المعالجة.

التحقّق من حالة الحدث أو الجمهور لكل وجهة

افحص حقل الحالة الذي يتطابق مع نوع طلب العرض. يتم ضبط حقل واحد فقط من الحقول التالية في كل RequestStatusPerDestination:

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

حالة عرض الأحداث

يتم ملء الحقل 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_count للتأكّد من أنّ عدد معرّفات PAIR المستلَمة يتطابق مع توقعاتك.

ppid_data_ingestion_status

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

تحقَّق من ppid_count للتأكّد من أنّ عدد معرّفات PPID المستلَمة يتطابق مع توقعاتك.

user_id_data_ingestion_status

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

تحقَّق من user_id_count للتأكّد من أنّ عدد معرّفات المستخدمين المستلَمة يتطابق مع توقعاتك.

composite_data_ingestion_status

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

تحقَّق من data_type_counts للتأكّد من أنّ عدد معرّفات المستخدمين يتطابق مع توقعاتك. تقدّم هذه القائمة تفصيلاً لجميع معرّفات المستخدمين المستلَمة (مثل عنوان البريد الإلكتروني ورقم الهاتف والعنوان الجغرافي وعنوان IP) حسب DataType.

إذا كان الطلب يحتوي على عدد كافٍ من السجلات، يتضمّن upload_match_rate_range نطاق معدّل المطابقة للسجلات في الطلب.

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

يتم ملء الحقل 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

حالة إزالة بيانات معرّف المستخدم

composite_data_removal_status

حالة إزالة البيانات المركّبة

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

بالإضافة إلى ذلك، تحقَّق من user_identifier_count أو mobile_id_count أو pair_id_count أو ppid_count أو user_id_count للتأكّد من العدد الإجمالي لمعرّفات المستخدمين المستلَمة.

بالنسبة إلى البيانات المركّبة، تحقَّق من data_type_counts للتأكّد من أنّ عدد معرّفات المستخدمين يتطابق مع توقعاتك. تقدّم هذه القائمة تفصيلاً لجميع معرّفات المستخدمين المستلَمة (مثل عنوان البريد الإلكتروني ورقم الهاتف والعنوان الجغرافي وعنوان IP) حسب DataType.

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

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

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

على سبيل المثال، إذا كان Event يحتوي على بيانات مشفّرة UserIdentifier و AdIdentifiers مثل gclid، ولا يمكن فك تشفير بيانات UserIdentifier، ستظلّ Data Manager API تعالج السجلّ باستخدام 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 يشير إلى عدد السجلات التي تحتوي على هذا النوع من التحذيرات.

تحقَّق من warning_info حتى إذا كانت حالة الوجهة العامة هي SUCCESS.

error_info

قائمة بكائنات ErrorCount. يحتوي كل ErrorCount على reason يتضمّن نوع الخطأ، وrecord_count يشير إلى عدد السجلات التي تعذّرت بسبب هذا النوع من الأخطاء.