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

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

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

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

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

Подробную информацию о схеме набора данных см. в разделе «Схема набора данных для экспортированных данных в BigQuery .

Узнайте о BigQuery SQL

• Узнайте о типах запросов, которые вы можете выполнять , включая интерактивные задания запросов, пакетные задания запросов и задания непрерывных запросов.

• Узнайте о поддерживаемых операторах и диалектах SQL в BigQuery .

• Узнайте, как писать запросы с помощью искусственного интеллекта ( Gemini ) .

Примеры запросов к данным Crashlytics

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

• Рассчитайте показатели без сбоев, используя данные сессий Firebase.
• Днем происходят аварии.
• Найдите наиболее распространенные аварии.
• Топ-10 устройств, вызывающих сбои в работе
• Фильтрация по пользовательскому ключу
• Извлечение идентификаторов пользователей
• Найти всех пользователей, столкнувшихся с конкретной проблемой сбоя.
• Количество пользователей, пострадавших от сбоя, в разбивке по странам.
• Топ-5 проблем на сегодняшний день
• Топ-5 проблем с ДАТЫ, включая сегодняшний день.

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

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

   Быстрый

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

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

Что дальше?

• Создавайте пользовательские панели мониторинга, используя экспортированные данные и различные сервисы Google Cloud , такие как Looker Studio .

• Узнайте о схеме набора данных для экспортируемых данных .

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

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

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

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

Подробную информацию о схеме набора данных см. в разделе «Схема набора данных для экспортированных данных в BigQuery .

Узнайте о BigQuery SQL

• Узнайте о типах запросов, которые вы можете выполнять , включая интерактивные задания запросов, пакетные задания запросов и задания непрерывных запросов.

• Узнайте о поддерживаемых операторах и диалектах SQL в BigQuery .

• Узнайте, как писать запросы с помощью искусственного интеллекта ( Gemini ) .

Примеры запросов к данным Crashlytics

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

• Рассчитайте показатели без сбоев, используя данные сессий Firebase.
• Днем происходят аварии.
• Найдите наиболее распространенные аварии.
• Топ-10 устройств, вызывающих сбои в работе
• Фильтрация по пользовательскому ключу
• Извлечение идентификаторов пользователей
• Найти всех пользователей, столкнувшихся с конкретной проблемой сбоя.
• Количество пользователей, пострадавших от сбоя, в разбивке по странам.
• Топ-5 проблем на сегодняшний день
• Топ-5 проблем с ДАТЫ, включая сегодняшний день.

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

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

   Быстрый

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

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

Что дальше?

• Создавайте пользовательские панели мониторинга, используя экспортированные данные и различные сервисы Google Cloud , такие как Looker Studio .

• Узнайте о схеме набора данных для экспортируемых данных .