داده های Firebase Crashlytics را به BigQuery صادر کنید

شما می‌توانید داده‌های Firebase Crashlytics خود را برای تجزیه و تحلیل بیشتر به BigQuery منتقل کنید. BigQuery به شما امکان می‌دهد داده‌ها را با استفاده از BigQuery SQL تجزیه و تحلیل کنید، آن را به یک ارائه دهنده ابری دیگر منتقل کنید و از آن برای تجسم و داشبوردهای سفارشی با Looker Studio استفاده کنید.

با داده‌های صادر شده چه کاری می‌توانید انجام دهید؟

خروجی‌ها به BigQuery حاوی داده‌های خام خرابی شامل نوع دستگاه، سیستم عامل، استثنائات (برنامه‌های اندروید) یا خطاها (برنامه‌های اپل) و گزارش‌های Crashlytics و همچنین سایر داده‌ها هستند. می‌توانید بعداً در این صفحه، دقیقاً داده‌های Crashlytics خروجی گرفته شده و طرح جدول آن را بررسی کنید.

در اینجا چند نمونه از کارهایی که می‌توانید با داده‌های Crashlytics صادر شده خود انجام دهید، آورده شده است:

  • اجرای کوئری‌ها
    شما می‌توانید کوئری‌هایی را روی داده‌های Crashlytics خود اجرا کنید تا گزارش‌هایی تولید کنید که داده‌های رویداد خرابی را در خلاصه‌هایی که فهم آنها آسان‌تر است، جمع‌آوری می‌کنند. از آنجایی که این نوع گزارش‌ها در داشبورد Crashlytics کنسول Firebase در دسترس نیستند، می‌توانند تجزیه و تحلیل و درک شما از داده‌های خرابی را تکمیل کنند. در ادامه این صفحه، مجموعه‌ای از کوئری‌های نمونه را خواهید یافت.

  • از یک الگوی Looker Studio استفاده کنید
    Crashlytics یک الگوی از پیش ساخته شده Looker Studio برای تجسم داده‌های خروجی شما ارائه می‌دهد.

  • ایجاد نماها
    با استفاده از رابط کاربری BigQuery ، می‌توانید یک نما (view) ایجاد کنید که یک جدول مجازی است که توسط یک کوئری SQL تعریف می‌شود. برای دستورالعمل‌های دقیق در مورد انواع مختلف نماها و نحوه ایجاد آنها، به مستندات BigQuery مراجعه کنید.

  • داده‌های مخصوص Crashlytics با داده‌های جلسات Firebase ترکیب کنید
    همچنین می‌توانید هنگام تنظیم خروجی داده‌های Crashlytics ، داده‌های جلسات Firebase را خروجی بگیرید. از داده‌های این جلسات برای بهبود درک کاربران بدون خرابی و جلسات بدون خرابی استفاده کنید.

مزایای خروجی گرفتن از استریم به BigQuery

به طور پیش‌فرض، داده‌ها به صورت روزانه و دسته‌ای به BigQuery صادر می‌شوند. علاوه بر این، می‌توانید داده‌های Crashlytics و جلسات Firebase خود را به صورت بلادرنگ با BigQuery streaming پخش کنید. می‌توانید از آن برای هر هدفی که نیاز به داده‌های زنده دارد، مانند ارائه اطلاعات در یک داشبورد زنده، تماشای یک به‌روزرسانی به صورت زنده یا نظارت بر مشکلات برنامه که باعث ایجاد هشدارها و گردش‌های کاری سفارشی می‌شوند، استفاده کنید.

وقتی قابلیت ارسال جریانی به BigQuery را فعال می‌کنید، جداول بلادرنگ (Realtime) نیز خواهید داشت (علاوه بر جداول دسته‌ای). هر دو نوع جدول، طرح مجموعه داده یکسانی خواهند داشت، اما در اینجا چند تفاوت مهم بین جداول دسته‌ای و جداول بلادرنگ وجود دارد:

