في ما يلي سير العمل المقترَح للتحقّق من حالة عمليات تحميل الأحداث وشرائح الجمهور وتحديد المشاكل في بياناتك.
إصدار طلبات لإرسال أحداث أو إرسال أو إزالة أفراد الجمهور
اطّلِع على الحالة العامة لكل طلب. يتضمّن الطلب الناجح
Statusمعcodeيساوي0(قيمة التعدادOK، استجابة HTTP200 OK)، ويعرضIngestEventsResponseأوIngestAudienceMembersResponseأوRemoveAudienceMembersResponse.إذا لم ينجح الطلب، عدِّله لمعالجة الخطأ وأرسِله مرة أخرى.
إذا نجح الطلب، يمكنك تسجيل
request_idالخاص بالاستجابة حتى تتمكّن من استخدامه لاسترداد بيانات التشخيص في الخطوة التالية.انتظِر لمدة 30 دقيقة، ثم أرسِل طلب
RetrieveRequestStatusلكل عمليةrequest_idناجحة.كرِّر هذه الخطوة بشكل دوري لكل
request_idإلى أن تصل حالة الوجهة لكل وجهة إلىSUCCESSأوPARTIAL_SUCCESSأوFAILURE. استخدِم خوارزمية الرقود الأسي الثنائي للانتظار بين كل طلب.راجِع كل
RetrieveRequestStatusResponseللتأكّد من أنّ عمليات التحميل تعمل بشكل صحيح وتحديد أي مشاكل في بياناتك.حلّ المشاكل المتعلّقة بالبيانات
ارجع إلى الخطوة 1 وكرِّرها إلى أن تحلّ جميع المشاكل المتعلّقة بعمليات التحميل.
أرسِل الطلبات
يتطلّب السمة RetrieveRequestStatusRequest قيمة واحدة للسمة
request_id. أرسِل طلب حالة منفصلاً لكل معرّف طلب تم الحصول عليه من طلب استيعاب ناجح.
التفويض
لا يقبل RetrieveRequestStatusRequest حسابات الوجهة أو عناوين الطلبات. بدلاً من ذلك، تحدّد Data Manager API
الوجهات من طلب نقل البيانات الأصلي المرتبط بـ
request_id وتتحقّق من أنّ المتصل لديه إذن الوصول إلى operating_account
على كل Destination.
للتحقّق من حالة طلب معيّن، يجب أن تستوفي بيانات الاعتماد المستخدَمة في
RetrieveRequestStatusRequest المتطلبات التالية
لـ operating_account لكل وجهة من طلب
الاستيراد الأصلي:
مسار الوصول نفسه: يجب أن تتيح بيانات الاعتماد الوصول إلى كل
operating_accountباستخدام مسار الوصول نفسه المحدّد في طلب نقل البيانات الأصلي.على سبيل المثال، إذا حدّد طلب نقل البيانات لحساب "إعلانات Google"
operating_accountحساب مدير رئيسي على أنّهlogin_account، يجب أن تتيح بيانات الاعتماد أيضًا الوصول إلىoperating_accountمن خلال حساب المدير نفسه. حتى إذا كان حساب Google المرتبط ببيانات الاعتماد لديه إذن وصول مباشر إلى حسابoperating_accountالفرعي، سيتعذّر تنفيذ الطلب وسيظهر الخطأPERMISSION_DENIEDإذا لم يكن لدى هذا الحساب إذن وصول من خلال حسابlogin_accountالإداري المحدّد أثناء عملية النقل.مستوى وصول كافٍ: يجب أن يكون لحساب Google المرتبط ببيانات الاعتماد مستوى وصول أو دور يمنحه الإذن بإدخال البيانات إلى
operating_account.على سبيل المثال، في "إعلانات Google"، يجب أن يكون لدى حساب Google مستوى الوصول إداري أو عادي. يتعذّر تنفيذ طلب يتضمّن بيانات اعتماد لحساب لديه مستوى الوصول للقراءة فقط ويظهر الخطأ
PERMISSION_DENIED.
استراتيجية الاقتراع
أرسِل RetrieveRequestStatusRequest بشكل دوري باستخدام خوارزمية الرقود الأسي الثنائي إلى أن يصل request_status إلى SUCCESS أو FAILURE أو PARTIAL_SUCCESS لكل وجهة في الطلب الأصلي. قد تستغرق هذه العملية مدة تصل إلى 24 ساعة، مع أنّ واجهة برمجة التطبيقات "إدارة بيانات إعلانات Google" قد تنتهي من معالجة بعض الطلبات في غضون 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 الذي يجب التحقّق منه لكل نوع من بيانات الجمهور. يتم ضبط حقل واحد فقط من هذه الحقول.
composite_data_ingestion_statusتحقَّق من
record_countفيIngestCompositeDataStatusللتأكّد من أنّ إجمالي عدد السجلات التي تم تلقّيها يتطابق مع توقعاتك. يتضمّنrecord_countالسجلات الناجحة والفاشلة.تحقَّق من
data_type_countsللتأكّد من أنّ عدد المعرّفات يتطابق مع توقعاتك. تقدّم هذه القائمة تفصيلاً لجميع المعرّفات التي تلقّتهاDataType(مثل عنوان البريد الإلكتروني ورقم الهاتف والعنوان الجغرافي وعنوان IP).إذا كان الطلب يحتوي على عدد كافٍ من السجلات، يحتوي الحقل
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_countIngestMobileDataStatusللتأكّد من أنّ إجمالي عدد السجلات التي تم تلقّيها يتطابق مع توقعاتك. يتضمّنrecord_countالسجلّات الناجحة وغير الناجحة.تحقَّق من
mobile_id_countللتأكّد من أنّ عدد بطاقات التعريف الرقمية على الأجهزة الجوّالة التي تم استلامها يتطابق مع توقعاتك.pair_data_ingestion_statusتحقَّق من
record_countIngestPairDataStatusللتأكّد من أنّ إجمالي عدد السجلات التي تم تلقّيها يتطابق مع توقعاتك. يتضمّن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_countIngestPpidDataStatusللتأكّد من أنّ إجمالي عدد السجلات التي تم تلقّيها يتطابق مع توقعاتك. يتضمّن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 للتأكّد من أنّ عدد المعرّفات يتطابق مع توقعاتك. تقدّم هذه القائمة تفاصيل عن جميع المعرّفات التي تلقّاها DataType (مثل عنوان البريد الإلكتروني ورقم الهاتف والعنوان الجغرافي وعنوان IP).
التحقّق من التحذيرات والأخطاء
بالإضافة إلى حقول الحالة للوجهة ونوع الطلب، يحتوي 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وهو يمثّل عنصر
WarningInfo. يحتوي الحقلwarning_countsعلى قائمة بعناصرWarningCount. يحتوي كل عنصرWarningCountعلى عنصرreasonيتضمّن نوع التحذير، وعنصرrecord_countيشير إلى عدد السجلات التي تتضمّن هذا النوع من التحذير.يُرجى التحقّق من
warning_infoحتى إذا كانت الحالة العامة للوجهة هيSUCCESS.error_infoعنصر
ErrorInfo. يحتوي حقلerror_countsعلى قائمة من عناصرErrorCount. يحتوي كلErrorCountعلىreasonمع نوع الخطأ، وrecord_countيشير إلى عدد السجلات التي تعذّر نقلها بسبب هذا النوع من الخطأ.