تصدير بيانات Firebase Crashlytics إلى BigQuery

يمكنك تصدير بيانات Firebase Crashlytics إلى BigQuery لإجراء المزيد من التحليلات. تتيح لك BigQuery تحليل البيانات باستخدام BigQuery SQL وتصديرها إلى مقدّم خدمة سحابية آخر واستخدامها في تصور البيانات ولوحات البيانات المخصّصة باستخدام Looker Studio.

ما هي الإجراءات التي يمكنك اتّخاذها بشأن البيانات التي تم تصديرها؟

تتضمّن عمليات التصدير إلى BigQuery بيانات الأعطال الأولية، بما في ذلك نوع الجهاز ونظام التشغيل والاستثناءات (تطبيقات Android) أو الأخطاء (تطبيقات Apple) وسجلّات Crashlytics، بالإضافة إلى بيانات أخرى. يمكنك مراجعة البيانات التي يتم تصديرها بالضبط Crashlytics ومخطط الجدول لاحقًا في هذه الصفحة.

في ما يلي بعض الأمثلة على ما يمكنك فعله ببياناتك التي تم تصديرها:Crashlytics

  • تنفيذ طلبات البحث
    يمكنك تنفيذ طلبات بحث على بيانات Crashlytics لإنشاء تقارير تجمع بيانات أحداث الأعطال في ملخّصات يسهل فهمها. بما أنّ هذه الأنواع من التقارير غير متاحة في لوحة بيانات Crashlytics في وحدة تحكّم Firebase، يمكنها أن تكمل تحليلك وفهمك لبيانات الأعطال. في وقت لاحق من هذه الصفحة، يمكنك الاطّلاع على مجموعة من أمثلة على طلبات البحث.

  • استخدام نموذج Looker Studio
    Crashlytics يوفّر نموذج Looker Studio مصمّم مسبقًا لعرض بياناتك التي تم تصديرها.

  • إنشاء طرق عرض
    باستخدام واجهة مستخدم BigQuery، يمكنك إنشاء طريقة عرض، وهي عبارة عن جدول افتراضي يتم تحديده من خلال طلب بحث SQL. للحصول على تعليمات تفصيلية حول أنواع طرق العرض المختلفة وكيفية إنشائها، يُرجى الاطّلاع على مستندات BigQuery.

  • دمج بيانات Crashlytics مع بيانات جلسات Firebase
    يمكنك أيضًا تصدير بيانات جلسات Firebase عند إعداد عملية تصدير بيانات Crashlytics. استخدِم بيانات الجلسات هذه لتحسين فهم المستخدمين الذين لم يواجهوا أي أعطال والجلسات الخالية من الأعطال.

مزايا بث التصدير إلى BigQuery

يتم تصدير البيانات تلقائيًا إلى BigQuery في عملية تصدير مجمّعة يومية. بالإضافة إلى ذلك، يمكنك بث بيانات Crashlytics وجلسات Firebase في الوقت الفعلي باستخدام ميزة BigQuery البث. يمكنك استخدامها لأي غرض يتطلّب بيانات مباشرة، مثل عرض المعلومات في لوحة بيانات مباشرة أو مشاهدة عملية طرح منتج مباشرة أو مراقبة مشاكل التطبيق التي تؤدي إلى إطلاق تنبيهات وسير عمل مخصّص.

عند تفعيل ميزة التصدير المتواصل إلى BigQuery، ستتوفّر لك أيضًا جداول في الوقت الفعلي (بالإضافة إلى جداول الدفعات). سيتضمّن كلا النوعين من الجداول مخطط مجموعة البيانات نفسه، ولكن إليك بعض الاختلافات المهمة بين جداول المعالجة المجمّعة وجداول الوقت الفعلي:

جدول الدُفعات جدول "الوقت الفعلي"
  • يتم تصدير البيانات مرة واحدة يوميًا.
  • يتم تخزين الأحداث بشكل دائم قبل كتابتها بشكل مجمّع إلى BigQuery.
  • يمكن إعادة ملء البيانات لمدة تصل إلى 30 يومًا قبل التاريخ الحالي*.
  • يتم تصدير البيانات في الوقت الفعلي.
  • لا تتوفّر إمكانية ملء البيانات السابقة.

يُعدّ جدول الدفعات مثاليًا للتحليل طويل الأمد وتحديد المؤشرات بمرور الوقت، لأنّنا نخزّن الأحداث بشكل دائم قبل تسجيلها، ويمكن إعادة ملء الجدول بالبيانات السابقة لمدة تصل إلى 30 يومًا*. عندما نكتب البيانات في جدول الوقت الفعلي، نكتبها على الفور في BigQuery، ما يجعلها مثالية للوحات البيانات المباشرة والتنبيهات المخصّصة. يمكن دمج هذين الجدولين باستخدام استعلام ربط للاستفادة من مزايا كليهما.

بشكلٍ تلقائي، يبلغ وقت انتهاء صلاحية القسم في جدول الوقت الفعلي 30 يومًا. لمعرفة كيفية تعديل ذلك، راجِع مقالة ضبط تاريخ انتهاء صلاحية القسم في مستندات BigQuery.

* يمكنك الاطّلاع على تفاصيل حول إمكانية توفير بيانات سابقة في الترقية إلى البنية الأساسية الجديدة للتصدير.


تفعيل التصدير إلى BigQuery

  1. في وحدة تحكّم Firebase، انتقِل إلى صفحة عمليات الدمج.

  2. في بطاقة BigQuery، انقر على ربط.

  3. اتّبِع التعليمات الظاهرة على الشاشة لتفعيل التصدير إلى BigQuery، بما في ذلك الخيارات التالية:

