什么是数字体验监测？如何从外部观察客户旅程

您的正常运行监控报告为100%。您的服务器响应时间为180毫秒。但自周二早上以来，订单下降了30%。

数字体验监控（DEM）就是为这种情况而存在。服务器端指标确认您的基础设施接通了电话，但它们无法说明法兰克福的某个购物者是否真的能在一部中端安卓手机上，通过一个支付按钮前面有慢速支付脚本的结账流程。

关于这一主题的大多数指南都将 DEM 定义为 IT 团队监控员工笔记本和 VPN 通道。这篇指南涵盖另一种版本：监控产生收入的面向客户的旅程。量测 DEM 什么，每个数据源在哪儿看不见，如何在真实店铺设置，以及哪种 Dotcom-Monitor 检测覆盖每种失败。

本指南内容

• 什么是数字体验监控？
• 为什么您的仪表盘显示正常运行而结账却出错
• 合成监控 vs. RUM vs. 网络路径分析
• 收入路径应测量内容
• 四种正常运行监控漏检的故障
• 如何设置数字体验监控
• 如何选择数字体验监控工具
• Dotcom-Monitor 如何处理数字体验监控
• 数字体验监控常见问题解答
• 总结

什么是数字体验监控？

数字体验监控是衡量用户如何从头到尾体验您的网站或应用的实践，涵盖用户所用的网络、浏览器和设备。它不问“服务器是否响应”而问“用户是否能完成他们来的目的，以及用了多长时间”。这种测量可以来自真实会话、按计划运行的脚本旅程，或两者兼有。

其范围比正常运行监控更广。DEM 监控页面渲染、多步骤交易如搜索和结账、这些步骤背后的 API、第三方脚本，以及它们如何因地区、浏览器和连接速度而异。相同实践有时被称为终端用户体验监控、应用体验监控或数字体验管理。名词不同，测量内容大体一致。

两种 DEM 类型及为何容易混淆

搜索这一术语，首页大多偏向网络和安全供应商：Palo Alto Networks、Fortinet、Cloudflare、ThousandEyes、Tanium。他们描述的多是面向员工的，监控终端健康、SASE 隧道和远程员工笔记本与 Microsoft 365 之间的路径。一些覆盖客户流量，但结果顶部的定义偏重于员工端。

这是真实类别，解决真实问题。但这不是电商或数字运营团队面临的问题。

面向客户的版本则是向外看的。您的用户是不属于您控制网络上的陌生人，使用您未配置的设备，他们离开时不会提交工单。没人会升级一个损坏的促销代码字段，用户会直接去竞争对手那里。

员工 DEM 回答“为什么 Sarah 的 Zoom 通话卡顿”。客户 DEM 回答“为什么昨晚巴西的购物车完成率下降了18%”。同一缩写，不同工具，不同负责人。

本指南剩余内容聚焦第二种。

为什么您的仪表盘显示正常运行而结账却出错

三种常见设置都朝同一方向失败，而且失败时没有明显提示。

正常运行 ping 检测错了内容。主页的 HTTP 检测确认一个 URL 返回 200。结账页可能返回一个 200，但是页面内渲染了“我们无法处理您的付款”信息。状态码不会反映内容质量。

服务器端指标只监控到边缘。应用响应时间、CPU 和错误率描述的是您的基础设施情况，不包含 DNS 解析、TLS 握手、CDN 边缘行为、第三方标签执行，或者移动端阻塞主线程2.8秒的聊天插件。

真实用户监控有存活偏差问题。 真实用户监控来自页面内 JavaScript 信标收集数据。仅报告页面加载且信标触发的会话。遭遇 DNS 失败、CDN 403 或 TLS 错误的用户根本加载不了信标，因此不会报告数据。最严重的故障反而产生最少的 RUM 数据，流量静默消失看起来像是销售淡季。

检测速度加剧了以上三个问题。很多真实故障时间短，而短暂故障最不易被仪表盘捕捉。如果检测每五分钟一次，一次四分钟的故障可能在两次检测之间发生并结束，除了少了的订单外毫无痕迹。

弥合这三方面缺口需要三个条件：从您基础设施外部监测、在真实浏览器中渲染，并根据页面内容判断结果而非状态码。这正是合成监控所做，也将是本指南后续步骤。

合成监控 vs. RUM vs. 网络路径分析

分析师一般将 DEM 分成三个输入部分。它们之间有重叠，各自在某些方面存在盲点。

合成监控和 RUM 是大多数团队实际运行的组合。合成监控提供稳定信号，不依赖有人在线购物。RUM 显示真实受众的样貌。用合成监控检测并报警，用 RUM 确定修复优先级。

Dotcom-Monitor 覆盖的是第一和第三行。Web 应用监控运行脚本浏览器流程，Internet Infrastructure 检测处理 DNS、TLS 和其下层网络相关部分。不收集 RUM 实时数据，若需用户会话层分析，需配合 RUM 工具。

