Đ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 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.

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle

Bài viết này hướng dẫn bạn cách theo dõi hoạt động sử dụng trang web của bạn khi không có mạng để giúp bạn đưa ra lý do tại sao trang web cần chế độ ngoại tuyến tốt hơn. Đồng thời, hướng dẫn này cũng giải thích những sai lầm và vấn đề cần tránh khi triển khai số liệu phân tích 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 việc sử dụng ngoại tuyến là tạo trình nghe sự kiện cho onlineoffline sự kiện ( nhiều trình duyệt hỗ trợ) và đặt số liệu phân tích theo dõi trong các trình nghe đó. Rất tiếc, có một số vấn đề và hạn chế với việc này phương pháp tiếp cận:

  • 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ư khi cần càng ít dữ liệu càng tốt đã thu thập. Ngoài ra, các sự kiện onlineoffline có thể kích hoạt chỉ trong một phần giây mất mạng mà người dùng thậm chí có thể không thấy hoặc nhận thấy.
  • Quá trình 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ủ Analytics vì người dùng đang... ngoại tuyến.
  • Theo dõi cục bộ một dấu thời gian khi người dùng không có kết nối mạng và gửi hoạt động ngoại tuyến tới máy chủ phân tích khi người dùng trở lại 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, bạn có thì không có cách nào để theo dõi thông tin đó. 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 về lý do khiến trang web của bạn cần chế độ ngoại tuyến tốt hơn.
  • Sự kiện online không đáng tin cậy vì chỉ biết về truy cập mạng, chứ không phải quyền truy cập Internet. Do đó, người dùng có thể vẫn đang ngoại tuyến và việc gửi lệnh ping theo dõi có thể vẫn không thành công.
  • Ngay cả khi người dùng vẫn ở trên trang hiện tại khi đang ngoại tuyến, không trang nào khác các sự kiện Analytics (ví dụ: sự kiện cuộn, lượt nhấp, v.v.) được theo dõi. thông tin phù hợp và hữu ích.
  • 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ó thể điều quan trọng hơn là biết được loại tài nguyên nào 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 khiến trình duyệt ngoại tuyến trang lỗi (mà người dùng có thể hiểu) nhưng có nhiều khả năng khiến các phần động ngẫu nhiên của trang bị lỗi im lặ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 nhiều nhược điểm và hạn chế cần được xem xét cẩn thậ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 ngoại tuyến mức sử dụng. Ý tưởng cơ bản là 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 chúng khi người dùng trực tuyến 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, Tuy nhiên, xin lưu ý rằng lượt truy cập gửi nhiều hơn bị hoãn 4 giờ có thể không được xử lý. Ở hình thức đơn giản nhất, bạn có thể kích hoạt tính năng này trong một dịch vụ dựa trên Workbox worker với 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 và ping lượt xem trang hiện có khi ở chế độ ngoại tuyến, nhưng bạn sẽ không biết điều đó thì sự kiện đó diễn ra ngay cả khi không có mạng (vì chúng chỉ được phát lại y như cũ). Để làm việc này bạn có thể thao túng 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 thứ nguyên tùy 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 có kết nối Internet quay lại? Mặc dù trình chạy dịch vụ này thường chuyển sang chế độ ngủ (vì trình chạy dịch vụ không thể gửi dữ liệu) khi có kết nối lại), mô-đun Workbox Google Analytics sử dụng đồng bộ hoá trong nền API này sẽ gửi số liệu phân tích dữ liệu 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ể sử dụng 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 kết nối bị ngắt. 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 đượ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 xuất hiện, giúp người dùng hiểu đ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 hoạt động theo cách khác. Người dùng ở lại cùng trang và nội dung mới được tải động thông qua AJAX mà không cần điều hướng của trình duyệt nào. Người dùng không thấy 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 hiển thị cùng với lỗi, hãy truy cập vào trạng thái không xác định hoặc 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 không thành cô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 việc theo dõi chúng là hợp lý. Trình chạy dịch vụ là điểm chính xác nhất để phát hiện lỗi mạng và cuối cùng theo dõi chúng bằng cách sử dụng phân tích. Với Workbox, một trình xử lý khai thác toàn cầu có thể đị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 một sự kiện tin nhắn:

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ì lắng nghe tất cả yêu cầu không thực hiện được, có một cách khác là 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 dấu kiểm 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. Quy tắc này bao gồm logic nghiệp vụ thành một tuyến riêng biệt, nhờ đó có thể duy 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 cho Google Analytics được tích hợp sẵn của Google.

Ví dụ sau đây sử dụng Google Analytics, nhưng có thể được áp dụng theo cách tương tự cho các công cụ phân tích khác các nhà cung cấp 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, nơi chúng có thể được phân tích bằng báo cáo. Thông tin chi tiết phái sinh có thể là dùng để cải thiện chức 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, giúp trang trở nên mạnh mẽ hơn và đáng tin cậy 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ù điều này có thể giúp xác định số lượng người dùng không có kết nối mạng và gặp sự cố do sự cố, 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, bạn thì rõ ràng là bạn sẽ không thấy nhiều hoạt động sử dụng ngoại tuyến trong Analytics.

Bạn nên thiết lập đầy đủ tính năng theo dõi sẵn, sau đó mở rộng khả năng theo dõi ngoại tuyến trong lặp lại để chú ý đến số theo dõi. Bắt đầu với một trang lỗi ngoại tuyến đơn giản trước bằng Hộp công việc thật đơn giản nên–và vẫn nên được xem 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 đó làm việc theo ý bạn nhắm đến 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 thực ngoại tuyến. Hãy đảm bảo bạn quảng cáo và giải thích thông tin này cho người dùng và bạn sẽ thấy mức sử dụng ngày càng tăng. Vì sau cùng thì thỉnh thoảng mọi người sẽ chuyển sang chế độ ngoại tuyến.

Tham khảo bài viết Cách báo cáo chỉ số và xây dựng văn hoá về hiệu suấtKhắc phục vấn đề tốc độ của trang web theo nhiều chức năng để biết các mẹo về việc thuyết phục các bên liên quan liên 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, chúng sẽ giúp bạn có được ý tưởng chung về cách tương tác các bên liên quan khác.

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