Экспорт данных Firebase Crashlytics в BigQuery

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 и обновляете его каждый раз, когда пользователь достигает нового уровня.

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

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. Обновите свое приложение, чтобы передавать идентификатор пользователя как в Google Analytics SDK, так и в Crashlytics SDK.

   Быстрый

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

   Objective-C

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

   Ява

   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

• Набор данных сеансов Firebase (если данные сеансов включены для экспорта)

Набор данных 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 :

Набор данных сеансов Firebase

Данные сеансов Firebase экспортируются в набор данных BigQuery с именем firebase_sessions . Этот набор данных охватывает весь ваш проект, даже если он состоит из нескольких приложений.

Таблицы

По умолчанию Firebase создает отдельные таблицы внутри набора данных сеансов Firebase для каждого приложения в вашем проекте, связанного с BigQuery .

Имена таблиц формируются на основе идентификатора приложения (точки заменяются подчёркиваниями) с добавлением платформы приложения ( _IOS или _ANDROID ). Например, данные для приложения Android с именем пакета com.google.test будут находиться в таблице с именем com_google_test_ANDROID .

Ряды

Каждая строка в таблице представляет собой произошедшее событие сеанса.

Колонны

Если включен потоковый экспорт в BigQuery , то таблица реального времени будет иметь те же столбцы, что и пакетная таблица.

Вот столбцы в таблице для экспортированных данных сеансов Firebase:

Переход на новую экспортную инфраструктуру

В середине октября 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 (в зависимости от того, какая дата наступила позже).

• Новая инфраструктура именует пакетные таблицы BigQuery используя идентификаторы, заданные для ваших приложений Firebase в вашем проекте Firebase.

  • Старая инфраструктура записывала данные в пакетные таблицы с именами, основанными на идентификаторах пакетов или именах пакетов в двоичном файле вашего приложения .

  • Новая инфраструктура записывает данные в пакетные таблицы с именами, основанными на идентификаторах пакетов или именах пакетов , установленных для зарегистрированных приложений Firebase в вашем проекте Firebase .

Шаг 1 : Предварительное условие для обновления

1. Убедитесь, что в ваших существующих пакетных таблицах BigQuery используются идентификаторы, соответствующие идентификаторам пакетов или именам пакетов , заданным для зарегистрированных приложений Firebase в вашем проекте Firebase . Если они не совпадают, могут возникнуть сбои в экспортированных пакетных данных. Большинство проектов будут находиться в корректном и совместимом состоянии, но перед обновлением важно проверить это.

   • Все приложения Firebase, зарегистрированные в вашем проекте Firebase, можно найти в консоли Firebase : перейдите в настройки settings проекта , затем прокрутите до карточки Ваши приложения , чтобы увидеть все ваши приложения Firebase и их информацию.

   • Все таблицы пакетных заданий BigQuery можно найти на странице BigQuery консоли Google Cloud .

   Например, вот идеальные штаты, в которых у вас не возникнет проблем с обновлением:

   • У вас есть пакетная таблица с именем com_yourcompany_yourproject_IOS и приложение Firebase iOS+ с идентификатором пакета com.yourcompany.yourproject зарегистрированным в вашем проекте Firebase.

   • У вас есть пакетная таблица с именем com_yourcompany_yourproject_ANDROID и приложение Firebase Android с именем пакета com.yourcompany.yourproject зарегистрированное в вашем проекте Firebase.

2. Если имена ваших пакетных таблиц не соответствуют идентификаторам, установленным для ваших зарегистрированных приложений Firebase, следуйте инструкциям, приведенным далее на этой странице , прежде чем выполнять обновление вручную или до 15 сентября 2025 г., чтобы избежать сбоев в пакетном экспорте.

Шаг 2 : Выполните обновление до новой инфраструктуры вручную

Если вы включили пакетный экспорт до середины октября 2024 года, то вы можете вручную перейти на новую инфраструктуру, просто отключив и снова включив экспорт данных Crashlytics в консоли Firebase .

Вот подробные шаги:

1. В консоли Firebase перейдите на страницу Интеграции .

2. На карточке BigQuery нажмите Управление .

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