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

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

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

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

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

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

• Looker Studio टेंप्लेट का इस्तेमाल करना
  Crashlytics एक्सपोर्ट किए गए डेटा को विज़ुअलाइज़ करने के लिए, पहले से बना Looker Studio टेंप्लेट उपलब्ध कराता है.

• व्यू बनाना
  BigQuery यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, व्यू बनाया जा सकता है. यह एक वर्चुअल टेबल होती है, जिसे SQL क्वेरी के आधार पर तय किया जाता है. अलग-अलग तरह के व्यू और उन्हें बनाने के तरीके के बारे में ज़्यादा जानने के लिए, BigQuery का दस्तावेज़ देखें.

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

BigQuery में स्ट्रीमिंग एक्सपोर्ट करने के फ़ायदे

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

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

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

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

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

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

1. Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.

2. BigQuery कार्ड में जाकर, लिंक करें पर क्लिक करें.

3. BigQuery में एक्सपोर्ट करने की सुविधा चालू करने के लिए, स्क्रीन पर दिए गए निर्देशों का पालन करें. इसमें ये विकल्प शामिल हैं:

   • ऐसे उपयोगकर्ताओं और सेशन के बारे में ज़्यादा जानने के लिए जिनमें ऐप्लिकेशन बंद नहीं हुआ, Firebase सेशन के डेटा को एक्सपोर्ट करने की सुविधा चालू करें.

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

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

• Firebase, BigQuery से लिंक किए गए ऐप्लिकेशन से डेटा एक्सपोर्ट करता है.

  • सेटअप के दौरान, आपके प्रोजेक्ट में मौजूद सभी ऐप्लिकेशन डिफ़ॉल्ट रूप से BigQuery से लिंक होते हैं. हालांकि, सेटअप के दौरान कुछ ऐप्लिकेशन को लिंक न करने का विकल्प चुना जा सकता है.

  • बाद में Firebase प्रोजेक्ट में जोड़े जाने वाले सभी ऐप्लिकेशन, BigQuery से अपने-आप लिंक हो जाते हैं.

  • आपके पास कभी भी, यह मैनेज करने का विकल्प होता है कि कौनसे ऐप्लिकेशन डेटा एक्सपोर्ट करेंगे.

• Firebase, डेटा को उस डेटासेट लोकेशन पर एक्सपोर्ट करता है जिसे आपने सेटअप के दौरान चुना था.

  • यह जगह, Crashlytics डेटासेट और Firebase सेशन डेटासेट, दोनों पर लागू होती है. हालांकि, ऐसा तब होता है, जब सेशन के डेटा को एक्सपोर्ट करने की सुविधा चालू हो.

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

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

• Firebase, आपके बैच डेटा को हर दिन BigQuery के साथ सिंक करता है.

  • BigQuery से लिंक करने के बाद, शुरुआती बैच का डेटा एक्सपोर्ट होने में 48 घंटे लग सकते हैं.

  • रोज़ाना सिंक होने की प्रोसेस, दिन में एक बार होती है. भले ही, आपने BigQuery में कोई शेड्यूल एक्सपोर्ट सेट अप किया हो. ध्यान दें कि सिंक करने की प्रोसेस का समय और अवधि बदल सकती है. इसलिए, हमारा सुझाव है कि एक्सपोर्ट के किसी खास समय के आधार पर, डाउनस्ट्रीम ऑपरेशन या जॉब शेड्यूल न करें.

• Firebase, BigQuery में आपके मौजूदा डेटा की कॉपी एक्सपोर्ट करता है.

  • लिंक किए गए हर ऐप्लिकेशन के लिए, इस एक्सपोर्ट में एक बैच टेबल शामिल होती है. इसमें हर दिन सिंक किए गए डेटा की जानकारी होती है.

  • पिछले 30 दिनों तक के लिए डेटा बैकफ़िल को मैन्युअल तरीके से शेड्यूल किया जा सकता है. इसके अलावा, BigQuery में एक्सपोर्ट करने की सुविधा चालू करने की सबसे हाल की तारीख के लिए भी डेटा बैकफ़िल को मैन्युअल तरीके से शेड्यूल किया जा सकता है. या इन दोनों में से जो भी तारीख सबसे हाल की हो उसके लिए डेटा बैकफ़िल को मैन्युअल तरीके से शेड्यूल किया जा सकता है.

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

