আপনার সাইটের অফলাইন ব্যবহার কীভাবে ট্র্যাক করবেন, যাতে আপনি এই যুক্তি উপস্থাপন করতে পারেন যে কেন আপনার সাইটের একটি উন্নততর অফলাইন অভিজ্ঞতা প্রয়োজন।
আপনার সাইটের অফলাইন ব্যবহার কীভাবে ট্র্যাক করবেন তা শিখুন, যাতে আপনি যুক্তি দিয়ে বোঝাতে পারেন কেন আপনার সাইটের একটি উন্নত অফলাইন মোড প্রয়োজন। অফলাইন ব্যবহারের অ্যানালিটিক্স প্রয়োগ করার সময় কোন কোন সমস্যা ও ফাঁদ এড়িয়ে চলতে হবে তা বুঝুন।
অনলাইন এবং অফলাইন ব্রাউজার ইভেন্টের অসুবিধাগুলো
অফলাইন ব্যবহার ট্র্যাক করার সবচেয়ে সহজ সমাধান হলো online এবং offline ইভেন্টের জন্য ইভেন্ট লিসেনার তৈরি করা (যা অনেক ব্রাউজার সমর্থন করে ) এবং সেই লিসেনারগুলোর মধ্যে আপনার অ্যানালিটিক্স ট্র্যাকিং লজিক রাখা। দুর্ভাগ্যবশত, এই পদ্ধতির বেশ কিছু সমস্যা এবং সীমাবদ্ধতা রয়েছে:
- সাধারণভাবে, প্রতিটি নেটওয়ার্ক সংযোগের স্থিতির ঘটনা ট্র্যাক করাটা বাড়াবাড়ি হতে পারে এবং গোপনীয়তা-কেন্দ্রিক বিশ্বে এটি হিতে বিপরীত, যেখানে যথাসম্ভব কম ডেটা সংগ্রহ করা উচিত। এছাড়াও,
onlineএবংofflineইভেন্টগুলো মাত্র এক মুহূর্তের জন্য নেটওয়ার্ক বিচ্ছিন্ন হলেও সক্রিয় হতে পারে, যা একজন ব্যবহারকারী সম্ভবত দেখতে বা লক্ষ্যও করবেন না। - অফলাইন কার্যকলাপের অ্যানালিটিক্স ট্র্যাকিং অ্যানালিটিক্স সার্ভারে পৌঁছায় না।
- কোনো ব্যবহারকারী অফলাইনে গেলে স্থানীয়ভাবে একটি টাইমস্ট্যাম্প ট্র্যাক করা এবং তিনি আবার অনলাইনে ফিরে এলে সেই অফলাইন কার্যকলাপ অ্যানালিটিক্স সার্ভারে পাঠানো—এই পুরো বিষয়টি নির্ভর করে ব্যবহারকারীর আপনার সাইটে পুনরায় আসার ওপর। যদি অফলাইন মোডের অভাবে কোনো ব্যবহারকারী আপনার সাইট ছেড়ে চলে যান এবং আর কখনও ফিরে না আসেন, তবে তা ট্র্যাক করার কোনো উপায় আপনার কাছে থাকে না। আপনার সাইটে কেন একটি উন্নত অফলাইন মোড প্রয়োজন, সেই বিষয়ে যুক্তি দাঁড় করানোর জন্য অফলাইনে সাইট ছেড়ে চলে যাওয়ার ঘটনা ট্র্যাক করার ক্ষমতা একটি অত্যন্ত গুরুত্বপূর্ণ তথ্য।
-
onlineইভেন্টটি খুব নির্ভরযোগ্য নয়, কারণ এটি শুধু নেটওয়ার্ক অ্যাক্সেস সম্পর্কে জানে , ইন্টারনেট অ্যাক্সেস সম্পর্কে নয়। তাই একজন ব্যবহারকারী তখনও অফলাইনে থাকতে পারেন এবং ট্র্যাকিং পিং পাঠানো ব্যর্থ হতে পারে। - ব্যবহারকারী অফলাইনে থাকা অবস্থায়ও যদি বর্তমান পেজেই থাকেন, তাহলেও অন্য কোনো অ্যানালিটিক্স ইভেন্ট (যেমন স্ক্রল ইভেন্ট, ক্লিক ইত্যাদি) ট্র্যাক করা হয় না, যেগুলো আরও প্রাসঙ্গিক ও দরকারি তথ্য হতে পারত।
- শুধু অফলাইনে থাকাটা খুব একটা অর্থবহ নয়। সম্ভবত সবচেয়ে গুরুত্বপূর্ণ হলো এটা জানা যে কোন রিসোর্সগুলো লোড হতে ব্যর্থ হচ্ছে। এটি বিশেষ করে সিঙ্গেল-পেজ অ্যাপ্লিকেশন (SPA)-এর ক্ষেত্রে প্রাসঙ্গিক, যেখানে নেটওয়ার্ক সংযোগ বিচ্ছিন্ন হয়ে গেলে ব্রাউজারে অফলাইন ত্রুটির পৃষ্ঠা নাও আসতে পারে, যা ব্যবহারকারীরা বুঝতে পারেন। এর পরিবর্তে, এর ফলে সম্ভবত পেজের এলোমেলো, পরিবর্তনশীল অংশগুলো নীরবে ব্যর্থ হয়ে যায়।
অফলাইন ব্যবহার সম্পর্কে প্রাথমিক ধারণা পেতে আপনি এখনও এই সমাধানটি ব্যবহার করতে পারেন, কিন্তু এর নানা অসুবিধা ও সীমাবদ্ধতাগুলো সতর্কতার সাথে বিবেচনা করা প্রয়োজন।
একটি উন্নততর পন্থা: পরিষেবা কর্মী
যে সমাধানটি অফলাইন মোড সক্ষম করে, সেটি অফলাইন ব্যবহার ট্র্যাক করার জন্যও একটি উন্নততর সমাধান। ব্যবহারকারী অফলাইনে থাকা পর্যন্ত আপনি অ্যানালিটিক্স পিংগুলো IndexedDB-তে সংরক্ষণ করতে পারেন এবং ব্যবহারকারী আবার অনলাইনে এলে সেগুলো পুনরায় পাঠাতে পারেন। গুগল অ্যানালিটিক্সের জন্য, এটি একটি ওয়ার্কবক্স মডিউলে ইতিমধ্যেই উপলব্ধ আছে, কিন্তু মনে রাখবেন যে চার ঘণ্টার বেশি বিলম্বিতভাবে পাঠানো হিটগুলো প্রসেস নাও হতে পারে।
এর সবচেয়ে সরল রূপে, একটি ওয়ার্কবক্স-ভিত্তিক সার্ভিস ওয়ার্কারের মধ্যে এই দুটি লাইনের মাধ্যমে এটি সক্রিয় করা যেতে পারে:
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize();
এটি অফলাইনে থাকাকালীন সমস্ত বিদ্যমান ইভেন্ট এবং পেজভিউ পিং ট্র্যাক করে, কিন্তু সেগুলি যে অফলাইনে ঘটেছে তা আপনি জানতে পারবেন না, কারণ সেগুলি হুবহু পুনরায় চালানো হয়। আপনি একটি কাস্টম ডাইমেনশন ব্যবহার করে অ্যানালিটিক্স পিং-এ একটি offline ফ্ল্যাগ যোগ করার মাধ্যমে Workbox দিয়ে ট্র্যাকিং অনুরোধগুলি নিয়ন্ত্রণ করতে পারেন:
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize({
parameterOverrides: {
customDimension1: 'offline',
},
});
ইন্টারনেট সংযোগ ফিরে আসার আগেই যদি ব্যবহারকারী অফলাইনে থাকার কারণে পেজটি থেকে বেরিয়ে যান, তাহলে কী হবে? সাধারণত এক্ষেত্রে সার্ভিস ওয়ার্কারটি নিষ্ক্রিয় হয়ে যায়, কারণ সংযোগ ফিরে এলে এটি ডেটা পাঠাতে পারে না। কিন্তু ওয়ার্কবক্স গুগল অ্যানালিটিক্স মডিউলটি ব্যাকগ্রাউন্ড সিঙ্ক এপিআই (Background Sync API) ব্যবহার করে। ব্যবহারকারী ট্যাব বা ব্রাউজার বন্ধ করে দিলেও, সংযোগ ফিরে এলে ব্যাকগ্রাউন্ড সিঙ্ক অ্যানালিটিক্স ডেটা পাঠিয়ে দেয়।
এখনও একটি অসুবিধা রয়েছে: যদিও এটি বিদ্যমান ট্র্যাকিংকে অফলাইন-সক্ষম করে তোলে, একটি সাধারণ অফলাইন মোড প্রয়োগ না করা পর্যন্ত আপনি সম্ভবত খুব বেশি প্রাসঙ্গিক ডেটা পাবেন না। সংযোগ বিচ্ছিন্ন হয়ে গেলে ব্যবহারকারীরা তখনও দ্রুত আপনার সাইট থেকে বেরিয়ে যাবে। কিন্তু এখন আপনি অন্তত এটি পরিমাপ ও পরিমাণ নির্ধারণ করতে পারবেন, অফলাইন মোড প্রয়োগ করা ব্যবহারকারীদের সাথে আপনার সাধারণ ব্যবহারকারীদের গড় সেশন দৈর্ঘ্য এবং ব্যবহারকারীর সম্পৃক্ততা তুলনা করে।
এসপিএ এবং লেজি লোডিং
যদি একাধিক পৃষ্ঠার ওয়েবসাইট হিসেবে তৈরি কোনো পেজের ব্যবহারকারীরা অফলাইনে গিয়ে নেভিগেট করার চেষ্টা করেন, তাহলে ব্রাউজারের ডিফল্ট অফলাইন পেজটি প্রদর্শিত হয়, যা ব্যবহারকারীদের বুঝতে সাহায্য করে যে কী ঘটছে। তবে, একক-পৃষ্ঠার অ্যাপ্লিকেশন হিসেবে তৈরি পেজগুলো ভিন্নভাবে কাজ করে। ব্যবহারকারী একই পেজে থাকেন এবং কোনো ব্রাউজার নেভিগেশন ছাড়াই AJAX-এর মাধ্যমে নতুন কন্টেন্ট ডাইনামিকভাবে লোড হয়। অফলাইনে গেলে ব্যবহারকারীরা ব্রাউজারের এরর পেজ দেখতে পান না। এর পরিবর্তে, পেজের ডাইনামিক অংশগুলো এররসহ রেন্ডার হয়, অনির্ধারিত অবস্থায় চলে যায়, অথবা ডাইনামিক থাকা বন্ধ করে দেয়।
লেজি লোডিংয়ের কারণে একাধিক পৃষ্ঠার ওয়েবসাইটেও একই ধরনের প্রভাব দেখা যেতে পারে। উদাহরণস্বরূপ, হয়তো প্রাথমিক লোডটি অনলাইনে হয়েছিল, কিন্তু ব্যবহারকারী স্ক্রল করার আগেই অফলাইনে চলে গেলেন। সেক্ষেত্রে, 'বিলো দ্য ফোল্ড' (পৃষ্ঠার নিচের অংশ)-এর সমস্ত লেজি লোডেড কন্টেন্ট নীরবে ব্যর্থ হবে এবং অদৃশ্য হয়ে যাবে।
যেহেতু এই ঘটনাগুলো ব্যবহারকারীদের জন্য খুবই বিরক্তিকর, তাই এগুলো ট্র্যাক করা যুক্তিযুক্ত। নেটওয়ার্ক ত্রুটি শনাক্ত করতে এবং পরবর্তীতে অ্যানালিটিক্স ব্যবহার করে সেগুলো ট্র্যাক করার জন্য সার্ভিস ওয়ার্কার হলো সবচেয়ে উপযুক্ত জায়গা। ওয়ার্কবক্সের মাধ্যমে, একটি মেসেজ ইভেন্ট পাঠিয়ে ব্যর্থ অনুরোধগুলো সম্পর্কে পেজকে জানানোর জন্য একটি গ্লোবাল ক্যাচ হ্যান্ডলার কনফিগার করা যেতে পারে:
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 এ একটি চেক যোগ করতে পারি যা একটি রেগুলার এক্সপ্রেশন দিয়ে URI-টি ফিল্টার করে।
একটি আরও পরিচ্ছন্ন সমাধান হলো একটি কাস্টম হ্যান্ডলার দিয়ে registerRoute ইমপ্লিমেন্ট করা। এটি বিজনেস লজিককে একটি আলাদা রুটের মধ্যে আবদ্ধ করে, যা আরও জটিল সার্ভিস ওয়ার্কারদের ক্ষেত্রে উন্নততর রক্ষণাবেক্ষণযোগ্যতা প্রদান করে।
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 ইভেন্টটি শুনতে হবে এবং অ্যানালিটিক্স পিং পাঠাতে হবে। আবারও, সার্ভিস ওয়ার্কারের মধ্যে অফলাইনে হওয়া অ্যানালিটিক্স রিকোয়েস্টগুলো বাফার করা নিশ্চিত করুন। পূর্বে বর্ণিত পদ্ধতি অনুযায়ী, বিল্ট-ইন গুগল অ্যানালিটিক্স সাপোর্টের জন্য workbox-google-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
});
}
});
}
এটি গুগল অ্যানালিটিক্সে ব্যর্থ রিসোর্স লোডগুলো ট্র্যাক করবে, যেখানে রিপোর্টিংয়ের মাধ্যমে সেগুলো বিশ্লেষণ করা যাবে। এই থেকে প্রাপ্ত তথ্য সার্ভিস ওয়ার্কার ক্যাশিং এবং সার্বিকভাবে এরর হ্যান্ডলিং উন্নত করতে ব্যবহার করা যেতে পারে, যাতে অস্থিতিশীল নেটওয়ার্ক পরিস্থিতিতে পেজটি আরও শক্তিশালী ও নির্ভরযোগ্য হয়ে ওঠে।
পরবর্তী পদক্ষেপ
আপনি অফলাইন ব্যবহার ট্র্যাক করার বিভিন্ন উপায় এবং সেগুলোর সুবিধা ও অসুবিধা সম্পর্কে জেনেছেন। যদিও এটি আপনার কতজন ব্যবহারকারী অফলাইনে যান এবং এর কারণে সমস্যায় পড়েন তা পরিমাপ করতে সাহায্য করতে পারে, তবুও এটি কেবল একটি শুরু। যতক্ষণ না আপনার ওয়েবসাইটে একটি সুগঠিত অফলাইন মোড থাকবে, ততক্ষণ আপনি স্বাভাবিকভাবেই অ্যানালিটিক্সে অফলাইন ব্যবহারের তেমন কোনো তথ্য দেখতে পাবেন না।
আমরা পরামর্শ দিই যে, প্রথমে সম্পূর্ণ ট্র্যাকিং ব্যবস্থা চালু করুন এবং তারপর ট্র্যাকিংয়ের ওপর মনোযোগ রেখে ধাপে ধাপে আপনার অফলাইন সক্ষমতা বাড়ান। একটি অফলাইন এরর পেজ দিয়ে শুরু করুন। Workbox দিয়ে এটি তৈরি করা খুবই সহজ এবং এটি কাস্টম 404 পেজের মতোই একটি ইউএক্স (UX) বেস্ট প্র্যাকটিস। এরপর, আরও উন্নত অফলাইন ফলব্যাকের দিকে কাজ করুন এবং সবশেষে আসল অফলাইন কনটেন্টের দিকে যান। নিশ্চিত করুন যে আপনি আপনার ব্যবহারকারীদের কাছে এটি ভালোভাবে প্রচার ও ব্যাখ্যা করছেন, তাহলেই আপনি এর ব্যবহার বাড়তে দেখবেন। সর্বোপরি, সবাই তো মাঝে মাঝে অফলাইনে যায়।
আপনার ওয়েবসাইটে আরও বেশি বিনিয়োগ করতে বিভিন্ন বিভাগের স্টেকহোল্ডারদের রাজি করানোর টিপসের জন্য ‘How to report metrics and build a performance culture’ এবং ‘Fixing website speed cross-functionally’ পোস্টগুলো দেখুন। যদিও এই পোস্টগুলো পারফরম্যান্সের উপর কেন্দ্র করে লেখা, তবুও স্টেকহোল্ডারদের কীভাবে সম্পৃক্ত করা যায় সে সম্পর্কে সাধারণ ধারণা পেতে এগুলো আপনাকে সাহায্য করবে।