جدول دسته‌ای جدول بی‌درنگ
  • داده‌ها روزی یک بار صادر می‌شوند.
  • رویدادها قبل از نوشتن دسته‌ای در BigQuery به طور پایدار ذخیره می‌شوند.
  • داده‌ها را می‌توان تا 30 روز قبل* دوباره پر کرد .
  • داده‌ها به صورت بلادرنگ (Realtime) صادر می‌شوند.
  • امکان پر کردن مجدد وجود ندارد.

جدول دسته‌ای برای تحلیل بلندمدت و شناسایی روندها در طول زمان ایده‌آل است، زیرا ما رویدادها را قبل از نوشتن به طور مداوم ذخیره می‌کنیم و می‌توان آن‌ها را تا 30 روز* در جدول ذخیره کرد. وقتی داده‌ها را در جدول بلادرنگ شما می‌نویسیم، بلافاصله آن را در BigQuery می‌نویسیم و بنابراین برای داشبوردهای زنده و هشدارهای سفارشی ایده‌آل است. این دو جدول را می‌توان با یک کوئری دوخت ترکیب کرد تا از مزایای هر دو بهره‌مند شوید.

به طور پیش‌فرض، جدول realtime دارای زمان انقضای پارتیشن 30 روزه است. برای یادگیری نحوه تغییر این زمان، به بخش تنظیم انقضای پارتیشن در مستندات BigQuery مراجعه کنید.

* جزئیات مربوط به پشتیبانی از پر کردن مجدد را در ارتقاء به زیرساخت صادرات جدید مشاهده کنید.


فعال کردن صادرات به BigQuery

  1. در کنسول Firebase ، به صفحه Integrations بروید.

  2. در کارت BigQuery ، روی پیوند (Link) کلیک کنید.

  3. برای فعال کردن خروجی گرفتن به BigQuery دستورالعمل‌های روی صفحه را دنبال کنید، از جمله گزینه‌های زیر:

وقتی export رو ​​فعال می‌کنی چه اتفاقی می‌افته؟

  • فایربیس داده‌ها را از برنامه‌های مرتبط با BigQuery استخراج می‌کند.

    • در طول راه‌اندازی، به‌طور پیش‌فرض، تمام برنامه‌های پروژه شما به BigQuery لینک می‌شوند، اما می‌توانید انتخاب کنید که برنامه‌های خاص در طول راه‌اندازی لینک نشوند .

    • هر برنامه‌ای که بعداً به پروژه Firebase خود اضافه کنید، به‌طور خودکار به BigQuery پیوند داده می‌شود.

    • در هر زمانی، می‌توانید مدیریت کنید که کدام برنامه‌ها داده‌ها را صادر کنند .

  • فایربیس داده‌ها را به محل مجموعه داده‌ای که هنگام راه‌اندازی انتخاب کرده‌اید، صادر می‌کند.

    • این مکان هم برای مجموعه داده Crashlytics و هم برای مجموعه داده Sessions در Firebase (در صورتی که داده‌های Session برای خروجی گرفتن فعال باشد) اعمال می‌شود.

    • این مکان فقط برای داده‌های صادر شده به BigQuery قابل استفاده است و تاثیری بر مکان داده‌های ذخیره شده برای استفاده در داشبورد Crashlytics کنسول Firebase یا در Android Studio ندارد.

    • پس از ایجاد یک مجموعه داده، مکان آن قابل تغییر نیست، اما می‌توانید مجموعه داده را در مکان دیگری کپی کنید یا به صورت دستی مجموعه داده را در مکان دیگری جابجا (بازسازی) کنید. برای کسب اطلاعات بیشتر، به تغییر مکان برای صادرات موجود مراجعه کنید.

  • فایربیس همگام‌سازی‌های روزانه داده‌های دسته‌ای شما را با BigQuery تنظیم می‌کند.

    • پس از اتصال به BigQuery ، ممکن است خروجی اولیه داده‌های دسته‌ای تا ۴۸ ساعت طول بکشد.

    • همگام‌سازی روزانه، صرف نظر از هرگونه صادرات برنامه‌ریزی‌شده‌ای که ممکن است در BigQuery تنظیم کرده باشید، یک بار در روز اتفاق می‌افتد. توجه داشته باشید که زمان و مدت زمان کار همگام‌سازی می‌تواند تغییر کند، بنابراین توصیه نمی‌کنیم عملیات یا کارهای پایین‌دستی را بر اساس زمان‌بندی خاصی از صادرات برنامه‌ریزی کنید.

  • فایربیس یک کپی از داده‌های موجود شما را به BigQuery ارسال می‌کند.

    • برای هر برنامه‌ی لینک‌شده، این خروجی شامل یک جدول دسته‌ای است که شامل داده‌های همگام‌سازی روزانه است.

    • شما می‌توانید به صورت دستی، زمان‌بندی‌های تکمیل داده‌ها را برای جدول دسته‌ای تا 30 روز گذشته یا برای جدیدترین تاریخی که امکان صادرات به BigQuery را فعال کرده‌اید (هر کدام که جدیدتر باشد) برنامه‌ریزی کنید.

    توجه داشته باشید که اگر قبل از اواسط اکتبر ۲۰۲۴، خروجی گرفتن از داده‌های Crashlytics را فعال کرده باشید، می‌توانید ۳۰ روز قبل از روزی که خروجی گرفتن را فعال کرده‌اید، دوباره اطلاعات را پر کنید.

  • موارد زیر در صورت فعال کردن خروجی استریمینگ به BigQuery اعمال می‌شود.

    • هر برنامه‌ی لینک‌شده، جدول بی‌درنگ مخصوص به خود را نیز خواهد داشت که شامل داده‌های دائماً در حال به‌روزرسانی است (علاوه بر جدول دسته‌ای برنامه برای خروجی گرفتن روزانه از دسته‌ها).

    • پس از فعال کردن پخش، ممکن است تا ۱ ساعت طول بکشد تا پخش داده‌ها شروع شود.