• अगर आपने BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू की है, तो यह जानकारी आपके लिए है.

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

  • स्ट्रीमिंग की सुविधा चालू करने के बाद, डेटा स्ट्रीम होने में एक घंटा लग सकता है.

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

  1. पक्का करें कि आपने अपने ऐप्लिकेशन से कम से कम दो इवेंट Crashlytics को भेजे हों. साथ ही, उन्हें भेजने के बाद कुछ मिनट इंतज़ार किया हो.

  2. पक्का करें कि आपका Firebase प्रोजेक्ट, इस्तेमाल के हिसाब से शुल्क चुकाने वाले ब्लेज़ प्लान पर हो.
     इसके लिए, Firebase कंसोल के सबसे नीचे बाएं कोने में देखें.

  3. अगर दो इवेंट भेजने और कुछ मिनट इंतज़ार करने के बाद भी, रीयलटाइम टेबल में कोई डेटा नहीं दिखता है, तो:

     1. Firebase कंसोल में, BigQuery कार्ड पर जाएं.

     2. स्ट्रीमिंग एक्सपोर्ट करने की सुविधा को बंद करें और फिर से चालू करें.

     3. पक्का करें कि सेवा खाता service-PROJECT_NUMBER@gcp-sa-crashlytics.iam.gserviceaccount.com आपके Firebase प्रोजेक्ट में हो और उसके पास Firebase Crashlytics सेवा एजेंट की भूमिका हो.
        इसकी जांच, Google Cloud console के IAM पेज पर की जा सकती है. Google की ओर से असाइन किए गए रोल शामिल करें चेकबॉक्स को चुनना न भूलें.

     4. Crashlytics में कम से कम दो इवेंट भेजें और कुछ मिनट इंतज़ार करें.

  4. अगर आपको अब भी रीयलटाइम टेबल में डेटा नहीं दिखता है, तो Firebase की सहायता टीम से संपर्क करें.

क्वेरी के उदाहरण

पहला उदाहरण: Firebase सेशन के डेटा का इस्तेमाल करके, क्रैश-फ़्री मेट्रिक का हिसाब लगाना

आपने अपने ऐप्लिकेशन के नए वर्शन में, ऐप्लिकेशन को पूरी तरह से नया रूप दिया है. ऐसा इसलिए किया गया है, ताकि उपयोगकर्ता की अहम गतिविधि के दौरान ऐप्लिकेशन क्रैश होने की समस्या को ठीक किया जा सके. आपको उपयोगकर्ताओं से बेहतरीन समीक्षाएं मिली हैं, लेकिन आपको यह साबित करने के लिए आंकड़ों की ज़रूरत है कि आपका ऐप्लिकेशन पहले से ज़्यादा स्थिर है.

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

यहां Android ऐप्लिकेशन के लिए क्वेरी के उदाहरण दिए गए हैं. iOS ऐप्लिकेशन के लिए, उसके बंडल आईडी और IOS का इस्तेमाल करें (पैकेज के नाम और ANDROID के बजाय).

किसी वर्शन के लिए, ऐसे उपयोगकर्ता जिनके डिवाइस में ऐप्लिकेशन क्रैश नहीं हुआ:

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT installation_uuid) / COUNT (DISTINCT instance_id))) AS CFU
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL"
  AND crashlytics.application.display_version="APP_VERSION"
  AND sessions.application.display_version = "APP_VERSION"
GROUP BY
  event_date
ORDER BY
  event_date

