Uruchamianie zapytań SQL na wyeksportowanych danych w BigQuery

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

  • Analizowanie danych za pomocą zapytań SQL
    Możesz uruchamiać zapytania dotyczące danych Crashlytics, aby generować niestandardowe raporty i podsumowania. Tego typu raporty niestandardowe nie są dostępne w CrashlyticspaneluFirebase konsoli, dlatego mogą uzupełniać Twoją analizę i wiedzę o danych o awariach. Przykłady zapytań znajdziesz w kolekcji poniżej.

  • Łączenie danych z różnych zbiorów danych
    Jeśli na przykład podczas konfigurowaniaCrashlytics eksportu danych zdecydujesz się eksportować dane o sesjach w Firebase, możesz lepiej poznać użytkowników i sesje bez awarii (zobacz przykładowe zapytanie). Możesz też eksportować dane z różnych usług Firebase (np. Performance Monitoring) lub z Google Analytics, a następnie łączyć i analizować te dane w BigQuery z danymi Crashlytics.

  • Tworzenie widoków
    Za pomocą interfejsu BigQuery możesz utworzyć widok, czyli wirtualną tabelę 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 BigQuerySQL

Przykładowe zapytania dotyczące danych Crashlytics

W tej sekcji znajdziesz przykłady sytuacji i zapytań, które pokazują, jak używać BigQuerySQL-a z wyeksportowanymi Crashlyticsdanymi i danymi o sesjach w Firebase.

Przykład 1. Obliczanie wskaźników bez awarii na podstawie danych o sesjach w Firebase

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

Dane o braku awarii mogą dostarczyć tych informacji. Te wskaźniki to ważne pomiary, które pomagają zrozumieć ogólną kondycję aplikacji. Za pomocą danych o sesjach w Firebase i Crashlyticszdarzeń możesz obliczyć te wskaźniki 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).

Użytkownicy, u których nie wystąpił błąd w przypadku konkretnej 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

Sesjebez 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. Awarie według dnia

Po usunięciu jak największej liczby błędów uważasz, że Twój zespół jest w końcu gotowy do wprowadzenia na rynek nowej aplikacji do udostępniania zdjęć. Zanim to zrobisz, chcesz sprawdzić liczbę awarii dziennie w ostatnim miesiącu, aby upewnić się, że dzięki sesji usuwania 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 identyfikatora pakietu i znaku IOS (zamiast nazwy pakietu i znaku 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 określić priorytety planów produkcyjnych, chcesz znaleźć 10 najczęstszych awarii w aplikacji. Tworzysz zapytanie, które dostarcza odpowiednie punkty danych.

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

Jesień to sezon nowych telefonów! W firmie wiesz, że oznacza to również sezon problemów związanych z nowymi urządzeniami – zwłaszcza z Androidem. Aby zapobiec problemom ze zgodnością, tworzysz zapytanie, które identyfikuje 10 urządzeń, na których w ostatnim tygodniu (168 godzinach) wystąpiło najwięcej awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i znaku IOS (zamiast nazwy pakietu i znaku 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ś deweloperem gier i chcesz wiedzieć, na którym poziomie gry występuje najwięcej awarii.

Aby śledzić te statystyki, ustawiasz niestandardowy klucz Crashlytics (iOS+ | Android | Flutter | Unity) o nazwie current_level i aktualizujesz 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);

Dzięki temu kluczowi w wyeksportowanym pliku 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 identyfikatora pakietu i znaku IOS (zamiast nazwy pakietu i znaku 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

masz aplikację na Androida w ramach wcześniejszego dostępu, Większość użytkowników jest zadowolona, ale u 3 osób wystąpiła nietypowo duża liczba awarii. Aby rozwiązać ten problem, możesz napisać zapytanie, które pobierze 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 identyfikatora pakietu i znaku IOS (zamiast nazwy pakietu i znaku 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ą

Twój zespół przypadkowo udostępnił krytyczny błąd grupie beta-testerów. Twój zespół mógł użyć zapytania z przykładu „Znajdź najczęstsze awarie” powyżej, aby zidentyfikować konkretny identyfikator problemu z awarią. Twój zespół chce teraz uruchomić zapytanie, aby wyodrębnić listę użytkowników aplikacji, których dotyczyło to awaryjne zamknięcie.

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

Podczas wdrażania nowej wersji zespół wykrył krytyczny błąd. Za pomocą zapytania z przykładu „Znajdź najczęstsze awarie” powyżej udało Ci się zidentyfikować konkretny identyfikator problemu z awarią. Twój zespół chce teraz sprawdzić, czy ten błąd występuje też u użytkowników w innych krajach na świecie.

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

  1. Włącz eksportowanie danych z Google Analytics do BigQuery. Więcej informacji znajdziesz w artykule Eksportowanie danych projektu do BigQuery.

  2. Zaktualizuj aplikację, aby przekazywała identyfikator użytkownika do pakietu SDK Google Analytics i pakietu 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. 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 identyfikatora pakietu i znaku IOS (zamiast nazwy pakietu i znaku 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 DATE, w tym dzisiaj

Możesz też połączyć tabele przetwarzane wsadowo i tabele czasu rzeczywistego za pomocą zapytania łączącego, aby dodać informacje w czasie rzeczywistym do wiarygodnych danych przetwarzanych wsadowo. Ponieważ event_id jest kluczem podstawowym, możesz użyć DISTINCT event_id, aby usunąć duplikaty wszystkich wspólnych zdarzeń z obu tabel.

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