परफ़ॉर्मेंस को बेहतर बनाने के लिए, आपको क्या मेज़र करना चाहिए?

खरीदारी फ़नल के हर चरण में परफ़ॉर्मेंस का आकलन करने की रणनीतियां.

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

Twitter GitHub

खरीदारी फ़नल के अलग-अलग चरणों में परफ़ॉर्मेंस की समस्याएं अलग-अलग हो सकती हैं. इसलिए, इन्हें अलग-अलग मेज़रमेंट और ऑप्टिमाइज़ेशन की ज़रूरत होती है:

एक कन्वर्ज़न फ़नल.

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

लैब डेटा को स्थानीय तौर पर टेस्ट करके इकट्ठा किया जाता है. उदाहरण के लिए, Lighthouse और दूसरे टूल का इस्तेमाल करके. इसकी मदद से, समय के साथ वेबसाइट की परफ़ॉर्मेंस की तुलना, कंट्रोल और स्थिर तरीके से की जा सकती है. हालांकि, ऐसा हो सकता है कि इससे उपयोगकर्ताओं को असल ज़िंदगी में परफ़ॉर्मेंस का पता न चले.

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

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

डिस्कवरी कैंपेन

खोज के नतीजों को ऑप्टिमाइज़ करने का मतलब है, पहली बार लोड होने के लिए ऑप्टिमाइज़ करना. इससे नए उपयोगकर्ताओं को यह ऐक्सेस मिलेगा. हालांकि, Search और सोशल क्रॉलर का भी इस्तेमाल किया जा सकता है. पहली बार लोड होने वाले लैब के डेटा को Lighthouse से आसानी से हासिल किया जा सकता है, जबकि फ़ील्ड डेटा (कम से कम Chrome के लिए) Chrome UX रिपोर्ट से आसानी से उपलब्ध होता है. इन दोनों का आसानी से इस्तेमाल करने के लिए, PageSpeed Insights टैब पर जाएं. आपको फ़ील्ड से भी काम की मेट्रिक को खुद ट्रैक करना चाहिए: असल उपयोगकर्ताओं के डिवाइसों पर इन मेट्रिक को मेज़र करने से आपको अच्छी खास जानकारी मिलती है.

उपयोगकर्ता के नज़रिए से सबसे अहम मेट्रिक ये हैं:

• फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी): वह समय जब उपयोगकर्ता किसी खाली स्क्रीन को देखता है. ऐसा तब होता है, जब ज़्यादातर उपयोगकर्ता बाउंस करते हैं, क्योंकि उन्हें गेम की प्रोग्रेस नहीं दिखती.
• फ़र्स्ट मीनिंगफ़ुल पेंट (एफ़एमपी): जब उपयोगकर्ता वह मुख्य कॉन्टेंट देखना शुरू करता है जिसके लिए वह आया था. आम तौर पर, यह हीरो इमेज होती है. हालांकि, लैंडिंग पेज के लिए यह खरीदें बटन जैसा कॉल-टू-ऐक्शन भी हो सकता है. ऐसा इसलिए, क्योंकि हो सकता है कि उपयोगकर्ता किसी साफ़ मकसद से आपकी साइट पर आया हो. उदाहरण के लिए, टारगेट करके बनाए गए विज्ञापन कैंपेन से.
• फ़र्स्ट इनपुट डिले (एफ़आईडी): वह समय जो उपयोगकर्ता के पहले इनपुट पर वेबसाइट को प्रतिक्रिया देने के लिए ज़रूरी है. JavaScript और एसेट लोड होने से जुड़ी दूसरी समस्याओं की वजह से इसे ब्लॉक किया जा सकता है. इनमें टैप या क्लिक में गड़बड़ी हो सकती है, गलत इनपुट हो सकते हैं, और पेज छोड़ दिया जा सकता है.

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

सहभागिता और रूपांतरण

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

इस चरण में तेज़ और रिस्पॉन्सिव नेविगेशन और इंटरैक्शन होना ज़रूरी है. माफ़ करें, फ़ील्ड में नेविगेशन और इंटरैक्शन इवेंट के पूरे फ़्लो को मेज़र करना आसान नहीं है, क्योंकि हर उपयोगकर्ता पेज पर अलग-अलग पाथ का इस्तेमाल करता है. इसलिए, हमारा सुझाव है कि कन्वर्ज़न या कन्वर्ज़न के सब-लक्ष्यों ("टू-ऐक्शन") के लिए लगने वाले समय को मेज़र करें. इसके लिए, लैब टेस्ट में फ़्लो को स्क्रिप्ट और मेज़र करें, ताकि समय के साथ परफ़ॉर्मेंस की तुलना की जा सके.