مثال‌های پرسشی

مثال ۱: محاسبه معیارهای بدون خرابی با استفاده از داده‌های جلسات Firebase

در آخرین نسخه خود، شما یک به‌روزرسانی اساسی در برنامه خود انجام داده‌اید تا مشکلات مربوط به خرابی‌ها در یک سفر کاربری حیاتی را برطرف کنید. شما نظرات فوق‌العاده‌ای از کاربران دریافت کرده‌اید، اما به شواهد کمی نیاز دارید که نشان دهد برنامه شما نسبت به قبل پایدارتر شده است.

معیارهای بدون خرابی می‌توانند به ارائه این اطلاعات کمک کنند. این معیارها، معیارهای مهمی هستند که به شما در درک سلامت کلی برنامه‌تان کمک می‌کنند. با داده‌های جلسات Firebase و رویدادهای Crashlytics ، می‌توانید این معیارها را با یک پرس‌وجوی ساده محاسبه کنید.

در اینجا نمونه‌هایی از کوئری‌ها برای یک برنامه اندروید آورده شده است. برای یک برنامه 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

مثال ۲: خرابی‌ها بر اساس روز

بعد از تلاش برای رفع هرچه بیشتر اشکالات، فکر می‌کنید تیم شما بالاخره آماده است تا برنامه جدید اشتراک‌گذاری عکس شما را راه‌اندازی کند. قبل از انجام این کار، می‌خواهید تعداد خرابی‌های روزانه را در ماه گذشته بررسی کنید تا مطمئن شوید که رفع اشکالات، برنامه را در طول زمان پایدارتر کرده است.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۳: فراگیرترین خرابی‌ها را پیدا کنید

برای اولویت‌بندی صحیح برنامه‌های تولید، باید 10 مورد از رایج‌ترین خرابی‌ها را در برنامه خود پیدا کنید. شما یک پرس‌وجو ایجاد می‌کنید که نکات مربوط به داده‌ها را ارائه می‌دهد.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۴: ۱۰ دستگاهی که بیشترین خرابی را دارند

