इस पेज का अनुवाद Cloud Translation API से किया गया है.

Firebase Crashlytics का डेटा BigQuery में एक्सपोर्ट करें

ज़्यादा विश्लेषण के लिए, अपने Firebase Crashlytics डेटा को BigQuery में एक्सपोर्ट किया जा सकता है. BigQuery की मदद से, डेटा का विश्लेषण किया जा सकता है. इसके लिए, BigQuery एसक्यूएल का इस्तेमाल करें. साथ ही, इसे किसी दूसरे क्लाउड सेवा देने वाली कंपनी को एक्सपोर्ट करें. इसके अलावा, Google Data Studio की मदद से, इसे विज़ुअलाइज़ करने और कस्टम डैशबोर्ड बनाने के लिए इस्तेमाल करें.

BigQuery में एक्सपोर्ट करने की सुविधा चालू करना

Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.
BigQuery कार्ड में जाकर, लिंक करें पर क्लिक करें.
BigQuery में एक्सपोर्ट करने की सुविधा चालू करने के लिए, स्क्रीन पर दिए गए निर्देशों का पालन करें.

अगर आपको Crashlytics में BigQuery के डेटा का ऐक्सेस रीयल-टाइम में चाहिए, तो स्ट्रीमिंग एक्सपोर्ट पर अपग्रेड करें.

डेटा एक्सपोर्ट करने की सुविधा चालू करने पर क्या होता है?

डेटासेट की जगह चुनें. डेटासेट बनाने के बाद, उसकी जगह को बदला नहीं जा सकता. हालांकि, डेटासेट को किसी दूसरी जगह पर कॉपी किया जा सकता है. इसके अलावा, मैन्युअल तरीके से डेटासेट को किसी दूसरी जगह पर ले जाया जा सकता है, यानी कि इसे फिर से बनाया जा सकता है. ज़्यादा जानने के लिए, मौजूदा एक्सपोर्ट के लिए लोकेशन बदलना लेख पढ़ें.

यह जगह की जानकारी, सिर्फ़ BigQuery में एक्सपोर्ट किए गए डेटा पर लागू होती है. इससे Firebase कंसोल या Android Studio के Crashlytics डैशबोर्ड में इस्तेमाल के लिए सेव किए गए डेटा की जगह की जानकारी पर कोई असर नहीं पड़ता.

ध्यान दें: डेटा एक्सपोर्ट करने के लिए जगह चुनने और उसे बदलने की सुविधा सिर्फ़ तब उपलब्ध होती है, जब आपने अक्टूबर 2024 के मध्य के बाद एक्सपोर्ट करने की सुविधा चालू की हो या आपने एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड किया हो.
आपके प्रोजेक्ट के सभी ऐप्लिकेशन डिफ़ॉल्ट रूप से, BigQuery से लिंक होते हैं. साथ ही, बाद में प्रोजेक्ट में जोड़े जाने वाले ऐप्लिकेशन भी अपने-आप BigQuery से लिंक कर दिए जाते हैं. आपके पास BigQuery में डेटा भेजने वाले ऐप्लिकेशन चुनने का विकल्प होता है.
Firebase, आपके डेटा को हर दिन BigQuery के साथ सिंक करता है.
- प्रोजेक्ट लिंक करने के बाद, आम तौर पर आपको अगले दिन के सिंक होने तक इंतज़ार करना होगा. इसके बाद, डेटा का पहला सेट BigQuery में एक्सपोर्ट किया जाएगा.
- रोज़ाना सिंक होने की प्रोसेस, दिन में एक बार होती है. भले ही, आपने BigQuery में कोई शेड्यूल एक्सपोर्ट सेट अप किया हो. ध्यान दें कि सिंक करने की प्रोसेस का समय और अवधि बदल सकती है. इसलिए, हमारा सुझाव है कि एक्सपोर्ट के किसी खास समय के आधार पर, डाउनस्ट्रीम ऑपरेशन या जॉब शेड्यूल न करें.
Firebase, BigQuery में आपके मौजूदा डेटा की कॉपी एक्सपोर्ट करता है. एक्सपोर्ट के लिए डेटा को शुरू में प्रोसेस होने में 48 घंटे लग सकते हैं.
- लिंक किए गए हर ऐप्लिकेशन के लिए, इस एक्सपोर्ट में एक बैच टेबल शामिल होती है. इसमें हर दिन सिंक किए गए डेटा की जानकारी होती है.
- पिछले 30 दिनों तक के लिए डेटा बैकफ़िल को मैन्युअल तरीके से शेड्यूल किया जा सकता है. इसके अलावा, BigQuery में एक्सपोर्ट करने की सुविधा चालू करने की सबसे हाल की तारीख के लिए भी डेटा बैकफ़िल को शेड्यूल किया जा सकता है.
ध्यान दें कि अगर आपने Crashlytics डेटा को एक्सपोर्ट करने की सुविधा, अक्टूबर 2024 के पहले चालू की थी, तो एक्सपोर्ट की सुविधा चालू करने से 30 दिन पहले का डेटा भी बैकफ़िल किया जा सकता है.
अगर आपने BigQuery में Crashlytics स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू की है, तो लिंक किए गए सभी ऐप्लिकेशन में भी रीयलटाइम टेबल होगी. इसमें लगातार अपडेट होने वाला डेटा शामिल होगा.

BigQuery में डेटा एक्सपोर्ट करने की सुविधा बंद करने के लिए, Firebase कंसोल में जाकर अपने प्रोजेक्ट को अनलिंक करें.

BigQuery में कौनसा डेटा एक्सपोर्ट किया जाता है?

Firebase Crashlytics डेटा को BigQuery डेटासेट में एक्सपोर्ट किया जाता है. इस डेटासेट का नाम firebase_crashlytics है. डिफ़ॉल्ट रूप से, आपके प्रोजेक्ट में मौजूद हर ऐप्लिकेशन के लिए, अलग-अलग टेबल Crashlytics डेटासेट में बनाई जाएंगी. Firebase, ऐप्लिकेशन के आइडेंटिफ़ायर के आधार पर टेबल के नाम रखता है. इसमें, अवधि को अंडरस्कोर में बदल दिया जाता है और आखिर में प्लैटफ़ॉर्म का नाम जोड़ दिया जाता है.

उदाहरण के लिए, com.google.test पैकेज के नाम वाले Android ऐप्लिकेशन का डेटा, com_google_test_ANDROID नाम की टेबल में होगा. यह बैच टेबल हर दिन एक बार अपडेट होती है. अगर आपने Crashlytics में Crashlytics स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू की है, तो Crashlytics का डेटा भी रीयलटाइम में com_google_test_ANDROID_REALTIME नाम की टेबल में स्ट्रीम किया जाएगा.BigQuery

टेबल की हर लाइन, ऐप्लिकेशन में हुए किसी इवेंट के बारे में बताती है. इसमें क्रैश, नॉन-फ़ैटल गड़बड़ियां, और एएनआर शामिल हैं.

Crashlytics से BigQuery तक स्ट्रीमिंग एक्सपोर्ट

BigQuery स्ट्रीमिंग की मदद से, Crashlytics डेटा को रीयलटाइम में स्ट्रीम किया जा सकता है. इसका इस्तेमाल किसी भी ऐसे काम के लिए किया जा सकता है जिसके लिए लाइव डेटा की ज़रूरत होती है. जैसे, लाइव डैशबोर्ड में जानकारी दिखाना, रोलआउट को लाइव देखना या ऐप्लिकेशन से जुड़ी उन समस्याओं को मॉनिटर करना जिनसे सूचनाएं और कस्टम वर्कफ़्लो ट्रिगर होते हैं.

Crashlytics पर स्ट्रीमिंग एक्सपोर्ट BigQuery चालू करने पर, आपको बैच टेबल के साथ-साथ रीयलटाइम टेबल भी मिलेगी. टेबल के बीच के अंतर यहां दिए गए हैं:

बैच टेबल	रीयलटाइम टेबल
डेटा को हर दिन एक बार एक्सपोर्ट किया जाता है. इवेंट को BigQuery में बैच राइटिंग से पहले, स्थायी तौर पर सेव किया जाता है. डेटा को 30 दिन पहले तक के लिए बैकफ़िल किया जा सकता है*.	डेटा को रीयल टाइम में एक्सपोर्ट किया जाता है. बैकफ़िलिंग की सुविधा उपलब्ध नहीं है.

बैच टेबल

रीयलटाइम टेबल