ऐसा करने के दो आसान तरीके हैं:

WebPageTest

WebPageTest एक बेहद आसान स्क्रिप्टिंग समाधान देता है. बुनियादी आइडिया यह है:

• WebPage Test को, navigate कमांड की मदद से फ़्लो के पेजों पर जाने के लिए कहें.
• ज़रूरत पड़ने पर, clickAndWait निर्देशों से बटन को क्लिक करने की स्क्रिप्ट तैयार करें और setValue के ज़रिए टेक्स्ट वाले फ़ील्ड भरें. एक पेज के ऐप्लिकेशन की जांच के लिए, पहले चरण के बाद के सभी चरणों के लिए navigate निर्देशों के बजाय clickAndWait का इस्तेमाल करें. ऐसा इसलिए, क्योंकि navigate लाइटवेट वर्चुअल पेज लोड के बजाय, पूरा लोड करेगा.
• combineSteps की मदद से, विश्लेषण में फ़्लो के अलग-अलग चरणों को ज़रूर जोड़ें, ताकि पूरे फ़्लो के लिए एक ही कुल नतीजे की रिपोर्ट बनाई जा सके.

ऐसी स्क्रिप्ट कुछ इस तरह दिख सकती है:

combineSteps
navigate    https://www.store.google.com/landingpage
navigate    https://www.store.google.com/productpage
clickAndWait    innerText=Buy Now
navigate    https://www.store.google.com/basket
navigate    https://www.store.google.com/checkout

इस तरह की स्क्रिप्ट की मदद से, समय के साथ परफ़ॉर्मेंस को मेज़र और उनकी तुलना की जा सकती है. इसे WebPageTest API के ज़रिए भी अपने-आप किया जा सकता है.

कठपुतली का किरदार

स्क्रिप्ट टेस्टिंग का एक और बेहतरीन विकल्प, बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले Chrome का इस्तेमाल करना है. इसे Node API Puppeteer से कंट्रोल किया जा सकता है. आम तौर पर, ऐसा करने के लिए Puppeteer से ब्राउज़र शुरू करें, goto फ़ंक्शन के ज़रिए लैंडिंग पेज पर जाएं, फ़ील्ड भरने या क्लिक करने बटनों के लिए JavaScript इंजेक्ट करें और ज़रूरत पड़ने पर goto कॉल करके फ़नल में आगे बढ़ें.

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

const puppeteer = require('puppeteer');
(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  const start = performance.now();
  await page.goto('https://www.store.google.com/landingpage');
  await page.goto('https://www.store.google.com/productpage');
  // click the buy button, which triggers overlay basket
  await page.click('#buy_btn');
  // wait until basket overlay is shown
  await page.waitFor('#close_btn');
  await page.goto('https://www.store.google.com/basket');
  await page.goto('https://www.store.google.com/checkout');
  console.log('Flow took ' + parseInt((performance.now() - start)/1000) + ' seconds');
  await browser.close();
})();

यह स्क्रिप्ट आसानी से ऑटोमेटेड हो सकती है. यहां तक कि इसे बिल्ड प्रोसेस या परफ़ॉर्मेंस बजट का हिस्सा बनाया जा सकता है और इसकी नियमित रूप से निगरानी की जाती है.

फिर से जुड़ाव

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

Webpagetest में पहली बार लोड करने और फिर से लोड करने के विकल्प को भी टेस्ट करने के विकल्प मिलते हैं

फ़ील्ड में बार-बार होने वाली विज़िट की परफ़ॉर्मेंस को बेहतर तरीके से समझने के लिए, अपने पसंदीदा Analytics पैकेज का इस्तेमाल करके, उपयोगकर्ता टाइप के आधार पर अपनी परफ़ॉर्मेंस मेट्रिक को सेगमेंट करें. Google Analytics में मौजूद ऐसी रिपोर्ट का एक उदाहरण यहां दिया गया है:

Google Analytics की कस्टम रिपोर्ट का इस्तेमाल करके, नए और लौटने वाले उपयोगकर्ताओं के लिए स्पीड मेट्रिक रिपोर्ट की जा सकती है.

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

ज़रूरी बातों पर फिर से एक नज़र

इस गाइड में, फ़ील्ड और लैब टेस्ट की मदद से पहली बार लोड करने, फ़्लो करने, और बार-बार लोड होने को मेज़र करने का तरीका बताया गया है. फ़नल के अलग-अलग चरणों को उसके हिसाब से ऑप्टिमाइज़ करना न भूलें, ताकि खोज (फ़र्स्ट लोड), यूज़र ऐक्टिविटी (नेविगेशन और फ़्लो) और फिर से यूज़र ऐक्टिविटी (रिपीट लोड) को बढ़ाया जा सके.