پاییز فصل گوشی‌های جدید است! شرکت شما می‌داند که این به معنای فصل مشکلات جدید مختص دستگاه‌ها - به خصوص برای اندروید - نیز هست. برای جلوگیری از نگرانی‌های مربوط به سازگاری قریب‌الوقوع، شما یک کوئری (پرس‌وجو) ایجاد می‌کنید که 10 دستگاهی را که بیشترین خرابی را در هفته گذشته (168 ساعت) تجربه کرده‌اند، شناسایی می‌کند.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۵: فیلتر بر اساس کلید سفارشی

شما یک توسعه‌دهنده بازی هستید که می‌خواهید بدانید کدام سطح از بازی شما بیشترین خرابی را تجربه می‌کند.

برای کمک به ردیابی این آمار، شما یک کلید سفارشی Crashlytics به نام current_level تنظیم می‌کنید و هر بار که کاربر به سطح جدیدی می‌رسد، آن را به‌روزرسانی می‌کنید.

سویفت 

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

هدف-سی 

CrashlyticsKit setIntValue:3 forKey:@"current_level";

جاوا 

Crashlytics.setInt("current_level", 3);

با استفاده از آن کلید در خروجی خود به BigQuery ، می‌توانید یک کوئری بنویسید تا توزیع مقادیر current_level مرتبط با هر رویداد خرابی را گزارش دهد.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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

مثال ۶: استخراج شناسه کاربر

شما یک برنامه اندروید در مرحله دسترسی زودهنگام دارید. اکثر کاربران شما آن را دوست دارند، اما سه نفر از آنها تعداد غیرمعمولی از خرابی‌ها را تجربه کرده‌اند. برای رسیدن به ریشه مشکل، شما یک کوئری می‌نویسید که تمام رویدادهای خرابی را برای آن کاربران، با استفاده از شناسه کاربری آنها، استخراج می‌کند.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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

مثال ۷: یافتن تمام کاربرانی که با یک مشکل خرابی خاص مواجه هستند

تیم شما به‌طور تصادفی یک اشکال بحرانی را برای گروهی از آزمایش‌کنندگان بتا منتشر کرده است. تیم شما توانست با استفاده از پرس‌وجوی مثال «یافتن فراگیرترین خرابی‌ها» در بالا، شناسه مشکل خرابی خاص را شناسایی کند. اکنون تیم شما می‌خواهد یک پرس‌وجو برای استخراج لیست کاربران برنامه که تحت تأثیر این خرابی قرار گرفته‌اند، اجرا کند.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۸: تعداد کاربرانی که تحت تأثیر مشکل خرابی قرار گرفته‌اند، به تفکیک کشور

تیم شما در طول انتشار یک نسخه جدید، یک اشکال بحرانی را شناسایی کرده است. شما توانستید از پرس و جوی مثال "یافتن فراگیرترین خرابی‌ها" در بالا برای شناسایی شناسه مشکل خرابی خاص استفاده کنید. تیم شما اکنون می‌خواهد ببیند که آیا این خرابی به کاربران در کشورهای مختلف جهان سرایت کرده است یا خیر.

برای نوشتن این پرس و جو، تیم شما باید موارد زیر را انجام دهد:

  1. فعال کردن خروجی گرفتن از داده‌های Google Analytics به BigQuery . به بخش خروجی گرفتن از داده‌های پروژه به BigQuery مراجعه کنید.

  2. برنامه خود را به‌روزرسانی کنید تا یک شناسه کاربری را هم به Google Analytics SDK و هم به Crashlytics SDK ارسال کند.

    سویفت 

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

    هدف-سی 

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

    جاوا 

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

  3. یک کوئری بنویسید که از فیلد شناسه کاربری برای اتصال رویدادهای مجموعه داده Google Analytics به رویدادهای خرابی در مجموعه داده Crashlytics استفاده کند.

    در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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

مثال ۹: ۵ شماره برتر تا به امروز

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۱۰: ۵ شماره برتر از تاریخ DATE، شامل امروز