डेटा को हर दिन एक बार एक्सपोर्ट किया जाता है.
इवेंट को BigQuery में बैच राइटिंग से पहले, स्थायी तौर पर सेव किया जाता है.
डेटा को 30 दिन पहले तक के लिए बैकफ़िल किया जा सकता है*.

डेटा को रीयल टाइम में एक्सपोर्ट किया जाता है.
बैकफ़िलिंग की सुविधा उपलब्ध नहीं है.

बैच टेबल, लंबे समय तक के विश्लेषण और समय के साथ रुझानों की पहचान करने के लिए सबसे सही है. ऐसा इसलिए, क्योंकि हम इवेंट को लिखने से पहले उन्हें लंबे समय तक सेव रखते हैं. साथ ही, उन्हें 30 दिनों* तक टेबल में वापस भरा जा सकता है. जब हम आपकी रीयलटाइम टेबल में डेटा लिखते हैं, तो हम उसे तुरंत BigQuery में लिख देते हैं. इसलिए, यह लाइव डैशबोर्ड और कस्टम सूचनाओं के लिए सबसे सही है. इन दोनों टेबल को स्टिचिंग क्वेरी के साथ मिलाकर, दोनों के फ़ायदे पाए जा सकते हैं.

डिफ़ॉल्ट रूप से, रीयलटाइम टेबल के पार्टीशन की समयसीमा 30 दिन होती है. इसमें बदलाव करने का तरीका जानने के लिए, BigQuery के दस्तावेज़ में पार्टिशन के खत्म होने की तारीख सेट करना लेख पढ़ें.

^{* बैकफ़िल की सुविधा के बारे में ज़्यादा जानकारी के लिए, एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करें लेख पढ़ें.}

Crashlytics से BigQuery में स्ट्रीमिंग एक्सपोर्ट करने की सुविधा चालू करना

Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.
BigQuery कार्ड में, मैनेज करें पर क्लिक करें.
स्ट्रीमिंग शामिल करें चेकबॉक्स चुनें.

इस कार्रवाई से, लिंक किए गए सभी ऐप्लिकेशन के लिए स्ट्रीमिंग की सुविधा चालू हो जाती है.

क्या आपको रीयलटाइम टेबल में डेटा नहीं दिख रहा है?

पक्का करें कि आपने अपने ऐप्लिकेशन से कम से कम दो इवेंट Crashlytics को भेजे हों. साथ ही, उन्हें भेजने के बाद कुछ मिनट इंतज़ार किया हो.
पक्का करें कि आपका Firebase प्रोजेक्ट, इस्तेमाल के हिसाब से शुल्क चुकाने वाले ब्लेज़ प्लान पर हो.
इसके लिए, Firebase कंसोल में सबसे नीचे बाएं कोने में देखें.
अगर दो इवेंट भेजने और कुछ मिनट इंतज़ार करने के बाद भी, रीयलटाइम टेबल में कोई डेटा नहीं दिखता है, तो:
1. Firebase कंसोल में, BigQuery कार्ड पर जाएं.
2. स्ट्रीमिंग एक्सपोर्ट करने की सुविधा को बंद करें और फिर से चालू करें.
3. पक्का करें कि सेवा खाता service-PROJECT_NUMBER@gcp-sa-crashlytics.iam.gserviceaccount.com आपके Firebase प्रोजेक्ट में हो और उसके पास Firebase Crashlytics सेवा एजेंट की भूमिका हो.
  इसकी जांच, Google Cloud कंसोल के IAM पेज पर की जा सकती है. Google की ओर से असाइन किए गए रोल शामिल करें चेकबॉक्स को चुनना न भूलें.
4. Crashlytics में कम से कम दो इवेंट भेजें और कुछ मिनट इंतज़ार करें.
अगर आपको अब भी रीयलटाइम टेबल में डेटा नहीं दिखता है, तो Firebase की सहायता टीम से संपर्क करें.

एक्सपोर्ट किए गए डेटा का इस्तेमाल कैसे किया जा सकता है?

BigQuery में एक्सपोर्ट किए गए डेटा में, क्रैश का रॉ डेटा शामिल होता है. इसमें डिवाइस का टाइप, ऑपरेटिंग सिस्टम, अपवाद (Android ऐप्लिकेशन) या गड़बड़ियां (Apple ऐप्लिकेशन), और Crashlytics लॉग के साथ-साथ अन्य डेटा भी शामिल होता है.

इस पेज पर, Crashlyticsएक्सपोर्ट किए गए डेटा और उसके टेबल स्कीमा के बारे में ज़्यादा जानें.

Data Studio टेंप्लेट का इस्तेमाल करना

अपने Data Studio टेंप्लेट में रीयलटाइम डेटा चालू करने के लिए, Data Studio की मदद से एक्सपोर्ट किए गए Crashlytics डेटा को विज़ुअलाइज़ करना में दिए गए निर्देशों का पालन करें.

व्यू बनाना

BigQuery यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, क्वेरी को व्यू में बदला जा सकता है. ज़्यादा जानकारी के लिए, BigQuery के दस्तावेज़ में व्यू बनाना लेख पढ़ें.

क्वेरी चलाना

यहां दिए गए उदाहरणों में, ऐसी क्वेरी दिखाई गई हैं जिन्हें Crashlytics डेटा पर चलाया जा सकता है. इससे ऐसी रिपोर्ट जनरेट होती हैं जिनमें क्रैश इवेंट के डेटा को आसानी से समझी जा सकने वाली खास जानकारी में एग्रीगेट किया जाता है. इस तरह की रिपोर्ट, Crashlytics कंसोल के Crashlytics डैशबोर्ड में उपलब्ध नहीं होती हैं. इसलिए, ये क्रैश डेटा के विश्लेषण और उसे समझने में आपकी मदद कर सकती हैं.Firebase

उदाहरण 1: दिन के हिसाब से क्रैश की संख्या

आपने ज़्यादा से ज़्यादा बग ठीक कर लिए हैं. अब आपको लगता है कि आपकी टीम, फ़ोटो शेयर करने वाले नए ऐप्लिकेशन को लॉन्च करने के लिए तैयार है. हालांकि, इससे पहले आपको यह पक्का करना है कि बग-बैश की वजह से, ऐप्लिकेशन समय के साथ ज़्यादा स्टेबल हो गया है. इसके लिए, आपको पिछले महीने हर दिन ऐप्लिकेशन के क्रैश होने की संख्या देखनी है.

यहां Android ऐप्लिकेशन के लिए क्वेरी का एक उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, उसके बंडल आईडी और IOS का इस्तेमाल करें. इसके बजाय, पैकेज के नाम और 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;

दूसरा उदाहरण: सबसे ज़्यादा क्रैश होने वाले ऐप्लिकेशन ढूंढना

आपको प्रोडक्शन प्लान को सही तरीके से प्राथमिकता देनी है. इसके लिए, आपको अपने ऐप्लिकेशन में सबसे ज़्यादा होने वाली 10 क्रैश की जानकारी चाहिए. आपने एक क्वेरी बनाई है, जो डेटा के ज़रूरी पॉइंट उपलब्ध कराती है.

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;

तीसरा उदाहरण: क्रैश होने वाले टॉप 10 डिवाइस

पतझड़ के मौसम में, नए फ़ोन खरीदने का चलन है! आपकी कंपनी को पता है कि इसका मतलब यह भी है कि यह नए डिवाइस से जुड़ी समस्याओं का सीज़न है. खास तौर पर, Android के लिए. डिवाइसों के साथ काम न करने की समस्या से बचने के लिए, आपने एक क्वेरी तैयार की है. इससे आपको उन 10 डिवाइसों के बारे में पता चलेगा जिन पर पिछले हफ़्ते (168 घंटे) में सबसे ज़्यादा क्रैश हुए हैं.

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;

चौथा उदाहरण: कस्टम कुंजी के हिसाब से फ़िल्टर करना

आप एक गेम डेवलपर हैं. आपको यह जानना है कि आपके गेम के किस लेवल में सबसे ज़्यादा क्रैश होते हैं.

इस आंकड़े को ट्रैक करने के लिए, कस्टम Crashlytics कुंजी सेट करें. इसे current_level कहा जाता है. साथ ही, जब भी उपयोगकर्ता किसी नए लेवल पर पहुंचता है, तब इसे अपडेट करें.

Swift

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

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

Crashlytics.setInt("current_level", 3);

BigQuery में एक्सपोर्ट की गई उस कुंजी की मदद से, क्वेरी लिखी जा सकती है. इससे हर क्रैश इवेंट से जुड़ी current_level वैल्यू के डिस्ट्रिब्यूशन की रिपोर्ट बनाई जा सकती है.

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

