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

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

  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 لتحديد ما إذا كانت Data Manager 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_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 التي تم تلقّيها يتوافق مع توقعاتك.

ppid_data_ingestion_status

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

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

user_id_data_ingestion_status

تحقَّق من record_countIngestUserIdDataStatus للتأكّد من أنّ إجمالي عدد السجلات التي تم تلقّيها يتطابق مع توقعاتك. يتضمّن 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
حالة الإزالة لبيانات المعرّف المقدَّم من الناشر
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، سترفض واجهة برمجة التطبيقات Data Manager API السجلّ بأكمله وستعرض الخطأ 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 يشير إلى عدد السجلات التي تعذّر نقلها بسبب هذا النوع من الخطأ.