ماذا يحدث عند تفعيل ميزة التصدير؟

  • تصدِّر Firebase البيانات من التطبيقات المرتبطة بـ BigQuery.

    • أثناء عملية الإعداد، يتم تلقائيًا ربط جميع التطبيقات في مشروعك بـ BigQuery، ولكن يمكنك اختيار عدم ربط تطبيقات معيّنة أثناء عملية الإعداد.

    • يتم تلقائيًا ربط أي تطبيقات تضيفها لاحقًا إلى مشروعك على Firebase بـ BigQuery.

    • يمكنك في أي وقت إدارة التطبيقات التي تصدّر البيانات.

  • يصدّر Firebase البيانات إلى موقع مجموعة البيانات الذي اخترته أثناء عملية الإعداد.

    • ينطبق هذا الموقع الجغرافي على مجموعة بيانات Crashlytics ومجموعة بيانات جلسات Firebase (في حال تفعيل ميزة تصدير بيانات الجلسات).

    • لا ينطبق هذا الموقع الجغرافي إلا على البيانات التي يتم تصديرها إلى BigQuery، ولا يؤثّر في الموقع الجغرافي للبيانات المخزَّنة لاستخدامها في لوحة بيانات Crashlytics في وحدة تحكّم Firebase أو في Android Studio.

    • بعد إنشاء مجموعة بيانات، لا يمكن تغيير موقعها الجغرافي، ولكن يمكنك نسخها إلى موقع جغرافي آخر أو نقلها (إعادة إنشائها) يدويًا في موقع جغرافي آخر. لمزيد من المعلومات، اطّلِع على مقالة تغيير الموقع الجغرافي لعمليات التصدير الحالية.

  • يُعدّ Firebase عمليات مزامنة يومية لبيانات الدفعات إلى BigQuery.

    • بعد الربط بـ BigQuery، قد يستغرق تصدير الدفعة الأولية من البيانات مدة تصل إلى 48 ساعة.

    • تتم المزامنة اليومية مرة واحدة في اليوم، بغض النظر عن أي عملية تصدير مجدولة ربما تكون قد أعددتها في BigQuery. يُرجى العِلم أنّ توقيت مهمة المزامنة ومدتها قد يتغيّران، لذا لا ننصح بجدولة العمليات أو المهام اللاحقة استنادًا إلى توقيت محدّد للتصدير.

  • تصدّر Firebase نسخة من بياناتك الحالية إلى BigQuery.

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

    • يمكنك تحديد موعد يدويًا لعمليات إعادة تعبئة البيانات لجدول الدفعات حتى آخر 30 يومًا أو لأحدث تاريخ عند تفعيل التصدير إلى BigQuery (أيهما أحدث).

    يُرجى العِلم أنّه في حال فعّلت تصدير بيانات Crashlytics قبل منتصف أكتوبر 2024، يمكنك أيضًا إعادة ملء البيانات لمدة 30 يومًا قبل اليوم الذي فعّلت فيه عملية التصدير.

  • ينطبق ما يلي في حال تفعيل بث التصدير إلى BigQuery.

    • سيكون لكل تطبيق مرتبط أيضًا جدول خاص به في الوقت الفعلي يحتوي على بيانات يتم تعديلها باستمرار (بالإضافة إلى جدول الدُفعات الخاص بالتطبيق لتصدير الدُفعات اليومية).

    • بعد تفعيل البث، قد يستغرق بدء بث البيانات ساعة واحدة.


أمثلة على طلبات البحث

المثال 1: احتساب مقاييس عدم حدوث أعطال باستخدام بيانات الجلسات في Firebase

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

يمكن أن تساعد مقاييس عدم حدوث أعطال في توفير هذه المعلومات. هذه المقاييس هي قياسات مهمة تساعدك في فهم الحالة العامة لتطبيقك. وباستخدام بيانات الجلسات وCrashlytics الأحداث في Firebase، يمكنك احتساب هذه المقاييس باستخدام طلب بحث أساسي.

في ما يلي أمثلة على طلبات بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

المستخدمون الذين لم يواجههم أي تعطُّل في إصدار معيّن:

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT installation_uuid) / COUNT (DISTINCT instance_id))) AS CFU
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL"
  AND crashlytics.application.display_version="APP_VERSION"
  AND sessions.application.display_version = "APP_VERSION"
GROUP BY
  event_date
ORDER BY
  event_date

الجلسات الخالية من الأعطال خلال الأسبوع الماضي (آخر 168 ساعة):

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT crashlytics.event_id) / COUNT (DISTINCT sessions.session_id))) AS CFS
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL" AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND _PARTITIONTIME < CURRENT_TIMESTAMP()
GROUP BY
  event_date
ORDER BY
  event_date

المثال 2: الأعطال حسب اليوم

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

في ما يلي مثال على طلب بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

المثال 3: العثور على الأعطال الأكثر انتشارًا

لتحديد أولويات خطط الإنتاج بشكل سليم، عليك العثور على أكثر 10 أعطال شيوعًا في تطبيقك. يمكنك إنشاء طلب بحث يقدّم نقاط البيانات ذات الصلة.

في ما يلي مثال على طلب بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

SELECT
  DISTINCT issue_id,
  COUNT(DISTINCT event_id) AS number_of_crashes,
  COUNT(DISTINCT installation_uuid) AS number_of_impacted_user,
  blame_frame.file,
  blame_frame.line
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  issue_id,
  blame_frame.file,
  blame_frame.line
ORDER BY
  number_of_crashes DESC
LIMIT 10;

المثال 4: أفضل 10 أجهزة تحدث فيها أعطال

الخريف هو موسم الهواتف الجديدة! تدرك شركتك أنّ هذا يعني أيضًا أنّ موسم المشاكل الخاصة بالأجهزة الجديدة قد بدأ، خاصةً على Android. للتغلّب على المخاوف بشأن التوافق، أعددت طلب بحث يحدّد 10 أجهزة حدثت فيها معظم الأعطال خلال الأسبوع الماضي (168 ساعة).