उदाहरण 5: यूज़र आईडी निकालना

आपके पास 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

उदाहरण 6: क्रैश की किसी समस्या का सामना करने वाले सभी उपयोगकर्ताओं को ढूंढना

आपकी टीम ने गलती से, बीटा टेस्टर के किसी ग्रुप के लिए गंभीर बग रिलीज़ कर दिया है. आपकी टीम ने ऊपर दिए गए "सबसे ज़्यादा बार क्रैश होने की समस्या ढूंढें" उदाहरण में दी गई क्वेरी का इस्तेमाल करके, क्रैश होने की समस्या का आईडी पता लगाया. अब आपकी टीम, ऐप्लिकेशन इस्तेमाल करने वाले उन लोगों की सूची निकालने के लिए क्वेरी चलाना चाहती है जिन पर इस क्रैश का असर पड़ा है.

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;

उदाहरण 7: क्रैश की समस्या से प्रभावित उपयोगकर्ताओं की संख्या, देश के हिसाब से

आपकी टीम को नई रिलीज़ को रोल आउट करते समय, एक गंभीर बग का पता चला है. ऊपर दिए गए "सबसे ज़्यादा बार क्रैश होने की समस्या ढूंढें" उदाहरण में दी गई क्वेरी का इस्तेमाल करके, क्रैश होने की समस्या का आईडी पता लगाया जा सकता है. अब आपकी टीम यह देखना चाहती है कि क्या यह क्रैश, दुनिया भर के अलग-अलग देशों में मौजूद उपयोगकर्ताओं के लिए भी हुआ है.

इस क्वेरी को लिखने के लिए, आपकी टीम को यह काम करना होगा:

Google Analytics के डेटा को BigQuery में एक्सपोर्ट करने की सुविधा चालू करें. प्रोजेक्ट के डेटा को BigQuery में एक्सपोर्ट करना लेख पढ़ें.

अपने ऐप्लिकेशन को अपडेट करें, ताकि उपयोगकर्ता आईडी को Google Analytics SDK और 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");

ऐसी क्वेरी लिखें जो यूज़र आईडी फ़ील्ड का इस्तेमाल करके, Google Analytics डेटासेट में मौजूद इवेंट को Crashlytics डेटासेट में मौजूद क्रैश से जोड़ती हो.