همچنین می‌توانید جداول batch و realtime را با یک کوئری stitching ترکیب کنید تا اطلاعات realtime را به داده‌های batch قابل اعتماد اضافه کنید. از آنجایی که event_id یک کلید اصلی است، می‌توانید از DISTINCT event_id برای dedupe کردن هرگونه رویداد مشترک از دو جدول استفاده کنید.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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 streaming export to BigQuery را فعال کرده باشید، می‌توانید آن داده‌ها را در صفحه روندهای Realtime قالب Looker Studio مشاهده کنید. می‌توانید از این نمونه به عنوان یک الگو برای ایجاد سریع گزارش‌ها و تجسم‌های جدید بر اساس داده‌های خام خرابی برنامه خود استفاده کنید:

  1. الگوی داشبورد Crashlytics Looker Studio را باز کنید.

  2. روی «استفاده از الگو» در گوشه بالا سمت راست کلیک کنید.

  3. در منوی کشویی منبع داده جدید ، گزینه ایجاد منبع داده جدید را انتخاب کنید.

  4. روی گزینه‌ی «انتخاب» در کارت BigQuery کلیک کنید.

  5. با انتخاب My Projects > PROJECT_ID > firebase_crashlytics > TABLE_NAME ، جدولی حاوی داده‌های خروجی Crashlytics انتخاب کنید.

    جدول دسته‌ای شما همیشه برای انتخاب در دسترس است. اگر قابلیت ارسال خروجی Crashlytics به BigQuery فعال باشد، می‌توانید جدول بلادرنگ خود را انتخاب کنید.

  6. در قسمت پیکربندی ، سطح قالب Crashlytics را روی پیش‌فرض تنظیم کنید.

  7. برای ایجاد منبع داده جدید، روی «اتصال» کلیک کنید.

  8. برای بازگشت به الگوی Crashlytics ، روی «افزودن به گزارش» کلیک کنید.

  9. در نهایت، روی ایجاد گزارش کلیک کنید تا نسخه خود از الگوی داشبورد Crashlytics Looker Studio ایجاد شود.


آشنایی با طرحواره (schema) در BigQuery

فایربیس برای داده‌های اکسپورت شده شما، مجموعه داده‌های جدیدی در BigQuery ایجاد می‌کند:

مجموعه داده Crashlytics

داده‌های Crashlytics به یک مجموعه داده BigQuery به نام firebase_crashlytics منتقل می‌شوند. این مجموعه داده کل پروژه شما را پوشش می‌دهد، حتی اگر چندین برنامه داشته باشد.

جداول

به طور پیش‌فرض، فایربیس برای هر برنامه در پروژه شما که به BigQuery لینک شده است، جداول جداگانه‌ای را در مجموعه داده‌های Crashlytics ایجاد می‌کند.