合成监控自身的限制是它只认您编写的旅程。若无人编写访客结账脚本，该流程故障可持续数周。

收入路径应测量内容

从旅程开始，而非指标列表。对大多数电商和 SaaS 站点，四条路径几乎承载全部风险：搜索、加入购物车、结账和登录。

对这些路径，请追踪：

• 步骤级成功率。每一步是否完成，页面是否包含应有文本？确认号码比状态码信号更优。在 EveryStep 中，这是附加在每一步的内容断言，可检测文本、元素、HTTP 状态、响应头或 JSON 负载。
• 步骤级耗时。整体时长掩盖问题。您希望看到“应用促销码”由400毫秒飙升至9秒，其他步骤保持稳定。EveryStep 的脚本时间监测器为每步设定阈值，使该步单独失败，而不是在整体过关的旅程中消失。
• 核心网页性能指标。包括最大内容绘制、交互到下一绘制和累计布局偏移，对转化页测量，而非仅主页。网页监控报告每页数据及元素瀑布图。
• 首字节时间。区分获取第一响应的延迟（涵盖 DNS、TLS、重定向、CDN 边缘表现和源站延迟）与之后的渲染工作。首字节快而页面慢即前端问题。
• 第三方元素时序。支付提供商、标签管理器、聊天插件、评价平台、广告像素。第三方内容监控至关重要，因为这些是无法修补只能绕开的资源。瀑布图中每个第三方请求为一独立条目，让您看出哪个厂商本月多耗时900毫秒。还要监控第三方域名：支付网关证书过期致使结账完全失效，与您自身故障无异。
• API 响应时间与正确性。库存、价格、税费、配送和支付调用支撑每个漏斗步骤。Web Services 检测直接访问端点并断言响应体，能在坏负载到达页面前捕获异常。
• 证书和 DNS 健康。支付子域证书过期导致结账完全宕机，用SSL 证书监控和DNS 监控配合浏览器检测，完全可预防。
• 地域差异。分别来自芝加哥、伦敦、新加坡的同一页面。地域差异多指向 CDN 或 DNS 问题，而非应用原因。这也是 Dotcom-Monitor 会从30多个全球位置运行相同脚本的原因。

四种正常运行监控漏检的故障

它们都会留下正常运行绿灯仪表盘。

1. 200 OK 错误页面

卡处理器修改了 API 协议。您的结账步骤捕获异常，渲染一条“出了点问题，请重试”的友好提示，并返回 HTTP 200。网络上所有正常运行检测报告网站正常，订单却停止。

解决方法是内容断言：脚本旅程必须找到订单确认号，否则该步骤失败。

捕获工具：带确认步骤内容断言的 Web Applications (UserView) 检测。EveryStep 验证实际渲染文本，即便服务器返回200，“出现问题”信息也会导致检测失败。

2. 只影响移动端的第三方脚本

市场团队添加了个个性化标签。桌面端几乎无感。在限速移动网络上，支付按钮可交互时间延长3秒，导致移动端转化下降而桌面正常。发布是通过标签管理器非发布版本，没人察觉长达一周。

同一脚本在40+移动浏览器和设备及桌面上运行，能当天显现差异。这也是用于转化率优化的浏览器监控常出现在漏斗复盘的原因。

捕获工具：EveryStep 脚本在桌面和移动端对比分析。按步骤时长对比发现标签导致的单一步骤变慢，而非笼统“移动端感觉慢”。

3. 区域性 CDN 或 DNS 故障

CDN 配置推送破坏一个分发点。圣保罗的客户收到边缘 403，页面无 JavaScript 加载。您的 RUM 数据流量未下降，只是不再收到巴西游客会话，看起来像流量淡日。

圣保罗监测节点在首个检测点失败。此为全球监测网络胜于单一云区域检测的理由。

捕获工具：从30+地点运行旅程，失败时视频同步瀑布图。让您看到巴西游客看到的403页面和产生该响应的请求，而非事后三天才收到工单。

4. 退化但不失败的 API

配送费服务响应时间从300毫秒变成11秒。它从不返回错误，因此错误率告警保持沉默。用户到达配送步骤后看着转圈然后放弃。

捕获工具：针对配送费端点的 Web Services (WebView) 检测，带响应时间阈值和返回 JSON 断言。直接在 API 层触发告警，无需等浏览器旅程超时。

如何设置数字体验监控

此顺序适用于从无到有设立，或为已有正常运行监控添加深度。

步骤1：绘制产生收入的旅程。查看漏斗报告，列出实际客户走的三至五条路径：搜索、加入购物车、访客结账、账号结账、登录。写下每条路径的精准成功条件。

