Eksportowanie danych z Firebase Crashlytics do BigQuery

Dane Firebase Crashlytics możesz wyeksportować do pliku BigQuery, aby przeanalizować je dokładniej. BigQuery umożliwia analizowanie danych za pomocą BigQuery SQL, eksportowanie ich do innego dostawcy usług w chmurze oraz wykorzystywanie do 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.

   Jeśli chcesz mieć dostęp do danych Crashlytics w BigQuery w czasie zbliżonym do rzeczywistego, rozważ użycie eksportu strumieniowego.

Co się stanie, gdy włączysz eksport?

• Wybierasz lokalizację zbioru danych. Po utworzeniu zbioru danych jego lokalizacji nie można już zmienić. Możesz natomiast skopiować zbiór danych do innej lokalizacji lub ręcznie przenieść (ponownie utworzyć) zbiór danych w innej lokalizacji. Więcej informacji znajdziesz w artykule Zmienianie lokalizacji dotychczasowych eksportów.

  Ta lokalizacja dotyczy tylko danych eksportowanych do BigQuery. Nie ma wpływu na lokalizację danych przechowywanych na potrzeby korzystania w panelu Crashlytics w konsoli Firebase lub w Android Studio.

• Domyślnie wszystkie aplikacje w projekcie są połączone z poziomem BigQuery, a wszystkie aplikacje, które dodasz później do projektu, zostaną automatycznie połączone z poziomem BigQuery. Możesz określić, które aplikacje mają wysyłać dane.

• Firebase konfiguruje codzienną synchronizację danych z usługą BigQuery.

  • Po połączeniu projektu musisz zwykle zaczekać do następnej synchronizacji, aby pierwszy zestaw danych został wyeksportowany do BigQuery.

  • Codzienna synchronizacja odbywa się raz dziennie, niezależnie od harmonogramu eksportu BigQuery. Pamiętaj, że czas i długość działania zadania synchronizacji mogą się zmieniać, więc nie zalecamy planowania dalszych operacji ani zadań na podstawie określonego czasu eksportu.

• Firebase eksportuje kopię Twoich dotychczasowych danych do usługi BigQuery. Początkowa propagacja danych na potrzeby eksportu może potrwać do 48 godzin.

  • W przypadku każdej połączonej aplikacji ten eksport obejmuje tabelę zbiorczą z danymi z codzienniej synchronizacji.

  • Możesz ręcznie zaplanować uzupełnianie danych w tabeli zbiorczej z ostatnich 30 dni lub z ostatniego dnia, w którym włączono eksport do BigQuery (w zależności od tego, co jest najnowsze).

  Pamiętaj, że jeśli eksport danych Crashlytics został włączony przed połową października 2024 r., możesz też uzupełnić dane z 30 dni poprzedzających dzień włączenia eksportu.

• Jeśli włączysz eksport strumieniowy Crashlytics do BigQuery, wszystkie połączone aplikacje będą też mieć tabelę w czasie rzeczywistym z ciągle aktualizowanymi danymi.

Aby dezaktywować eksport do usługi BigQuery, odłącz projekt w konsoli Firebase.

Jakie dane są eksportowane do BigQuery?

Dane Firebase Crashlytics są eksportowane do zbioru danych BigQuery o nazwie firebase_crashlytics. Domyślnie w przypadku każdej aplikacji w projekcie zostaną utworzone osobne tabele w zbiorze danych Crashlytics. 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 zbiorcza jest aktualizowana raz dziennie. Jeśli włączysz eksport strumieniowy Crashlytics do tabeli BigQuery, dane Crashlytics będą też przesyłane 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, m.in. awariom, niekrytycznym błędom i zgłoszeniom ANR.

Eksport strumieniowy Crashlytics do BigQuery

Dane Crashlytics możesz przesyłać strumieniowo w czasie rzeczywistym za pomocą BigQuery. Możesz go używać do dowolnego celu, który wymaga danych na żywo, np. prezentowania informacji w panelu na żywo, obserwowania wdrażania na żywo lub monitorowania problemów z aplikacją, które powodują 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 należy pamiętać:

Tabela zbiorcza jest idealna do długoterminowej analizy i określania trendów na przestrzeni czasu, ponieważ zdarzenia są trwało przechowywane przed zapisaniem i można je uzupełnić w tabeli przez maksymalnie 30 dni*. Gdy zapisujemy dane w tabeli czasu rzeczywistego, zapisujemy je też natychmiast w tabeli BigQuery. Dzięki temu są one idealne do paneli na żywo i alertów niestandardowych. Aby korzystać z zalet obu tych tabel, możesz połączyć je za pomocą zapytania łączącego.

