4种操作轨迹设计

日志的记录顺序为首先记录登录日志，然后记录操作日志，最后记录退出日志，这样才能形成完整的用户行为时间轴，如图6-5所示。操作日志属于数据量最大、可分析利用的空间也最大的一部分内容，经常与埋点分析相互结合使用。

图6-5 日志的记录顺序

用户在登录进入系统后，所产生的所有行为都可以称为操作日志。例如，进入了哪个菜单、使用了哪个功能、点击了哪个按钮，甚至是操作了哪条数据、数据前后发生了什么变化。

系统、菜单、功能和页面的关系如图6-6所示。一个系统中包含多个菜单，每个菜单中包含多个功能，每个功能又包含多个页面。同时，一个页面可以被多个功能共用，一个功能也可以放入多个菜单中。在这样复杂的关系下，可以将操作日志分为菜单操作日志、功能操作日志、流程操作日志和业务操作日志。对于不同的操作日志，也要采用不同的设计方式。

图6-6 系统、菜单、功能和页面的关系

6.4.1 菜单操作日志设计

菜单操作日志就是记录用户对于系统菜单（包括PC端系统、移动端系统）的使用轨迹，以便于进行指标分析和问题查证。要记录的内容包括当前用户在什么时候、进入了哪个菜单，停留了多长时间。菜单日志记录表的结构如表6-4所示。

表6-4 菜单日志记录表的结构

如表6-4所示，用户姓名和菜单名称字段看似是冗余的，其实对于追查问题的意义很大，能够准确地还原当时的用户操作状态。停留时长可以反映出用户使用某个功能菜单的耗时情况，当用户进行菜单切换时，使用当前的系统时间减去上一次的操作时间即可计算出停留时长。例如，当前时间为11点，而用户上一次切换菜单的时间为10点30分，则可以用11点减去10点30分， 从而得到用户在上一个菜单中停留了30分钟。

通过菜单操作日志可以掌握用户的工作习惯和重点关注内容，以便针对用户的痛点去设计新功能和解决系统问题。

一个系统中往往包括大量的功能菜单，有些功能会经常被使用，而有些功能则很少被使用。这些经常被使用的菜单称为热点菜单，是做性能优化、提升体验的重点。有些企业投入巨大的资源在一些用户并不常用的功能上，这是典型的错误做法。

6.4.2 功能操作日志设计

功能操作日志描述了当前用户在什么时间、哪个页面、使用了哪个功能。例如，用户A在2020年9月30日9点30分20秒，在某宝App的个人余额菜单中使用了余额提现功能。用户B在2020年10月30日9点30分

20秒，在公司财务系统的科目管理菜单中使用了新增财务科目的功能。

一个菜单中往往包含多个功能，因此功能操作日志属于菜单操作日志的下一层。PC端和移动端的区别在于PC端能够承载的内容更多，所以同一个菜单中的功能也就更多。移动端由于显示限制，因此同一个菜单中的功能往往较少，甚至一个菜单项只包含一个功能。功能操作日志记录表的结构如表6-5所示。

表6-5 功能操作日志记录表的结构

如表6-5所示，如果想要记录每个功能的操作日志，则必须要先将功能定义出来（包含功能编码、功能名称、功能描述等），这一般是在权限设计时就确定的，可参见5.7节。

功能与菜单为多对多关系，一个菜单中可以包含多个功能，而一个功能也同样可以在不同的菜单中使用。因此，记录功能操作日志时，必须要记录对应的菜单编码和名称，这样才可以知道，是在哪个菜单中使用了哪个功能。对于同样的功能，在哪个菜单中被使用得最为频繁。

通过功能操作日志也可以统计出用户使用菜单的情况，但是并不能很好地反映出用户进入菜单的时间、停留的时长这些系统关注的内容。所以，设计上不可以用功能操作日志替代菜单操作日志。

6.4.3 流程操作日志设计

对于一些复杂的业务场景，具有较长的操作过程，在这个过程中会包含大量的页面跳转、前进和后退的动作，以及在页面中包含了大量的功能操作。在这种极为复杂的操作环境下可能产生各种意想不到和测试无法覆盖的问题。如果可以记录用户的完整操作过程，就可以更好地帮助系统重现

用户的操作过程。例如，一次支付过程可以记录为表6-6所示的数据。

表6-6 支付流程操作日志示例

如表6-6所示，记录了用户一次完整的支付操作流程，可以将日志转化为流程图展示，如图6-7所示。用户首先进入支付页面，点击“支付”按钮，发现没有绑定银行卡，所以跳转到银行卡绑定页面，在页面中点击“保存”按钮，完成了银行卡绑定，又跳转到支付页面，在支付页面点击“支付”按钮，最后支付成功并跳转到支付成功页面。这样就可以很轻松地重现用户操作，排查系统问题了。

图6-7 支付流程日志转化为流程图

流程操作日志记录表的结构如表6-7所示，用于记录完整的用户操作流程数据。

表6-7 流程操作日志记录表的结构

由于流程操作日志涉及大量的页面跳转及元素操作（点击按钮、滑动、点选等），如果所有的页面动作都实时地调用后端服务接口，就会造成请求量过大，不仅服务端性能无法保障，前端操作也会受到影响。

注意事项如下。

（1）     区分业务重要程度，并不需要在所有页面、所有元素动作上记录日志，而只需专注于重点流程、重点业务场景，这样可以减少日志的存储量。

（2）     对于重点监控内容可以采用前端实时异步上报日志的方式。对于非重点监控内容可以采用定时异步调用，先将用户的操作轨迹信息缓存在本地，再定时异步批量上报给后端服务，每次上报后清空本地缓存即可，从而减少交互次数，提高传输效率。

（3）     采用人工上报日志的方式，在前端设计一个上报日志的功能，在用户登录系统后将所有的操作轨迹缓存在前端，当用户使用发生问题时，由用户主动上报操作日志供开发人员排查问题。这种方式主要用在2B系统中使用。（4）流程操作日志的数据量巨大，可以在用户操作过程中进行轨迹的缓存，在发生异常时自动上报，而业务正常操作完毕时进行清除，无须上报，从而能够达到自动收集问题数据的目的。

6.4.4 业务操作日志设计

业务操作日志往往记录到某一类或某一笔具体业务的数据级别。例如，变更前的数据和变更后的数据，形成数据的对比，也可以用于用户数据的回滚和追查。

由于不同业务的数据结构千差万别，所以很难做到统一的系统设计，往往由某个业务功能独自设计实现。但是，设计思路可以统一为按照事件的记录方式。

任何数据的变化都是由某个事件的触发而改变的。例如，对于某个用户状态的变化可以记录为表6-8所示的数据。

表6-8 用户状态的变化记录示例

一系列的事件导致了用户状态的变化，通过表6-8可以得到清晰的用户状态迁移图，如图6-8所示。

图6-8 用户状态迁移

可以将事件的粒度控制到不同的级别，如果需要更为详细的日志粒度，则只需要把事件定义得更加详细即可。但是，这样也只是知道了事件的发生时间点、顺序对固定状态字段的影响而已，并不知道每个数据内容的变化。

可以建立对应的业务快照表，与具体的操作日志相关联，用于查找每个事件发生时的数据快照。