Uruchamianie zapytań SQL na wyeksportowanych danych w BigQuery

Po wyeksportowaniu danych Crashlytics i (opcjonalnie) danych o sesjach w 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ć raporty niestandardowe i podsumowania. Tego typu raporty niestandardowe nie są dostępne na CrashlyticspaneluFirebase konsoli, dlatego mogą uzupełniać Twoją analizę i wiedzę o danych o awariach. Kolekcję przykładowych zapytań znajdziesz poniżej.

  • Łączenie danych z różnych zbiorów danych
    Jeśli na przykład podczas konfigurowania 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).Crashlytics 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 tabelę wirtualną zdefiniowaną przez zapytanie SQL. Szczegółowe instrukcje dotyczące różnych rodzajów widoków i sposobu ich tworzenia znajdziesz w BigQuery dokumentacji.

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

Więcej informacji o BigQuerySQL

Przykładowe zapytania dotyczące danych Crashlytics

W tej sekcji znajdziesz przykładowe sytuacje i zapytania, które pokazują, jak używać BigQuerySQL z wyeksportowanymiCrashlytics danymi i danymi o sesjach w Firebase.

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

W najnowszej wersji wprowadziliśmy znaczące zmiany w aplikacji, aby rozwiązać problemy z awariami na kluczowej ścieżce użytkownika. Użytkownicy wystawili Ci świetne opinie, ale chcesz mieć dowody ilościowe na to, że Twoja aplikacja jest bardziej stabilna niż wcześniej.

Dane o braku awarii mogą pomóc w uzyskaniu tych informacji. Te dane to ważne pomiary, które pomagają zrozumieć ogólną kondycję aplikacji. Korzystając z danych o sesjach Firebase i Crashlyticszdarzeń, 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, 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

Sesje bez awarii w ostatnim tygodniu (ostatnich 168 godzinach):

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 wreszcie 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 intensywnemu testowaniu aplikacji stała się ona bardziej stabilna.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj 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 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 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 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 w przypadku Androida. 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 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ś 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);

Gdy klucz ten znajdzie się w wyeksportowanym pliku BigQuery, możesz napisać zapytanie, aby uzyskać raport o rozkładzie 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 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

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, piszesz zapytanie, które pobiera wszystkie zdarzenia awarii dotyczące tych użytkowników, korzystając z ich identyfikatorów.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj 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, u których występuje 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ą. Teraz Twój zespół chce uruchomić zapytanie, aby wyodrębnić listę użytkowników aplikacji, których dotyczył ten błąd.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj 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

Podczas wdrażania nowej wersji zespół wykrył krytyczny błąd. Używając zapytania z przykładu „Znajdź najczęstsze awarie” powyżej, możesz 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, Twój 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 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 DATE, w tym dzisiaj

Możesz też połączyć tabele przetwarzane wsadowo i w czasie rzeczywistym 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 typowych zdarzeń z obu tabel.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj 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?