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

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

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

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

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

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

Подробнее о BigQuery SQL

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

В этом разделе приведены примеры ситуаций и запросов, которые демонстрируют, как можно использовать SQL BigQuery с экспортированными данными 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 и 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;

Что дальше?