Выполнять SQL-запросы к экспортированным данным в BigQuery

После того как вы экспортируете данные сеансов Crashlytics и (при необходимости) Firebase в BigQuery, вы можете начать работу с ними:

  • Анализ данных с помощью SQL-запросов
    Вы можете выполнять запросы к данным Crashlytics, чтобы создавать специальные отчеты и сводки. Поскольку такие специальные отчеты недоступны на панели управления Crashlytics консоли Firebase, они могут дополнить ваш анализ и помочь лучше понять данные о сбоях. Ниже на этой странице приведены примеры запросов.

  • Объединение данных из разных наборов
    Например, если при настройке экспорта данных Crashlyticsвы выбрали экспорт данных о сеансах Firebase, то сможете лучше понять, что такое пользователи без сбоев и сеансы без сбоев (см. пример запроса). Кроме того, вы можете экспортировать данные из различных продуктов Firebase (например, Performance Monitoring) или из Google Analytics, а затем объединять и анализировать их в BigQuery вместе с данными Crashlytics.

  • Создание представлений
    В интерфейсе BigQuery можно создать представление – виртуальную таблицу, определяемую SQL-запросом. Подробные инструкции о разных типах представлений и способах их создания можно найти в документации по BigQuery.

Подробнее о схеме набора данных для экспортированных данных в BigQuery…

SQL в BigQuery

Примеры запросов для данных Crashlytics

В этом разделе приведены примеры ситуаций и запросов, которые показывают, как использовать BigQuery SQL с экспортированными данными Crashlytics и данными сеансов Firebase.

Пример 1. Расчет показателей без сбоев на основе данных о сеансах Firebase

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

Показатели отсутствия сбоев помогут вам получить эту информацию. Эти показатели помогают понять общее состояние приложения. С помощью данных о сеансах Firebase и событиях Crashlytics вы можете рассчитать эти показатели с помощью простого запроса.

Ниже приведены примеры запросов для приложения 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(sessions.event_timestamp,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.firebase_session_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(sessions.event_timestamp,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 (iOS+ | Android | Flutter | Unity) 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. Пять самых распространенных проблем на сегодня

Вот пример запроса для приложения 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. Пять самых распространенных проблем с ДАТЫ, включая сегодня

Вы также можете объединить пакетные таблицы и таблицы в реальном времени с помощью запроса на объединение, чтобы добавить информацию в реальном времени к надежным пакетным данным. Поскольку 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;

Что дальше?