衡量离线使用情况

如何跟踪网站的离线使用情况,以便阐明您的网站为何需要更好的离线体验。

Stephan Giesau
Stephan Giesau
Martin Schierle
Martin Schierle

本文将向您介绍如何跟踪网站的离线使用情况,以帮助您了解 网站需要更好的离线模式。还说明了在实施代码时要避免的陷阱和问题 离线使用情况分析

在线和离线浏览器事件的误区

跟踪离线使用情况显而易见的解决方案是为 onlineoffline 事件( 许多浏览器支持),并将您的分析数据跟踪 逻辑。遗憾的是,这种方法存在一些问题和限制 方法:

  • 一般来说,跟踪每个网络连接状态事件可能过多, 在以隐私保护为中心的时代,应尽可能少用数据,会适得其反 。此外,onlineoffline 事件可能会在 网络丢失,用户可能根本看不到或注意到这一点。
  • 对线下活动的分析跟踪永远无法到达分析服务器,因为 用户处于离线状态
  • 当用户离线时在本地跟踪时间戳,并将离线活动发送到 分析服务器在用户恢复在线状态时取决于该用户再次访问您的网站。 如果用户由于缺少离线模式而离开您的网站且从未重新访问,那么您 没办法跟踪跟踪线下访问者流失情况对于构建 网站需要更好的离线模式的案例。
  • online 事件不是很可靠,因为它 只知道网络访问, 而不是互联网访问。因此,用户可能仍然处于离线状态,且发送跟踪 ping 可以 也仍然会失败
  • 即使用户处于离线状态时仍然停留在当前页面上, Google Analytics 事件(例如滚动事件、点击等)也会被跟踪, 相关而实用的信息
  • 离线本身通常也没什么意义。作为网站开发者 更重要的是要知道哪些类型的资源会加载失败。这与 在 SPA 中,网络连接断开可能不会导致浏览器离线 错误网页(用户能理解),但更有可能随机显示网页的随机动态部分失败 无声地。

您仍然可以使用此解决方案来对离线使用情况有基本的了解, 缺点和限制需要仔细考虑。

更好的方法:Service Worker

事实证明,启用离线模式的解决方案是更好的离线跟踪解决方案 。其基本思路是,只要用户处于离线状态,系统就会将分析 ping 存储到 IndexedDB 中, 并在用户重新联网时重新发送这些邮件对于 Google Analytics,我们已经提供 现成可用的工作区, 但请注意,发送的匹配数 推迟了 4 小时 可能无法得到处理。形式最简单的服务可以在基于 Workbox 的服务中激活 worker:

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

googleAnalytics.initialize();

这样就能在离线状态下跟踪所有现有事件和网页浏览 ping,但您不会知道 它们是离线发生的(因为它们只是按原样重放)。为此 您可以使用 Workbox 方法是使用自定义维度(代码中的 cd1)向分析 ping 添加 offline 标记。 示例如下):

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

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

如果用户由于离线而离开页面,而未连接互联网,该怎么办? 返回?尽管这通常会使 Service Worker 进入休眠状态(因为它无法发送数据 重新连接时),Workbox Google Analytics 模块将使用后台同步 API:将分析数据发送到 数据,即使用户关闭标签页或浏览器也是如此。

但这也有一个缺点:虽然这使得现有跟踪能够离线进行,但您最有可能 您只有在实现基本离线模式后才能看到传入的相关数据。用户仍然会 在连接中断时迅速离开您的网站。但现在,您至少可以测量 量化衡量方式,方法是比较离线用户的平均会话时长和用户互动度 与常规用户进行比较

SPA 和延迟加载

如果用户访问某个采用多页网站形式的网页,但在离线状态下尝试进行浏览,那么浏览器的 系统会显示默认的离线页面,帮助用户了解所发生的情况。然而,构建为 单页应用的工作方式有所不同用户未离开页面,又看到新内容 通过 AJAX 动态加载,无需进行任何浏览器导航。用户看不到浏览器错误 页面。相反,网页的动态部分会呈现存在错误的内容, 或停止动态化。

在多页网站中,也可能会因延迟加载而产生类似的效果。例如, 初始加载是在线进行的,但用户在滚动之前就下线了。所有延迟加载的内容 非首屏将会失效且缺失。

因为这些情况会让用户感到非常烦恼,因此跟踪它们是明智之举。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。 同样,请确保缓冲 Service Worker 中离线发生的分析请求。如 请初始化内置 Google Analytics 的 workbox-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 缓存和错误处理,使页面更可靠 在网络条件不稳定的情况下仍然非常可靠。

后续步骤

本文介绍了跟踪离线使用情况的不同方法及其优缺点。 虽然这有助于量化您有多少用户由于离线而遇到问题, 这仍然仅仅是一个开始只要您的网站未提供完善的离线模式 显然在分析中,离线使用的情况不多

我们建议实施全面的跟踪,然后在 关注跟踪编号。先从简单的离线错误页面开始 - 使用 只需简单操作, 正确做法 都应该被视为类似于自定义 404 网页的用户体验最佳做法。然后,按自己的方式工作 向更高级的线下后备广告 最后才是真正的离线内容。确保投放广告并向用户说明这一点 而且您会发现使用量也在不断增加。毕竟,每个人都会偶尔处于离线状态。

请参阅如何报告指标并打造效果文化跨部门修复网站速度一文,了解相关技巧 说服跨职能利益相关方对您的网站投入更多资金。虽然这些帖子 注重效果,应该可以帮助您大致了解应该如何吸引 相关方。

主打照片,由 JC GellidonUnsplash 用户上传。