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(sessions.event_timestamp,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.firebase_session_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(sessions.event_timestamp,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 की (iOS+ | Android | Flutter | Unity ) नाम की कस्टम 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 डेटा को BigQuery डेटासेट में एक्सपोर्ट किया जाता है. इस डेटासेट का नाम firebase_crashlytics होता है. डेटासेट में आपके पूरे प्रोजेक्ट का डेटा शामिल होता है. भले ही, उसमें एक से ज़्यादा ऐप्लिकेशन हों.

टेबल

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

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

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

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

• इन टेबल में, Crashlytics का स्टैंडर्ड सेट होता है. साथ ही, इसमें आपके ऐप्लिकेशन में तय की गई कस्टम Crashlytics कुंजियां भी होती हैं (iOS+ | Android | Flutter | Unity).

लाइन

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

कॉलम

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

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

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

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

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

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

टेबल

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

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

लाइन

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

कॉलम

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

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

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

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

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

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