Domyślny czas ważności partycji tabeli w czasie rzeczywistym wynosi 30 dni. Aby dowiedzieć się, jak to zmienić, przeczytaj artykuł Ustawianie daty wygaśnięcia partycji w dokumentacji BigQuery.

^{* Więcej informacji o obsługiwaniu danych zapasowych znajdziesz w artykule Przejście na nową infrastrukturę eksportu.}

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 włącza strumieniowanie dla wszystkich połączonych aplikacji.

Co można zrobić z wyeksportowanymi danymi?

Dane eksportowane do pliku BigQuery zawierają surowe dane o awariach, w tym typ urządzenia, system operacyjny, wyjątki (aplikacje na Androida) lub błędy (aplikacje na urządzenia Apple), a także inne dane.Crashlytics

W dalszej części tej strony możesz sprawdzić, jakie dokładnie dane Crashlytics są eksportowane, oraz schemat tabeli.

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ż te typy raportów są niedostępne na panelu Crashlytics w konsoli Firebase, mogą one uzupełniać Twoją analizę i pomóc w zrozumieniu danych o wypadkach.

Przykład 1. Błędy a dzień

Po wyeliminowaniu jak największej liczby błędów Twój zespół jest gotowy do uruchomienia nowej aplikacji do udostępniania zdjęć. Zanim to zrobi, chce sprawdzić liczbę awarii dziennie w ciągu ostatniego miesiąca, aby upewnić się, że dzięki spotkaniu poświęconemu zgłaszaniu 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 wartości IOS (zamiast nazwy pakietu i wartości 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 prawidłowo ustalić priorytety planów produkcyjnych, musisz znaleźć 10 najczęstszych przyczyn awarii w aplikacji. W tym celu tworzysz zapytanie, które zawiera odpowiednie punkty 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 czas na nowe telefony. Twoja firma wie, że oznacza to również nowy sezon problemów związanych z urządzeniami, zwłaszcza z Androidem. Aby uniknąć problemów z kompatybilnoś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 którym poziomie gry najczęściej występują awarie.

Aby śledzić tę statystykę, możesz ustawić niestandardowy klucz Crashlytics o nazwie current_level i aktualizować go 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);

