Uruchamianie zapytań SQL na wyeksportowanych danych w BigQuery

Po wyeksportowaniu danych Crashlytics i (opcjonalnie) sesji Firebase do BigQuery możesz zacząć z nimi pracować:

  • Analizuj dane za pomocą zapytań SQL
    Możesz uruchamiać zapytania dotyczące danych Crashlytics, aby generować niestandardowe raporty i podsumowania. Ponieważ te typy niestandardowych raportów nie są dostępne w Crashlytics panelu Firebase konsoli, mogą one uzupełniać Twoją analizę i zrozumienie danych o awariach. Kolekcję przykładowych zapytań znajdziesz w dalszej części tej strony.

  • Łącz dane z różnych zbiorów danych
    Jeśli na przykład podczas konfigurowania eksportu danych Crashlytics zdecydujesz się wyeksportować dane sesji Firebase, możesz lepiej zrozumieć liczbę użytkowników i sesji bez awarii (zobacz przykładowe zapytanie). Możesz też wyeksportować dane z różnych usług Firebase (np. Performance Monitoring) lub z Google Analytics, a następnie połączyć je i przeanalizować w BigQuery razem z danymi Crashlytics.

  • Twórz widoki
    Za pomocą interfejsu BigQuery możesz utworzyć widok, czyli tabelę wirtualną zdefiniowaną przez zapytanie SQL. Szczegółowe instrukcje dotyczące różnych typów widoków i sposobu ich tworzenia znajdziesz w BigQuery dokumentacji.

Szczegółowe informacje o schemacie zbioru danych znajdziesz w artykule Schemat zbioru danych na potrzeby wyeksportowanych danych w BigQuery.

Więcej informacji o BigQuery SQL

Przykładowe zapytania dotyczące danych Crashlytics

W tej sekcji znajdziesz kilka przykładowych sytuacji i zapytań, które pokazują, jak możesz używać BigQuery SQL z wyeksportowanymi Crashlytics danymi i danymi sesji Firebase.

Przykład 1. Obliczanie danych o bezawaryjnej pracy na podstawie danych sesji Firebase

W najnowszej wersji wprowadziliśmy duże zmiany w aplikacji, aby rozwiązać problemy z awariami w głównej ścieżce użytkownika. Otrzymaliśmy świetne opinie od użytkowników, ale chcemy mieć dowody ilościowe, że aplikacja jest bardziej stabilna niż wcześniej.

Dane o bezawaryjnej pracy mogą pomóc w uzyskaniu tych informacji. Te dane są ważnymi pomiarami, które pomagają zrozumieć ogólny stan aplikacji. Dzięki danym sesji Firebase i Crashlytics zdarzeniom, możesz obliczyć te dane za pomocą podstawowego zapytania.

Oto przykładowe zapytania dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

Liczba użytkowników bez awarii w określonej wersji:

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

Liczba sesji bez awarii w ciągu ostatniego tygodnia (ostatnich 168 godzin):

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

Przykład 2. Awaria według dnia

Po rozwiązaniu jak największej liczby błędów uważamy, że nasz zespół jest wreszcie gotowy do uruchomienia nowej aplikacji do udostępniania zdjęć. Zanim to zrobimy, chcemy sprawdzić liczbę awarii dziennie w ciągu ostatniego miesiąca, aby mieć pewność, że dzięki usunięciu błędów aplikacja stała się bardziej stabilna.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i 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;

Przykład 3. Znajdowanie najczęstszych awarii

Aby prawidłowo ustalać priorytety planów produkcyjnych, chcemy znaleźć 10 najczęstszych awarii w aplikacji. Tworzymy zapytanie, które zawiera odpowiednie punkty danych.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i 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;

Przykład 4. 10 urządzeń, na których najczęściej występują awarie

Jesień to sezon nowych telefonów. W naszej firmie wiemy, że oznacza to też sezon problemów związanych z nowymi urządzeniami, zwłaszcza z Androidem. Aby wyprzedzić nadchodzące problemy z kompatybilnością, tworzymy zapytanie, które identyfikuje 10 urządzeń, na których w ciągu ostatniego tygodnia (168 godzin) wystąpiło najwięcej awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i 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;

Przykład 5. Filtrowanie według klucza niestandardowego

Jesteśmy deweloperami gier i chcemy wiedzieć, na którym poziomie naszej gry występuje najwięcej awarii.

Aby śledzić te statystyki, ustawiamy niestandardowy klucz Crashlytics (iOS+ | Android | Flutter | Unity ) o nazwie current_level i aktualizujemy go za każdym razem, gdy użytkownik osiągnie nowy poziom.

Swift

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

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

Crashlytics.setInt("current_level", 3);

Gdy ten klucz znajdzie się w wyeksportowanych danych w BigQuery, możesz napisać zapytanie, które będzie raportować rozkład wartości current_level powiązanych z każdym zdarzeniem awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i 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

Przykład 6. Wyodrębnianie identyfikatorów użytkowników

Mamy aplikację na Androida we wczesnym dostępie. Większość użytkowników jest zadowolona, ale 3 z nich doświadczyło niezwykłej liczby awarii. Aby rozwiązać ten problem, piszemy zapytanie, które pobiera wszystkie zdarzenia awarii tych użytkowników na podstawie ich identyfikatorów.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i 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

Przykład 7. Znajdowanie wszystkich użytkowników, których dotyczy konkretny problem z awarią

Nasz zespół przypadkowo udostępnił krytyczny błąd grupie beta testerów. Zespół mógł użyć zapytania z przykładu „Znajdowanie najczęstszych awarii” powyżej, aby zidentyfikować konkretny identyfikator problemu z awarią. Teraz zespół chce uruchomić zapytanie, aby wyodrębnić listę użytkowników aplikacji, których dotyczy ta awaria.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i 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;

Przykład 8. Liczba użytkowników, których dotyczy problem z awarią, według kraju

Nasz zespół wykrył krytyczny błąd podczas wdrażania nowej wersji. Udało nam się użyć zapytania z przykładu „Znajdowanie najczęstszych awarii” powyżej, aby zidentyfikować konkretny identyfikator problemu z awarią. Teraz zespół chce sprawdzić, czy ta awaria rozprzestrzeniła się na użytkowników w różnych krajach na całym świecie.

Aby napisać to zapytanie, zespół musi wykonać te czynności:

  1. Włącz eksport danych Google Analytics do BigQuery. Zobacz Eksportowanie danych projektu do BigQuery.

  2. Zaktualizuj aplikację, aby przekazywać identyfikator użytkownika zarówno do pakietu Google Analytics SDK jak i pakietu Crashlytics SDK.

    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. Napisz zapytanie, które używa pola identyfikatora użytkownika do łączenia zdarzeń w zbiorze danych Google Analytics z awariami w zbiorze danych Crashlytics.

    Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i 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

Przykład 9. 5 najczęstszych problemów do tej pory

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i 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;

Przykład 10. 5 najczęstszych problemów od daty, w tym dzisiaj

Możesz też połączyć tabele zbiorcze i w czasie rzeczywistym za pomocą zapytania łączącego, aby dodać informacje w czasie rzeczywistym do wiarygodnych danych zbiorczych. Ponieważ event_id jest kluczem podstawowym, możesz użyć DISTINCT event_id, aby usunąć duplikaty typowych zdarzeń z obu tabel.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i 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;

Co dalej?