جداول بر اساس شناسه برنامه (با تبدیل نقطه به زیرخط) نامگذاری شده و پلتفرم برنامه ( _IOS یا _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 آدرس موجود در تصویر دودویی که حاوی کد است
برای فریم‌های جاوا تنظیم نشده است
blame_frame.blamed بولی اینکه آیا Crashlytics تشخیص داده است که این فریم علت خرابی یا خطا است یا خیر
blame_frame.file رشته نام فایل فریم
blame_frame.library رشته نام نمایشی کتابخانه‌ای که شامل قاب است
blame_frame.line INT64 شماره خط فایل فریم
blame_frame.offset INT64 بایت آفست به تصویر دودویی که حاوی کد است
برای استثنائات جاوا تنظیم نشده است
blame_frame.owner رشته برای مثال، DEVELOPER ، VENDOR ، RUNTIME ، PLATFORM یا SYSTEM
blame_frame.symbol رشته نماد هیدراته یا نماد خام در صورت عدم هیدراته بودن
breadcrumbs رکورد تکرار شده در صورت فعال بودن، مسیریاب‌های Google Analytics با مهر زمانی
breadcrumbs.name رشته نام مرتبط با بردکرامب
breadcrumbs.params رکورد تکرار شده پارامترهای مرتبط با breadcrumb
breadcrumbs.params.key رشته یک کلید پارامتر مرتبط با breadcrumb
breadcrumbs.params.value رشته مقدار پارامتر مرتبط با breadcrumb
breadcrumbs.timestamp مهر زمانی مهر زمانی مرتبط با breadcrumb
bundle_identifier رشته شناسه منحصر به فرد برای برنامه همانطور که در پروژه Firebase ثبت شده است (برای مثال، com.google.gmail )
برای برنامه‌های پلتفرم اپل، این شناسه بسته (bundle ID) برنامه است.
برای برنامه‌های اندروید، این نام بسته‌ی برنامه است.
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 رکورد تکرار شده (فقط برنامه‌های اپل) خطاهای غیرمهلک
error_type رشته نوع خطای رویداد (برای مثال، FATAL ، NON_FATAL ، ANR و غیره)
error.blamed بولی آیا Crashlytics تشخیص داده است که این فریم علت خطا است یا خیر
error.code INT64 کد خطای مرتبط با NSError ثبت‌شده‌ی سفارشی برنامه
error.frames رکورد تکرار شده فریم‌های stacktrace
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 رکورد تکرار شده (فقط اندروید) استثناهایی که در طول این رویداد رخ داده‌اند. استثناهای تو در تو به ترتیب زمانی معکوس نمایش داده می‌شوند، به این معنی که آخرین رکورد، اولین استثنای رخ داده است.
exceptions.blamed بولی اگر Crashlytics تشخیص دهد که استثنا مسئول خطا یا خرابی است، صحیح است.
exceptions.exception_message رشته پیامی مرتبط با استثنا
exceptions.frames رکورد تکرار شده فریم‌های مرتبط با استثنا
exceptions.frames.address INT64 آدرس موجود در تصویر دودویی که حاوی کد است
برای فریم‌های جاوا تنظیم نشده است
exceptions.frames.blamed بولی اینکه آیا Crashlytics تشخیص داده است که این فریم علت خرابی یا خطا است یا خیر
exceptions.frames.file رشته نام فایل فریم
exceptions.frames.library رشته نام نمایشی کتابخانه‌ای که شامل قاب است
exceptions.frames.line INT64 شماره خط فایل فریم
exceptions.frames.offset INT64 بایت آفست به تصویر دودویی که حاوی کد است
برای استثنائات جاوا تنظیم نشده است
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 رشته (فقط برنامه‌های اپل) نوع سیستم عامل در حال اجرا روی دستگاه (مثلاً IOS ، MACOS و غیره)
platform رشته پلتفرم برنامه همانطور که در پروژه Firebase ثبت شده است (مقادیر معتبر: IOS یا ANDROID )
process_state رشته BACKGROUND یا FOREGROUND
storage رکورد حافظه دائمی دستگاه
storage.free INT64 بایت‌های فضای ذخیره‌سازی باقی‌مانده
storage.used INT64 بایت‌های فضای ذخیره‌سازی استفاده شده
threads رکورد تکرار شده موضوعات موجود در زمان رویداد
threads.blamed بولی اینکه آیا Crashlytics تشخیص داده است که این فریم علت خرابی یا خطا است یا خیر
threads.code INT64 (فقط برنامه‌های اپل) کد خطای 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 رشته (فقط برنامه‌های اپل) صفی که رشته در آن اجرا می‌شد
threads.signal_code رشته کد سیگنالی که باعث خرابی برنامه شده است؛ فقط در نخ‌های بومی خراب‌شده وجود دارد
threads.signal_name رشته نام سیگنالی که باعث خرابی برنامه شده است، فقط در نخ‌های بومی خراب‌شده وجود دارد
threads.subtitle رشته زیرعنوان تاپیک
threads.thread_name رشته نام تاپیک
threads.title رشته عنوان تاپیک
unity_metadata.debug_build بولی اگر این یک ساخت اشکال‌زدایی است
unity_metadata.graphics_copy_texture_support رشته پشتیبانی از کپی کردن بافت گرافیکی همانطور که در 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 رشته DPI صفحه نمایش به عنوان یک عدد ممیز شناور
unity_metadata.screen_size_px رشته اندازه صفحه نمایش بر حسب پیکسل، با فرمت عرض × ارتفاع
unity_metadata.system_memory_size_mb INT64 اندازه حافظه سیستم بر حسب مگابایت
unity_metadata.unity_version رشته نسخه یونیتی که روی این دستگاه اجرا می‌شود
user رکورد (اختیاری) اطلاعات جمع‌آوری‌شده درباره کاربر برنامه
user.email رشته (اختیاری) آدرس ایمیل کاربر
user.id رشته (اختیاری) یک شناسه مخصوص برنامه که به کاربر مرتبط است
user.name رشته (اختیاری) نام کاربر
variant_id رشته نوع مشکل مرتبط با این رویداد
توجه داشته باشید که همه رویدادها دارای یک نوع مشکل مرتبط نیستند.

مجموعه داده‌های جلسات فایربیس

داده‌های جلسات Firebase به یک مجموعه داده BigQuery به نام firebase_sessions صادر می‌شوند. این مجموعه داده کل پروژه شما را پوشش می‌دهد، حتی اگر چندین برنامه داشته باشد.

جداول

به طور پیش‌فرض، فایربیس برای هر برنامه در پروژه شما که به BigQuery لینک شده است، جداول جداگانه‌ای را در مجموعه داده‌های جلسات فایربیس ایجاد می‌کند.

جداول بر اساس شناسه برنامه (با تبدیل نقطه به زیرخط) نامگذاری شده و پلتفرم برنامه ( _IOS یا _ANDROID ) به آنها اضافه می‌شود. برای مثال، داده‌های یک برنامه اندروید با نام بسته com.google.test در جدولی با نام com_google_test_ANDROID قرار می‌گیرند.

ردیف‌ها

هر ردیف در یک جدول نشان دهنده یک رویداد جلسه است که اتفاق افتاده است.

ستون‌ها

اگر ارسال جریانی به BigQuery فعال باشد، جدول بی‌درنگ ستون‌های مشابه جدول دسته‌ای را خواهد داشت.

ستون‌های درون جدول مربوط به داده‌های جلسات خروجی فایربیس به شرح زیر است:

نام فیلد نوع داده توضیحات
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 بولی آیا جمع‌آوری داده‌های Firebase Performance Monitoring SDK در زمان جلسه فعال بوده است یا خیر
crashlytics_data_collection_enabled بولی اینکه آیا جمع‌آوری داده‌های Firebase Crashlytics SDK در زمان جلسه فعال بوده است یا خیر
application رکورد برنامه را شرح می‌دهد
application.build_version رشته نسخه ساخت برنامه (برای مثال، 1523456 )
application.display_version رشته نسخه نمایشی برنامه (برای مثال، 4.1.7 )
device رکورد دستگاهی که رویداد روی آن رخ داده است
device.model رشته مدل دستگاه
device.manufacturer رشته سازنده دستگاه. برای برنامه‌های پلتفرم اپل، این مقدار NULL خواهد بود.
operating_system رکورد سیستم عامل دستگاه را شرح می‌دهد
operating_system.display_version رشته نسخه نمایشی سیستم عامل (برای مثال، 10.2.1 )
operating_system.name رشته نام سیستم عامل
operating_system.type رشته نوع سیستم عامل (مثلاً IOS ). این فیلد فقط برای دستگاه‌های اپل تنظیم شده است.
operating_system.device_type رشته نوع دستگاه (مثلاً MOBILE ، TABLET ، TV )


ارتقاء به زیرساخت‌های صادراتی جدید

در اواسط اکتبر ۲۰۲۴، Crashlytics زیرساخت جدیدی را برای صادرات دسته‌ای داده‌های Crashlytics به BigQuery راه‌اندازی کرد.

تمام پروژه‌های فایربیس از ۱۵ سپتامبر ۲۰۲۵ به طور خودکار به زیرساخت جدید صادرات دسته‌ای ارتقا خواهند یافت. می‌توانید قبل از این تاریخ ارتقا دهید ، اما مطمئن شوید که جداول دسته‌ای BigQuery شما پیش‌نیازهای ارتقا را برآورده می‌کنند.

شما می‌توانید به زیرساخت جدید ارتقا دهید ، اما مطمئن شوید که جداول دسته‌ای BigQuery شما پیش‌نیازهای ارتقا را برآورده می‌کنند.

مشخص کنید که آیا روی زیرساخت جدید هستید یا خیر

اگر صادرات دسته‌ای را در اواسط اکتبر ۲۰۲۴ یا بعد از آن فعال کرده باشید، پروژه Firebase شما به طور خودکار از زیرساخت صادرات جدید استفاده می‌کند.

می‌توانید بررسی کنید که پروژه شما از کدام زیرساخت استفاده می‌کند: به کنسول Google Cloud بروید و اگر "پیکربندی انتقال داده" شما با عنوان Firebase Crashlytics with Multi-Region Support برچسب‌گذاری شده باشد، پروژه شما از زیرساخت صادرات جدید استفاده می‌کند.

تفاوت‌های مهم بین زیرساخت‌های صادراتی قدیمی و زیرساخت‌های صادراتی جدید

  • زیرساخت جدید از مجموعه داده‌های Crashlytics در مکان‌های خارج از ایالات متحده پشتیبانی می‌کند.

    • صادرات قبل از اواسط اکتبر ۲۰۲۴ فعال شده و به زیرساخت صادرات جدید ارتقا یافته است - اکنون می‌توانید به صورت اختیاری مکان صادرات داده‌ها را تغییر دهید .

    • فعال‌سازی صادرات در اواسط اکتبر ۲۰۲۴ یا بعد از آن — در هنگام راه‌اندازی از شما خواسته شد تا مکانی را برای صادرات داده‌ها انتخاب کنید.

  • زیرساخت جدید از پر کردن مجدد داده‌های مربوط به قبل از فعال کردن قابلیت خروجی گرفتن پشتیبانی نمی‌کند.

    • زیرساخت قدیمی تا 30 روز قبل از تاریخی که شما صادرات را فعال کردید، از پر کردن مجدد پشتیبانی می‌کرد.

    • زیرساخت جدید از پر کردن مجدد داده‌ها تا 30 روز گذشته یا برای جدیدترین تاریخی که امکان صادرات به BigQuery را فعال کرده‌اید (هر کدام که جدیدتر باشد) پشتیبانی می‌کند.

  • این زیرساخت جدید، جداول دسته‌ای BigQuery را با استفاده از شناسه‌های تعیین‌شده برای برنامه‌های Firebase شما در پروژه Firebase نامگذاری می‌کند.

    • زیرساخت قدیمی، داده‌ها را در جداول دسته‌ای با نام‌هایی بر اساس شناسه‌های بسته یا نام‌های بسته در فایل باینری برنامه شما می‌نوشت.

    • زیرساخت جدید، داده‌ها را در جداول دسته‌ای با نام‌هایی بر اساس شناسه‌های بسته یا نام‌های بسته تنظیم‌شده برای برنامه‌های Firebase ثبت‌شده شما در پروژه Firebase می‌نویسد.

مرحله ۱ : پیش‌نیازهای ارتقاء

  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 و یک برنامه اندروید Firebase با نام بسته com.yourcompany.yourproject در پروژه Firebase خود ثبت کرده‌اید.

  2. If you have batch table names that do not match the identifiers set for your registered Firebase Apps, then follow the instructions later on this page before manually upgrading or before September 15, 2025 to avoid disruption to your batch export.

Step 2 : Manually upgrade to the new infrastructure

If you enabled batch export before mid-October 2024, then you can manually upgrade to the new infrastructure simply by toggling Crashlytics data export off and then on again in the Firebase console.

Here are the detailed steps:

  1. In the Firebase console, go to the Integrations page .

  2. In the BigQuery card, click Manage .

  3. Toggle off the Crashlytics slider to disable export. When prompted, confirm that you want data export to stop.

  4. Immediately toggle on again the Crashlytics slider to re-enable export. When prompted, confirm that you want to export data.

    Your Crashlytics data export to BigQuery is now using the new export infrastructure.

Your existing batch table name doesn't match your Firebase App identifier