ऑफ़लाइन इस्तेमाल को मापा जा रहा है

अपनी साइट के ऑफ़लाइन इस्तेमाल को कैसे ट्रैक करें, ताकि आपको पता चल सके कि आपकी साइट को बेहतर ऑफ़लाइन अनुभव की ज़रूरत क्यों है.

स्टेफ़न गिसॉ

मार्टिन शिर्ले

इस लेख में, अपनी साइट के ऑफ़लाइन इस्तेमाल को ट्रैक करने का तरीका बताया गया है. इससे आपको यह पता लगाने में मदद मिलेगी कि आपकी साइट के लिए, बेहतर ऑफ़लाइन मोड की ज़रूरत क्यों है. इसमें ऑफ़लाइन इस्तेमाल के आंकड़े लागू करते समय होने वाली परेशानियों और समस्याओं के बारे में बताया गया है.

ऑनलाइन और ऑफ़लाइन ब्राउज़र इवेंट से होने वाली गलतियां

ऑफ़लाइन इस्तेमाल को ट्रैक करने का सबसे अच्छा तरीका यह है कि आप online और offline इवेंट के लिए इवेंट लिसनर बनाएं (जो कई ब्राउज़र पर काम करते हैं) और उन लिसनर में Analytics ट्रैकिंग लॉजिक को शामिल करें. दुर्भाग्य से, इस तरीके में कई समस्याएं और सीमाएं हैं:

• आम तौर पर, नेटवर्क कनेक्शन की स्थिति से जुड़े हर इवेंट की ट्रैकिंग ज़रूरत से ज़्यादा हो सकती है. साथ ही, यह निजता का पूरा ध्यान रखने वाली दुनिया में काम करता है, जहां कम से कम डेटा इकट्ठा किया जाना चाहिए. इसके अलावा, online और offline इवेंट, नेटवर्क बंद होने के कुछ सेकंड के लिए चालू हो सकते हैं, जिसे शायद उपयोगकर्ता को न दिखे या न ही उसका पता चले.
• ऑफ़लाइन गतिविधि की Analytics ट्रैकिंग कभी भी Analytics सर्वर तक नहीं पहुंचेगी, क्योंकि उपयोगकर्ता ऑफ़लाइन है.
• उपयोगकर्ता के ऑफ़लाइन होने पर, स्थानीय तौर पर टाइमस्टैंप ट्रैक करना और उसके ऑनलाइन होने पर, Analytics सर्वर पर ऑफ़लाइन गतिविधि भेजना, इस बात पर निर्भर करता है कि उपयोगकर्ता आपकी साइट पर फिर से आता है या नहीं. अगर उपयोगकर्ता किसी ऑफ़लाइन मोड में न होने की वजह से, आपकी साइट छोड़कर चला जाता है और कभी भी वापस नहीं आता, तो आपके पास उसे ट्रैक करने का कोई तरीका नहीं है. ऑफ़लाइन ड्रॉप-ऑफ़ को ट्रैक करने की क्षमता काफ़ी अहम डेटा है. इससे पता चलता है कि आपकी साइट के लिए बेहतर ऑफ़लाइन मोड की ज़रूरत क्यों है.
• online इवेंट बहुत भरोसेमंद नहीं है, क्योंकि इसे सिर्फ़ नेटवर्क के ऐक्सेस के बारे में पता है, इंटरनेट के ऐक्सेस के बारे में नहीं. इसलिए हो सकता है कि कोई उपयोगकर्ता अब भी ऑफ़लाइन हो और ट्रैकिंग पिंग नहीं भेज पा रहा हो.
• भले ही उपयोगकर्ता ऑफ़लाइन रहते हुए भी मौजूदा पेज पर बना रहता है, लेकिन Analytics के दूसरे किसी भी इवेंट (जैसे कि स्क्रोल इवेंट, क्लिक वगैरह) को ट्रैक नहीं किया जाता है. इस तरह की जानकारी ज़्यादा काम की और काम की हो सकती है.
• खुद में ऑफ़लाइन होना भी सामान्य तौर पर बहुत ज़्यादा सार्थक नहीं है. एक वेबसाइट डेवलपर के तौर पर, यह जानना ज़्यादा अहम हो सकता है कि किस तरह के संसाधन लोड नहीं हो सके. यह खास तौर पर एसपीए के मामले में होता है, जहां नेटवर्क कनेक्शन के बंद होने की वजह से, हो सकता है कि ब्राउज़र के ऑफ़लाइन गड़बड़ी वाले पेज (जिसे उपयोगकर्ता समझ पाएं) पर न ले जाए. हालांकि, इस बात की संभावना ज़्यादा होती है कि पेज के अचानक से काम न करने वाले डाइनैमिक पार्ट अचानक काम न करें.

