ज़्यादा विश्लेषण के लिए, Firebase Crashlytics के डेटा को BigQuery में एक्सपोर्ट किया जा सकता है. BigQuery की मदद से, BigQuery एसक्यूएल का इस्तेमाल करके डेटा का विश्लेषण किया जा सकता है. साथ ही, इसे किसी अन्य क्लाउड सेवा पर एक्सपोर्ट किया जा सकता है. साथ ही, Google Data Studio में इसे विज़ुअलाइज़ेशन और कस्टम डैशबोर्ड के लिए भी इस्तेमाल किया जा सकता है.
BigQuery में एक्सपोर्ट करने की सुविधा चालू करें
Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.
BigQuery कार्ड में, लिंक करें पर क्लिक करें.
BigQuery में एक्सपोर्ट की सुविधा चालू करने के लिए, स्क्रीन पर दिए गए निर्देशों का पालन करें.
अगर आपको BigQuery में अपने Crashlytics डेटा को रीयल-टाइम में ऐक्सेस करना है, तो स्ट्रीमिंग एक्सपोर्ट पर अपग्रेड करें.
एक्सपोर्ट की सुविधा चालू करने पर क्या होता है?
डेटासेट की जगह चुनें. डेटासेट बनाने के बाद, उसकी जगह को बदला नहीं जा सकता. हालांकि, डेटासेट को किसी दूसरी जगह पर कॉपी किया जा सकता है या मैन्युअल तरीके से किसी दूसरी जगह पर ले जाया जा सकता है, यानी कि इसे फिर से बनाया जा सकता है. ज़्यादा जानने के लिए, मौजूदा एक्सपोर्ट की जगह बदलना लेख पढ़ें.
यह जगह सिर्फ़ BigQuery में एक्सपोर्ट किए गए डेटा पर लागू होती है. साथ ही, इससे Firebase कंसोल के Crashlytics डैशबोर्ड या Android Studio में इस्तेमाल के लिए सेव किए गए डेटा की जगह पर कोई असर नहीं पड़ता.
आपके प्रोजेक्ट के सभी ऐप्लिकेशन डिफ़ॉल्ट रूप से, BigQuery से लिंक होते हैं. साथ ही, बाद में प्रोजेक्ट में जोड़े जाने वाले ऐप्लिकेशन भी अपने-आप BigQuery से लिंक कर दिए जाते हैं. आपके पास BigQuery में डेटा भेजने वाले ऐप्लिकेशन चुनने का विकल्प होता है.
Firebase, आपके डेटा को BigQuery के साथ हर दिन सिंक करने की सुविधा सेट अप करता है.
प्रोजेक्ट को लिंक करने के बाद, आम तौर पर आपको अगले दिन के सिंक होने तक इंतज़ार करना होगा, ताकि आपके डेटा का पहला सेट BigQuery में एक्सपोर्ट किया जा सके.
रोज़ सिंक होता है. भले ही, आपने BigQuery में कोई भी शेड्यूल किया गया एक्सपोर्ट सेट अप किया हो. ध्यान दें कि सिंक जॉब के समय और अवधि में बदलाव हो सकता है. इसलिए, हम एक्सपोर्ट के खास समय के आधार पर डाउनस्ट्रीम ऑपरेशन या जॉब शेड्यूल करने का सुझाव नहीं देते.
Firebase, BigQuery में आपके मौजूदा डेटा की कॉपी एक्सपोर्ट करता है. एक्सपोर्ट के लिए डेटा का शुरुआती प्रॉपेगेशन होने में 48 घंटे लग सकते हैं.
लिंक किए गए हर ऐप्लिकेशन के लिए, इस एक्सपोर्ट में एक बैच टेबल शामिल होती है. इसमें हर दिन सिंक किए गए डेटा की जानकारी होती है.
आपके पास, BigQuery में डेटा एक्सपोर्ट करने की सुविधा चालू करने के बाद, बैच टेबल के लिए डेटा बैकफ़िल को मैन्युअल तरीके से शेड्यूल करने का विकल्प होता है. यह शेड्यूल, पिछले 30 दिनों तक की डेटा बैच टेबल के लिए या उस तारीख के लिए किया जा सकता है जिस दिन आपने BigQuery में डेटा एक्सपोर्ट करने की सुविधा चालू की थी.
ध्यान दें कि अगर आपने Crashlytics डेटा को एक्सपोर्ट करने की सुविधा, मध्य अक्टूबर 2024 से पहले चालू की है, तो डेटा एक्सपोर्ट करने की सुविधा चालू करने से 30 दिन पहले का डेटा भी बैकफ़िल किया जा सकता है.
अगर आपने Crashlytics से BigQuery पर स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू की है, तो लिंक किए गए सभी ऐप्लिकेशन में एक रीयल-टाइम टेबल भी होगी. इसमें लगातार अपडेट होने वाला डेटा शामिल होगा.
BigQuery में एक्सपोर्ट की सुविधा बंद करने के लिए, Firebase कंसोल में प्रोजेक्ट को अनलिंक करें.
BigQuery में कौनसा डेटा एक्सपोर्ट किया जाता है?
Firebase Crashlytics के डेटा को BigQuery के firebase_crashlytics
नाम वाले डेटासेट में एक्सपोर्ट किया जाता है. डिफ़ॉल्ट रूप से, आपके प्रोजेक्ट में मौजूद हर ऐप्लिकेशन के लिए, Crashlytics डेटासेट में अलग-अलग टेबल बनाई जाएंगी. Firebase, टेबल को ऐप्लिकेशन के आइडेंटिफ़ायर के आधार पर नाम देता है. इसमें पीरियड को अंडरस्कोर में बदला जाता है और आखिर में प्लैटफ़ॉर्म का नाम जुड़ा होता है.
उदाहरण के लिए, com.google.test
नाम वाले पैकेज वाले Android ऐप्लिकेशन का डेटा, com_google_test_ANDROID
नाम वाली टेबल में होगा. इस बैच टेबल को हर दिन एक बार अपडेट किया जाता है. अगर Crashlytics को BigQuery में स्ट्रीमिंग एक्सपोर्ट करने की सुविधा चालू की जाती है, तो Crashlytics का डेटा com_google_test_ANDROID_REALTIME
नाम की टेबल में रीयल टाइम में भी स्ट्रीम किया जाएगा.
टेबल की हर पंक्ति ऐप्लिकेशन में होने वाले किसी इवेंट को दिखाती है. इसमें क्रैश, नुकसान न पहुंचाने वाली गड़बड़ियां, और एएनआर शामिल हैं.
Crashlytics BigQuery में स्ट्रीमिंग एक्सपोर्ट
BigQuery स्ट्रीमिंग की मदद से, अपने Crashlytics डेटा को रीयल टाइम में स्ट्रीम किया जा सकता है. इसका इस्तेमाल, लाइव डेटा की ज़रूरत वाले किसी भी काम के लिए किया जा सकता है. जैसे, लाइव डैशबोर्ड में जानकारी दिखाना, रोल आउट को लाइव देखना या चेतावनियों और कस्टम वर्कफ़्लो को ट्रिगर करने वाली ऐप्लिकेशन की समस्याओं को मॉनिटर करना.
Crashlytics BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू करने पर, बैच टेबल के साथ-साथ आपके पास रीयल टाइम टेबल भी होगी. यहां टेबल के बीच के उन अंतरों के बारे में बताया गया है जिनके बारे में आपको पता होना चाहिए:
बैच टेबल | रीयलटाइम टेबल |
---|---|
|
|
बैच टेबल, लंबे समय तक के विश्लेषण और समय के साथ रुझानों की पहचान करने के लिए बेहतरीन है. ऐसा इसलिए, क्योंकि हम इवेंट को लिखने से पहले उन्हें सुरक्षित तरीके से सेव करते हैं. साथ ही, इन्हें 30 दिनों तक टेबल में बैकफ़िल किया जा सकता है*. जब हम आपकी रीयल टाइम टेबल में डेटा डालते हैं, तो हम उसे तुरंत BigQuery में डाल देते हैं. इसलिए, यह लाइव डैशबोर्ड और कस्टम सूचनाओं के लिए सबसे सही है. इन दोनों टेबल को स्टिचिंग क्वेरी के साथ जोड़ा जा सकता है, ताकि आपको दोनों के फ़ायदे मिल सकें.
डिफ़ॉल्ट रूप से, रीयल टाइम टेबल में, सेगमेंट की समयसीमा 30 दिन की होती है. इसमें बदलाव करने का तरीका जानने के लिए, BigQuery दस्तावेज़ में पार्टिशन की समयसीमा सेट करना देखें.
* एक्सपोर्ट के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करें में, बैकफ़िल की सहायता के बारे में जानकारी देखें.
Crashlytics स्ट्रीमिंग एक्सपोर्ट को BigQuery पर चालू करें
Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.
BigQuery कार्ड में, मैनेज करें पर क्लिक करें.
स्ट्रीमिंग शामिल करें चेकबॉक्स को चुनें.
ऐसा करने से, लिंक किए गए सभी ऐप्लिकेशन के लिए स्ट्रीमिंग की सुविधा चालू हो जाती है.
एक्सपोर्ट किए गए डेटा का क्या किया जा सकता है?
BigQuery में एक्सपोर्ट किए गए डेटा में, क्रैश का रॉ डेटा शामिल होता है. इसमें डिवाइस टाइप, ऑपरेटिंग सिस्टम, अपवाद (Android ऐप्लिकेशन) या गड़बड़ियां (Apple ऐप्लिकेशन), और Crashlytics लॉग के साथ-साथ अन्य डेटा भी शामिल होता है.
इस पेज पर आगे जाकर, देखें कि Crashlytics का कौनसा डेटा एक्सपोर्ट किया गया है और उसकी टेबल का स्कीमा क्या है.
Data Studio टेंप्लेट का इस्तेमाल करना
अपने Data Studio टेंप्लेट में रीयल टाइम डेटा चालू करने के लिए, Data Studio की मदद से, एक्सपोर्ट किए गए Crashlytics डेटा को विज़ुअलाइज़ करना में दिए गए निर्देशों का पालन करें.
व्यू बनाना
BigQuery यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, क्वेरी को व्यू में बदला जा सकता है. ज़्यादा जानकारी के लिए, BigQuery दस्तावेज़ में व्यू बनाना देखें.
क्वेरी चलाना
यहां दिए गए उदाहरणों में ऐसी क्वेरी दिखाई गई हैं जिन्हें अपने Crashlytics डेटा पर चलाया जा सकता है. इससे, क्रैश इवेंट के डेटा को आसानी से समझी जा सकने वाली खास जानकारी में एग्रीगेट करने वाली रिपोर्ट जनरेट की जा सकती हैं. इस तरह की रिपोर्ट, Firebase कंसोल के Crashlytics डैशबोर्ड में उपलब्ध नहीं होती हैं. इसलिए, ये रिपोर्ट क्रैश डेटा के विश्लेषण और उसे समझने में मदद कर सकती हैं.
पहला उदाहरण: दिन के हिसाब से क्रैश
ज़्यादा से ज़्यादा गड़बड़ियों को ठीक करने के बाद, आपको लगता है कि आपकी टीम अब फ़ोटो शेयर करने वाला नया ऐप्लिकेशन लॉन्च करने के लिए तैयार है. हालांकि, ऐसा करने से पहले आपको पिछले महीने के लिए, हर दिन ऐप्लिकेशन के क्रैश होने की संख्या देखनी है. इससे आपको यह पक्का करने में मदद मिलेगी कि गड़बड़ियों को ठीक करने की प्रोसेस के बाद, ऐप्लिकेशन ज़्यादा बेहतर तरीके से काम कर रहा है या नहीं.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID
के बजाय, उसके बंडल आईडी और IOS
का इस्तेमाल करें.
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 सबसे ज़्यादा बार क्रैश होने वाले क्रैश का पता लगाना होगा. इसके लिए, आपको एक ऐसी क्वेरी बनानी होगी जिसमें डेटा की अहम जानकारी दी गई हो.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID
के बजाय, उसके बंडल आईडी और IOS
का इस्तेमाल करें.
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 के लिए. इस समस्या से बचने के लिए, एक ऐसी क्वेरी लिखें जो पिछले हफ़्ते (168 घंटे) में सबसे ज़्यादा क्रैश हुए 10 डिवाइसों की पहचान करती हो.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID
के बजाय, उसके बंडल आईडी और IOS
का इस्तेमाल करें.
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;
चौथा उदाहरण: कस्टम बटन के हिसाब से फ़िल्टर करना
आप एक गेम डेवलपर हैं और आपको यह जानना है कि आपके गेम के किस लेवल में सबसे ज़्यादा क्रैश आते हैं.
उस आंकड़े को ट्रैक करने के लिए, current_level
नाम की एक कस्टम Crashlytics कुंजी सेट की जाती है. साथ ही, हर बार जब उपयोगकर्ता किसी नए लेवल पर पहुंचता है, तो उसे अपडेट किया जाता है.
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
वैल्यू के डिस्ट्रिब्यूशन की रिपोर्ट करने के लिए क्वेरी लिखी जा सकती है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID
के बजाय, उसके बंडल आईडी और IOS
का इस्तेमाल करें.
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
पांचवां उदाहरण: यूज़र आईडी निकालना
आपके पास Android ऐप्लिकेशन का रिलीज़ होने से पहले इस्तेमाल करने का विकल्प है. आपके ज़्यादातर उपयोगकर्ताओं को यह पसंद आया, लेकिन तीन उपयोगकर्ताओं को ऐप्लिकेशन के क्रैश होने की समस्या का सामना करना पड़ा. समस्या की पूरी जानकारी पाने के लिए, एक क्वेरी लिखी जाती है. यह क्वेरी, उन उपयोगकर्ताओं के यूज़र आईडी का इस्तेमाल करके, उनके सभी क्रैश इवेंट को खींचती है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID
के बजाय, उसके बंडल आईडी
और IOS
का इस्तेमाल करें.
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
छठा उदाहरण: क्रैश से जुड़ी किसी खास समस्या का सामना कर रहे सभी उपयोगकर्ताओं को ढूंढना
आपकी टीम ने गलती से बीटा टेस्टर के ग्रुप को एक गंभीर गड़बड़ी भेज दी है. आपकी टीम, क्रैश की समस्या के आईडी की पहचान करने के लिए, ऊपर दिए गए "सबसे ज़्यादा क्रैश होने की समस्या ढूंढना" उदाहरण में दी गई क्वेरी का इस्तेमाल कर पाई. अब आपकी टीम को ऐप्लिकेशन के उन उपयोगकर्ताओं की सूची निकालने के लिए क्वेरी चलानी है जिन पर इस क्रैश का असर पड़ा है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID
के बजाय, उसके बंडल आईडी और IOS
का इस्तेमाल करें.
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;
सातवां उदाहरण: ऐप्लिकेशन बंद होने की समस्या का असर जिन उपयोगकर्ताओं पर पड़ा उनकी संख्या, देश के हिसाब से बांटी गई
नई रिलीज़ को रोल आउट करने के दौरान, आपकी टीम को एक गंभीर गड़बड़ी का पता चला है. क्रैश की समस्या से जुड़े आईडी की पहचान करने के लिए, आपने ऊपर दिए गए "सबसे ज़्यादा क्रैश होने की समस्या ढूंढें" उदाहरण में दी गई क्वेरी का इस्तेमाल किया. आपकी टीम अब यह देखना चाहेगी कि क्या यह क्रैश, दुनिया भर के अलग-अलग देशों में मौजूद उपयोगकर्ताओं को भी हुआ है.
यह क्वेरी लिखने के लिए, आपकी टीम को ये काम करने होंगे:
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 ऐप्लिकेशन के लिए, पैकेज के नाम और
ANDROID
के बजाय, उसके बंडल आईडी औरIOS
का इस्तेमाल करें.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
आठवां उदाहरण: आज तक की पांच सबसे बड़ी समस्याएं
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID
के बजाय, उसके बंडल आईडी और IOS
का इस्तेमाल करें.
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
का इस्तेमाल किया जा सकता है.
यहां Android ऐप्लिकेशन के लिए क्वेरी का उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, पैकेज के नाम और ANDROID
के बजाय, उसके बंडल आईडी और IOS
का इस्तेमाल करें.
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 हाल ही के इवेंट (क्रैश, गड़बड़ियां, और ANR) एक्सपोर्ट करता है. इनमें लिंक करने से दो दिन पहले तक के इवेंट भी शामिल होते हैं. साथ ही, 30 दिनों तक के डेटा को बैकफ़िल करने का विकल्प भी मिलता है.
इसके बाद, जब तक एक्सपोर्ट की सुविधा बंद नहीं की जाती, तब तक Firebase हर दिन Crashlytics इवेंट एक्सपोर्ट करता है. हर एक्सपोर्ट के बाद, BigQuery में डेटा उपलब्ध होने में कुछ मिनट लग सकते हैं.
डेटासेट
Crashlytics, Crashlytics के डेटा के लिए BigQuery में एक नया डेटासेट बनाता है. डेटासेट में आपके पूरे प्रोजेक्ट का डेटा शामिल होता है. भले ही, उसमें एक से ज़्यादा ऐप्लिकेशन हों.
टेबल
Crashlytics आपके प्रोजेक्ट में हर ऐप्लिकेशन के लिए डेटासेट में एक टेबल बनाता है. ऐसा तब तक होता है, जब तक कि आपने उस ऐप्लिकेशन के लिए डेटा एक्सपोर्ट करने की सुविधा से ऑप्ट आउट न किया हो. Firebase, ऐप्लिकेशन के आइडेंटिफ़ायर के आधार पर टेबल को नाम देता है. इसमें पीरियड को अंडरस्कोर में बदला जाता है और आखिर में प्लैटफ़ॉर्म का नाम जोड़ा जाता है.
उदाहरण के लिए, पैकेज का नाम com.google.test
वाला Android ऐप्लिकेशन का डेटा, com_google_test_ANDROID
नाम की टेबल में होगा. साथ ही, रीयलटाइम डेटा (अगर चालू है) com_google_test_ANDROID_REALTIME
नाम की टेबल में होगा
टेबल में Crashlytics डेटा का स्टैंडर्ड सेट होता है. साथ ही, इसमें आपके ऐप्लिकेशन में तय की गई कस्टम Crashlytics कुंजियां भी शामिल होती हैं.
लाइन
टेबल की हर पंक्ति, ऐप्लिकेशन को मिली एक गड़बड़ी के बारे में बताती है.
कॉलम
टेबल में मौजूद कॉलम, ऐप्लिकेशन के बंद होने, गड़बड़ियों, और ANR के लिए एक जैसे होते हैं. अगर Crashlytics से BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू है, तो रीयल टाइम टेबल में वही कॉलम होंगे जो बैच टेबल में हैं. ध्यान दें कि हो सकता है कि आपकी लाइनों में ऐसे कॉलम हों जो ऐसे इवेंट दिखाते हों जिनमें स्टैक ट्रेस न हों.
एक्सपोर्ट में शामिल कॉलम इस टेबल में दिए गए हैं:
फ़ील्ड का नाम | डेटा टाइप | ब्यौरा |
---|---|---|
platform |
स्ट्रिंग | Firebase प्रोजेक्ट में रजिस्टर किया गया ऐप्लिकेशन का प्लैटफ़ॉर्म
(मान्य वैल्यू: IOS या ANDROID )
|
bundle_identifier |
स्ट्रिंग | Firebase प्रोजेक्ट में रजिस्टर किए गए ऐप्लिकेशन का यूनीक आइडेंटिफ़ायर (उदाहरण के लिए, com.google.gmail Apple प्लैटफ़ॉर्म के ऐप्लिकेशन के लिए, यह ऐप्लिकेशन का बंडल आईडी होता है. Android ऐप्लिकेशन के लिए, यह ऐप्लिकेशन का पैकेज नाम होता है. |
event_id |
स्ट्रिंग | इवेंट का यूनीक आईडी |
is_fatal |
बूलियन | ऐप्लिकेशन क्रैश हुआ है या नहीं |
error_type |
स्ट्रिंग | इवेंट में हुई गड़बड़ी का टाइप (उदाहरण के लिए, FATAL ,
NON_FATAL , ANR वगैरह) |
issue_id |
स्ट्रिंग | इवेंट से जुड़ी समस्या |
variant_id |
स्ट्रिंग | इस इवेंट से जुड़ा समस्या वैरिएंट ध्यान दें कि सभी इवेंट में समस्या वैरिएंट नहीं होता. |
event_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 |
स्ट्रिंग | इवेंट जनरेट करने वाला SDK टूल का Crashlytics वर्शन |
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 |
टाइमस्टैंप | ब्रेडक्रंब से जुड़ा टाइमस्टैंप |
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 |
बूलियन | आखिरी बार ट्रिगर हुए अपवाद (यानी पहला रिकॉर्ड) को छोड़कर सभी के लिए True |
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 के लिए एक सैंपल रिपोर्ट होती है. इसमें, एक्सपोर्ट किए गए CrashlyticsBigQuery स्कीमा के डाइमेंशन और मेट्रिक का पूरा सेट शामिल होता है. अगर आपने Crashlytics BigQuery पर स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू की है, तो उस डेटा को Data Studio टेंप्लेट के रीयल टाइम रुझान पेज पर देखा जा सकता है. अपने ऐप्लिकेशन के क्रैश के रॉ डेटा के आधार पर, नई रिपोर्ट और विज़ुअलाइज़ेशन तुरंत बनाने के लिए, सैंपल को टेंप्लेट के तौर पर इस्तेमाल किया जा सकता है:
सबसे ऊपर दाएं कोने में मौजूद, टेंप्लेट का इस्तेमाल करें पर क्लिक करें.
नया डेटा सोर्स ड्रॉप-डाउन में, नया डेटा सोर्स बनाएं को चुनें.
BigQuery कार्ड पर, चुनें पर क्लिक करें.
एक्सपोर्ट किया गया Crashlytics डेटा दिखाने वाली टेबल चुनने के लिए, मेरे प्रोजेक्ट > PROJECT_ID > firebase_crashlytics > TABLE_NAME चुनें.
आपकी बैच टेबल हमेशा चुनने के लिए उपलब्ध होती है. अगर CrashlyticsBigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू है, तो रीयल टाइम टेबल चुनी जा सकती है.
कॉन्फ़िगरेशन में जाकर, Crashlytics टेंप्लेट लेवल को डिफ़ॉल्ट पर सेट करें.
नया डेटा सोर्स बनाने के लिए, कनेक्ट करें पर क्लिक करें.
Crashlytics टेंप्लेट पर वापस जाने के लिए, रिपोर्ट में जोड़ें पर क्लिक करें.
आखिर में, Crashlytics Data Studio डैशबोर्ड टेंप्लेट की कॉपी बनाने के लिए, रिपोर्ट बनाएं पर क्लिक करें.
एक्सपोर्ट के नए इंफ़्रास्ट्रक्चर पर अपग्रेड करना
अक्टूबर 2024 के मध्य में, Crashlytics ने Crashlytics डेटा को BigQuery में एक्सपोर्ट करने के लिए, एक नया इन्फ़्रास्ट्रक्चर लॉन्च किया. फ़िलहाल, इस नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करना ज़रूरी नहीं है.
यह नया इन्फ़्रास्ट्रक्चर, अमेरिका से बाहर Crashlytics डेटासेट की जगहों के साथ काम करता है.
अगर आपने अक्टूबर 2024 के मध्य से पहले डेटा एक्सपोर्ट करने की सुविधा चालू की थी, तो अब आपके पास BigQuery के साथ काम करने वाले किसी भी डेटासेट की जगह पर, डेटा एक्सपोर्ट करने की जगह बदलने का विकल्प है.
अगर आपने अक्टूबर 2024 के बीच या उसके बाद एक्सपोर्ट की सुविधा चालू की है, तो सेटअप के दौरान, BigQuery के साथ काम करने वाले किसी भी डेटासेट की जगह को चुनें.
नए इन्फ़्रास्ट्रक्चर में एक और अंतर यह है कि यह एक्सपोर्ट की सुविधा चालू करने से पहले के डेटा को बैकफ़िल नहीं करता. (पुराने इन्फ़्रास्ट्रक्चर की मदद से, चालू होने की तारीख से 30 दिन पहले तक बैकफ़िल किया जा सकता था.) नया इंफ़्रास्ट्रक्चर, पिछले 30 दिनों तक बैकफ़िल की सुविधा देता है या वह तारीख जब आपने BigQuery में एक्सपोर्ट करने की सुविधा चालू की थी (इनमें से जो भी सबसे हाल की तारीख हो).
अपग्रेड करने से जुड़ी ज़रूरी शर्तें
नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करने से पहले, पुष्टि करें कि आपने यहां दी गई ज़रूरी शर्तें पूरी की हैं: आपकी मौजूदा बैच BigQuery टेबल में, रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए बंडल आईडी या पैकेज के नाम से मिलते-जुलते आइडेंटिफ़ायर हैं.
उदाहरण के लिए:
अगर आपके पास
com_yourcompany_yourproject_IOS
नाम की BigQuery टेबल है, तो आपके Firebase प्रोजेक्ट में बंडल आईडीcom.yourcompany.yourproject
के साथ Firebase iOS+ ऐप्लिकेशन रजिस्टर होना चाहिए.अगर आपके पास
com_yourcompany_yourproject_ANDROID
नाम की BigQuery टेबल है, तो आपके Firebase प्रोजेक्ट में पैकेज के नामcom.yourcompany.yourproject
के साथ Firebase Android ऐप्लिकेशन रजिस्टर होना चाहिए.
अपने Firebase प्रोजेक्ट में रजिस्टर किए गए सभी Firebase ऐप्लिकेशन ढूंढने का तरीका यहां बताया गया है:
Firebase कंसोल में, अपने प्रोजेक्ट सेटिंग पर जाएं.
नीचे की ओर स्क्रोल करके, आपके ऐप्लिकेशन कार्ड पर जाएं. इसके बाद, जिस Firebase ऐप्लिकेशन की जानकारी देखनी है उस पर क्लिक करें. इसमें, ऐप्लिकेशन का आइडेंटिफ़ायर भी शामिल है.
एक्सपोर्ट के नए इन्फ़्रास्ट्रक्चर में, रजिस्टर किए गए Firebase ऐप्लिकेशन के लिए सेट किए गए पैकेज के नाम या बंडल आईडी के आधार पर, हर ऐप्लिकेशन का डेटा एक्सपोर्ट किया जाएगा. BigQuery वर्कफ़्लो में रुकावट न आए, इसके लिए यह पक्का करना ज़रूरी है कि आपकी मौजूदा बैच टेबल में पहले से ही सही नाम मौजूद हों. इससे, नया इन्फ़्रास्ट्रक्चर मौजूदा टेबल में सारा नया डेटा जोड़ पाएगा. अगर आपकी बैच टेबल के नाम, रजिस्टर किए गए Firebase ऐप्लिकेशन से मेल नहीं खाते, लेकिन आपको फिर भी अपग्रेड करना है, तो Firebase सहायता टीम से संपर्क करें.
नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करने का तरीका
अगर आपने डेटा एक्सपोर्ट की सुविधा पहले ही चालू कर दी है, तो नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करने के लिए, Crashlytics डेटा एक्सपोर्ट को टॉगल करके बंद करें और फिर Firebase कंसोल में जाकर, उसे फिर से चालू करें.
यहां इस बारे में ज़्यादा जानकारी दी गई है:
Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.
BigQuery कार्ड में, मैनेज करें पर क्लिक करें.
एक्सपोर्ट की सुविधा बंद करने के लिए, Crashlytics स्लाइडर को टॉगल करें. जब आपसे कहा जाए, तब पुष्टि करें कि आपको डेटा एक्सपोर्ट की प्रोसेस बंद करनी है.
एक्सपोर्ट की सुविधा को फिर से चालू करने के लिए, Crashlytics स्लाइडर को तुरंत फिर से चालू करें. जब आपसे कहा जाए, तब पुष्टि करें कि आपको डेटा एक्सपोर्ट करना है.
Crashlytics से BigQuery में एक्सपोर्ट किया गया आपका डेटा, अब नए एक्सपोर्ट इन्फ़्रास्ट्रक्चर का इस्तेमाल कर रहा है.