यहां Android ऐप्लिकेशन के लिए क्वेरी का एक उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, उसके बंडल आईडी और IOS का इस्तेमाल करें (पैकेज के नाम और 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
```

उदाहरण 8: आज अब तक की पांच सबसे बड़ी समस्याएं

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;

उदाहरण 9: DATE से लेकर आज तक की पांच सबसे बड़ी समस्याएं

भरोसेमंद बैच डेटा में रीयलटाइम जानकारी जोड़ने के लिए, बैच और रीयलटाइम टेबल को स्टिचिंग क्वेरी के साथ भी जोड़ा जा सकता है. event_id एक प्राइमरी कुंजी है. इसलिए, DISTINCT event_id का इस्तेमाल करके, दोनों टेबल से किसी भी सामान्य इवेंट को डुप्लीकेट होने से रोका जा सकता है.

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;

BigQuery में Crashlytics स्कीमा को समझना

Crashlytics में BigQuery का डेटा एक्सपोर्ट करने की सुविधा सेट अप करने पर, Firebase हाल ही के इवेंट (क्रैश, नॉन-फ़ैटल गड़बड़ियां, और एएनआर) एक्सपोर्ट करता है. इसमें लिंक करने से दो दिन पहले के इवेंट भी शामिल होते हैं. साथ ही, 30 दिनों तक के डेटा को बैकफ़िल करने का विकल्प भी मिलता है.

एक्सपोर्ट की सुविधा बंद करने तक, Firebase हर दिन Crashlytics इवेंट एक्सपोर्ट करता है. हर एक्सपोर्ट के बाद, डेटा को BigQuery में उपलब्ध होने में कुछ मिनट लग सकते हैं.

डेटासेट

Crashlytics, BigQuery में Crashlytics डेटा के लिए एक नया डेटासेट बनाता है. डेटासेट में आपके पूरे प्रोजेक्ट का डेटा शामिल होता है. भले ही, उसमें एक से ज़्यादा ऐप्लिकेशन हों.

टेबल

Crashlytics आपके प्रोजेक्ट में मौजूद हर ऐप्लिकेशन के लिए, डेटासेट में एक टेबल बनाता है. हालांकि, ऐसा तब तक होता है, जब तक आपने उस ऐप्लिकेशन के लिए डेटा एक्सपोर्ट करने की सुविधा बंद न की हो. Firebase, ऐप्लिकेशन के आइडेंटिफ़ायर के आधार पर टेबल के नाम रखता है. इसमें अवधि को अंडरस्कोर में बदल दिया जाता है. साथ ही, प्लैटफ़ॉर्म का नाम आखिर में जोड़ दिया जाता है.

उदाहरण के लिए, com.google.test पैकेज के नाम वाले Android ऐप्लिकेशन का डेटा, com_google_test_ANDROID नाम की टेबल में होगा. साथ ही, रीयलटाइम डेटा (अगर चालू है), com_google_test_ANDROID_REALTIME नाम की टेबल में होगा

टेबल में Crashlytics डेटा का स्टैंडर्ड सेट होता है. इसके अलावा, इसमें आपके ऐप्लिकेशन में तय की गई कस्टम Crashlytics कुंजियां भी होती हैं.

लाइन

टेबल की हर लाइन, ऐप्लिकेशन में हुई किसी गड़बड़ी के बारे में बताती है.

कॉलम

किसी टेबल में मौजूद कॉलम, क्रैश, नॉन-फ़ैटल गड़बड़ियों, और एएनआर के लिए एक जैसे होते हैं. अगर Crashlytics में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू है, तो रीयलटाइम टेबल में वही कॉलम होंगे जो बैच टेबल में हैं.BigQuery ध्यान दें कि ऐसा हो सकता है कि आपकी लाइनों में ऐसे इवेंट दिखाने वाले कॉलम हों जिनके स्टैक ट्रेस मौजूद नहीं हैं.

एक्सपोर्ट में शामिल कॉलम की जानकारी इस टेबल में दी गई है:

फ़ील्ड का नाम	डेटा टाइप	ब्यौरा
`platform`	स्ट्रिंग	Firebase प्रोजेक्ट में रजिस्टर किए गए ऐप्लिकेशन का प्लैटफ़ॉर्म (मान्य वैल्यू: `IOS` या `ANDROID`)
`bundle_identifier`	स्ट्रिंग	Firebase प्रोजेक्ट में रजिस्टर किए गए ऐप्लिकेशन का यूनीक आइडेंटिफ़ायर (उदाहरण के लिए, `com.google.gmail`) Apple प्लैटफ़ॉर्म के ऐप्लिकेशन के लिए, यह ऐप्लिकेशन का बंडल आईडी होता है. Android ऐप्लिकेशन के लिए, यह ऐप्लिकेशन के पैकेज का नाम होता है.
`event_id`	स्ट्रिंग	इवेंट के लिए यूनीक आईडी
`is_fatal`	बूलियन	यह फ़ील्ड काम नहीं करता है. इसके बजाय, `error_type` का इस्तेमाल करें. क्या ऐप्लिकेशन क्रैश हुआ
`error_type`	स्ट्रिंग	इवेंट में हुई गड़बड़ी का टाइप. उदाहरण के लिए, `FATAL`, `NON_FATAL`, `ANR` वगैरह
`issue_id`	स्ट्रिंग	इवेंट से जुड़ी समस्या
`variant_id`	स्ट्रिंग	इस इवेंट से जुड़ा समस्या वाला वैरिएंट ध्यान दें कि सभी इवेंट से समस्या वाला वैरिएंट जुड़ा नहीं होता.
`event_timestamp`	TIMESTAMP	इवेंट कब हुआ
`device`	रिकॉर्ड	वह डिवाइस जिस पर इवेंट हुआ
`device.manufacturer`	स्ट्रिंग	डिवाइस बनाने वाली कंपनी
`device.model`	स्ट्रिंग	डिवाइस का मॉडल
`device.architecture`	स्ट्रिंग	उदाहरण के लिए, `X86_32`, `X86_64`, `ARMV7`, `ARM64`, `ARMV7S` या `ARMV7K`
`memory`	रिकॉर्ड	डिवाइस के स्टोरेज की स्थिति
`memory.used`	INT64	इस्तेमाल की गई मेमोरी के बाइट
`memory.free`	INT64	बची हुई मेमोरी के बाइट
`storage`	रिकॉर्ड	डिवाइस का स्थायी स्टोरेज
`storage.used`	INT64	इस्तेमाल किए गए स्टोरेज के बाइट
`storage.free`	INT64	स्टोरेज के लिए बचे हुए बाइट
`operating_system`	रिकॉर्ड	डिवाइस पर मौजूद ओएस की जानकारी
`operating_system.display_version`	स्ट्रिंग	डिवाइस पर मौजूद ओएस का वर्शन
`operating_system.name`	स्ट्रिंग	डिवाइस पर मौजूद ओएस का नाम
`operating_system.modification_state`	स्ट्रिंग	डिवाइस में बदलाव किया गया है या नहीं (उदाहरण के लिए, जेलब्रेक किए गए ऐप्लिकेशन को `MODIFIED` और रूट किए गए ऐप्लिकेशन को `UNMODIFIED` के तौर पर दिखाया जाता है)
`operating_system.type`	स्ट्रिंग	(सिर्फ़ Apple ऐप्लिकेशन के लिए) डिवाइस पर चल रहे ओएस का टाइप (उदाहरण के लिए, `IOS`, `MACOS` वगैरह)
`operating_system.device_type`	स्ट्रिंग	डिवाइस का टाइप (उदाहरण के लिए, `MOBILE`, `TABLET`, `TV` वगैरह); इसे "डिवाइस कैटगरी" भी कहा जाता है
`application`	रिकॉर्ड	वह ऐप्लिकेशन जिसने इवेंट जनरेट किया है
`application.build_version`	स्ट्रिंग	ऐप्लिकेशन के बिल्ड का वर्शन
`application.display_version`	स्ट्रिंग
`user`	रिकॉर्ड	(ज़रूरी नहीं) ऐप्लिकेशन के उपयोगकर्ता के बारे में इकट्ठा की गई जानकारी
`user.name`	स्ट्रिंग	यह फ़ील्ड काम नहीं करता है. इसका इस्तेमाल न करें. (ज़रूरी नहीं) उपयोगकर्ता का नाम
`user.email`	स्ट्रिंग	यह फ़ील्ड काम नहीं करता है. इसका इस्तेमाल न करें. (ज़रूरी नहीं) उपयोगकर्ता का ईमेल पता
`user.id`	स्ट्रिंग	(ज़रूरी नहीं) उपयोगकर्ता से जुड़ा ऐप्लिकेशन-विशिष्ट आईडी
`custom_keys`	बार-बार रिकॉर्ड किया गया	डेवलपर के तय किए गए की-वैल्यू पेयर
`custom_keys.key`	स्ट्रिंग	डेवलपर की तय की गई कुंजी
`custom_keys.value`	स्ट्रिंग	डेवलपर की ओर से तय की गई वैल्यू
`installation_uuid`	स्ट्रिंग	यह आईडी, किसी ऐप्लिकेशन और डिवाइस के यूनीक इंस्टॉलेशन की पहचान करता है
`crashlytics_sdk_versions`	स्ट्रिंग	इवेंट जनरेट करने वाले Crashlytics SDK टूल का वर्शन
`app_orientation`	स्ट्रिंग	उदाहरण के लिए, `PORTRAIT`, `LANDSCAPE`, `FACE_UP`, `FACE_DOWN` वगैरह.
`device_orientation`	स्ट्रिंग	उदाहरण के लिए, `PORTRAIT`, `LANDSCAPE`, `FACE_UP`, `FACE_DOWN` वगैरह.
`process_state`	स्ट्रिंग	`BACKGROUND` या `FOREGROUND`
`logs`	बार-बार रिकॉर्ड किया गया	अगर Crashlytics लॉगर चालू है, तो उससे जनरेट हुए टाइमस्टैंप वाले लॉग मैसेज
`logs.timestamp`	TIMESTAMP	लॉग कब बनाया गया था
`logs.message`	स्ट्रिंग	लॉग किया गया मैसेज
`breadcrumbs`	बार-बार रिकॉर्ड किया गया	टाइमस्टैंप किए गए Google Analytics ब्रेडक्रंब, अगर चालू हों
`breadcrumbs.timestamp`	TIMESTAMP	ब्रेडक्रंब से जुड़ा टाइमस्टैंप
`breadcrumbs.name`	स्ट्रिंग	ब्रैडक्रंब से जुड़ा नाम
`breadcrumbs.params`	बार-बार रिकॉर्ड किया गया	ब्रेडक्रंब से जुड़े पैरामीटर
`breadcrumbs.params.key`	स्ट्रिंग	ब्रेडक्रंब से जुड़ी पैरामीटर कुंजी
`breadcrumbs.params.value`	स्ट्रिंग	ब्रेडक्रंब से जुड़ी पैरामीटर वैल्यू
`blame_frame`	रिकॉर्ड	क्रैश या गड़बड़ी की मुख्य वजह के तौर पर पहचाना गया फ़्रेम
`blame_frame.line`	INT64	फ़्रेम की फ़ाइल का लाइन नंबर
`blame_frame.file`	स्ट्रिंग	फ़्रेम फ़ाइल का नाम
`blame_frame.symbol`	स्ट्रिंग	हाइड्रेटेड सिंबल या अगर हाइड्रेट नहीं किया जा सकता, तो रॉ सिंबल
`blame_frame.offset`	INT64	बाइनरी इमेज में बाइट ऑफ़सेट, जिसमें कोड शामिल है Java अपवादों के लिए सेट नहीं किया गया है
`blame_frame.address`	INT64	बाइनरी इमेज में मौजूद वह पता जिसमें कोड शामिल है Java फ़्रेम के लिए सेट नहीं है
`blame_frame.library`	स्ट्रिंग	उस लाइब्रेरी का डिसप्ले नेम जिसमें फ़्रेम शामिल है
`blame_frame.owner`	स्ट्रिंग	उदाहरण के लिए, `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` या `SYSTEM`
`blame_frame.blamed`	बूलियन	क्या Crashlytics ने यह तय किया है कि इस फ़्रेम की वजह से क्रैश या गड़बड़ी हुई है
`exceptions`	बार-बार रिकॉर्ड किया गया	(सिर्फ़ Android के लिए) इस इवेंट के दौरान हुई गड़बड़ियां. नेस्ट किए गए अपवादों को उल्टे कालानुक्रम में दिखाया जाता है. इसका मतलब है कि आखिरी रिकॉर्ड, पहला अपवाद होता है
`exceptions.type`	स्ट्रिंग	अपवाद का टाइप (उदाहरण के लिए, `java.lang.IllegalStateException)`
`exceptions.exception_message`	स्ट्रिंग	अपवाद से जुड़ा मैसेज
`exceptions.nested`	बूलियन	यह वैल्यू, पहले रिकॉर्ड को छोड़कर सभी के लिए सही होती है
`exceptions.title`	स्ट्रिंग	थ्रेड का टाइटल
`exceptions.subtitle`	स्ट्रिंग	थ्रेड का सबटाइटल
`exceptions.blamed`	बूलियन	अगर Crashlytics यह तय करता है कि अपवाद की वजह से गड़बड़ी हुई है या ऐप्लिकेशन क्रैश हुआ है, तो वैल्यू 'सही' के तौर पर सेट होगी
`exceptions.frames`	बार-बार रिकॉर्ड किया गया	अपवाद से जुड़े फ़्रेम
`exceptions.frames.line`	INT64	फ़्रेम की फ़ाइल का लाइन नंबर
`exceptions.frames.file`	स्ट्रिंग	फ़्रेम फ़ाइल का नाम
`exceptions.frames.symbol`	स्ट्रिंग	हाइड्रेटेड सिंबल या अगर हाइड्रेट नहीं किया जा सकता, तो रॉ सिंबल
`exceptions.frames.offset`	INT64	बाइनरी इमेज में बाइट ऑफ़सेट, जिसमें कोड शामिल है Java अपवादों के लिए सेट नहीं किया गया है
`exceptions.frames.address`	INT64	बाइनरी इमेज में मौजूद वह पता जिसमें कोड शामिल है Java फ़्रेम के लिए सेट नहीं है
`exceptions.frames.library`	स्ट्रिंग	उस लाइब्रेरी का डिसप्ले नेम जिसमें फ़्रेम शामिल है
`exceptions.frames.owner`	स्ट्रिंग	उदाहरण के लिए, `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` या `SYSTEM`
`exceptions.frames.blamed`	बूलियन	क्या Crashlytics ने यह तय किया है कि इस फ़्रेम की वजह से क्रैश या गड़बड़ी हुई है
`error`	बार-बार रिकॉर्ड किया गया	(सिर्फ़ Apple के ऐप्लिकेशन के लिए) नुकसान न पहुंचाने वाली गड़बड़ियां
`error.queue_name`	स्ट्रिंग	वह कतार जिस पर थ्रेड चल रहा था
`error.code`	INT64	ऐप्लिकेशन के कस्टम लॉग किए गए NSError से जुड़ा गड़बड़ी कोड
`error.title`	स्ट्रिंग	थ्रेड का टाइटल
`error.subtitle`	स्ट्रिंग	थ्रेड का सबटाइटल
`error.blamed`	बूलियन	क्या Crashlytics ने यह तय किया है कि इस फ़्रेम की वजह से गड़बड़ी हुई है
`error.frames`	बार-बार रिकॉर्ड किया गया	स्टैकट्रेस के फ़्रेम
`error.frames.line`	INT64	फ़्रेम की फ़ाइल का लाइन नंबर
`error.frames.file`	स्ट्रिंग	फ़्रेम फ़ाइल का नाम
`error.frames.symbol`	स्ट्रिंग	हाइड्रेटेड सिंबल या अगर हाइड्रेट नहीं किया जा सकता, तो रॉ सिंबल
`error.frames.offset`	INT64	बाइनरी इमेज में बाइट ऑफ़सेट, जिसमें कोड मौजूद है
`error.frames.address`	INT64	बाइनरी इमेज में मौजूद वह पता जिसमें कोड मौजूद है
`error.frames.library`	स्ट्रिंग	उस लाइब्रेरी का डिसप्ले नेम जिसमें फ़्रेम शामिल है
`error.frames.owner`	स्ट्रिंग	उदाहरण के लिए, `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` या `SYSTEM`
`error.frames.blamed`	बूलियन	क्या Crashlytics ने यह तय किया है कि इस फ़्रेम की वजह से गड़बड़ी हुई है
`threads`	बार-बार रिकॉर्ड किया गया	इवेंट के समय मौजूद थ्रेड
`threads.crashed`	बूलियन	थ्रेड क्रैश हुई या नहीं
`threads.thread_name`	स्ट्रिंग	थ्रेड का नाम
`threads.queue_name`	स्ट्रिंग	(सिर्फ़ Apple ऐप्लिकेशन के लिए) वह कतार जिस पर थ्रेड चल रहा था
`threads.signal_name`	स्ट्रिंग	उस सिग्नल का नाम जिसकी वजह से ऐप्लिकेशन क्रैश हुआ. यह सिर्फ़ क्रैश हुए नेटिव थ्रेड पर मौजूद होता है
`threads.signal_code`	स्ट्रिंग	उस सिग्नल का कोड जिसकी वजह से ऐप्लिकेशन क्रैश हुआ; यह सिर्फ़ क्रैश हुए नेटिव थ्रेड पर मौजूद होता है
`threads.crash_address`	INT64	उस सिग्नल का पता जिसकी वजह से ऐप्लिकेशन क्रैश हुआ; यह सिर्फ़ क्रैश हुई नेटिव थ्रेड पर मौजूद होता है
`threads.code`	INT64	(सिर्फ़ Apple ऐप्लिकेशन के लिए) ऐप्लिकेशन के कस्टम लॉग किए गए NSError का गड़बड़ी कोड
`threads.title`	स्ट्रिंग	थ्रेड का टाइटल
`threads.subtitle`	स्ट्रिंग	थ्रेड का सबटाइटल
`threads.blamed`	बूलियन	क्या Crashlytics ने यह तय किया है कि इस फ़्रेम की वजह से क्रैश या गड़बड़ी हुई है
`threads.frames`	बार-बार रिकॉर्ड किया गया	थ्रेड के फ़्रेम
`threads.frames.line`	INT64	फ़्रेम की फ़ाइल का लाइन नंबर
`threads.frames.file`	स्ट्रिंग	फ़्रेम फ़ाइल का नाम
`threads.frames.symbol`	स्ट्रिंग	हाइड्रेटेड सिंबल या अगर हाइड्रेट नहीं किया जा सकता, तो रॉ सिंबल
`threads.frames.offset`	INT64	बाइनरी इमेज में बाइट ऑफ़सेट, जिसमें कोड मौजूद है
`threads.frames.address`	INT64	बाइनरी इमेज में मौजूद वह पता जिसमें कोड मौजूद है
`threads.frames.library`	स्ट्रिंग	उस लाइब्रेरी का डिसप्ले नेम जिसमें फ़्रेम शामिल है
`threads.frames.owner`	स्ट्रिंग	उदाहरण के लिए, `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` या `SYSTEM`
`threads.frames.blamed`	बूलियन	क्या Crashlytics ने यह तय किया है कि इस फ़्रेम की वजह से गड़बड़ी हुई है
`unity_metadata.unity_version`	स्ट्रिंग	इस डिवाइस पर चल रहा Unity का वर्शन
`unity_metadata.debug_build`	बूलियन	अगर यह डीबग बिल्ड है
`unity_metadata.processor_type`	स्ट्रिंग	प्रोसेसर का टाइप
`unity_metadata.processor_count`	INT64	प्रोसेसर (कोर) की संख्या
`unity_metadata.processor_frequency_mhz`	INT64	प्रोसेसर की फ़्रीक्वेंसी, मेगाहर्ट्ज़ में
`unity_metadata.system_memory_size_mb`	INT64	सिस्टम की मेमोरी का साइज़, एमबी में
`unity_metadata.graphics_memory_size_mb`	INT64	एमबी में ग्राफ़िक्स मेमोरी
`unity_metadata.graphics_device_id`	INT64	ग्राफ़िक्स डिवाइस का आइडेंटिफ़ायर
`unity_metadata.graphics_device_vendor_id`	INT64	ग्राफ़िक्स प्रोसेसर के वेंडर का आइडेंटिफ़ायर
`unity_metadata.graphics_device_name`	स्ट्रिंग	ग्राफ़िक्स डिवाइस का नाम
`unity_metadata.graphics_device_vendor`	स्ट्रिंग	ग्राफ़िक्स डिवाइस का वेंडर
`unity_metadata.graphics_device_version`	स्ट्रिंग	ग्राफ़िक्स डिवाइस का वर्शन
`unity_metadata.graphics_device_type`	स्ट्रिंग	ग्राफ़िक्स डिवाइस का टाइप
`unity_metadata.graphics_shader_level`	INT64	ग्राफ़िक्स का शेडर लेवल
`unity_metadata.graphics_render_target_count`	INT64	ग्राफ़िकल रेंडरिंग के टारगेट की संख्या
`unity_metadata.graphics_copy_texture_support`	स्ट्रिंग	Unity API में बताए गए तरीके के मुताबिक, ग्राफ़िक्स टेक्सचर कॉपी करने की सुविधा
`unity_metadata.graphics_max_texture_size`	INT64	टेक्सचर रेंडर करने के लिए तय किया गया ज़्यादा से ज़्यादा साइज़
`unity_metadata.screen_size_px`	स्ट्रिंग	स्क्रीन का साइज़, पिक्सल में. इसे चौड़ाई x ऊंचाई के तौर पर फ़ॉर्मैट किया जाता है
`unity_metadata.screen_resolution_dpi`	स्ट्रिंग	स्क्रीन का डीपीआई, फ़्लोटिंग पॉइंट नंबर के तौर पर
`unity_metadata.screen_refresh_rate_hz`	INT64	स्क्रीन की रीफ़्रेश दर, हर्ट्ज़ में

Data Studio की मदद से, एक्सपोर्ट किए गए Crashlytics डेटा को विज़ुअलाइज़ करना

Google Data Studio, BigQuery में मौजूद आपके Crashlytics डेटासेट को ऐसी रिपोर्ट में बदल देता है जिन्हें पढ़ना और शेयर करना आसान होता है. साथ ही, इन्हें पूरी तरह से अपनी ज़रूरत के हिसाब से इस्तेमाल किया जा सकता है.

Data Studio का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, Data Studio की क्विकस्टार्ट गाइड, Data Studio में आपका स्वागत है पढ़ें.

Crashlytics रिपोर्ट टेंप्लेट का इस्तेमाल करना

Data Studio में Crashlytics के लिए एक सैंपल रिपोर्ट है. इसमें एक्सपोर्ट किए गए Crashlytics BigQuery स्कीमा से डाइमेंशन और मेट्रिक का पूरा सेट शामिल है. अगर आपने Crashlytics पर BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू की है, तो Data Studio टेंप्लेट के रीयलटाइम रुझान पेज पर जाकर उस डेटा को देखा जा सकता है. सैंपल का इस्तेमाल टेंप्लेट के तौर पर किया जा सकता है. इससे अपने ऐप्लिकेशन के क्रैश से जुड़े रॉ डेटा के आधार पर, नई रिपोर्ट और विज़ुअलाइज़ेशन तुरंत बनाए जा सकते हैं:

Crashlytics Data Studio डैशबोर्ड टेंप्लेट खोलें.
सबसे ऊपर दाएं कोने में मौजूद, टेंप्लेट का इस्तेमाल करें पर क्लिक करें.
नया डेटा सोर्स ड्रॉप-डाउन में जाकर, नया डेटा सोर्स बनाएं को चुनें.
BigQuery कार्ड पर, चुनें पर क्लिक करें.
एक्सपोर्ट किए गए Crashlytics डेटा वाली टेबल चुनें. इसके लिए, मेरे प्रोजेक्ट > PROJECT_ID > firebase_crashlytics > TABLE_NAME चुनें.

आपके पास बैच टेबल को चुनने का विकल्प हमेशा होता है. अगर Crashlytics BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू है, तो इसके बजाय रीयलटाइम टेबल को चुना जा सकता है.
कॉन्फ़िगरेशन में जाकर, Crashlytics टेंप्लेट लेवल को डिफ़ॉल्ट पर सेट करें.
नया डेटा सोर्स बनाने के लिए, कनेक्ट करें पर क्लिक करें.
Crashlytics टेंप्लेट पर वापस जाने के लिए, रिपोर्ट में जोड़ें पर क्लिक करें.
आखिर में, Crashlytics Data Studio डैशबोर्ड टेंप्लेट की कॉपी बनाने के लिए, रिपोर्ट बनाएं पर क्लिक करें.

एक्सपोर्ट करने के नए इंफ़्रास्ट्रक्चर पर अपग्रेड करना

अक्टूबर 2024 के बीच में, Crashlytics ने Crashlytics के डेटा को BigQuery में बैच एक्सपोर्ट करने के लिए, नया इन्फ़्रास्ट्रक्चर लॉन्च किया.

सभी Firebase प्रोजेक्ट, 15 सितंबर, 2025 से बैच एक्सपोर्ट के नए इन्फ़्रास्ट्रक्चर पर अपने-आप अपग्रेड हो जाएंगे. इस तारीख से पहले अपग्रेड किया जा सकता है. हालांकि, पक्का करें कि आपकी BigQuery बैच टेबल, अपग्रेड करने की ज़रूरी शर्तों को पूरा करती हों.

नए इन्फ़्रास्ट्रक्चर पर अपग्रेड किया जा सकता है. हालांकि, पक्का करें कि आपकी BigQuery बैच टेबल, अपग्रेड करने की ज़रूरी शर्तों को पूरा करती हों.

यह पता लगाना कि आप नए इंफ़्रास्ट्रक्चर पर हैं या नहीं

अगर आपने अक्टूबर 2024 के बीच या उसके बाद बैच एक्सपोर्ट की सुविधा चालू की है, तो आपका Firebase प्रोजेक्ट, एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर का इस्तेमाल अपने-आप कर रहा है.

यह देखा जा सकता है कि आपका प्रोजेक्ट किस इंफ़्रास्ट्रक्चर का इस्तेमाल कर रहा है: Google Cloud कंसोल पर जाएं. अगर आपके "डेटा ट्रांसफ़र कॉन्फ़िगरेशन" को Firebase Crashlytics with Multi-Region Support के तौर पर लेबल किया गया है, तो इसका मतलब है कि आपका प्रोजेक्ट, नए एक्सपोर्ट इंफ़्रास्ट्रक्चर का इस्तेमाल कर रहा है.

डेटा एक्सपोर्ट करने के पुराने और नए इन्फ़्रास्ट्रक्चर के बीच अहम अंतर

नए इंफ़्रास्ट्रक्चर में, अमेरिका के बाहर की Crashlytics डेटासेट लोकेशन काम करती हैं.
- डेटा एक्सपोर्ट करने की सुविधा, अक्टूबर 2024 के मध्य से पहले चालू की गई हो और एक्सपोर्ट करने के नए इंफ़्रास्ट्रक्चर पर अपग्रेड की गई हो — अब आपके पास डेटा एक्सपोर्ट करने की जगह बदलने का विकल्प है.
- डेटा एक्सपोर्ट करने की सुविधा अक्टूबर 2024 के बीच में या उसके बाद चालू की गई हो — सेटअप के दौरान, आपको डेटा एक्सपोर्ट करने के लिए कोई जगह चुनने के लिए कहा गया था.
नए इन्फ़्रास्ट्रक्चर में, एक्सपोर्ट की सुविधा चालू करने से पहले के डेटा को वापस नहीं लाया जा सकता.
- पुराने इन्फ़्रास्ट्रक्चर में, एक्सपोर्ट की सुविधा चालू करने की तारीख से 30 दिन पहले तक का डेटा बैकफ़िल किया जा सकता था.
- नया इन्फ़्रास्ट्रक्चर, पिछले 30 दिनों तक के बैकफ़िल का समर्थन करता है. इसके अलावा, यह उस तारीख तक के बैकफ़िल का भी समर्थन करता है जब आपने BigQuery में एक्सपोर्ट करने की सुविधा चालू की थी. इन दोनों में से जो भी तारीख सबसे नई होगी उस तक का डेटा बैकफ़िल किया जा सकेगा.
नया इंफ़्रास्ट्रक्चर, BigQuery बैच टेबल के नाम रखता है. इसके लिए, वह आपके Firebase प्रोजेक्ट में मौजूद Firebase ऐप्लिकेशन के लिए सेट किए गए आइडेंटिफ़ायर का इस्तेमाल करता है.
- पुराना इन्फ़्रास्ट्रक्चर, बैच टेबल में डेटा लिखता था. इन टेबल के नाम, बंडल आईडी या पैकेज के नाम के आधार पर तय होते थे. ये नाम, आपके ऐप्लिकेशन के कोडबेस में Firebase कॉन्फ़िगरेशन में मौजूद होते हैं.
- नया इन्फ़्रास्ट्रक्चर, बैच टेबल में डेटा लिखता है. इन टेबल के नाम, आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए बंडल आईडी या पैकेज के नामों पर आधारित होते हैं.
अहम जानकारी: अगर आपने अक्टूबर 2024 के मध्य से पहले बैच एक्सपोर्ट की सुविधा चालू की थी, तो पक्का करें कि आपकी मौजूदा बैच टेबल, बंडल आईडी और पैकेज के नाम से जुड़ी ज़रूरी शर्तों को पूरा करती हों. ऐसा, एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर मैन्युअल तरीके से अपग्रेड करने से पहले या 15 सितंबर, 2025 से पहले करें. 15 सितंबर, 2025 को सभी प्रोजेक्ट अपने-आप अपग्रेड हो जाएंगे.

पहला चरण: अपग्रेड करने के लिए ज़रूरी शर्तें

देखें कि आपकी मौजूदा BigQuery बैच टेबल में, बंडल आईडी या पैकेज के नामों से मिलते-जुलते आइडेंटिफ़ायर इस्तेमाल किए गए हों. ये आइडेंटिफ़ायर, आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए हों. अगर वे आपस में मेल नहीं खाते, तो एक्सपोर्ट किए गए बैच डेटा में रुकावटें आ सकती हैं. ज़्यादातर प्रोजेक्ट सही तरीके से काम करेंगे और अपग्रेड किए जा सकेंगे. हालांकि, अपग्रेड करने से पहले यह जांच करना ज़रूरी है.
- आपको अपने Firebase प्रोजेक्ट में रजिस्टर किए गए सभी Firebase ऐप्लिकेशन, Firebase कंसोल में मिल सकते हैं: अपने प्रोजेक्ट सेटिंग पर जाएं. इसके बाद, आपके ऐप्लिकेशन कार्ड पर स्क्रोल करके, अपने सभी Firebase ऐप्लिकेशन और उनकी जानकारी देखें.
- आपको अपनी सभी BigQuery बैच टेबल, Google Cloud कंसोल के BigQuery पेज पर मिल सकती हैं.
ध्यान दें: BigQuery से खत्म होने वाली स्ट्रीमिंग टेबल पर, एक्सपोर्ट करने के नए इंफ़्रास्ट्रक्चर का कोई असर नहीं पड़ता. इसलिए, इन्हें अनदेखा किया जा सकता है.
REALTIME
उदाहरण के लिए, यहां कुछ ऐसी स्थितियां दी गई हैं जिनमें अपग्रेड करने पर आपको कोई समस्या नहीं आएगी:
- आपके पास com_yourcompany_yourproject_IOS नाम की बैच टेबल है. साथ ही, आपके Firebase प्रोजेक्ट में com.yourcompany.yourproject बंडल आईडी वाला Firebase iOS+ ऐप्लिकेशन रजिस्टर है.
- आपके पास com_yourcompany_yourproject_ANDROID नाम की बैच टेबल है. साथ ही, आपके Firebase प्रोजेक्ट में com.yourcompany.yourproject पैकेज नाम वाला Firebase Android ऐप्लिकेशन रजिस्टर है.
अगर आपके बैच टेबल के नाम, रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए आइडेंटिफ़ायर से मेल नहीं खाते हैं, तो दिए गए निर्देशों का पालन करें. मैन्युअल तरीके से अपग्रेड करने या 15 सितंबर, 2025 से पहले इस पेज पर दिए गए निर्देशों का पालन करें, ताकि बैच एक्सपोर्ट में कोई रुकावट न आए.

दूसरा चरण: मैन्युअल तरीके से नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करना

अगर आपने अक्टूबर 2024 के मध्य से पहले बैच एक्सपोर्ट की सुविधा चालू की थी, तो Firebase कंसोल में जाकर, डेटा एक्सपोर्ट की सुविधा को बंद करें और फिर से चालू करें. इससे, आपको नए इन्फ़्रास्ट्रक्चर पर मैन्युअल तरीके से अपग्रेड करने का विकल्प मिलेगा.Crashlytics

यहां रिस्पॉन्सिव साइट में बदलने के तरीके के बारे में ज़्यादा जानकारी दी गई है:

Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.
BigQuery कार्ड में, मैनेज करें पर क्लिक करें.
एक्सपोर्ट की सुविधा बंद करने के लिए, Crashlytics स्लाइडर को टॉगल करके बंद करें. जब कहा जाए, तब पुष्टि करें कि आपको डेटा एक्सपोर्ट करने की सुविधा बंद करनी है.
एक्सपोर्ट की सुविधा को फिर से चालू करने के लिए, Crashlytics स्लाइडर को तुरंत फिर से चालू करें. जब आपसे पूछा जाए, तब पुष्टि करें कि आपको डेटा एक्सपोर्ट करना है.

Crashlytics से BigQuery में डेटा एक्सपोर्ट करने के लिए, अब नए एक्सपोर्ट इन्फ़्रास्ट्रक्चर का इस्तेमाल किया जा रहा है.

आपकी मौजूदा बैच टेबल का नाम, आपके Firebase ऐप्लिकेशन आइडेंटिफ़ायर से मेल नहीं खाता

अगर आपकी मौजूदा बैच टेबल का नाम, रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए बंडल आईडी या पैकेज के नाम से मेल नहीं खाता है, तो इस सेक्शन को बड़ा करें. इसके बाद, एक्सपोर्ट किए गए बैच डेटा में रुकावटों से बचने के लिए, इनमें से कोई एक विकल्प लागू करें.

अगर आपके पास इस स्थिति में मौजूद BigQuery बैच टेबल हैं, तो इसका मतलब है कि वे Firebase के नए बैच एक्सपोर्ट-टू-BigQuery इन्फ़्रास्ट्रक्चर के साथ काम नहीं करती हैं. ध्यान दें कि सभी Firebase प्रोजेक्ट, 15 सितंबर, 2025 से पहले ही नए एक्सपोर्ट इंफ़्रास्ट्रक्चर पर अपने-आप माइग्रेट हो जाएंगे.

Crashlytics से BigQuery में अपने डेटा को बैच एक्सपोर्ट करने में कोई रुकावट न आए, इसके लिए इस सेक्शन में दिए गए दिशा-निर्देशों का पालन करें. मैन्युअल तरीके से अपग्रेड करने से पहले या 15 सितंबर, 2025 से पहले ऐसा करें.

वीडियो में रुकावटों से बचने के विकल्पों के बारे में निर्देश पर जाएं

यह समझना कि एक्सपोर्ट इंफ़्रास्ट्रक्चर, BigQuery टेबल में डेटा लिखने के लिए आइडेंटिफ़ायर का इस्तेमाल कैसे करता है

यहां बताया गया है कि एक्सपोर्ट करने के लिए इस्तेमाल किए जाने वाले दोनों इन्फ़्रास्ट्रक्चर, Crashlytics डेटा को BigQuery बैच टेबल में कैसे लिखते हैं:

एक्सपोर्ट करने का लेगसी इन्फ़्रास्ट्रक्चर: यह डेटा को ऐसी टेबल में लिखता है जिसका नाम, बंडल आईडी या पैकेज के नाम पर आधारित होता है. यह नाम, आपके ऐप्लिकेशन के कोडबेस में Firebase कॉन्फ़िगरेशन में मौजूद होता है. आम तौर पर, यह नाम आपकी GoogleService-Info.plist फ़ाइल या google-services.json फ़ाइल में मौजूद होता है.
डेटा एक्सपोर्ट करने का नया इन्फ़्रास्ट्रक्चर: यह डेटा को ऐसी टेबल में लिखता है जिसका नाम, आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए बंडल आईडी या पैकेज के नाम पर आधारित होता है.

माफ़ करें, कभी-कभी ऐसा होता है कि आपके कोडबेस में मौजूद कॉन्फ़िगरेशन में दिया गया बंडल आईडी या पैकेज का नाम, आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए बंडल आईडी या पैकेज के नाम से मैच नहीं करता. ऐसा आम तौर पर तब होता है, जब किसी व्यक्ति ने आपके ऐप्लिकेशन के कोडबेस में मौजूद कॉन्फ़िगरेशन फ़ाइल में मैन्युअल तरीके से बदलाव किया हो या ऐप्लिकेशन के रजिस्ट्रेशन के दौरान असली आइडेंटिफ़ायर न डाला हो.

ध्यान दें: आपकी Firebase कॉन्फ़िगरेशन फ़ाइल, आपके ऐप्लिकेशन के बंडल आईडी / पैकेज के नाम को आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के साथ मैप करती है. हम इस कॉन्फ़िगरेशन फ़ाइल में मैन्युअल तरीके से बदलाव करने का सुझाव नहीं देते हैं. ऐसा इसलिए, क्योंकि इससे डेटा प्रोसेसिंग और एक्सपोर्ट में अंतर आ सकता है.

अपग्रेड करने से पहले इस समस्या को ठीक न करने पर क्या होगा?

अगर इन दोनों जगहों पर मौजूद आइडेंटिफ़ायर मेल नहीं खाते हैं, तो एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करने के बाद, यह होगा:

आपका Crashlytics डेटा, BigQuery की नई बैच टेबल में लिखना शुरू कर देगा. इसका मतलब है कि बंडल आईडी या पैकेज के नाम के आधार पर, एक नई टेबल बनाई जाएगी. यह नाम आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किया गया होगा.
आइडेंटिफ़ायर के आधार पर नाम वाली किसी भी मौजूदा "लेगसी" टेबल में, अब डेटा नहीं लिखा जाएगा. यह कॉन्फ़िगरेशन, आपके कोडबेस में मौजूद होता है.

पहचानकर्ताओं के मेल न खाने के उदाहरण

ध्यान दें कि BigQuery बैच टेबल के नामों में, ऐप्लिकेशन के प्लैटफ़ॉर्म के बारे में बताने के लिए _IOS या _ANDROID अपने-आप जुड़ जाता है.

आपके ऐप्लिकेशन के कोडबेस में मौजूद आइडेंटिफ़ायर	आपके Firebase ऐप्लिकेशन के लिए सेट किए गए आइडेंटिफ़ायर	लेगसी वर्शन का व्यवहार	एक्सपोर्ट के नए इंफ़्रास्ट्रक्चर पर अपग्रेड करने के बाद का व्यवहार	समाधान
`foo`	`bar`	यह ऐप्लिकेशन के कोडबेस (`foo`) में मौजूद आइडेंटिफ़ायर के नाम वाली एक टेबल में डेटा लिखता है	यह कुकी, Firebase ऐप्लिकेशन (`bar`) के लिए सेट किए गए आइडेंटिफ़ायर के नाम वाली एक टेबल बनाती है और फिर उसमें डेटा लिखती है	यहां दिए गए पहले या दूसरे विकल्प को लागू करें.
`foo`	`bar`, `qux` वगैरह	यह ऐप्लिकेशन के कोडबेस (`foo`) में मौजूद आइडेंटिफ़ायर के नाम वाली एक टेबल में डेटा लिखता है	यह कुकी, Firebase ऐप्लिकेशन (`bar`, `qux` वगैरह) के लिए सेट किए गए आइडेंटिफ़ायर के नाम वाली कई टेबल बनाती है* और फिर उनमें डेटा लिखती है	नीचे दिए गए दूसरे विकल्प को लागू करें.
`foo`, `baz` वगैरह	`bar`	यह ऐप्लिकेशन के कोडबेस (`foo`, `baz` वगैरह) में मौजूद कई आइडेंटिफ़ायर के नाम वाली कई टेबल में डेटा लिखता है	यह हर ऐप्लिकेशन का डेटा बनाता है** और फिर उसे एक टेबल में लिखता है. इस टेबल का नाम, Firebase ऐप्लिकेशन (`bar`) के लिए सेट किए गए आइडेंटिफ़ायर के नाम पर रखा जाता है	इनमें से कोई भी विकल्प लागू नहीं किया जा सकता. डेटा को एक्सपोर्ट करते समय, ऐप्लिकेशन के `bundle_identifier` को भी एक्सपोर्ट किया जाता है. इसलिए, एक ही टेबल में मौजूद हर ऐप्लिकेशन के डेटा को अलग-अलग किया जा सकता है.

^{* अगर आपके ऐप्लिकेशन के कोडबेस में मौजूद आइडेंटिफ़ायर, Firebase ऐप्लिकेशन के लिए सेट किए गए किसी आइडेंटिफ़ायर से मेल खाता है, तो नया एक्सपोर्ट इन्फ़्रास्ट्रक्चर उस आइडेंटिफ़ायर के लिए नई टेबल नहीं बनाएगा. इसके बजाय, यह उस ऐप्लिकेशन के लिए डेटा को इसमें लिखता रहेगा. अन्य सभी ऐप्लिकेशन, नई टेबल में लिखे जाएंगे.}

^{** अगर आपके ऐप्लिकेशन के कोडबेस में मौजूद कोई आइडेंटिफ़ायर, Firebase ऐप्लिकेशन के लिए सेट किए गए आइडेंटिफ़ायर से मेल खाता है, तो एक्सपोर्ट करने की नई सुविधा से नई टेबल नहीं बनेगी. इसके बजाय, यह उस टेबल को बनाए रखेगा और सभी ऐप्लिकेशन के लिए डेटा लिखना शुरू कर देगा.}

रुकावट से बचने के विकल्प

किसी भी तरह की रुकावट से बचने के लिए, यहां दिए गए विकल्पों में से किसी एक के लिए दिए गए निर्देशों का पालन करें. ऐसा इससे पहले करें कि आप मैन्युअल तरीके से अपग्रेड करें या इससे पहले कि 15 सितंबर, 2025 की समयसीमा खत्म हो जाए.

पहला विकल्प:
एक्सपोर्ट करने के नए इंफ़्रास्ट्रक्चर से बनाई गई नई टेबल का इस्तेमाल करें. मौजूदा टेबल से डेटा को नई टेबल में कॉपी किया जाएगा.
1. Firebase कंसोल में जाकर, लिंक किए गए ऐप्लिकेशन के लिए एक्सपोर्ट की सुविधा बंद करें. इसके बाद, उसे फिर से चालू करके, डेटा एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करें.
  
  इस कार्रवाई से एक नई बैच टेबल बनती है. इसका नाम, आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए बंडल आईडी या पैकेज के नाम पर आधारित होता है.
2. Google Cloud कंसोल में जाकर, अपनी लेगसी टेबल से पूरा डेटा कॉपी करें और उसे अभी-अभी बनाई गई नई टेबल में चिपकाएं.
3. अगर आपके पास कोई ऐसी डाउनस्ट्रीम डिपेंडेंसी है जो आपकी बैच टेबल पर निर्भर करती है, तो उसे नई टेबल का इस्तेमाल करने के लिए बदलें.
ध्यान दें: अपग्रेड करने के बाद, नया डेटा आपकी लेगसी टेबल में नहीं लिखा जाएगा. लेगसी टेबल में पहले से लिखा गया कोई भी डेटा नहीं मिटाया जाएगा.
दूसरा विकल्प:
अपनी मौजूदा टेबल में लिखना जारी रखें. इसके लिए, आपको BigQuery कॉन्फ़िगरेशन में कुछ डिफ़ॉल्ट सेटिंग बदलनी होंगी.
1. Firebase कंसोल में, बैच टेबल के नाम और आइडेंटिफ़ायर के न मिलने वाले ऐप्लिकेशन का Firebase ऐप्लिकेशन आईडी ढूंढें और उसे नोट करें. उदाहरण के लिए, 1:1234567890:ios:321abc456def7890:
  प्रोजेक्ट सेटिंग पर जाएं. इसके बाद, आपके ऐप्लिकेशन कार्ड पर स्क्रोल करके, अपने सभी Firebase ऐप्लिकेशन और उनकी जानकारी देखें.
2. Firebase कंसोल में जाकर, लिंक किए गए ऐप्लिकेशन के लिए एक्सपोर्ट की सुविधा बंद करें. इसके बाद, उसे फिर से चालू करके, डेटा एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करें.
  
  इस कार्रवाई से दो काम होते हैं:
  - यह एक नई बैच टेबल बनाता है. इसका नाम, आपके Firebase प्रोजेक्ट में रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए बंडल आईडी या पैकेज के नाम पर आधारित होता है. (आपको इस टेबल को मिटाना होगा, लेकिन इसे अभी न मिटाएं.)
  - यह सोर्स Firebase Crashlytics with Multi-Region Support के साथ BigQuery "डेटा ट्रांसफ़र कॉन्फ़िगरेशन" बनाता है.
3. Google Cloud कंसोल में, नए "डेटा ट्रांसफ़र कॉन्फ़िगरेशन" को बदलें, ताकि डेटा आपकी मौजूदा टेबल में लिखा जाता रहे:
  1. "डेटा ट्रांसफ़र कॉन्फ़िगरेशन " देखने के लिए, BigQuery> डेटा ट्रांसफ़र पर जाएं.
  2. वह कॉन्फ़िगरेशन चुनें जिसमें सोर्स मौजूद है Firebase Crashlytics with Multi-Region Support.
  3. सबसे ऊपर दाएं कोने में मौजूद, बदलाव करें पर क्लिक करें.
  4. डेटा सोर्स की जानकारी सेक्शन में, gmp_app_id और client_namespace की सूची ढूंढें.
    
    BigQuery में, Firebase ऐप्लिकेशन आईडी को gmp_app_id कहा जाता है. डिफ़ॉल्ट रूप से, BigQuery में client_namespace की वैल्यू, ऐप्लिकेशन का यूनीक बंडल आईडी / पैकेज का नाम होता है. हालांकि, इस डिफ़ॉल्ट कॉन्फ़िगरेशन को बदला जा सकता है.
    
    BigQuery, लिंक किए गए हर Firebase ऐप्लिकेशन के लिए, बैच टेबल के नाम के तौर पर client_namespace वैल्यू का इस्तेमाल करता है.
  5. उस Firebase ऐप्लिकेशन का gmp_app_id ढूंढें जिसके लिए आपको डिफ़ॉल्ट सेटिंग बदलनी हैं. इसके client_namespace की वैल्यू को उस टेबल के नाम पर सेट करें जिसमें Firebase ऐप्लिकेशन को डेटा लिखना है. आम तौर पर, यह उस लेगसी टेबल का नाम होता है जिसमें ऐप्लिकेशन, लेगसी एक्सपोर्ट इंफ़्रास्ट्रक्चर का इस्तेमाल करके डेटा लिखता था.
    
    ध्यान दें: अगर पहले एक ही टेबल में डेटा लिखा जाता था और अपग्रेड करने के बाद आपके पास कई टेबल हैं, तो हर लागू होने वाले gmp_app_id के लिए एक ही client_namespace का इस्तेमाल किया जा सकता है. BigQuery सभी टेबल को मर्ज कर देगा और Firebase ऐप्लिकेशन का सारा डेटा एक ही टेबल में लिख देगा.
  6. कॉन्फ़िगरेशन में किए गए बदलाव को सेव करें.
4. जिन दिनों का डेटा आपकी मौजूदा टेबल में मौजूद नहीं है उनके लिए, बैकफ़िल शेड्यूल करें.
5. बैकफ़िल पूरा होने के बाद, नई टेबल मिटा दें. यह टेबल, एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर की मदद से अपने-आप बनाई गई थी.