ऑफ़लाइन इस्तेमाल के बारे में बुनियादी जानकारी पाने के लिए, अब भी इस तरीके का इस्तेमाल किया जा सकता है. हालांकि, इसकी कई कमियों और सीमाओं पर ध्यान देने की ज़रूरत है.

बेहतर तरीका: सर्विस वर्कर

ऑफ़लाइन मोड को चालू करने वाला समाधान, ऑफ़लाइन इस्तेमाल को ट्रैक करने का बेहतर समाधान होता है. बुनियादी आइडिया यह है कि जब तक उपयोगकर्ता ऑफ़लाइन हो, तब तक आंकड़ों के पिंग IndexedDB में स्टोर करें. इसके अलावा, जब उपयोगकर्ता फिर से ऑनलाइन हो जाए, तब उन्हें फिर से भेजें. Google Analytics के लिए यह पहले से ही वर्कबॉक्स मॉड्यूल के ज़रिए उपलब्ध है, लेकिन ध्यान रखें कि जिन हिट से जुड़े इवेंट चार घंटे से ज़्यादा समय तक भेजे जाते हैं उन्हें प्रोसेस नहीं किया जा सकता. अपने सबसे आसान रूप में, इसे Workbox पर आधारित सर्विस वर्कर में इन दो लाइनों की मदद से चालू किया जा सकता है:

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize();

यह ऑफ़लाइन रहते हुए सभी मौजूदा इवेंट और पेज व्यू पिंग को ट्रैक करता है, लेकिन आपको यह पता नहीं चलेगा कि वे ऑफ़लाइन हुए हैं (क्योंकि उन्हें ठीक वैसे ही फिर से चलाया जाता है). इसके लिए Workbox की मदद से ट्रैकिंग अनुरोधों में हेर-फेर की जा सकती है. इसके लिए, Analytics पिंग में offline फ़्लैग जोड़ें और कस्टम डाइमेंशन (नीचे दिए गए कोड में cd1) का इस्तेमाल करें:

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize({
  parameterOverrides: {
    cd1: 'offline',
  },
});

अगर इंटरनेट कनेक्शन के वापस आने से पहले ही, उपयोगकर्ता ऑफ़लाइन होने की वजह से पेज से हट जाता है, तो क्या होगा? हालांकि, आम तौर पर यह सर्विस वर्कर को सुला देती है (क्योंकि कनेक्शन वापस आने पर यह डेटा भेजने में असमर्थ होता है), Workbox Google Analytics मॉड्यूल में बैकग्राउंड सिंक एपीआई का इस्तेमाल होता है, जो बाद में कनेक्शन वापस आने पर Analytics डेटा भेजता है, भले ही उपयोगकर्ता टैब या ब्राउज़र बंद कर दे.

इसमें भी एक कमी है: हालांकि, यह मौजूदा ट्रैकिंग को ऑफ़लाइन-सुविधा के लिए योग्य बनाता है, लेकिन जब तक आप किसी बुनियादी ऑफ़लाइन मोड को लागू नहीं कर देते, तब तक आपको बहुत प्रासंगिक डेटा नहीं दिखाई देगा. कनेक्शन टूट जाने पर भी, उपयोगकर्ता आपकी साइट को तुरंत छोड़ देंगे. हालांकि, अब ऑफ़लाइन डाइमेंशन इस्तेमाल करने वाले उपयोगकर्ताओं और आम उपयोगकर्ताओं की संख्या की तुलना करके, सेशन की औसत अवधि और उपयोगकर्ता के जुड़ाव की तुलना की जा सकती है.

