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

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

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

  2. تحقَّق من الحالة العامة لكل طلب. يكون الطلب ناجحًا إذا كانت Status تحتوي على code يساوي 0 (قيمة التعداد OK، استجابة HTTP هي 200 OK)، وتعرض 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 ساعة)

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

رسم بياني للدالة

استراتيجية الاستطلاع

البيانات

المحاولة الوقت منذ طلب العرض (س‌س:دد) مدة التأخير قبل المحاولة ملاحظات
1 00:30 30.0 دقيقة أول تحقّق من توفّر الحالة
2 01:09 39.0 دقيقة
3 01:59 50.7 دقيقة
4 02:59 60.0 دقيقة تم الآن تحديد الحد الأقصى للتأخير بساعة واحدة
5 03:59 60.0 دقيقة
6 04:59 60.0 دقيقة
7 05:59 60.0 دقيقة
8 06:59 60.0 دقيقة
9 07:59 60.0 دقيقة
10 08:59 60.0 دقيقة
11 09:59 60.0 دقيقة
12 10:59 60.0 دقيقة
13 11:59 60.0 دقيقة علامة 12 ساعة
14 12:59 60.0 دقيقة
15 13:59 60.0 دقيقة
16 14:59 60.0 دقيقة
17 15:59 60.0 دقيقة
18 16:59 60.0 دقيقة
19 17:59 60.0 دقيقة
20 18:59 60.0 دقيقة
21 19:59 60.0 دقيقة
22 20:59 60.0 دقيقة
23 21:59 60.0 دقيقة
24 22:59 60.0 دقيقة
25 23:59 60.0 دقيقة آخر طلب قبل الحد الأقصى للوقت الإجمالي البالغ 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 إذا كان الطلب IngestEventsRequest.

تحقَّق من record_count في IngestEventStatus للتأكّد من أنّ العدد الإجمالي للسجلّات المستلَمة يتطابق مع توقعاتك. يتضمّن record_count السجلّات الناجحة والفاشلة على حد سواء.

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

تتم تعبئة الحقل audience_members_ingestion_status إذا كان الطلب IngestAudienceMembersRequest. في ما يلي الحقل IngestAudienceMembersStatus الذي يجب التحقّق منه لكل نوع من بيانات الجمهور. يتم ضبط حقل واحد فقط من هذه الحقول.

composite_data_ingestion_status

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

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

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

google_user_id_data_ingestion_status

تحقَّق من record_count في IngestGoogleUserIdDataStatus للتأكّد من أنّ العدد الإجمالي للسجلّات المستلَمة يتطابق مع توقعاتك. يتضمّن record_count السجلّات الناجحة والفاشلة على حد سواء.

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

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 المستلَمة يتطابق مع توقعاتك.

partner_provided_id_data_ingestion_status

تحقَّق من record_count في IngestPartnerProvidedIdDataStatus للتأكّد من أنّ العدد الإجمالي للسجلّات المستلَمة يتطابق مع توقعاتك. يتضمّن record_count السجلّات الناجحة والفاشلة على حد سواء.

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

ppid_data_ingestion_status

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

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

user_data_ingestion_status

تحقَّق من record_count في IngestUserDataStatus للتأكّد من أنّ العدد الإجمالي للسجلّات المستلَمة يتطابق مع توقعاتك. يتضمّن record_count السجلّات الناجحة والفاشلة على حد سواء.

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

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

user_id_data_ingestion_status

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

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

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

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

composite_data_removal_status
حالة إزالة البيانات المركّبة
google_user_id_data_removal_status
حالة إزالة بيانات معرّف مستخدم Google
mobile_data_removal_status
حالة إزالة بيانات الأجهزة الجوّالة.
pair_data_removal_status
حالة إزالة بيانات PAIR.
partner_provided_id_data_removal_status
حالة إزالة بيانات معرّف الشريك
ppid_data_removal_status
حالة إزالة بيانات معرّف PPID.
user_data_removal_status
حالة إزالة بيانات المستخدم.
user_id_data_removal_status
حالة إزالة بيانات معرّف المستخدم

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

بالإضافة إلى ذلك، تحقَّق من user_identifier_count أو mobile_id_count أو pair_id_count أو ppid_count أو user_id_count أو google_user_id_count أو partner_provided_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 يشير إلى عدد السجلّات التي تعذّرت معالجتها بسبب هذا النوع من الأخطاء.