Eksportowanie danych z Firebase Crashlytics do BigQuery

Swoje dane z usługi Firebase Crashlytics możesz wyeksportować do BigQuery dla dalszą analizę. BigQuery umożliwia analizowanie danych za pomocą BigQuery SQL, wyeksportuj go do innego dostawcy chmury i użyj wizualizacji i paneli niestandardowych w Studiu danych Google.

Włącz eksport do usługi BigQuery

1. W konsoli Firebase otwórz stronę Integracje.
2. Na karcie BigQuery kliknij Połącz.
3. Aby umożliwić eksportowanie do BigQuery, postępuj zgodnie z instrukcjami wyświetlanymi na ekranie.

Gdy włączysz eksportowanie do BigQuery:

• Domyślnie wszystkie aplikacje w projekcie są połączone z BigQuery oraz dowolnymi aplikacje, które dodasz później do projektu, zostaną automatycznie połączone BigQuery Dostępne opcje określać, które aplikacje mają wysyłać dane.

• Firebase konfiguruje codzienne synchronizacje danych z projektu Firebase w BigQuery

• Firebase wyeksportuje kopię dotychczasowych danych do: BigQuery. W przypadku każdej połączonej aplikacji obejmuje to tabelę zbiorczą. który zawiera dane z codziennej synchronizacji.

• Jeśli włącz eksport strumieniowy z aplikacji Crashlytics do BigQuery, wszystkie połączone aplikacje będą też miały tabelę czasu rzeczywistego, która zawiera stale aktualizowane i skalowalnych danych.

Aby wyłączyć eksportowanie do usługi BigQuery, odłącz projekt w konsoli Firebase.

Jakie dane są eksportowane do usługi BigQuery?

Dane usługi Firebase Crashlytics są eksportowane do zbioru danych BigQuery o nazwie firebase_crashlytics Domyślnie poszczególne tabele będą tworzone wewnątrz zbiór danych Crashlytics dla każdej aplikacji w Twoim projekcie. Firebase nadaje nazwy tabelom na podstawie identyfikatora aplikacji, przy czym kropki są zamieniane na podkreślenia, a na końcu dodawana jest nazwa platformy.

Na przykład dane aplikacji na Androida o nazwie pakietu com.google.test będą znajdować się w tabeli o nazwie com_google_test_ANDROID. Ta tabela wsadowa została zaktualizowana raz dziennie. Jeśli włączysz eksport strumieniowy Crashlytics do BigQuery, a następnie dane z Crashlytics również będą przesyłane strumieniowo w czasie rzeczywistym do tabeli o nazwie com_google_test_ANDROID_REALTIME.

Każdy wiersz w tabeli odpowiada zdarzeniu, które wystąpiło w aplikacji, w tym oraz błędów niekrytycznych i błędów ANR.

Eksport strumieniowy Crashlytics do BigQuery

Dane Crashlytics możesz przesyłać strumieniowo w czasie rzeczywistym za pomocą BigQuery. Można ich używać do dowolnych celów, które wymagają danych na żywo, takich jak prezentowanie w panelu transmisji na żywo, obserwować wdrożenia na żywo lub monitorować je problemy z aplikacją, które aktywują alerty i niestandardowe przepływy pracy.

Gdy włączysz eksport strumieniowy Crashlytics do BigQuery, oprócz tabeli zbiorczej będziesz mieć też tabelę w czasie rzeczywistym. Oto różnice między tymi tabelami, o których warto pamiętać:

Tabela wsadowa jest idealna do długoterminowej analizy i identyfikowania trendów w czasie. bo przechowujemy zdarzenia przed ich napisaniem i można je uzupełniać z perspektywy maksymalnie 30 dni. Przy zapisie danych w tabeli czasu rzeczywistego od razu zapisać go w aplikacji BigQuery. Dzięki temu idealnie nadaje się do transmisji na żywo. z paneli informacyjnych i alertów niestandardowych. Aby korzystać z zalet obu tabel, możesz je połączyć za pomocą zapytania łączącego.

Domyślnie tabela czasu rzeczywistego ma okres ważności partycji wynoszący 30 dni. Do dowiedzieć się, jak to zmienić, zobacz Ustawianie daty wygaśnięcia partycji w dokumentacji BigQuery.

Włącz eksport strumieniowy Crashlytics do BigQuery

1. W konsoli Firebase otwórz stronę Integracje.
2. Na karcie BigQuery kliknij Zarządzaj.
3. Zaznacz pole wyboru Uwzględnij strumieniowanie.

To działanie spowoduje włączenie strumieniowego przesyłania danych ze wszystkich połączonych aplikacji.

Co można zrobić z wyeksportowanymi danymi?

