如何跟踪网站的离线使用情况,以便阐明您的网站为何需要更好的离线体验。
本文将向您介绍如何跟踪网站的离线使用情况,以帮助您了解 网站需要更好的离线模式。还说明了在实施代码时要避免的陷阱和问题 离线使用情况分析
在线和离线浏览器事件的误区
跟踪离线使用情况显而易见的解决方案是为
online
和
offline
事件(
许多浏览器支持),并将您的分析数据跟踪
逻辑。遗憾的是,这种方法存在一些问题和限制
方法:
- 一般来说,跟踪每个网络连接状态事件可能过多,
在以隐私保护为中心的时代,应尽可能少用数据,会适得其反
。此外,
online
和offline
事件可能会在 网络丢失,用户可能根本看不到或注意到这一点。 - 对线下活动的分析跟踪永远无法到达分析服务器,因为 用户处于离线状态
- 当用户离线时在本地跟踪时间戳,并将离线活动发送到 分析服务器在用户恢复在线状态时取决于该用户再次访问您的网站。 如果用户由于缺少离线模式而离开您的网站且从未重新访问,那么您 没办法跟踪跟踪线下访问者流失情况对于构建 网站需要更好的离线模式的案例。
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 Gellidon 在 Unsplash 用户上传。