في ما يلي مثال على طلب بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  device.model
ORDER BY
  number_of_crashes DESC
LIMIT 10;

المثال 5: الفلترة حسب المفتاح المخصّص

أنت مطوّر ألعاب وتريد معرفة مستوى اللعبة الذي يحدث فيه أكبر عدد من الأعطال.

للمساعدة في تتبُّع هذا الإحصاء، يمكنك ضبط مفتاح Crashlytics مخصّص باسم current_level، وتعديله في كل مرة يصل فيها المستخدم إلى مستوى جديد.

Swift

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

Crashlytics.setInt("current_level", 3);

باستخدام هذا المفتاح في عملية التصدير إلى BigQuery، يمكنك بعد ذلك كتابة طلب بحث لإعداد تقرير عن توزيع قيم current_level المرتبطة بكل حدث تعطل.

في ما يلي مثال على طلب بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

المثال 6: استخراج رقم تعريف المستخدم

لديك تطبيق Android متاح للاستخدام قبل إطلاقه. معظم المستخدمين يحبون هذا التطبيق، ولكن ثلاثة منهم واجهوا عددًا غير معتاد من الأعطال. للوصول إلى سبب المشكلة، يمكنك كتابة طلب بحث يستردّ جميع أحداث الأعطال لهؤلاء المستخدمين باستخدام أرقام تعريف المستخدمين.

في ما يلي مثال على طلب بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

SELECT *
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
  user.id

المثال 7: العثور على جميع المستخدمين الذين يواجهون مشكلة تعطُّل معيّنة

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

في ما يلي مثال على طلب بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

SELECT user.id as user_id
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  issue_id = "ISSUE_ID"
  AND application.display_version = "APP_VERSION"
  AND user.id != ""
ORDER BY
  user.id;

المثال 8: عدد المستخدمين المتأثرين بمشكلة تعطُّل، مصنّف حسب البلد

رصد فريقك خطأً فادحًا أثناء طرح إصدار جديد. لقد تمكّنت من استخدام طلب البحث من مثال"العثور على الأعطال الأكثر انتشارًا" أعلاه لتحديد رقم تعريف مشكلة التعطُّل المحدّدة. يريد فريقك الآن معرفة ما إذا كان هذا العطل قد انتشر بين المستخدمين في بلدان مختلفة حول العالم.

لكتابة هذا الاستعلام، على فريقك تنفيذ ما يلي:

  1. فعِّل تصدير بيانات Google Analytics إلى BigQuery. اطّلِع على مقالة تصدير بيانات المشروع إلى BigQuery.

  2. حدِّث تطبيقك لإدخال معرّف مستخدم في كلّ من حزمة تطوير البرامج (SDK) الخاصة بـ Google Analytics وحزمة تطوير البرامج (SDK) الخاصة بـ Crashlytics.

    Swift 

    Crashlytics.sharedInstance().setUserIdentifier("123456789");
Analytics.setUserID("123456789");

    Objective-C 

    CrashlyticsKit setUserIdentifier:@"123456789";
FIRAnalytics setUserID:@"12345678 9";

    Java 

    Crashlytics.setUserIdentifier("123456789");
mFirebaseAnalytics.setUserId("123456789");

  3. اكتب طلب بحث يستخدِم حقل رقم تعريف المستخدِم لربط الأحداث في مجموعة بيانات Google Analytics بالأعطال في مجموعة بيانات Crashlytics.

    في ما يلي مثال على طلب بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

    SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c