Eksporty do BigQuery zawierają nieprzetworzone dane o awariach, w tym o typie urządzenia, systemu operacyjnego, wyjątków (aplikacje na Androida) lub błędów (aplikacje Apple), Crashlytics oraz inne dane.

Sprawdź, jakie dane z usługi Crashlytics są eksportowane i jakie są ich tabele w tabeli schemat na tej stronie.

Używanie szablonu Studia danych

Aby włączyć dane w czasie rzeczywistym w szablonie Studia danych, postępuj zgodnie z instrukcjami podanymi w artykule Wizualizacja wyeksportowanych danych Crashlytics w Studiu danych.

Tworzenie widoków

Zapytania możesz przekształcać w widoki za pomocą interfejsu BigQuery. Szczegółowe instrukcje znajdziesz w dokumentacji BigQuery dotyczącej tworzenia widoków.

Uruchamianie zapytań

Poniższe przykłady pokazują zapytania, które możesz uruchamiać na danych Crashlytics, aby generować raporty, które agregują dane o zdarzeniach awarii w bardziej zrozumiałe podsumowania. Ponieważ nie są dostępne tego typu raporty w panelu Crashlytics w konsoli Firebase mogą uzupełniać analizy i interpretacji danych dotyczących awarii.

Przykład 1: awarie według dnia

Po wyeliminowaniu jak największej liczby błędów uważasz, że Twój zespół jest gotowy do uruchomienia nowej aplikacji do udostępniania zdjęć. Zanim to zrobisz, chcesz sprawdzić liczbę awarii dziennie w ciągu ostatniego miesiąca, aby upewnić się, że dzięki spotkaniu poświęconemu wyeliminowaniu błędów aplikacja jest stabilniejsza.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej 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 2. Znajdowanie najczęściej występujących awarii

Aby ustalić priorytety planów produkcji, znajdź 10 najlepszych powszechnych awarii w aplikacji. Tworzysz zapytanie, w którym punktów danych.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości 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 3. 10 najczęściej zawieszających się urządzeń

Jesień to nowy sezon telefonów! Twoja firma wie, że oznacza to też, że musi zacząć problemów związanych z urządzeniami – szczególnie z Androidem. Aby uniknąć problemów ze zgodnością, które mogą się pojawić w przyszłości, tworzysz zapytanie, które wskazuje 10 urządzeń, które w ostatnim tygodniu (168 godzin) najczęściej ulegały awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości 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 4. Filtrowanie według klucza niestandardowego

Jesteś deweloperem gier i chcesz wiedzieć, na jakim poziomie działa Twoja gra z największą liczbą awarii.

Aby ułatwić śledzenie tych statystyk, ustaw niestandardowy klucz Crashlytics o nazwie current_level i aktualizuj ją za każdym razem, gdy użytkownik osiągnie nowy poziom.

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

Mając ten klucz w eksporcie do usługi BigQuery, możesz napisać zapytanie do zgłoś rozkład wartości current_level powiązanych z każdą awarią .

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej 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 5. Wyodrębnianie identyfikatorów użytkownika

Masz aplikację na Androida w programie wcześniejszego dostępu. Większość użytkowników ją uwielbia, ale u 3 z nich wystąpiła nietypowa liczba awarii. Aby przejść do dołu piszesz zapytanie, które pobiera wszystkie zdarzenia awarii tych użytkowników za pomocą identyfikatorów użytkowników.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości 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 6. Znajdowanie wszystkich użytkowników, którzy mają problem z określonym błędem powodującym zamykanie aplikacji

Twój zespół przypadkowo udostępnił krytyczny błąd grupie beta-testerów. Twój zespół mógł użyć zapytania z przykładu „Znajdowanie najczęściej występujących awarii” powyżej, aby zidentyfikować konkretny identyfikator problemu z awarią. Twój zespół chce przeprowadzić w celu wyodrębnienia listy 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 identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości 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 7. Liczba użytkowników, których dotyczy awaria, z podziałem na kraje

Twój zespół wykrył błąd krytyczny podczas wdrażania nowej wersji. Ty mogli użyć zapytania z „Wykrywaj najpowszechniejsze awarie” przykład powyżej, aby zidentyfikować konkretny identyfikator problemu powodującego awarię. Nasz zespół chce teraz sprawdzić, czy ten błąd występuje u użytkowników w różnych krajach na całym świecie.

Aby utworzyć to zapytanie, Twój zespół musi wykonać te czynności:

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

2. Zaktualizuj aplikację, aby przekazywać identyfikator użytkownika do obu pakietów SDK: Google Analytics i 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 złączania zdarzeń w zbiorze danych Google Analytics ze zdarzeniami awarii w zbiorze danych Crashlytics.

   Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikator 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 8. 5 najważniejszych do tej pory tematów na dziś

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej 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 9. Najważniejsze problemy od daty {DATE}, w tym dzisiaj

