Cách theo dõi việc sử dụng trang web của bạn khi không có mạng để bạn có thể xem xét lý do trang web của bạn cần có trải nghiệm ngoại tuyến tốt hơn.
Bài viết này hướng dẫn cách theo dõi hoạt động sử dụng trang web khi không có mạng để giúp bạn giải thích lý do trang web của bạn cần chế độ ngoại tuyến tốt hơn. Hướng dẫn này cũng giải thích các cạm bẫy và vấn đề cần tránh khi triển khai số liệu phân tích mức sử dụng ngoại tuyến.
Những sai lầm của sự kiện trình duyệt trực tuyến và ngoại tuyến
Giải pháp rõ ràng để theo dõi mức sử dụng ngoại tuyến là tạo trình nghe sự kiện cho các sự kiện online và offline (được nhiều trình duyệt hỗ trợ) và đưa logic theo dõi số liệu phân tích vào các trình nghe đó. Không may, phương pháp này có một số vấn đề và hạn chế:
- Nhìn chung, việc theo dõi mọi sự kiện trạng thái kết nối mạng có thể là quá mức và phản tác dụng trong một thế giới chú trọng quyền riêng tư khi cần thu thập càng ít dữ liệu càng tốt. Ngoài ra, các sự kiện
onlinevàofflinecó thể kích hoạt chỉ trong một vài giây do mất mạng mà người dùng thậm chí có thể không thấy hoặc không nhận thấy. - Việc theo dõi số liệu phân tích hoạt động ngoại tuyến sẽ không bao giờ tiếp cận được máy chủ phân tích vì người dùng đang... ngoại tuyến.
- Việc theo dõi dấu thời gian cục bộ khi người dùng không có kết nối mạng và gửi hoạt động ngoại tuyến đến máy chủ phân tích khi người dùng kết nối mạng trở lại tuỳ thuộc vào việc người dùng truy cập lại trang web của bạn. Nếu người dùng rời khỏi trang web của bạn do thiếu chế độ ngoại tuyến và không bao giờ truy cập lại, thì bạn không có cách nào để theo dõi điều đó. Khả năng theo dõi số lượt bỏ ngang khi không có mạng là dữ liệu quan trọng để giải thích lý do trang web của bạn cần một chế độ ngoại tuyến tốt hơn.
- Sự kiện
onlinekhông đáng tin cậy lắm vì chỉ biết về việc truy cập mạng chứ không biết về quyền truy cập Internet. Do đó, người dùng có thể vẫn không có kết nối mạng và việc gửi lệnh ping theo dõi vẫn có thể không thành công. - Ngay cả khi người dùng vẫn ở trên trang hiện tại khi không có kết nối mạng, thì không có sự kiện phân tích nào khác (ví dụ: sự kiện cuộn, lượt nhấp, v.v.) được theo dõi. Đó có thể là thông tin phù hợp và hữu ích hơn.
- Nhìn chung, hoạt động ngoại tuyến cũng không có ý nghĩa gì quá nhiều. Là nhà phát triển trang web, bạn cần biết những loại tài nguyên không tải được. Điều này đặc biệt cần thiết trong bối cảnh SPA, trong đó kết nối mạng bị gián đoạn có thể không dẫn đến trang lỗi ngoại tuyến của trình duyệt (mà người dùng hiểu được) nhưng có nhiều khả năng khiến các phần động ngẫu nhiên của trang không thành công.
Bạn vẫn có thể sử dụng giải pháp này để có được hiểu biết cơ bản về việc sử dụng ngoại tuyến, nhưng cần phải xem xét kỹ lưỡng nhiều hạn chế và giới hạn.
Cách tiếp cận tốt hơn: trình chạy dịch vụ
Giải pháp bật chế độ ngoại tuyến hoá ra là giải pháp tốt hơn để theo dõi mức sử dụng ngoại tuyến. Về cơ bản, lưu trữ ping phân tích vào IndexedDB miễn là người dùng không có kết nối mạng và chỉ gửi lại các ping đó khi người dùng có kết nối mạng trở lại. Đối với Google Analytics, tính năng này đã có sẵn có sẵn thông qua mô-đun Workbox, nhưng lưu ý rằng các lượt truy cập được gửi trễ hơn 4 giờ có thể không được xử lý. Ở dạng đơn giản nhất, bạn có thể kích hoạt trong một trình thực thi dịch vụ dựa trên Workbox bằng 2 dòng sau:
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize();
Tính năng này theo dõi tất cả các sự kiện và ping lượt xem trang hiện có khi không có mạng, nhưng bạn sẽ không biết liệu các sự kiện và ping lượt xem trang này có xảy ra ngoại tuyến hay không (vì chúng chỉ được phát lại theo nguyên trạng). Để làm được điều này, bạn có thể thao tác với các yêu cầu theo dõi bằng Workbox bằng cách thêm cờ offline vào ping Analytics, sử dụng một phương diện tuỳ chỉnh (cd1 trong mã mẫu bên dưới):
import * as googleAnalytics from 'workbox-google-analytics';
googleAnalytics.initialize({
parameterOverrides: {
cd1: 'offline',
},
});
Điều gì xảy ra nếu người dùng thoát khỏi trang do không có kết nối mạng, trước khi kết nối Internet hoạt động trở lại? Mặc dù điều này thường khiến trình chạy dịch vụ chuyển sang chế độ ngủ (vì không thể gửi dữ liệu khi kết nối trở lại), nhưng mô-đun Google Analytics của Workbox sử dụng API đồng bộ hoá trong nền để gửi dữ liệu phân tích sau khi có kết nối trở lại, ngay cả khi người dùng đóng thẻ hoặc trình duyệt.
Vẫn có một hạn chế: mặc dù điều này làm cho tính năng theo dõi hiện tại có thể theo dõi ngoại tuyến, nhưng rất có thể bạn sẽ không thấy nhiều dữ liệu có liên quan cho đến khi bạn triển khai chế độ ngoại tuyến cơ bản. Người dùng vẫn sẽ nhanh chóng rời khỏi trang web của bạn khi mất kết nối. Nhưng giờ đây, ít nhất bạn có thể đo lường và định lượng mức độ này bằng cách so sánh thời lượng phiên trung bình và mức độ tương tác của người dùng với phương diện ngoại tuyến được áp dụng so với người dùng thông thường.
SPA và tải từng phần
Nếu người dùng truy cập vào một trang được tạo dưới dạng trang web nhiều trang chuyển sang chế độ ngoại tuyến và cố gắng điều hướng, thì trang ngoại tuyến mặc định của trình duyệt sẽ xuất hiện, giúp người dùng hiểu được điều gì đang xảy ra. Tuy nhiên, các trang được tạo dưới dạng ứng dụng trang đơn sẽ hoạt động theo cách khác. Người dùng ở trên cùng một trang và nội dung mới sẽ được tải động thông qua AJAX mà không cần bất kỳ thao tác điều hướng nào của trình duyệt. Người dùng sẽ không thấy trang lỗi của trình duyệt khi chuyển sang chế độ ngoại tuyến. Thay vào đó, các phần động của trang hiển thị kèm theo lỗi, chuyển sang trạng thái không xác định hoặc chỉ ngừng linh động.
Những hiệu ứng tương tự có thể xảy ra trong các trang web có nhiều trang do tải từng phần. Ví dụ: có thể lượt tải ban đầu diễn ra trực tuyến nhưng người dùng đã chuyển sang chế độ ngoại tuyến trước khi cuộn. Tất cả nội dung được tải từng phần dưới màn hình đầu tiên sẽ tự động bị lỗi và bị thiếu.
Vì những trường hợp này thực sự gây khó chịu cho người dùng nên việc theo dõi chúng là hợp lý. Trình chạy dịch vụ là điểm hoàn hảo để phát hiện các lỗi mạng và cuối cùng theo dõi các lỗi đó bằng cách sử dụng số liệu phân tích. Với Workbox, bạn có thể định cấu hình một trình xử lý bắt toàn cục để thông báo cho trang về các yêu cầu không thành công bằng cách gửi một sự kiện thông báo:
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();
}());
});
Thay vì theo dõi tất cả các yêu cầu không thực hiện được, có một cách khác là chỉ phát hiện lỗi trên các tuyến cụ thể. Ví dụ: nếu chỉ muốn báo cáo lỗi xảy ra trên các tuyến đến /products/*, chúng ta có thể thêm một yêu cầu kiểm tra trong setCatchHandler để lọc URI bằng một biểu thức chính quy.
Một giải pháp gọn gàng hơn là triển khai registerRoute bằng một trình xử lý tuỳ chỉnh. Điều này sẽ đóng gói logic nghiệp vụ vào một tuyến riêng, với khả năng bảo trì tốt hơn trong các trình chạy dịch vụ phức tạp hơn:
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();
}
}
);
Bước cuối cùng, trang cần theo dõi sự kiện message và gửi ping số liệu phân tích.
Một lần nữa, hãy đảm bảo lưu vào bộ đệm các yêu cầu phân tích xảy ra ngoại tuyến trong trình chạy dịch vụ. Như
mô tả trước đó, hãy khởi chạy trình bổ trợ workbox-google-analytics để sử dụng
dịch vụ hỗ trợ tích hợp sẵn của Google Analytics.
Ví dụ sau đây sử dụng Google Analytics, nhưng có thể áp dụng theo cách tương tự cho các nhà cung cấp dịch vụ phân tích khác.
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
});
}
});
}
Tính năng này sẽ theo dõi các lượt tải tài nguyên không thành công trong Google Analytics, đồng thời có thể phân tích các tài nguyên đó bằng báo cáo. Bạn có thể sử dụng thông tin chi tiết thu được để cải thiện việc lưu vào bộ nhớ đệm của trình chạy dịch vụ và xử lý lỗi nói chung, giúp trang trở nên mạnh mẽ và đáng tin cậy hơn trong điều kiện mạng không ổn định.
Các bước tiếp theo
Bài viết này đã trình bày các cách theo dõi mức sử dụng ngoại tuyến khác nhau cùng với ưu điểm và nhược điểm của chúng. Mặc dù việc này có thể giúp xác định số lượng người dùng không kết nối mạng và gặp sự cố do vấn đề này, nhưng đây vẫn chỉ là một bước khởi đầu. Miễn là trang web của bạn không cung cấp chế độ ngoại tuyến được xây dựng tốt, thì rõ ràng bạn sẽ không thấy mức sử dụng ngoại tuyến nhiều trong Analytics.
Bạn nên thiết lập đầy đủ tính năng theo dõi, sau đó mở rộng khả năng ngoại tuyến nhiều lần để chú ý đến số theo dõi. Trước tiên, hãy bắt đầu với một trang lỗi ngoại tuyến đơn giản – với Hộp làm việc không dễ làm – và vẫn nên được coi là phương pháp hay nhất về trải nghiệm người dùng, tương tự như các trang 404 tuỳ chỉnh. Sau đó, hãy hướng đến các tính năng dự phòng ngoại tuyến nâng cao hơn và cuối cùng là đến nội dung ngoại tuyến thực. Hãy đảm bảo bạn quảng cáo và giải thích rõ điều này cho người dùng để họ sử dụng ngày càng nhiều hơn. Vì sau cùng thì thỉnh thoảng mọi người sẽ chuyển sang chế độ ngoại tuyến.
Hãy tham khảo bài viết Cách báo cáo chỉ số và xây dựng văn hoá hiệu suất cũng như Khắc phục tốc độ của trang web trên nhiều chức năng để biết các mẹo thuyết phục các bên liên quan liên chức năng đầu tư thêm vào trang web của bạn. Mặc dù tập trung vào hiệu suất, nhưng các bài đăng đó sẽ giúp bạn nhận được ý tưởng chung về cách tương tác với các bên liên quan.
Ảnh chính của JC Gellidon trên Unsplash.