पिछले हफ़्ते (पिछले 168 घंटों में) सेशन के दौरान ऐप्लिकेशन क्रैश नहीं हुआ:

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT crashlytics.event_id) / COUNT (DISTINCT sessions.session_id))) AS CFS
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL" AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND _PARTITIONTIME < CURRENT_TIMESTAMP()
GROUP BY
  event_date
ORDER BY
  event_date

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

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

यहां 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 क्रैश की जानकारी चाहिए. आपने एक ऐसी क्वेरी बनाई है जो डेटा के ज़रूरी पॉइंट उपलब्ध कराती है.

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

चौथा उदाहरण: सबसे ज़्यादा क्रैश होने वाले 10 डिवाइस

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

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

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

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

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

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

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

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

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

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

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

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

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

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

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

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

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

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

2. अपने ऐप्लिकेशन को अपडेट करें, ताकि 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");
   

3. ऐसी क्वेरी लिखें जो यूज़र आईडी फ़ील्ड का इस्तेमाल करके, 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

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

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

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

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

यहां Android ऐप्लिकेशन के लिए क्वेरी का एक उदाहरण दिया गया है. iOS ऐप्लिकेशन के लिए, उसके बंडल आईडी और IOS का इस्तेमाल करें (पैकेज के नाम और ANDROID के बजाय).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

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

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

Looker Studio का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, उनकी वेलकम गाइड देखें.

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

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

1. Crashlytics Looker Studio डैशबोर्ड टेंप्लेट खोलें.

2. सबसे ऊपर दाएं कोने में मौजूद, टेंप्लेट का इस्तेमाल करें पर क्लिक करें.

3. नया डेटा सोर्स ड्रॉप-डाउन में जाकर, नया डेटा सोर्स बनाएं को चुनें.

4. BigQuery कार्ड पर, चुनें पर क्लिक करें.

5. एक्सपोर्ट किए गए Crashlytics डेटा वाली टेबल चुनें. इसके लिए, मेरे प्रोजेक्ट > PROJECT_ID > firebase_crashlytics > TABLE_NAME चुनें.

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

6. कॉन्फ़िगरेशन में जाकर, Crashlytics टेंप्लेट लेवल को डिफ़ॉल्ट पर सेट करें.

7. नया डेटा सोर्स बनाने के लिए, कनेक्ट करें पर क्लिक करें.

8. Crashlytics टेंप्लेट पर वापस जाने के लिए, रिपोर्ट में जोड़ें पर क्लिक करें.

9. आखिर में, Crashlytics Looker Studio डैशबोर्ड टेंप्लेट की कॉपी बनाने के लिए, रिपोर्ट बनाएं पर क्लिक करें.

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

Firebase, एक्सपोर्ट किए गए डेटा के लिए BigQuery में नए डेटासेट बनाता है:

• Crashlytics डेटासेट

• Firebase सेशन डेटासेट (अगर सेशन के डेटा को एक्सपोर्ट करने की सुविधा चालू है)

Crashlytics डेटासेट

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

टेबल

डिफ़ॉल्ट रूप से, Firebase आपके प्रोजेक्ट में मौजूद हर उस ऐप्लिकेशन के लिए Crashlyticsडेटासेट में अलग-अलग टेबल बनाता है जो BigQuery से लिंक है.

टेबल के नाम, ऐप्लिकेशन के आइडेंटिफ़ायर के आधार पर रखे जाते हैं. इनमें मौजूद अवधि को अंडरस्कोर में बदल दिया जाता है. साथ ही, ऐप्लिकेशन के प्लैटफ़ॉर्म (_IOS या _ANDROID) को जोड़ दिया जाता है. उदाहरण के लिए, com.google.test पैकेज के नाम वाले Android ऐप्लिकेशन का डेटा, com_google_test_ANDROID नाम की टेबल में होगा.

• अगर BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू है, तो डेटा को रीयल टाइम में _REALTIME से जुड़ी टेबल (उदाहरण के लिए, com_google_test_ANDROID_REALTIME) में भी स्ट्रीम किया जाएगा.

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

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

