Đo lường mức sử dụng ngoại tuyến

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ể đưa ra lý do tại sao trang web của bạn cần có trải nghiệm tốt hơn khi không có mạng.

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle

Tìm hiểu 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ể đưa ra lý do tại sao trang web của bạn cần có chế độ ngoại tuyến tốt hơn. Tìm hiểu những cạm bẫy và vấn đề cần tránh khi triển khai tính năng phân tích mức sử dụng ngoại tuyến.

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

  • Nói 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ư, 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 onlineoffline có thể kích hoạt chỉ trong một phần giây khi mất mạng, mà người dùng có thể thậm chí không thấy hoặc không nhận thấy.
  • Tính năng theo dõi phân tích hoạt động ngoại tuyến không tiếp cận được máy chủ phân tích.
  • Việc theo dõi dấu thời gian cục bộ khi người dùng chuyển sang chế độ ngoại tuyến và gửi hoạt động ngoại tuyến đến máy chủ số liệu phân tích khi người dùng quay lại chế độ trực tuyến phụ 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 lượt bỏ ngang ngoại tuyến là dữ liệu quan trọng để xây dựng lý do tại sao 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 lắm vì sự kiện này 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ể ở chế độ ngoại tuyến 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 ở trên trang hiện tại khi ở chế độ ngoại tuyến, thì không có sự kiện phân tích nào khác (ví dụ: sự kiện di chuyển, lượt nhấp, v.v.) được theo dõi, đây có thể là thông tin hữu ích và phù hợp hơn.
  • Chỉ ở chế độ ngoại tuyến thì không có nhiều ý nghĩa. Điều quan trọng nhất có thể là biết những tài nguyên nào không tải được. Điều này đặc biệt phù hợp với các ứng dụng một trang (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. Thay vào đó, có thể dẫn đến các phần động, ngẫu nhiên của trang không hoạt động một cách âm thầm.

Bạn vẫn có thể sử dụng giải pháp này để hiểu cơ bản về mức sử dụng ngoại tuyến, nhưng cần cân nhắc kỹ lưỡng nhiều nhược điểm và hạn chế.

Phương pháp tốt hơn: trình chạy dịch vụ

Giải pháp cho phép chế độ ngoại tuyến cũng là một giải pháp tốt hơn để theo dõi mức sử dụng ngoại tuyến. Bạn có thể lưu trữ các ping phân tích trong IndexedDB miễn là người dùng ở chế độ ngoại tuyến và gửi lại các ping đó khi người dùng chuyển sang chế độ trực tuyến. Đối với Google Analytics, tính năng này đã có trong mô-đun Workbox, nhưng hãy lưu ý rằng các lượt truy cập được gửi muộ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 tính năng này trong trình chạy dịch vụ dựa trên Workbox bằng hai 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 hiện có và ping lượt xem trang khi ở chế độ ngoại tuyến, nhưng bạn sẽ không biết rằng các sự kiện đó xảy ra ở chế độ ngoại tuyến vì chúng chỉ được phát lại nguyên trạng. 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 phương diện tuỳ chỉnh:

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

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

Điều gì sẽ xảy ra nếu người dùng rời khỏi trang do ở chế độ ngoại tuyến, trước khi 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, nhưng mô-đun Google Analytics của Workbox sử dụng API Đồng bộ hoá trong nền. Tính năng Đồng bộ hoá trong nền sẽ gửi dữ liệu phân tích 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ó một nhược điểm: mặc dù điều này giúp tính năng theo dõi hiện có có thể hoạt động ở chế độ 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 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 kết nối bị gián đoạn. Nhưng giờ đây, bạn có thể ít nhất là đ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 những người dùng có 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ính năng tải từng phần

Nếu người dùng truy cập vào một trang được xây dựng dưới dạng trang web nhiều trang, chuyển sang chế độ ngoại tuyến 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 chuyện gì đang xảy ra. Tuy nhiên, các trang được xây dựng dưới dạng ứng dụng một trang hoạt động khác. Người dùng vẫn ở trên cùng một trang và nội dung mới được tải linh động thông qua AJAX mà không cần di chuyển trong trình duyệt. Người dùng 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ị lỗi, chuyển sang trạng thái không xác định hoặc chỉ ngừng hoạt động linh động.

Các hiệu ứng tương tự có thể xảy ra trong các trang web nhiều trang do tính năng tải từng phần. Ví dụ: có thể quá trình 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 di chuyển. Tất cả nội dung được tải từng phần dưới màn hình đầu tiên sẽ không hoạt động một cách âm thầm 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 cần theo dõi chúng. Trình chạy dịch vụ là nơi hoàn hảo để phát hiện lỗi mạng và cuối cùng là theo dõi các lỗi đó bằng tính năng phân tích. Với Workbox, a trình xử lý bắt lỗi toàn cầu có thể được định cấu hình để 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 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ì nghe tất cả các yêu cầu không thành công, một cách khác là chỉ bắt lỗi trên các tuyến đường cụ thể. Ví dụ: nếu chỉ muốn báo cáo các lỗi xảy ra trên các tuyến đường đến /products/*, thì bạn có thể thêm một lệnh kiểm tra trong setCatchHandler để lọc URI bằng biểu thức chính quy.

Một giải pháp rõ ràng hơn là triển khai registerRoute bằng trình xử lý tuỳ chỉnh. Giải pháp này đóng gói logic kinh doanh vào một tuyến đường riêng biệt, giúp dễ bảo trì 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 nghe sự kiện message và gửi ping phân tích. Một lần nữa, hãy nhớ đệm các yêu cầu phân tích xảy ra ở chế độ 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 để được hỗ trợ tích hợp Google Analytics.

Ví dụ sau đây sử dụng Google Analytics, nhưng bạn 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
      });
    }
  });
}

Điều 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, nơi bạn có thể phân tích các lượt tải đó bằng tính năng báo cáo. Thông tin chi tiết thu được có thể dùng để cải thiện tính năng lưu vào bộ nhớ đệm của trình chạy dịch vụ và xử lý lỗi nói chung, nhằm 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ạn đã tìm hiểu các cách theo dõi mức sử dụng ngoại tuyến với những ưu điểm và nhược điểm của chúng. Mặc dù điều này có thể giúp định lượng số lượng người dùng chuyển sang chế độ ngoại tuyến và gặp phải vấn đề do đó, nhưng đây chỉ là 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 là bạn sẽ không thấy nhiều mức sử dụng ngoại tuyến trong tính năng phân tích.

Bạn nên triển khai tính năng theo dõi đầy đủ, sau đó mở rộng các tính năng ngoại tuyến theo từng bước lặp, tập trung vào việc theo dõi. Bắt đầu bằng trang lỗi ngoại tuyến. Bạn có thể dễ dàng tạo trang này bằng Workbox và đây 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 chuyển sang các phương án dự phòng ngoại tuyến nâng cao hơn và cuối cùng là chuyển sang nội dung ngoại tuyến thực. Hãy nhớ quảng cáo và giải thích rõ ràng điều này cho người dùng, và bạn sẽ thấy mức sử dụng ngày càng tăng. Sau cùng, ai cũng chuyển sang chế độ ngoại tuyến thỉnh thoảng.

Hãy xem bài viết Cách báo cáo chỉ số và xây dựng văn hoá hiệu suấtKhắc phục tốc độ trang web đa chức năng để biết các mẹo về cách thuyết phục các bên liên quan đa 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.