Đo lường mức sử dụng khi không có mạng

Cách theo dõi việc sử dụng trang web khi không có mạng để bạn có thể giải thích lý do trang web của bạn cần có trải nghiệm ngoại tuyến tốt hơn.

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle
X GitHub

Bài viết này cho bạn biết cách theo dõi hoạt động sử dụng trang web khi không có mạng để giúp bạn lý giải lý do trang web của bạn cần có chế độ ngoại tuyến tốt hơn. Tài liệu này cũng giải thích các sai lầm và vấn đề cần tránh khi triển khai phân tích mức sử dụng ngoại tuyến.

Các sai lầm của sự kiện duyệt web trực tuyến và ngoại tuyến

Giải pháp rõ ràng để theo dõi hoạt động 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 (mà nhiều trình duyệt hỗ trợ) và đặt logic theo dõi phân tích vào những trình nghe đó. Rất tiếc, phương pháp này có một số vấn đề và hạn chế như sau:

  • 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á nhiều và gây ra hiệu quả phản tác dụng trong một thế giới chú trọng vào quyền riêng tư nơi cần thu thập càng ít dữ liệu càng tốt. Ngoài ra, các sự kiện online và offline có thể kích hoạt chỉ trong vài giây bị mất mạng mà người dùng có thể thậm chí sẽ không nhìn thấy hoặc nhận thấy.
  • Việc theo dõi phân tích hoạt động ngoại tuyến sẽ không bao giờ đế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 có 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, bạn sẽ không có cách nào để theo dõi điều đó. Khả năng theo dõi tỷ lệ bỏ ngang khi không có mạng là dữ liệu quan trọng để xây dựng trường hợp lý do trang web của bạn cần có chế độ ngoại tuyến tốt hơn.
  • Sự kiện online không đáng tin cậy vì nó chỉ biết về quyền truy cập mạng chứ không biết về quyền truy cập Internet. Do đó, người dùng vẫn có thể không kết nối mạng và việc gửi ping theo dõi vẫn có thể không thành công.
  • Ngay cả khi người dùng vẫn ở lại trang hiện tại trong 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. Đây 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 quá có ý nghĩa. Là một nhà phát triển trang web, việc biết những loại tài nguyên không tải được có thể quan trọng hơn. Điều này đặc biệt cần thiết trong bối cảnh SPA, khi 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 chạy ngầm.

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 khi không có mạng. Tuy nhiên, bạn cần xem xét kỹ nhiều hạn chế và hạn chế.

Cách tiếp cận hiệu quả hơn: service worker

Giải pháp cho phép bật chế độ ngoại tuyến hoá ra lại là giải pháp tốt hơn để theo dõi mức sử dụng ngoại tuyến. Ý tưởng cơ bản là lưu trữ các ping số liệu phân tích vào IndexedDB miễn là người dùng không kết nối mạng và chỉ gửi lại chúng khi người dùng kết nối mạng trở lại. Đối với Google Analytics, tính năng này đã có sẵn thông qua mô-đun Workbox, nhưng hãy lưu ý rằng các lượt truy cập được gửi bị trì hoãn 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 hoạt động này trong trình chạy dịch vụ dựa trên Workbox bằng 2 dòng sau:

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

googleAnalytics.initialize();

Việc 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ó kết nối mạng, nhưng bạn sẽ không biết rằng các sự kiện đó đã xảy ra ngoại tuyến (vì chúng chỉ được phát lại nguyên trạng). Đối với việc 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 phân tích, sử dụng thứ nguyên tùy chỉnh (cd1 trong mã mẫu dưới đây):

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

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

Điều gì sẽ xảy ra nếu người dùng rời khỏi trang do không có kết nối mạng trước khi có kết nối Internet 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), mô-đun Google Analytics của Workbox sử dụng Background Sync API (API đồng bộ hoá nền) sẽ gửi dữ liệu phân tích sau này khi 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òn một hạn chế: mặc dù điều này làm cho việc theo dõi hiện tại có khả năng 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 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 bị ngắt kết nối. Nhưng giờ đây, ít nhất bạn có thể đo lường và định lượng điều 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 đối với người dùng được áp dụng phương diện ngoại tuyến 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 nhưng không có kết nối mạng và cố gắng di chuyển, 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 điều gì đang diễn ra. Tuy nhiên, các trang được tạo dưới dạng ứng dụng trang đơn hoạt động theo cách khác. Người dùng ở lại trang và nội dung mới được tải động qua AJAX mà không cần điều hướng trên trình duyệt. Người dùng sẽ không thấy trang lỗi trình duyệt khi không có kết nối mạng. Thay vào đó, các phần động của trang sẽ hiển thị kèm lỗi, chuyển sang trạng thái không xác định hoặc ngừng động.

Các tác động tương tự có thể xảy ra trong các trang web nhiều trang do tải từng phần. Ví dụ: có thể lần tải ban đầu xảy 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 không hoạt động 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 bạn nên theo dõi các trường hợp này. Trình chạy dịch vụ là vị trí lý tưởng để phát hiện lỗi mạng và cuối cùng theo dõi 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 trình xử lý phát chung để 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ành công, 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 quy trình 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 rõ ràng hơn là triển khairegisterRoute bằng trình xử lý tuỳ chỉnh. Điều này sẽ đóng gói logic nghiệp vụ thành 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();
    }
  }
);

Trong 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 nhớ lưu vào vùng đệ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 để tích hợp sẵn Google Analytics.

Ví dụ sau sử dụng Google Analytics, nhưng có thể được á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, tại đó bạn có thể phân tích các lượt tải tài nguyên đó bằng tính năng báo cáo. Thông tin chi tiết phái sinh có thể dùng để 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 hoạt động 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 hoạt động sử dụng ngoại tuyến cùng với ưu điểm và nhược điểm của chúng. Mặc dù điều 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 đó vẫn chỉ là 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, rõ ràng bạn sẽ không thấy nhiều hoạt động sử dụng ngoại tuyến trong số liệu phân tích.

Bạn nên theo dõi đầy đủ, sau đó mở rộng các chức năng ngoại tuyến trong các vòng lặp bằng cách 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 Workbox, việc này rất đơn giản và vẫn nên được coi là một 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 tìm cách 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à hướng đến nội dung ngoại tuyến thực sự. 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 của mình, bạn sẽ thấy mức sử dụng tăng lên. Sau cùng, mọi người sẽ thỉnh thoảng ngoại tuyến.

Hãy xem bài viết Cách báo cáo chỉ số và xây dựng văn hoá về hiệu suất và 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 giữa các chức năng đầu tư nhiều hơn vào trang web của bạn. Mặc dù các bài đăng đó tập trung vào hiệu suất, nhưng chúng sẽ giúp bạn có được ý tưởng chung về cách thu hút các bên liên quan.

Ảnh chính của JC Gellidon trên Unsplash.