लाइन

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

कॉलम

किसी टेबल में मौजूद कॉलम, क्रैश, नॉन-फ़ैटल गड़बड़ियों, और एएनआर के लिए एक जैसे होते हैं.

• अगर BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू है, तो रीयलटाइम टेबल में वही कॉलम होंगे जो बैच टेबल में हैं.

• ऐसा हो सकता है कि आपकी लाइनों में ऐसे इवेंट दिखाने वाले कॉलम हों जिनके स्टैक ट्रेस मौजूद नहीं हैं.

एक्सपोर्ट किए गए Crashlytics डेटा की टेबल में मौजूद कॉलम यहां दिए गए हैं:

Firebase सेशन का डेटासेट

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

टेबल

डिफ़ॉल्ट रूप से, Firebase आपके प्रोजेक्ट में मौजूद हर उस ऐप्लिकेशन के लिए Firebase sessions डेटासेट में अलग-अलग टेबल बनाता है जो BigQuery से लिंक है.

टेबल के नाम, ऐप्लिकेशन के आइडेंटिफ़ायर के आधार पर रखे जाते हैं. इसमें अवधि को अंडरस्कोर में बदल दिया जाता है. साथ ही, ऐप्लिकेशन के प्लैटफ़ॉर्म (_IOS या _ANDROID) को जोड़ दिया जाता है. उदाहरण के लिए, com.google.test पैकेज के नाम वाले Android ऐप्लिकेशन का डेटा, com_google_test_ANDROID नाम की टेबल में होगा.

लाइन

टेबल की हर लाइन, किसी सेशन में हुए इवेंट के बारे में बताती है.

कॉलम

अगर BigQuery में स्ट्रीमिंग एक्सपोर्ट की सुविधा चालू है, तो रीयलटाइम टेबल में वही कॉलम होंगे जो बैच टेबल में हैं.

एक्सपोर्ट किए गए Firebase सेशन के डेटा की टेबल में ये कॉलम शामिल होते हैं:

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

अक्टूबर 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 ऐप्लिकेशन के लिए सेट किए जाते हैं.

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

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

   • आपको अपने Firebase प्रोजेक्ट में रजिस्टर किए गए सभी Firebase ऐप्लिकेशन, Firebase कंसोल में दिखेंगे: अपने Firebase प्रोजेक्ट सेटिंग पर जाएं. इसके बाद, आपके ऐप्लिकेशन कार्ड पर स्क्रोल करके, अपने सभी Firebase ऐप्लिकेशन और उनकी जानकारी देखें.settings

   • आपको अपनी सभी BigQuery बैच टेबल, Google Cloud कंसोल के BigQuery पेज पर मिल सकती हैं.

   REALTIME

   उदाहरण के लिए, यहां कुछ ऐसी स्थितियां दी गई हैं जिनमें अपग्रेड करने पर आपको कोई समस्या नहीं आएगी:

   • आपके पास com_yourcompany_yourproject_IOS नाम की बैच टेबल है. साथ ही, आपके Firebase प्रोजेक्ट में com.yourcompany.yourproject बंडल आईडी वाला Firebase iOS+ ऐप्लिकेशन रजिस्टर है.

   • आपके पास com_yourcompany_yourproject_ANDROID नाम की बैच टेबल है. साथ ही, आपके Firebase प्रोजेक्ट में com.yourcompany.yourproject पैकेज नाम वाला Firebase Android ऐप्लिकेशन रजिस्टर है.

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

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

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

यहां इस बारे में ज़्यादा जानकारी दी गई है:

1. Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.

2. BigQuery कार्ड में, मैनेज करें पर क्लिक करें.

3. एक्सपोर्ट की सुविधा बंद करने के लिए, Crashlytics स्लाइडर को टॉगल करके बंद करें. जब कहा जाए, तब पुष्टि करें कि आपको डेटा एक्सपोर्ट करने की सुविधा बंद करनी है.

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

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

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