步骤2：录制每个旅程为脚本事务。用 EveryStep Web Recorder 点击一次路径，它捕捉点击、表单填写、导航和等待，包括下拉、弹窗、AJAX 加载内容和 iframe。无需写选择器。针对特殊情况主动处理：cookie 横幅、动态元素ID、一时密码、测试支付方式且不产生真实订单。给脚本独立测试账号及库存安全SKU。此为网页事务监控的用途。

步骤3：为每一步添加断言。每步验证只有成功才出现的文本或元素：“订单确认”，“确认号”，购物车小计等与商品价格一致。EveryStep 也可断言 HTTP 状态、响应头和 JSON 负载，能在页面渲染错误前就捕获坏 API 响应。无断言即是回到检测状态码。

步骤4：选择符合流量特征的地点和设备。凭分析选出顶级地区作为监控点，不从服务器所在地点随意测。Dotcom-Monitor 提供30+地点、40+移动浏览器及设备，挑选真实受众匹配的三四个地点，并至少包含一个限速移动配置。您监控频率和位置应反映真实客户分布。

步骤5：按照收入影响设置监控频率。结账页应比招聘页面检测更频繁。完整交易脚本运行成本高于单页检测，应预算优先投入订单高峰处。

步骤6：监控底层服务。添加关键漏斗依赖 API 检测，加上 DNS、TLS 证书及支付路径相关伙伴端点。API 监控的响应断言能捕获浏览器旅程后续才显露的性能降低。

步骤7：将告警路由给可处理人员。故障发生先在第二地点确认，避免本地网络噪声虚假告警。确保第二地点在同区域，跨洲检测会压制区域性故障告警。Dotcom-Monitor 的告警规则自动处理阈值和确认逻辑，原生推送 PagerDuty、Slack 和 Teams，确保结账故障快速通知可回滚发布的人员。

步骤8：定期查阅瀑布图。每周打开最慢旅程的瀑布图查看变化。第三方资源缓慢增加且不发通知。失败时瀑布图配视频回放，大约十秒内解答“客户实际看到了什么”。解读瀑布图能将“慢”变成具体修复请求，公开仪表盘及邮件报告将同样数据展示给关注转化的人。

如何选择数字体验监控工具

大多数厂商会给您看仪表盘，能通过以下问题的少之又少。

• 是否运行真实浏览器？仅 HTTP 级检测无法执行 JavaScript，漏掉现代店铺初始响应后的所有操作。
• 编写多步骤旅程脚本难度如何？若结账脚本开发费两天，购物车页换版时没人维护。
• 支持在哪些地点测试？数节点总数不重要，关键是有与您客户匹配的节点。北美二十个节点对欧洲发版无用。
• 能否断言内容而非仅状态？这是事务监控区别于普通 ping 的分水岭。
• 失败时提供根因数据吗？瀑布图、失败时刻截图、失败元素。仅报“结账失败”的警报让调查从零开始。
• 适配您的事件处理流程吗？发送 PagerDuty、Slack、Teams、短信或 webhook 的告警会被处理。停留在无人打开的仪表盘的告警不会。
• 能触达内部或预发布环境吗？预生产和防火墙内的应用需网络内私有代理。
• 增加旅程时定价如何？按步骤或运行计费会惩罚您开深度旅程监控的需求。

Dotcom-Monitor 如何处理数字体验监控

Dotcom-Monitor 覆盖 DEM 的合成部分，也就是上述所有问题的检测层。四种设备类型映射到客户旅程层级，大多数店铺使用全部四种。

旅程在EveryStep Web Recorder中录制为点点点击捕获，非手写选择器，随后在40+移动浏览器及设备，30+全球监控节点回放。逐步阈值捕捉变慢步骤，内容断言识别看似正常实则异常步骤。私有代理可针对预发布或防火墙内应用执行相同检测，有助捕获结账发布前的故障。

需说明两点。Dotcom-Monitor 是合成平台，不收集 RUM 现场数据，若需会话分析请配合 RUM 工具。它也非 APM，不定位哪行代码出错，只告知哪个步骤失效。双重需求团队通常同时运行零售与电商监控与内部 APM，将合成层视为外部早期预警。

总结

数字体验监控弥合了“我们的服务器在线”与“我们的客户可以买到货”之间的差距。您因性能问题流失的大部分收入藏在这段缝隙里：200 OK 错误页面、只伤害移动端的第三方脚本、RUM 看不见的区域 CDN 故障，以及不报错却退化的 API。

不需庞大计划即可起步。挑选最高价值旅程，在 EveryStep 为每步加断言，从客户集中地区三个节点运行，告警直达可处理人员。此检测能捕获现仪表盘隐藏的失败。

运行一周正常后，录制下一个旅程，重复执行。大部分团队用三四轮覆盖完整漏斗。

数字体验监控常见问题解答