एसपीए और लेज़ी लोडिंग

अगर कई पेजों वाली वेबसाइट के तौर पर बनाए गए किसी पेज पर जाने वाले उपयोगकर्ता ऑफ़लाइन हो जाते हैं और नेविगेट करने की कोशिश करते हैं, तो ब्राउज़र का डिफ़ॉल्ट ऑफ़लाइन पेज दिखता है. इससे उपयोगकर्ताओं को यह समझने में मदद मिलती है कि क्या हो रहा है. हालांकि, एक पेज वाले ऐप्लिकेशन के तौर पर बनाए गए पेज अलग तरह से काम करते हैं. उपयोगकर्ता उसी पेज पर बना रहता है और नया कॉन्टेंट, बिना ब्राउज़र नेविगेशन के AJAX के ज़रिए डाइनैमिक तरीके से लोड होता है. ऑफ़लाइन होने पर, उपयोगकर्ताओं को ब्राउज़र की गड़बड़ी वाला पेज नहीं दिखता. इसके बजाय, पेज के डाइनैमिक हिस्से गड़बड़ियों के साथ रेंडर होते हैं, तय नहीं की गई स्थितियों में चले जाते हैं या फिर डाइनैमिक बने रहना बंद कर देते हैं.

लेज़ी लोडिंग की वजह से, कई पेज वाली वेबसाइटों पर इसी तरह के असर हो सकते हैं. उदाहरण के लिए, हो सकता है कि शुरुआत में लोड ऑनलाइन हुआ हो, लेकिन उपयोगकर्ता स्क्रोल करने से पहले ऑफ़लाइन हो गया हो. वेबसाइट में फ़ोल्ड के नीचे लेज़ी लोड किया गया कॉन्टेंट बिना किसी रुकावट के काम नहीं करेगा और उपलब्ध नहीं रहेगा.

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

import { setCatchHandler } from 'workbox-routing';

setCatchHandler(({ event }) => {
  // https://developer.mozilla.org/docs/Web/API/Client/postMessage
  event.waitUntil(async function () {
    // Exit early if we don't have access to the client.
    // Eg, if it's cross-origin.
    if (!event.clientId) return;

    // Get the client.
    const client = await clients.get(event.clientId);
    // Exit early if we don't get the client.
    // Eg, if it closed.
    if (!client) return;

    // Send a message to the client.
    client.postMessage({
      action: "network_fail",
      url: event.request.url,
      destination: event.request.destination
    });

    return Response.error();

  }());
});