INNER JOIN  `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id
WHERE
  c.issue_id = "ISSUE_ID"
  AND a._TABLE_SUFFIX BETWEEN '20190101'
  AND '20200101'
GROUP BY
  c.issue_id,
  a.geo.country,
  c.user.id

المثال 9: أهم 5 مشاكل حتى الآن اليوم

في ما يلي مثال على طلب بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

المثال 10: أهم 5 مشاكل منذ DATE، بما في ذلك اليوم

يمكنك أيضًا الجمع بين جدولَي الدُفعات والوقت الفعلي باستخدام طلب بحث ربط لإضافة معلومات الوقت الفعلي إلى بيانات الدُفعات الموثوقة. بما أنّ event_id هو مفتاح أساسي، يمكنك استخدام DISTINCT event_id لإزالة أي أحداث مكرّرة من الجدولَين.

في ما يلي مثال على طلب بحث لتطبيق Android. بالنسبة إلى تطبيق iOS، استخدِم معرّف الحزمة وIOS (بدلاً من اسم الحزمة وANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;


عرض بيانات Crashlytics التي تم تصديرها بصريًا باستخدام Looker Studio

تعمل Looker Studio على تحويل مجموعات بيانات Crashlytics في BigQuery إلى تقارير تسهل قراءتها ومشاركتها وتكون قابلة للتخصيص بالكامل.

لمزيد من المعلومات حول استخدام Looker Studio، يمكنك الاطّلاع على دليل الترحيب.

استخدام نموذج تقرير Crashlytics

يتضمّن Looker Studio تقريرًا نموذجيًا عن Crashlytics يتضمّن مجموعة شاملة من السمات والمقاييس من مخطط Crashlytics BigQuery الذي تم تصديره. إذا فعّلت ميزة Crashlytics تصدير البيانات المتدفّقة إلى BigQuery، يمكنك الاطّلاع على هذه البيانات في صفحة المؤشرات في الوقت الفعلي في نموذج Looker Studio.يمكنك استخدام النموذج كقالب لإنشاء تقارير وعروض مرئية جديدة بسرعة استنادًا إلى بيانات الأعطال الأولية في تطبيقك:

  1. افتح Crashlytics Looker Studio نموذج لوحة البيانات.

  2. انقر على استخدام نموذج في أعلى يسار الصفحة.

  3. في القائمة المنسدلة مصدر بيانات جديد، انقر على إنشاء مصدر بيانات جديد.

  4. انقر على اختيار في بطاقة BigQuery.

  5. اختَر جدولاً يحتوي على بيانات Crashlytics تم تصديرها من خلال النقر على مشاريعي > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

    يتوفّر جدول الدفعات دائمًا لتحديده. في حال تفعيل Crashlytics تصدير بيانات البث إلى BigQuery، يمكنك بدلاً من ذلك اختيار جدولك في الوقت الفعلي.

  6. ضمن الضبط، اضبط Crashlytics مستوى النموذج على تلقائي.

  7. انقر على ربط لإنشاء مصدر البيانات الجديد.

  8. انقر على إضافة إلى التقرير للرجوع إلى نموذج Crashlytics.

  9. أخيرًا، انقر على إنشاء تقرير لإنشاء نسختك من نموذج لوحة البيانات Crashlytics Looker Studio.


فهم المخطط في BigQuery

تنشئ Firebase مجموعات بيانات جديدة في BigQuery لبياناتك التي تم تصديرها:

مجموعة البيانات: Crashlytics

يتم تصدير بيانات Crashlytics إلى مجموعة بيانات BigQuery باسم firebase_crashlytics. تغطي مجموعة البيانات مشروعك بالكامل، حتى إذا كان يتضمّن تطبيقات متعددة.

الجداول

تنشئ Firebase تلقائيًا جداول فردية داخل مجموعة البيانات Crashlytics لكل تطبيق في مشروعك مرتبط بـ BigQuery.

تتم تسمية الجداول استنادًا إلى معرّف التطبيق (مع تحويل النقاط إلى شرطات سفلية) وإضافة نظام التشغيل الخاص بالتطبيق (_IOS أو _ANDROID). على سبيل المثال، ستكون بيانات تطبيق Android الذي يحمل اسم الحزمة com.google.test في جدول باسم com_google_test_ANDROID.

  • في حال تفعيل خيار تصدير بيانات البث إلى BigQuery، سيتم أيضًا بث البيانات في الوقت الفعلي إلى جدول مُلحق بـ _REALTIME (على سبيل المثال، com_google_test_ANDROID_REALTIME).

  • يمثّل كل صف في الجدول حدثًا وقع في التطبيق، بما في ذلك الأعطال والأخطاء غير الفادحة وأخطاء ANR.

  • تحتوي الجداول على مجموعة عادية من بيانات Crashlytics بالإضافة إلى أي مفاتيح Crashlytics مخصّصة تحدّدها أنت في تطبيقك.

الصفوف

يمثّل كل صف في الجدول خطأً واجهه التطبيق.

الأعمدة

تكون الأعمدة في الجدول متطابقة بالنسبة إلى الأعطال والأخطاء غير الفادحة وأخطاء ANR.

  • في حال تفعيل تصدير بيانات البث إلى BigQuery، سيتضمّن الجدول في الوقت الفعلي الأعمدة نفسها التي يتضمّنها جدول الدفعات.

  • قد تتضمّن الصفوف أعمدة تمثّل أحداثًا لا تتضمّن عمليات تتبُّع تسلسل استدعاء الدوال البرمجية.

في ما يلي الأعمدة في جدول بيانات Crashlytics التي تم تصديرها:

اسم الحقل نوع البيانات الوصف
app_orientation سلسلة على سبيل المثال، PORTRAIT وLANDSCAPE وFACE_UP وFACE_DOWN وما إلى ذلك.
application سجلّ التطبيق الذي أنشأ الحدث
application.build_version سلسلة إصدار بنية التطبيق
application.display_version سلسلة
blame_frame سجلّ الإطار الذي تم تحديده كسبب أساسي للتعطُّل أو الخطأ
blame_frame.address INT64 العنوان في صورة الرمز الثنائي الذي يحتوي على الرمز
لم يتم ضبطه لإطارات Java
blame_frame.blamed قيمة منطقية ما إذا كان Crashlytics قد حدّد أنّ هذا الإطار هو سبب التعطُّل أو الخطأ
blame_frame.file سلسلة اسم ملف الإطار
blame_frame.library سلسلة الاسم المعروض للمكتبة التي تتضمّن الإطار
blame_frame.line INT64 رقم السطر في ملف اللقطة
blame_frame.offset INT64 إزاحة البايت في الصورة الثنائية التي تحتوي على الرمز
لم يتم ضبطها لأخطاء Java
blame_frame.owner سلسلة على سبيل المثال، DEVELOPER أو VENDOR أو RUNTIME أو PLATFORM أو SYSTEM
blame_frame.symbol سلسلة الرمز المائي أو الرمز الأولي إذا كان غير قابل للترطيب
breadcrumbs سجلّ متكرّر Google Analytics أشرطة التنقل التي تتضمّن طوابع زمنية، في حال تفعيلها
breadcrumbs.name سلسلة الاسم المرتبط بمسار التنقل
breadcrumbs.params سجلّ متكرّر المَعلمات المرتبطة بمسار التنقّل
breadcrumbs.params.key سلسلة مفتاح مَعلمة مرتبط بمسار التنقّل
breadcrumbs.params.value سلسلة قيمة مَعلمة مرتبطة بمسار التنقّل
breadcrumbs.timestamp الطابع الزمني الطابع الزمني المرتبط بمسار التنفيذ
bundle_identifier سلسلة المعرّف الفريد للتطبيق كما هو مسجّل في مشروع Firebase (على سبيل المثال، com.google.gmail)
بالنسبة إلى تطبيقات منصة Apple، هذا هو رقم تعريف الحزمة الخاص بالتطبيق.
بالنسبة إلى تطبيقات Android، هذا هو اسم حزمة التطبيق.
crashlytics_sdk_versions سلسلة إصدار حزمة تطوير البرامج (SDK) Crashlytics الذي أنشأ الحدث
custom_keys سجلّ متكرّر أزواج المفتاح/القيمة التي يحدّدها المطوّر
custom_keys.key سلسلة مفتاح يحدّده المطوّر
custom_keys.value سلسلة قيمة يحدّدها المطوِّر
device سجلّ الجهاز الذي وقع فيه الحدث
device_orientation سلسلة على سبيل المثال، PORTRAIT وLANDSCAPE وFACE_UP وFACE_DOWN وما إلى ذلك.
device.architecture سلسلة على سبيل المثال، X86_32 أو X86_64 أو ARMV7 أو ARM64 أو ARMV7S أو ARMV7K
device.manufacturer سلسلة الشركة المصنّعة للجهاز
device.model سلسلة طراز الجهاز
error سجلّ متكرّر أخطاء (تطبيقات Apple فقط) غير خطيرة
error_type سلسلة نوع الخطأ في الحدث (على سبيل المثال، FATAL وNON_FATAL وANR وما إلى ذلك)
error.blamed قيمة منطقية تحديد ما إذا كان Crashlytics قد حدّد أنّ هذا الإطار هو سبب الخطأ
error.code INT64 رمز الخطأ المرتبط بـ NSError المخصّص الذي سجّله التطبيق
error.frames سجلّ متكرّر إطارات تتبُّع تسلسل استدعاء الدوال البرمجية
error.frames.address INT64 العنوان في الصورة الثنائية الذي يحتوي على الرمز
error.frames.blamed قيمة منطقية تحديد ما إذا كان Crashlytics قد حدّد أنّ هذا الإطار هو سبب الخطأ
error.frames.file سلسلة اسم ملف الإطار
error.frames.library سلسلة الاسم المعروض للمكتبة التي تتضمّن الإطار
error.frames.line INT64 رقم السطر في ملف اللقطة
error.frames.offset INT64 إزاحة البايت في الصورة الثنائية التي تحتوي على الرمز
error.frames.owner سلسلة على سبيل المثال، DEVELOPER أو VENDOR أو RUNTIME أو PLATFORM أو SYSTEM
error.frames.symbol سلسلة الرمز المائي أو الرمز الأولي إذا كان غير قابل للترطيب
error.queue_name سلسلة قائمة الانتظار التي كان يتم تشغيل سلسلة المحادثات عليها
error.subtitle سلسلة العنوان الفرعي لسلسلة المحادثات
error.title سلسلة عنوان سلسلة المحادثات
event_id سلسلة المعرّف الفريد للحدث
event_timestamp الطابع الزمني وقت وقوع الحدث
exceptions سجلّ متكرّر (على أجهزة Android فقط) الأخطاء التي حدثت أثناء هذا الحدث يتم عرض الاستثناءات المتداخلة بترتيب زمني عكسي، ما يعني أنّ السجلّ الأخير هو الاستثناء الأول الذي تم طرحه.
exceptions.blamed قيمة منطقية صحيح إذا حدّد Crashlytics أنّ الاستثناء مسؤول عن الخطأ أو التعطُّل
exceptions.exception_message سلسلة رسالة مرتبطة بالاستثناء
exceptions.frames سجلّ متكرّر اللقطات المرتبطة بالاستثناء
exceptions.frames.address INT64 العنوان في صورة الرمز الثنائي الذي يحتوي على الرمز
لم يتم ضبطه لإطارات Java
exceptions.frames.blamed قيمة منطقية ما إذا كان Crashlytics قد حدّد أنّ هذا الإطار هو سبب التعطُّل أو الخطأ
exceptions.frames.file سلسلة اسم ملف الإطار
exceptions.frames.library سلسلة الاسم المعروض للمكتبة التي تتضمّن الإطار
exceptions.frames.line INT64 رقم السطر في ملف اللقطة
exceptions.frames.offset INT64 إزاحة البايت في الصورة الثنائية التي تحتوي على الرمز
لم يتم ضبطها لأخطاء Java
exceptions.frames.owner سلسلة على سبيل المثال، DEVELOPER أو VENDOR أو RUNTIME أو PLATFORM أو SYSTEM
exceptions.frames.symbol سلسلة الرمز المائي أو الرمز الأولي إذا كان غير قابل للترطيب
exceptions.nested قيمة منطقية صحيح لكل الأخطاء باستثناء الخطأ الأخير (أي السجلّ الأول)
exceptions.subtitle سلسلة العنوان الفرعي لسلسلة المحادثات
exceptions.title سلسلة عنوان سلسلة المحادثات
exceptions.type سلسلة نوع الاستثناء (على سبيل المثال، java.lang.IllegalStateException)
firebase_session_id سلسلة المعرّف الذي يتم إنشاؤه تلقائيًا لجلسة Firebase المرتبطة بالحدث من Crashlytics
installation_uuid سلسلة معرّف يحدّد عملية تثبيت فريدة للتطبيق والجهاز
is_fatal قيمة منطقية ما إذا كان التطبيق قد تعطل
issue_id سلسلة المشكلة المرتبطة بالحدث
logs سجلّ متكرّر رسائل السجلّات التي تحمل طابعًا زمنيًا والتي تم إنشاؤها بواسطة أداة تسجيل Crashlytics، في حال تفعيلها
logs.message سلسلة الرسالة المسجّلة
logs.timestamp الطابع الزمني وقت إنشاء السجل
memory سجلّ حالة ذاكرة الجهاز
memory.free INT64 بايتات الذاكرة المتبقية
memory.used INT64 بايت من الذاكرة المستخدَمة
operating_system سجلّ تفاصيل نظام التشغيل على الجهاز
operating_system.device_type سلسلة نوع الجهاز (على سبيل المثال، MOBILE أو TABLET أو TV وما إلى ذلك)، ويُعرف أيضًا باسم "فئة الجهاز"
operating_system.display_version سلسلة إصدار نظام التشغيل على الجهاز
operating_system.modification_state سلسلة ما إذا تم تعديل الجهاز (على سبيل المثال، يكون التطبيق الذي تمت إزالة جميع القيود عنه MODIFIED والتطبيق المزوّد بإذن الوصول إلى الجذر UNMODIFIED)
operating_system.name سلسلة اسم نظام التشغيل على الجهاز
operating_system.type سلسلة (تطبيقات Apple فقط) نوع نظام التشغيل الذي يعمل على الجهاز (على سبيل المثال، IOS أو MACOS أو غير ذلك)
platform سلسلة منصّة التطبيق كما تم تسجيلها في مشروع Firebase (القيم الصالحة: IOS أو ANDROID)
process_state سلسلة BACKGROUND أو FOREGROUND
storage سجلّ مساحة التخزين الدائمة على الجهاز
storage.free INT64 عدد وحدات البايت المتبقية من مساحة التخزين
storage.used INT64 وحدات البايت لمساحة التخزين المستخدَمة
threads سجلّ متكرّر سلاسل المحادثات المتوفّرة في وقت الحدث
threads.blamed قيمة منطقية ما إذا كان Crashlytics قد حدّد أنّ هذا الإطار هو سبب التعطُّل أو الخطأ
threads.code INT64 (تطبيقات Apple فقط) رمز الخطأ المخصّص الذي تم تسجيله في NSError للتطبيق
threads.crash_address INT64 عنوان الإشارة التي تسبّبت في تعطُّل التطبيق، ولا يظهر إلا في سلاسل التعليمات البرمجية الأصلية التي تعطلت
threads.crashed قيمة منطقية ما إذا تعطّلت سلسلة المحادثات
threads.frames سجلّ متكرّر لقطات سلسلة المحادثات
threads.frames.address INT64 العنوان في الصورة الثنائية الذي يحتوي على الرمز
threads.frames.blamed قيمة منطقية تحديد ما إذا كان Crashlytics قد حدّد أنّ هذا الإطار هو سبب الخطأ
threads.frames.file سلسلة اسم ملف الإطار
threads.frames.library سلسلة الاسم المعروض للمكتبة التي تتضمّن الإطار
threads.frames.line INT64 رقم السطر في ملف اللقطة
threads.frames.offset INT64 إزاحة البايت في الصورة الثنائية التي تحتوي على الرمز
threads.frames.owner سلسلة على سبيل المثال، DEVELOPER أو VENDOR أو RUNTIME أو PLATFORM أو SYSTEM
threads.frames.symbol سلسلة الرمز المائي أو الرمز الأولي إذا كان غير قابل للترطيب
threads.queue_name سلسلة (تطبيقات Apple فقط) قائمة الانتظار التي كان يتم تشغيل سلسلة المحادثات عليها
threads.signal_code سلسلة رمز الإشارة التي تسبّبت في تعطُّل التطبيق، ولا يظهر إلا في سلاسل التعليمات البرمجية الأصلية التي تعذّر تشغيلها
threads.signal_name سلسلة اسم الإشارة التي أدّت إلى تعطُّل التطبيق، ولا تظهر إلا في سلاسل التعليمات البرمجية الأصلية التي تعذّر تشغيلها
threads.subtitle سلسلة العنوان الفرعي لسلسلة المحادثات
threads.thread_name سلسلة اسم سلسلة المحادثات
threads.title سلسلة عنوان سلسلة المحادثات
unity_metadata.debug_build قيمة منطقية إذا كان هذا إصدارًا مخصّصًا لتصحيح الأخطاء
unity_metadata.graphics_copy_texture_support سلسلة إتاحة نسخ نسيج الرسومات كما هو محدّد في Unity API
unity_metadata.graphics_device_id INT64 معرّف جهاز الرسومات
unity_metadata.graphics_device_name سلسلة اسم جهاز الرسومات
unity_metadata.graphics_device_type سلسلة نوع جهاز الرسومات
unity_metadata.graphics_device_vendor_id INT64 معرّف مورّد معالج الرسومات
unity_metadata.graphics_device_vendor سلسلة مورّد جهاز الرسوميات
unity_metadata.graphics_device_version سلسلة إصدار جهاز الرسومات
unity_metadata.graphics_max_texture_size INT64 الحدّ الأقصى للحجم المخصّص لعرض النسيج
unity_metadata.graphics_memory_size_mb INT64 ذاكرة الرسومات بالميغابايت
unity_metadata.graphics_render_target_count INT64 عدد أهداف العرض الرسومي
unity_metadata.graphics_shader_level INT64 مستوى التظليل للرسومات
unity_metadata.processor_count INT64 عدد المعالجات (الأنوية)
unity_metadata.processor_frequency_mhz INT64 تمثّل هذه السمة تردد المعالجات بالميغاهرتز.
unity_metadata.processor_type سلسلة نوع المعالج
unity_metadata.screen_refresh_rate_hz INT64 معدّل إعادة تحميل الشاشة بالهرتز
unity_metadata.screen_resolution_dpi سلسلة تمثّل هذه السمة عدد النقاط لكل بوصة في الشاشة كعدد عشري.
unity_metadata.screen_size_px سلسلة حجم الشاشة بالبكسل، بتنسيق العرض × الارتفاع
unity_metadata.system_memory_size_mb INT64 حجم ذاكرة النظام بالميغابايت
unity_metadata.unity_version سلسلة إصدار Unity الذي يعمل على هذا الجهاز
user سجلّ (اختياري) المعلومات التي يتم جمعها عن مستخدم التطبيق
user.email سلسلة (اختياري) عنوان البريد الإلكتروني للمستخدم
user.id سلسلة (اختياري) معرّف خاص بالتطبيق ومرتبط بالمستخدم
user.name سلسلة (اختياري) اسم المستخدم
variant_id سلسلة نوع المشكلة المرتبط بهذا الحدث
يُرجى العِلم أنّه لا تتضمّن بعض الأحداث نوع مشكلة مرتبطًا بها.

مجموعة بيانات جلسات Firebase

يتم تصدير بيانات جلسات Firebase إلى مجموعة بيانات BigQuery باسم firebase_sessions. تغطي مجموعة البيانات مشروعك بالكامل، حتى إذا كان يتضمّن تطبيقات متعددة.

الجداول

تنشئ Firebase تلقائيًا جداول فردية داخل مجموعة بيانات جلسات Firebase لكل تطبيق في مشروعك مرتبط بـ BigQuery.

تتم تسمية الجداول استنادًا إلى معرّف التطبيق (مع تحويل النقاط إلى شرطات سفلية) وإضافة نظام التشغيل الخاص بالتطبيق (_IOS أو _ANDROID). على سبيل المثال، ستكون بيانات تطبيق Android الذي يحمل اسم الحزمة com.google.test في جدول باسم com_google_test_ANDROID.

الصفوف

يمثّل كل صف في الجدول حدث جلسة وقع.

الأعمدة

في حال تفعيل تصدير بيانات البث إلى BigQuery، سيتضمّن الجدول في الوقت الفعلي الأعمدة نفسها التي يتضمّنها جدول الدفعات.

في ما يلي الأعمدة ضِمن جدول بيانات جلسات Firebase التي تم تصديرها:

اسم الحقل نوع البيانات الوصف
instance_id سلسلة معرّف التثبيت في Firebase (FID) من الجهاز تحدّد هذه السمة عملية تثبيت فريدة للتطبيق على الجهاز.
session_id سلسلة المعرّف الفريد لهذه الجلسة
first_session_id سلسلة المعرّف الأول لسلسلة من الجلسات التي تنتمي إليها هذه الجلسة منذ بدء تشغيل التطبيق. يمكن استخدام هذا الحقل لتجميع كل الجلسات التي حدثت منذ بدء التشغيل البارد. إذا كانت هذه الجلسة هي الجلسة الأولى، سيكون هذا الحقل هو نفسه session_id.
session_index عدد صحيح الترتيب الذي تم استلام هذه الجلسة به بعد بدء تشغيل التطبيق على البارد بالنسبة إلى الجلسة الأولى بعد بدء التشغيل البارد، ستكون القيمة 0. سيتم زيادة الفهرس في كل مرة يتم فيها إنشاء جلسة بدون حدوث بدء تشغيل بارد (على سبيل المثال، بعد 30 دقيقة من عدم النشاط).
event_type سلسلة نوع الحدث الذي وقع في الجلسة (على سبيل المثال، SESSION_START)
event_timestamp الطابع الزمني وقت وقوع الحدث
received_timestamp الطابع الزمني الوقت الذي تلقّى فيه الخادم الحدث من الجهاز
performance_data_collection_enabled قيمة منطقية تحديد ما إذا كان قد تم تفعيل جمع البيانات في حزمة تطوير البرامج (SDK) الخاصة بخدمة "مراقبة الأداء في Firebase" في وقت الجلسة
crashlytics_data_collection_enabled قيمة منطقية تحديد ما إذا كانت ميزة جمع البيانات عبر حزمة تطوير البرامج (SDK) الخاصة بخدمة Firebase Crashlytics مفعّلة في وقت الجلسة
application سجلّ يصف التطبيق
application.build_version سلسلة إصدار بنية التطبيق (مثلاً، 1523456)
application.display_version سلسلة إصدار التطبيق المعروض (مثلاً، 4.1.7)
device سجلّ الجهاز الذي وقع فيه الحدث
device.model سلسلة طراز الجهاز
device.manufacturer سلسلة الشركة المصنّعة للجهاز بالنسبة إلى تطبيقات منصة Apple، سيكون هذا المعرّف هو NULL.
operating_system سجلّ توضّح هذه السمة نظام التشغيل على الجهاز
operating_system.display_version سلسلة تعرِض هذه السمة إصدار نظام التشغيل (مثلاً، 10.2.1)
operating_system.name سلسلة اسم نظام التشغيل
operating_system.type سلسلة نوع نظام التشغيل (على سبيل المثال، IOS). يتم ضبط هذا الحقل لأجهزة Apple فقط.
operating_system.device_type سلسلة نوع الجهاز (على سبيل المثال، MOBILE أو TABLET أو TV)


الترقية إلى البنية الأساسية الجديدة للتصدير

في منتصف تشرين الأول (أكتوبر) 2024، أطلقت Crashlytics بنية أساسية جديدة لتصدير الدُفعات من بيانات Crashlytics إلى BigQuery.

ستتم تلقائيًا ترقية جميع مشاريع Firebase إلى البنية الأساسية الجديدة لتصدير البيانات المجمّعة في أقرب وقت ممكن من 15 سبتمبر 2025. يمكنك الترقية قبل هذا التاريخ، ولكن تأكَّد من أنّ جداول الدفعة BigQuery تستوفي المتطلبات الأساسية للترقية.

يمكنك الترقية إلى البنية الأساسية الجديدة، ولكن تأكَّد من أنّ جداول الدفعات BigQuery تستوفي المتطلبات الأساسية للترقية.

تحديد ما إذا كنت تستخدم البنية الأساسية الجديدة

إذا فعّلت ميزة التصدير المجمّع في منتصف أكتوبر 2024 أو بعده، سيستخدم مشروعك على Firebase تلقائيًا البنية الأساسية الجديدة للتصدير.

يمكنك التحقّق من البنية الأساسية التي يستخدمها مشروعك: انتقِل إلى وحدة تحكّم Google Cloud، وإذا كان إعداد نقل البيانات يحمل التصنيف Firebase Crashlytics with Multi-Region Support، يعني ذلك أنّ مشروعك يستخدم بنية التصدير الأساسية الجديدة.

الاختلافات المهمة بين البنية الأساسية القديمة للتصدير والبنية الأساسية الجديدة للتصدير

  • تتيح البنية الأساسية الجديدة تحديد مواقع جغرافية لمجموعات البيانات خارج الولايات المتحدة.Crashlytics

    • تم تفعيل التصدير قبل منتصف أكتوبر 2024 وتمت الترقية إلى البنية الأساسية الجديدة للتصدير: يمكنك الآن تغيير الموقع الجغرافي لتصدير البيانات بشكل اختياري.

    • تم تفعيل التصدير في منتصف أكتوبر 2024 أو بعد ذلك: طُلب منك أثناء عملية الإعداد اختيار موقع جغرافي لتصدير البيانات.

  • لا تتيح البنية الأساسية الجديدة إعادة ملء البيانات من قبل تفعيل التصدير.

    • كانت البنية الأساسية القديمة تتيح إعادة تعبئة البيانات لمدة تصل إلى 30 يومًا قبل تاريخ تفعيل ميزة التصدير.

    • تتيح البنية الأساسية الجديدة إمكانية تعبئة البيانات السابقة لغاية آخر 30 يومًا أو لأحدث تاريخ فعّلت فيه ميزة التصدير إلى BigQuery (أيّهما أحدث).

  • تسمّي البنية الأساسية الجديدة جداول الدفعات باستخدام المعرّفات التي تم ضبطها لتطبيقات Firebase في مشروعك على Firebase.BigQuery

    • كانت البنية الأساسية القديمة تكتب البيانات في جداول مجمّعة بأسماء تستند إلى أرقام تعريف الحِزم أو أسماء الحِزم في الرمز الثنائي لتطبيقك.

    • تكتب البنية الأساسية الجديدة البيانات في جداول مجمّعة بأسماء تستند إلى أرقام تعريف الحِزم أو أسماء الحِزم المحدّدة لتطبيقات Firebase المسجّلة في مشروعك على Firebase.

الخطوة 1: المتطلبات الأساسية للترقية

  1. تأكَّد من أنّ جداول الدفعات BigQuery الحالية تستخدم معرّفات مطابقة لمعرّفات الحِزم أو أسماء الحِزم المحدّدة لتطبيقات Firebase المسجّلة في مشروعك على Firebase. في حال عدم تطابقها، قد تحدث انقطاعات في بيانات الدُفعات التي تم تصديرها. ستكون معظم المشاريع في حالة مناسبة ومتوافقة، ولكن من المهم التحقّق من ذلك قبل الترقية.

    • يمكنك العثور على جميع تطبيقات Firebase المسجّلة في مشروعك على Firebase في Firebase وحدة التحكّم: انتقِل إلى إعدادات المشروع، ثم انتقِل إلى بطاقة تطبيقاتك للاطّلاع على جميع تطبيقاتك على Firebase ومعلوماتها.

    • يمكنك العثور على جميع جداول الدفعات في BigQuery في صفحة BigQuery ضمن وحدة تحكّم Google Cloud.

    على سبيل المثال، إليك الحالات المثالية التي لن تواجه فيها أي مشاكل عند الترقية:

    • لديك جدول دفعات باسم com_yourcompany_yourproject_IOS وتطبيق Firebase iOS+ بمعرّف الحزمة com.yourcompany.yourproject مسجَّل في مشروعك على Firebase.

    • لديك جدول دفعي باسم com_yourcompany_yourproject_ANDROID وتطبيق Android على Firebase باسم الحزمة com.yourcompany.yourproject مسجَّل في مشروعك على Firebase.

  2. إذا كانت لديك أسماء جداول دفعية لا تتطابق مع المعرّفات التي تم ضبطها لتطبيقات Firebase المسجّلة، عليك اتّباع التعليمات الواردة لاحقًا في هذه الصفحة قبل الترقية يدويًا أو قبل 15 سبتمبر 2025 لتجنُّب حدوث انقطاع في عملية التصدير الدفعي.

الخطوة 2: الترقية يدويًا إلى البنية الأساسية الجديدة

إذا فعّلت ميزة التصدير المجمّع قبل منتصف أكتوبر 2024، يمكنك الترقية يدويًا إلى البنية الأساسية الجديدة من خلال إيقاف ميزة تصدير البيانات Crashlytics ثم إعادة تفعيلها في وحدة تحكّم Firebase.

في ما يلي الخطوات المفصّلة التي يجب اتّباعها:

  1. في وحدة تحكّم Firebase، انتقِل إلى صفحة عمليات الدمج.

  2. في بطاقة BigQuery، انقر على إدارة.

  3. انقر على شريط التمرير Crashlytics لإيقاف خيار التصدير. عندما يُطلب منك ذلك، أكِّد رغبتك في إيقاف عملية تصدير البيانات.

  4. أعِد تفعيل شريط التمرير Crashlytics على الفور لإعادة تفعيل التصدير. عندما يُطلب منك ذلك، أكِّد أنّك تريد تصدير البيانات.

    تستخدم عملية تصدير بيانات Crashlytics إلى BigQuery الآن البنية الأساسية الجديدة للتصدير.

لا يتطابق اسم جدول الدفعات الحالي مع معرّف تطبيق Firebase