Możesz też połączyć tabele wsadowe i w czasie rzeczywistym za pomocą zapytania o łączenie, aby dodać w czasie rzeczywistym do niezawodnych danych wsadowych. Ponieważ event_id jest głównym elementem za pomocą DISTINCT event_id możesz usunąć z nich dowolne typowe zdarzenia tabeli.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej 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 >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Schemat Crashlytics w pliku BigQuery

Gdy skonfigurujesz eksport danych Crashlytics do BigQuery, Firebase będzie eksportować ostatnie zdarzenia (awarie, błędy niekrytyczne i błędy ANR), w tym zdarzenia z okresu do 2 dni przed połączeniem, z opcją uzupełniania danych z okresu do 30 dni.

Od tego momentu Firebase będzie eksportować dane, dopóki nie wyłączysz eksportu Crashlytics zdarzeń dziennie. Po każdym eksporcie dane mogą być dostępne w BigQuery dopiero po kilku minutach.

Zbiory danych

Crashlytics tworzy nowy zbiór danych w BigQuery dla użytkowniczki Crashlytics i skalowalnych danych. Zbiór danych obejmuje cały projekt, nawet jeśli obejmuje on kilka aplikacji.

Tabele

Crashlytics tworzy w zbiorze danych tabelę dla każdej aplikacji w projekcie, chyba że zrezygnujesz z eksportowania danych z tej aplikacji. Firebase nadaje nazwę na podstawie identyfikatora aplikacji, z kropkami konwertowanymi na podkreślenia, z nazwą platformy dodaną na końcu.

Na przykład dane aplikacji na Androida o nazwie pakietu com.google.test będą się znajdować w tabeli o nazwie com_google_test_ANDROID, a dane w czasie rzeczywistym (jeśli są włączone) – w tabeli o nazwie com_google_test_ANDROID_REALTIME.

Tabele zawierają standardowy zestaw danych Crashlytics oraz wszystkie niestandardowe klucze Crashlytics zdefiniowane przez Ciebie w aplikacji.

Wiersze

Każdy wiersz w tabeli oznacza błąd napotkany przez aplikację.

Kolumny

Kolumny w tabeli są identyczne w przypadku awarii, błędów niekrytycznych i błędów ANR. Jeśli masz włączony eksport strumieniowy Crashlytics do tabeli BigQuery, tabela w czasie rzeczywistym będzie miała te same kolumny co tabela zbiorcza. Pamiętaj, że możesz mają kolumny w wierszach reprezentujące zdarzenia, które nie mają zrzutów stosu.

Kolumny w ramach eksportu wymienione są w tej tabeli:

Wizualizacja wyeksportowanych danych Crashlytics w Studiu danych

Studio danych Google przekształca Crashlytics zbiorów danych w usłudze BigQuery w raporty, które łatwiej jest do czytania, udostępniania i dostosowywania do własnych potrzeb.

Aby dowiedzieć się więcej o korzystaniu ze Studia danych, zapoznaj się z poradnikiem Witamy w Studiu danych.

Użyj szablonu raportu Crashlytics

Studio danych zawiera przykładowy raport dotyczący kategorii Crashlytics, który zawiera kompleksowy zestaw wymiarów i danych z wyeksportowanych Crashlytics Schemat BigQuery. Jeśli masz włączony eksport strumieniowy Crashlytics do BigQuery, możesz wyświetlić te dane w trendach w czasie rzeczywistym szablonu Studia danych.Przykład może służyć jako szablon, tworzenie nowych raportów i wizualizacji na podstawie nieprzetworzonych danych o awariach Twojej aplikacji:

1. Otwórz szablon Crashlytics panelu Studia danych.

2. W prawym górnym rogu kliknij Użyj szablonu.

3. W menu Nowe źródło danych wybierz Utwórz nowe źródło danych.

4. Na karcie BigQuery kliknij Wybierz.

5. Wybierz tabelę z wyeksportowanymi danymi Crashlytics: Moje projekty > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

   Tabela zbiorcza jest zawsze dostępna do wyboru. Jeśli włączony jest eksport strumieniowy Crashlytics do usługi BigQuery, a następnie możesz zamiast tego wybrać tabelę w czasie rzeczywistym.

6. W obszarze Konfiguracja ustaw opcję Poziom szablonu Crashlytics na Domyślny.

7. Kliknij Połącz, aby utworzyć nowe źródło danych.

8. Aby wrócić do szablonu Crashlytics, kliknij Dodaj do raportu.

9. Na koniec kliknij Utwórz raport, aby utworzyć kopię raportu Crashlytics. Szablon panelu Studia danych.