วิธีติดตามการใช้งานเว็บไซต์แบบออฟไลน์เพื่อให้คุณอธิบายได้ว่าเหตุใดเว็บไซต์จึงต้องมีประสบการณ์การใช้งานแบบออฟไลน์ที่ดียิ่งขึ้น
บทความนี้จะแสดงวิธีติดตามการใช้งานเว็บไซต์แบบออฟไลน์เพื่อช่วยให้คุณอธิบายเหตุผลที่เว็บไซต์ต้องมีโหมดออฟไลน์ที่ดีขึ้นได้ นอกจากนี้ ยังอธิบายถึงข้อผิดพลาดและปัญหาที่ควรหลีกเลี่ยงเมื่อใช้ข้อมูลวิเคราะห์การใช้งานแบบออฟไลน์
ข้อควรระวังเกี่ยวกับเหตุการณ์เบราว์เซอร์ออนไลน์และออฟไลน์
โซลูชันที่ชัดเจนสำหรับการติดตามการใช้งานแบบออฟไลน์คือการสร้างโปรแกรมรับฟังเหตุการณ์สําหรับเหตุการณ์ online
และ offline
(ซึ่งเบราว์เซอร์จํานวนมากรองรับ) และใส่ตรรกะการติดตามข้อมูลวิเคราะห์ในโปรแกรมรับฟังเหล่านั้น แต่วิธีนี้มีข้อจำกัดและปัญหาหลายประการ ดังนี้
- โดยทั่วไปแล้ว การติดตามเหตุการณ์สถานะการเชื่อมต่อเครือข่ายทุกรายการอาจไม่จำเป็นและทําให้เสียผลในโลกที่ให้ความสําคัญกับความเป็นส่วนตัวซึ่งควรเก็บรวบรวมข้อมูลให้น้อยที่สุด นอกจากนี้ เหตุการณ์
online
และoffline
อาจเกิดขึ้นเพียงเสี้ยววินาทีที่เครือข่ายขาดการเชื่อมต่อ ซึ่งผู้ใช้อาจไม่สังเกตเห็น - การติดตามข้อมูลวิเคราะห์ของกิจกรรมออฟไลน์จะไม่ส่งถึงเซิร์ฟเวอร์ข้อมูลวิเคราะห์เนื่องจากผู้ใช้ออฟไลน์อยู่
- การติดตามการประทับเวลาในเครื่องเมื่อผู้ใช้ออฟไลน์และการส่งกิจกรรมออฟไลน์ไปยังเซิร์ฟเวอร์ Analytics เมื่อผู้ใช้กลับมาออนไลน์อีกครั้งนั้นขึ้นอยู่กับว่าผู้ใช้กลับมาที่เว็บไซต์หรือไม่ หากผู้ใช้ออกจากเว็บไซต์เนื่องจากไม่มีโหมดออฟไลน์และไม่เคยกลับมาอีก คุณจะไม่มีวิธีติดตามเหตุการณ์ดังกล่าว ความสามารถในการติดตามการหยุดกลางคันในโหมดออฟไลน์เป็นข้อมูลสําคัญในการสร้างกรณีสําคัญว่าเหตุใดเว็บไซต์จึงต้องใช้โหมดออฟไลน์ที่ดีขึ้น
- เหตุการณ์
online
ไม่น่าเชื่อถือมากนักเนื่องจากรู้เฉพาะเกี่ยวกับการเข้าถึงเครือข่าย ไม่ใช่การเข้าถึงอินเทอร์เน็ต ดังนั้น ผู้ใช้อาจยังออฟไลน์อยู่และการส่งการติดตาม Ping อาจยังดำเนินการไม่สำเร็จ - แม้ว่าผู้ใช้จะยังอยู่ในหน้าปัจจุบันขณะออฟไลน์ แต่ระบบจะไม่ติดตามเหตุการณ์ Analytics อื่นๆ (เช่น เหตุการณ์การเลื่อน การคลิก ฯลฯ) ซึ่งอาจเป็นข้อมูลที่มีประโยชน์และมีความเกี่ยวข้องมากกว่า
- โดยทั่วไปแล้วการออฟไลน์ก็ไม่ได้มีความหมายมากนัก ในฐานะนักพัฒนาเว็บไซต์ คุณอาจต้องทราบว่าทรัพยากรประเภทใดโหลดไม่สำเร็จ การดำเนินการนี้มีความเกี่ยวข้องอย่างยิ่งในบริบทของ SPA ซึ่งการเชื่อมต่อเครือข่ายที่ขาดการเชื่อมต่ออาจไม่ทําให้เบราว์เซอร์ออฟไลน์และแสดงหน้าข้อผิดพลาด (ซึ่งผู้ใช้เข้าใจ) แต่มีแนวโน้มที่จะทําให้ส่วนแบบไดนามิกแบบสุ่มของหน้าเว็บไม่ทํางานโดยที่ผู้ใช้ไม่รู้ตัว
คุณยังคงใช้โซลูชันนี้เพื่อทําความเข้าใจพื้นฐานเกี่ยวกับการใช้งานแบบออฟไลน์ได้ แต่ต้องพิจารณาข้อเสียและข้อจํากัดต่างๆ อย่างรอบคอบ
แนวทางที่ดีกว่า: Service Worker
โซลูชันที่เปิดใช้โหมดออฟไลน์กลับกลายเป็นโซลูชันที่ดีกว่าในการติดตามการใช้งานแบบออฟไลน์ แนวคิดพื้นฐานคือจัดเก็บคําสั่ง ping ของข้อมูลวิเคราะห์ไว้ใน IndexedDB ตราบใดที่ผู้ใช้ออฟไลน์อยู่ และส่งอีกครั้งเมื่อผู้ใช้ออนไลน์อีกครั้ง สําหรับ Google Analytics ฟีเจอร์นี้พร้อมใช้งานทันทีผ่านโมดูล Workbox แต่โปรดทราบว่าระบบอาจไม่ประมวลผล Hit ที่ส่งล่าช้ากว่า 4 ชั่วโมง รูปแบบที่ง่ายที่สุดคือสามารถเปิดใช้งานภายใน Service Worker ที่ใช้ Workbox ได้ด้วย 2 บรรทัดนี้
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize();
ซึ่งจะติดตามเหตุการณ์ที่มีอยู่ทั้งหมดและพิงการดูหน้าเว็บขณะออฟไลน์ แต่คุณจะไม่รู้เลยว่าเหตุการณ์เหล่านั้นเกิดขึ้นขณะออฟไลน์ (เนื่องจากระบบจะเล่นซ้ำตามที่เป็นอยู่) ในกรณีนี้
คุณสามารถจัดการคําขอติดตามด้วย Workbox โดยการเพิ่ม Flag offline
ลงในคําสั่ง ping ของ Analytics โดยใช้มิติข้อมูลที่กำหนดเอง (cd1
ในตัวอย่างโค้ดด้านล่าง)
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize({
parameterOverrides: {
cd1: 'offline',
},
});
จะเกิดอะไรขึ้นหากผู้ใช้ออกจากหน้าเว็บเนื่องจากออฟไลน์อยู่ก่อนที่การเชื่อมต่ออินเทอร์เน็ตจะกลับมา แม้ว่าปกติแล้วการดําเนินการนี้จะทําให้ Service Worker หยุดทํางาน (เนื่องจากไม่สามารถส่งข้อมูลได้เมื่อการเชื่อมต่อกลับมา) แต่โมดูล Google Analytics ของ Workbox จะใช้ Background Sync API ซึ่งจะส่งข้อมูลวิเคราะห์ในภายหลังเมื่อการเชื่อมต่อกลับมา แม้ว่าผู้ใช้จะปิดแท็บหรือเบราว์เซอร์ไปแล้วก็ตาม
แต่ข้อเสียยังคงมีอยู่ แม้ว่าการดําเนินการนี้จะทําให้เครื่องมือติดตามที่มีอยู่ทํางานแบบออฟไลน์ได้ แต่คุณก็อาจไม่เห็นข้อมูลที่เกี่ยวข้องมากนักจนกว่าจะติดตั้งใช้งานโหมดออฟไลน์พื้นฐาน ผู้ใช้จะยังคงออกจากเว็บไซต์อย่างรวดเร็วเมื่อการเชื่อมต่อขาดหายไป แต่ตอนนี้คุณวัดและระบุปริมาณข้อมูลนี้ได้อย่างน้อยที่สุด โดยการเปรียบเทียบระยะเวลาเซสชันโดยเฉลี่ยและการมีส่วนร่วมของผู้ใช้สำหรับผู้ใช้ที่มีการใช้มิติข้อมูลออฟไลน์เทียบกับผู้ใช้ทั่วไป
SPA และการโหลดแบบ Lazy Loading
หากผู้ใช้เข้าชมหน้าเว็บที่สร้างเป็นเว็บไซต์หลายหน้าออฟไลน์และพยายามไปยังส่วนต่างๆ หน้าเว็บออฟไลน์เริ่มต้นของเบราว์เซอร์จะปรากฏขึ้น ซึ่งจะช่วยให้ผู้ใช้เข้าใจสิ่งที่เกิดขึ้น อย่างไรก็ตาม หน้าเว็บที่สร้างเป็นแอปพลิเคชันหน้าเว็บเดียวจะทํางานแตกต่างกัน ผู้ใช้จะยังคงอยู่ในหน้าเดิม และระบบจะโหลดเนื้อหาใหม่แบบไดนามิกผ่าน AJAX โดยไม่ต้องไปยังส่วนต่างๆ ของเบราว์เซอร์ ผู้ใช้จะไม่เห็นหน้าข้อผิดพลาดของเบราว์เซอร์เมื่อออฟไลน์ แต่ส่วนแบบไดนามิกของหน้าเว็บจะแสดงผลพร้อมข้อผิดพลาด เปลี่ยนเป็นสถานะที่ไม่ระบุ หรือหยุดเป็นแบบไดนามิก
ผลลัพธ์ที่คล้ายกันอาจเกิดขึ้นภายในเว็บไซต์หลายหน้าเนื่องจากการโหลดเมื่อจำเป็น เช่น โหลดครั้งแรกอาจเกิดขึ้นทางออนไลน์ แต่ผู้ใช้ออฟไลน์ไปก่อนเลื่อน เนื้อหาที่โหลดแบบ Lazy Loading ทั้งหมดใต้ส่วนที่เป็นขอบบนของหน้าเว็บจะโหลดไม่สำเร็จและหายไปโดยอัตโนมัติ
เนื่องจากกรณีเหล่านี้สร้างความรำคาญให้กับผู้ใช้เป็นอย่างมาก จึงควรติดตาม Service Worker เป็นจุดที่เหมาะเจาะในการจับข้อผิดพลาดของเครือข่าย และติดตามข้อผิดพลาดเหล่านั้นโดยใช้ข้อมูลวิเคราะห์ในท้ายที่สุด เมื่อใช้ 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
ซึ่งจะกรอง URI ด้วยนิพจน์ทั่วไป
โซลูชันที่เรียบร้อยกว่าคือการใช้ registerRoute กับตัวแฮนเดิลที่กําหนดเอง ซึ่งจะรวมตรรกะทางธุรกิจไว้ในเส้นทางแยกต่างหาก พร้อมความสามารถในการบำรุงรักษาที่ดีขึ้นใน Service Worker ที่ซับซ้อนมากขึ้น
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
และส่งคําสั่ง ping ไปยัง Analytics
โปรดตรวจสอบอีกครั้งว่าได้บัฟเฟอร์คําขอข้อมูลวิเคราะห์ที่เกิดขึ้นแบบออฟไลน์ภายใน Service Worker ดังที่อธิบายไว้ก่อนหน้านี้ ให้เริ่มต้นใช้งานปลั๊กอิน workbox-google-analytics
เพื่อรองรับ Google Analytics ในตัว
ตัวอย่างต่อไปนี้ใช้ 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
});
}
});
}
ซึ่งจะติดตามการโหลดทรัพยากรที่ไม่สําเร็จใน Google Analytics ซึ่งสามารถวิเคราะห์ได้โดยใช้การรายงาน ข้อมูลเชิงลึกที่ได้สามารถนำไปใช้ปรับปรุงการแคช Service Worker และการจัดการข้อผิดพลาดโดยทั่วไป เพื่อให้หน้าเว็บมีประสิทธิภาพและเชื่อถือได้มากขึ้นภายใต้เงื่อนไขเครือข่ายที่ไม่เสถียร
ขั้นตอนถัดไป
บทความนี้แสดงวิธีต่างๆ ในการติดตามการใช้งานแบบออฟไลน์พร้อมทั้งข้อดีและข้อเสีย แม้ว่าเมตริกนี้จะช่วยวัดจํานวนผู้ใช้ที่ออฟไลน์และพบปัญหาเนื่องจากการออฟไลน์ แต่ก็ยังเป็นเพียงจุดเริ่มต้นเท่านั้น ตราบใดที่เว็บไซต์ไม่มีโหมดออฟไลน์ที่สร้างขึ้นอย่างดี คุณจะไม่เห็นการใช้งานแบบออฟไลน์มากนักในข้อมูลวิเคราะห์
เราขอแนะนําให้ติดตั้งการติดตามอย่างเต็มรูปแบบ จากนั้นขยายความสามารถแบบออฟไลน์ในรุ่นต่างๆ โดยจับตาดูหมายเลขติดตาม เริ่มต้นด้วยหน้าข้อผิดพลาดแบบออฟไลน์ง่ายๆ ก่อน ซึ่งWorkbox ช่วยให้ทําได้ง่ายๆ และควรถือเป็นแนวทางปฏิบัติแนะนำด้าน UX เช่นเดียวกับหน้า 404 ที่กําหนดเอง จากนั้นค่อยๆ พัฒนาเนื้อหาสำรองแบบออฟไลน์ขั้นสูงขึ้น และสุดท้ายก็พัฒนาเป็นเนื้อหาออฟไลน์จริง อย่าลืมโฆษณาและอธิบายเรื่องนี้ให้ผู้ใช้ทราบอย่างละเอียด แล้วคุณจะเห็นการใช้งานเพิ่มขึ้น ทุกคนก็ออฟไลน์เป็นครั้งคราว
ดูเคล็ดลับในการโน้มน้าวผู้มีส่วนเกี่ยวข้องข้ามฟังก์ชันให้ลงทุนในเว็บไซต์มากขึ้นได้ที่วิธีรายงานเมตริกและสร้างวัฒนธรรมด้านประสิทธิภาพ และการแก้ไขปัญหาความเร็วของเว็บไซต์ในหลายฟังก์ชัน แม้ว่าโพสต์เหล่านั้นจะมุ่งเน้นที่ประสิทธิภาพ แต่จะช่วยให้คุณทราบแนวคิดทั่วไปเกี่ยวกับวิธีดึงดูดผู้มีส่วนเกี่ยวข้องได้
รูปภาพหลักโดย JC Gellidon ใน Unsplash