सभी पूरे न हो पाने वाले अनुरोधों को सुनने के बजाय, दूसरा तरीका यह है कि सिर्फ़ खास रास्तों पर गड़बड़ियों को ठीक किया जाए. उदाहरण के लिए, अगर हम सिर्फ़ /products/* के रूट पर होने वाली गड़बड़ियों की रिपोर्ट करना चाहते हैं, तो हम setCatchHandler में एक जांच जोड़ सकते हैं जो यूआरआई को रेगुलर एक्सप्रेशन से फ़िल्टर करता है. इसकी मदद से, कस्टम हैंडलर की मदद से रजिस्टरRoute को लागू किया जा सकता है. यह कारोबारी लॉजिक को एक अलग रूट में इकट्ठा करता है, जिससे ज़्यादा जटिल सर्विस वर्कर के लिए बेहतर तरीके से रखरखाव किया जा सकता है:

import { registerRoute } from 'workbox-routing';
import { NetworkOnly } from 'workbox-strategies';

const networkOnly = new NetworkOnly();
registerRoute(
  new RegExp('https:\/\/example\.com\/products\/.+'),
  async (params) => {
    try {
      // Attempt a network request.
      return await networkOnly.handle(params);
    } catch (error) {
      // If it fails, report the error.
      const event = params.event;
      if (!event.clientId) return;
      const client = await clients.get(event.clientId);
      if (!client) return;

      client.postMessage({
        action: "network_fail",
        url: event.request.url,
        destination: "products"
      });

      return Response.error();
    }
  }
);

आखिरी चरण में, पेज को message इवेंट सुनना होगा और आंकड़ों की जानकारी देने वाली पिंग भेजनी होगी. फिर से, सर्विस वर्कर में ऑफ़लाइन होने वाले विश्लेषण अनुरोधों को बफ़र करना पक्का करें. जैसा कि पहले बताया गया है, Google Analytics में पहले से मौजूद सहायता के लिए, workbox-google-analytics प्लगिन शुरू करें.

नीचे दिए गए उदाहरण में Google Analytics का इस्तेमाल किया गया है. हालांकि, इसे दूसरे Analytics वेंडर के लिए भी इसी तरह लागू किया जा सकता है.

if ("serviceWorker" in navigator) {
  // ... SW registration here

  // track offline error events
  navigator.serviceWorker.addEventListener("message", event => {
    if (gtag && event.data && event.data.action === "network_fail") {
      gtag("event", "network_fail", {
        event_category: event.data.destination,
        // event_label: event.data.url,
        // value: event.data.value
      });
    }
  });
}

यह Google Analytics में पूरे न हो पाने वाले रिसॉर्स लोड को ट्रैक करेगा. यहां रिपोर्टिंग की मदद से उनका विश्लेषण किया जा सकता है. हासिल की गई अहम जानकारी का इस्तेमाल, सर्विस वर्कर को कैश मेमोरी में सेव करने और गड़बड़ी ठीक करने के तरीके को बेहतर बनाने के लिए किया जा सकता है. इससे नेटवर्क के खराब होने पर, पेज को ज़्यादा मज़बूत और भरोसेमंद बनाया जा सकता है.

अगले चरण

इस लेख में ऑफ़लाइन इस्तेमाल को ट्रैक करने के अलग-अलग तरीके बताए गए हैं. साथ ही, उनके फ़ायदों और कमियों के बारे में भी बताया गया है. इससे यह आकलन करने में मदद मिलती है कि आपके कितने उपयोगकर्ता ऑफ़लाइन हो जाते हैं और इसकी वजह से उन्हें समस्याओं का सामना करना पड़ता है. हालांकि, यह सिर्फ़ शुरुआत है. अगर आपकी वेबसाइट अच्छी तरह से तैयार ऑफ़लाइन मोड उपलब्ध नहीं कराती है, तो बेशक आपको आंकड़ों में ऑफ़लाइन इस्तेमाल का ज़्यादा फ़ायदा नहीं दिखेगा.

हमारा सुझाव है कि आप पूरी ट्रैकिंग इंस्टॉल करें. इसके बाद, ट्रैकिंग संख्याओं पर नज़र रखते हुए, अपनी ऑफ़लाइन क्षमताओं को बढ़ाएं. सबसे पहले एक ऑफ़लाइन गड़बड़ी वाले पेज से शुरुआत करें. इसमें Workbox को इस्तेमाल करना आसान है, तो इसे 404 कोड वाले कस्टम पेजों की तरह ही UX के हिसाब से सबसे सही तरीका माना जाना चाहिए. इसके बाद, ज़्यादा बेहतर ऑफ़लाइन फ़ॉलबैक की ओर और आखिर में, असल ऑफ़लाइन कॉन्टेंट की ओर कदम बढ़ाएं. पक्का करें कि आप इसके बारे में अपने उपयोगकर्ताओं को बता रहे हों और फिर इसका इस्तेमाल आपको बढ़ता हुआ दिखेगा. आखिरकार, हर कोई कभी-कभी ऑफ़लाइन हो जाता है.

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

Unsplash पर जेसी गेलिडन की हीरो फ़ोटो.