Gdy masz ten klucz w eksporcie do BigQuery, możesz napisać zapytanie, aby zgłosić 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 wartości IOS (zamiast nazwy pakietu i wartości 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 identyfikatora użytkownika

Masz aplikację na Androida w ramach wcześniejszego dostępu. Większość użytkowników ją uwielbia, ale u 3 z nich wystąpiła nietypowa liczba awarii. Aby dojść do sedna problemu, możesz utworzyć zapytanie, które pobiera wszystkie zdarzenia awarii dla 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 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 teraz wykonać zapytanie, aby pobrać 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 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 problem z awarią, według kraju

Podczas wdrażania nowej wersji nasz zespół wykrył błąd krytyczny. Aby znaleźć konkretny identyfikator problemu z zawieszaniem, możesz użyć zapytania z powyższego przykładu „Znajdowanie najczęściej występujących awarii”. 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 artykuł 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 identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości 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 problemów do tej pory

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
  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 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 głównym, możesz używać DISTINCT event_id do usuwania duplikatów wspólnych zdarzeń z tych 2 tabel.

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
  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 do czasu dezaktywacji eksportu Firebase będzie codziennie eksportować zdarzenia Crashlytics. Po każdym eksporcie dane mogą być dostępne w BigQuery dopiero po kilku minutach.

Zbiory danych

Crashlytics tworzy w BigQuery nowy zbiór danych dla danych Crashlytics. Zbiór danych obejmuje cały projekt, nawet jeśli zawiera on wiele aplikacji.

Tabele

Crashlytics tworzy tabelę w zbiorze danych dla każdej aplikacji w Twoim projekcie, chyba że zrezygnowałeś(-aś) z eksportowania danych z tej aplikacji. Firebase nadaje nazwy tabel na podstawie identyfikatora aplikacji, przy czym kropki zastępuje podkreśleniami, a na końcu dodaje nazwę platformy.

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 odpowiada błędowi, na który napotkała aplikacja.

Kolumny

Kolumny w tabeli są identyczne w przypadku awarii, niekrytycznych błędów 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 w wierszach mogą występować kolumny, które reprezentują zdarzenia bez ścieżek wywołania.

Kolumny w ramach eksportu są wymienione w tej tabeli:

Wizualizacja wyeksportowanych danych Crashlytics w Studiu danych

Studio danych Google przekształca Twoje zbiory danych Crashlytics w BigQuery w raporty, które są łatwiejsze do odczytania i udostępnienia oraz w pełni konfigurowalne.

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

Używanie szablonu raportu Crashlytics

W Data Studio znajdziesz przykładowy raport Crashlytics, który zawiera obszerny zbiór wymiarów i danych z wyeksportowanego schematu Crashlytics BigQuery. Jeśli masz włączone Crashlytics eksportowanie danych strumieniowych BigQuery, możesz wyświetlić te dane na stronie Trendy w czasie rzeczywistym w szablonie Studia danych.Możesz użyć tego szablonu, aby szybko tworzyć nowe raporty i wizualizacje na podstawie nieprzetworzonych danych o awariach z 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 kliknij 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 masz włączony eksport Crashlytics strumieniowy do BigQuery, możesz zamiast tego wybrać tabelę w czasie rzeczywistym.

6. W sekcji Konfiguracja ustaw wartość Crashlytics Poziom szablonu na Domyślny.

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

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

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

Przejście na nową infrastrukturę eksportu

W połowie października 2024 r. Crashlytics wdrożył nową infrastrukturę do eksportowania danych Crashlytics do usługi BigQuery. Na razie przejście na tę nową infrastrukturę jest opcjonalne.

• Jeśli eksport został włączony przed połową października 2024 r., możesz teraz opcjonalnie zmienić lokalizację eksportu danych na dowolną lokalizację zbioru danych obsługiwaną przez BigQuery.

• Jeśli eksport został włączony w połowie października 2024 r. lub później, podczas konfiguracji możesz wybrać dowolną obsługiwaną przez BigQuery lokalizację zbioru danych.

Kolejną różnicą w nowej infrastrukturze jest to, że nie obsługuje ona uzupełniania danych z okresu poprzedzającego włączenie eksportu. (w przypadku starej infrastruktury można było uzupełnić dane do 30 dni przed datą włączenia). Nowa infrastruktura obsługuje uzupełnianie danych z ostatnich 30 dni lub z ostatniego dnia, w którym włączono eksport do BigQuery (w zależności od tego, co jest najnowsze).

Warunek wstępny przejścia na wyższą wersję

Zanim przejdziesz na nową infrastrukturę, sprawdź, czy spełniasz ten wymóg wstępny: tabele bieżących zbiorczych BigQuery mają identyfikatory pasujące do identyfikatorów pakietów lub nazw pakietów ustawionych dla zarejestrowanych aplikacji Firebase.

Przykład:

• Jeśli masz tabelę BigQuery o nazwie com_yourcompany_yourproject_IOS, w Twoim projekcie Firebase musi być zarejestrowana aplikacja Firebase na iOS+ z identyfikatorem pakietu com.yourcompany.yourproject.

• Jeśli masz tabelę BigQuery o nazwie com_yourcompany_yourproject_ANDROID, w Twoim projekcie Firebase musi być zarejestrowana aplikacja Firebase na Androida o nazwie pakietu com.yourcompany.yourproject.

Aby znaleźć wszystkie aplikacje Firebase zarejestrowane w Twoim projekcie Firebase:

1. W konsoli Firebase otwórz settings Ustawienia projektu.

2. Przewiń w dół do karty Twoje aplikacje, a potem kliknij wybraną aplikację Firebase, aby wyświetlić informacje o niej, w tym jej identyfikator.

Nowa infrastruktura eksportu będzie eksportować dane każdej aplikacji na podstawie nazwy pakietu lub identyfikatora zestawu ustawionego dla zarejestrowanej aplikacji Firebase. Aby nie zakłócać BigQuery przepływu pracy, upewnij się, że bieżące tabele zbiorczych mają już prawidłowe nazwy, aby nowa infrastruktura mogła dołączać wszystkie nowe dane do istniejących tabel. Jeśli masz nazwy tabel partii, które nie zgadzają się z zarejestrowanymi aplikacjami Firebase, ale nadal chcesz przejść na nową usługę, skontaktuj się z zespołem pomocy Firebase.

Jak przejść na nową infrastrukturę

Jeśli eksport jest już włączony, możesz przejść na nową infrastrukturę, po prostu wyłączając, a następnie włączając eksport danych w konsoli Crashlytics.Firebase

Oto szczegółowe instrukcje:

1. W konsoli Firebase otwórz stronę Integracje.

2. Na karcie BigQuery kliknij Zarządzaj.

3. Aby wyłączyć eksportowanie, wyłącz suwak Crashlytics. Gdy pojawi się odpowiedni komunikat, potwierdź, że chcesz zatrzymać eksport danych.

4. Od razu włącz suwak Crashlytics, aby ponownie włączyć eksportowanie. Gdy pojawi się odpowiedni komunikat, potwierdź, że chcesz wyeksportować dane.

   eksport danych z Crashlytics do BigQuery jest teraz realizowany za pomocą nowej infrastruktury eksportu.