C端用户体验度量实战篇-京东快递小程序体验度量全面升级

用户,体验,度量,实战篇,京东,快递,程序,全面,升级 · 浏览次数 : 53

小编点评

**度量模型升级** **1. 主观指标研究** - 建立主观指标库 - 筛选指标 **2. 客观指标研究** - 建立客观指标库 - 筛选指标 **3. 指标研究** - 主观赋分度量值 - 客观赋分度量模型 **4. 度量值研究** - 2.0客观指标赋分 - 区间映射法 **5. 结论** - 新升级后的度量模型在实际产品运行的情况 - 以全新的视角让我们看到真实的业务发展情况

正文

本文通过介绍体验度量模型升级研究过程、研究方法及研究结果等内容,结合实际C端产品应用,观测新模型运行周期的表现,验证了其在高速发展的业务形态和日益变化的用户需求上的适用性和有效性。我们从体验价值为导向的底层模型设计,到主客观体验影响因子在实际业务运用的方法,探索出一套切实可行的验证设计价值的体系。通过对体验度量模型不断地调优,不仅能够诊断出过往产品策略和行动是否对用户有效,而且能够前瞻性的预测出未来的体验走势。

一、背景

本次用户体验度量模型3.0是在2.0度量模型基础上进行的全新升级。如果说体验度量模型2.0是让团队共识了体验需要“科学”度量这件事,那么这次体验度量模型3.0则要求模型验证体验的"价值"。

在升级前我们一直在思考这样的问题,如何让度量模型能够更适用于快速发展的业务以及不断变化的用户,能够预判出未来体验趋势。

我们将此次升级体验度量模型的内容完整的分享给正在搭建度量模型或者是想要升级度量模型的设计团队,希望能给大家带来更多的启发。

二、现状问题

过去一段时间里,体验度量模型2.0的内容普适性很好,在物流各个系统运行正常。但由于各条业务线发展不统一,体验度量模型2.0度量出来的内容与日益发展的C端业务系统产生不匹配的情况。为了进一步确认问题,筹备前期我们通盘对度量模型应用在客户端上体验的问题和建议进行搜集。主要涉及三个方面问题:

  • 视角单一,问题不聚焦:原先度量模型业务参与度不高,缺失对指标深刻理解;加上业务高速发展,旧的指标指导实际业务价值不高,导致产品和业务的人员关注度不高;而度量出来的内容又无法聚焦问题。

  • 度量值无基准线参考,分数差异不明显:模型本身度量值无基线值参考,也没有对标值,对当前产品达成好坏情况比较模糊。另外,体验分数档位差距不明显,尤其是10分值小数点后的变化感知度不强,很难直观看出问题所在。

  • 缺少行业视角,标准不明确:对产品所处的行业情况存疑,长期以往则会陷入自我感觉良好而没有真实反映产品竞争力的情况。

基于此,本次模型升级围绕解决问题不聚焦视角单一、度量值无基准参考、度量标准不明确等问题进行。

三、研究目标和方向

根据现有问题找差距,依据差距确立行动目标。

  • 更聚焦问题。确定研究框架,重构研究流程。相较于度量模型2.0,在公司战略“自上而下”视角中业务需要看什么之外,增加“自下而上”可感知的用户视角。

  • 更突显对比。丰富指标,优化度量方式。拆解业现有业务目标,丰富主、客观指标库,严选每个指标及确定各指标基线值和目标值。

  • 更看清差距。优化、引入其他对比维度。从内部自己与自己比变为与外部行业垂类TOP1比。

本次度量模型升级以C端产品为起点,明确度量模型价值,作为过程管理的工具,弥补系统层细节体验缺失问题,快速帮助业务、产品、体验进行决策,达到青出于蓝而胜于蓝的效果。

四、研究框架和过程

在确定行动目标的指引下也确定本次升级主要从四方面进行:维度确定、权重确定、指标确定、度量值确定。

4.1 模型框架

度量模型共五层,第一层为度量分数——体验总分;第二层为权重层,包含主观、客观权重;第三层为主客观对应的维度层;第四层则是对应维度下指标层;第五层则是具体指标赋分情况。

4.2 维度研究

4.2.1 维度研究方法及过程介绍

本次升级对维度研究方法上做了优化。一方面从公司视角“自上而下”,专家意见作为参考深度绑定,对度量模型重新进行打乱和重排。另一方面从用户可感知的“自下而上”出发,结合定性和定量研究,进行用户访谈、重新绘制用户旅程图,进而用因子分析方法确定指标维度。确立好的研究方法之后我们开始重构维度研究。

  • 搭建维度库:在维度研究前期对行业内体验度量维度内容进行了分析和整理,取并集进行总结,搭建出一套完整的维度库。

  • 组建专家组,专家访谈:基于三大职能六个岗位选出资深9位专家成立了专家小组。通过一对一深访确定专家诉求以及未来预期,明确快递小程序体验度量的关注重点及维度。

  • 讨论验证确定维度:本着MECE原则(相互独立,完全穷尽原则)、可度量、可提升三个标准进行维度确定。期间,根据专家组给出的度量结果与维度库结果进行匹配,也是将理论与实际进行结合后输出3套可行方案。我们对每一套方案优势和劣势进行了充分讨论,在经历6轮讨论后最终确定维度方案。

4.2.2 维度研究结果

最终我们得到了功能体验、性能体验、易用体验、情感体验四个维度

  • 功能体验:功能是否完善,基础功能覆盖以及包含用户意图识别的定制化功能

  • 性能体验:产品基础性能、稳定性表现

  • 易用体验:易操作、易学、易查找、清晰可见

  • 情感体验:包含满意度、忠诚度、推荐度,包含用户选择产品的原因

这四个维度基于产品系统本身,从有用的基础的功能体验至卓越的性能体验,直到成为好用的易用体验升华至用户爱用的情感体验。

从最终确定的维度结果上看,相较于之前,维度的内容范围更明确更易懂,最重要的是各方达成统一共识,这一点对于后期度量出来的内容受各方高度关注起到了关键性的作用。

4.3 各维度权重研究

4.3.1 主客观权重、客观各维度权重研究方法

维度确定后,接着就需要对主观权重、客观权重进行确定,以及各维度权重系数进行确认。主客观的权重采用的是AHP层次分析法。具体的定义可参考下面词条的内容,我们重点介绍如何使用的

“AHP层次分析法是一种将定性与定量分析方法相结合的多目标决策分析方法 。该方法的主要思想是通过将复杂问题分解为若干层次和若干因素, 对两两指标之间的重要程度作出比较判断, 建立判断矩阵, 通过计算判断矩阵的最大特征值以及对应特征向量,就可得出不同方案重要性程度的权重, 为最佳方案的选择提供依据。”——引自百度百科

首先建立层次结构模型,其次通过专家重要性比较打分,最终通过软件分析效验计算得出权重系数。

  • 建立层次结构模型:将系统体验度量分解为维度,按照因素间的相互关联影响以及隶属关系将因素按不同的层次聚集组合,形成一个多层次的分析结构模型。例如体验度量分主、客观维度,而客观维度下又是由功能、易用、性能、情感四个因素构成。构建好层次模型后就可以将所有因素放在一起进行两两比较了。

  • 专家重要性比较:组建的9名职能专家组分别对主观维度及客观维度的相对重要性进行了评价。

  • 软件分析效验:按照专家评价结果,通过软件yaahp计算出各维度权重系数。最终专家组针对结果进行讨论,确定权重系数。

通过这样的方法,我们同时确定了主客观权重,以及客观各维度的权重系数。这次主客观权重相较于之前是有变化的,而这种变化的根本原因在于,自上而下对现有产品清晰定位及最终目标导向的结果,可以说是团队共识之后,致力做好用户体验决心的一种体现。另外,客观各维度的权重也会随着产品的发展阶段而进行调整。

4.3.2 主观各维度权重确定

与客观维度确定不同,主观各维度权重的确定采用的是因子分析法(Factor Analysis)。它是一种数据简化的方法,主要用于对一组数据较多而且相互关联的变量进行提炼与概括。因子分析的目的是以尽可能是少的信息损失,把大量相互关联的变量浓缩为少数几个因子,便于对数据的理解和进一步的统计分析。

如果说层次分析法输出的专家组认可的维度,那因子分析获得则是用户可感知到维度。因子分析最难的部分是因子结果可以与层次分析法得到的维度匹配上,在这个阶段中可能需要不断的调整量表、分析结果、检验到再调整、再分析、再检验。因子分析是本次模型升级最大的亮点,它不仅解决旧模型可信度的问题,更重要的是帮助我们看清从用户感知层面评价出来的维度以及对应的权重分配,为后期体验问题的聚焦及决策上提供了支撑依据。

4.4 指标研究

4.4.1 主观指标研究

在主观各维度研究的时候提到构成主观各维度的主观指标,主观指标研究分为两步,先搭建主观指标库,在筛选指标。由于主观指标库是在原有基础上进行的,本次主要从细化指标和扩充维度进行。一方面是按照用户视角,对用户旅程阶段的触点进行细化,另一方面根据业务视角,通过业务的目标拆解进行指标扩充。当有这些指标后,以满意度的方式回收用户反馈,继而对问卷结果进行因子分析,确定最终对整体分数的贡献度情况。

4.4.2 客观指标研究

在客观指标研究上也是先搭建客观指标库,再进行客观指标筛选。客观指标库搭建的原则:业务目标导向、数据质量、产研侧专家评价。在搭建客观指标库时,首要是强绑定业务目标导向,纳入指标库的指标要与业务指标关联紧密。其次指标数据的质量要真实、客观,观测一个好的指标要看过往数据反映问题的情况以及有效的指导一线业务行动。最后也需要产研侧专家筛选最贴近产品实际和目标的客观指标。基于这样三层原则我们搭建出快递小程序客观指标库。在进行客观指标筛选过程中确定筛选指标的四个标准:可衡量用户价值、反映产品策略、指标直观可拆解、与营收相关的先导性指标,最终确定每个维度下的客观指标。当然,过程中也有发现指标应用价值高但数据统计口径有出入的,以及现有指标不满足需求的额外需要新设计指标的情况。

4.5 度量值研究

4.5.1 主观赋分

度量值简单理解就是赋分,主观分数是通过因子分析中用户打分的结果得出分数。

4.5.2 客观赋分

度量模型2.0客观指标赋分采用的是分箱法,选取过去一段时间的数据,查看其最小值、最大值及平均值、中位数的分布情况,进而设定自身的客观评分标准。这种依据数据等频进行的划档赋分,实际得出的分数不够敏锐,看不出来每个指标数据变化的情况。另外,客观赋分延用主观用户打分的十分值,由于之前没有基准线和目标值的对比,加权之后的分数难以直观的暴露问题。这会导致大家容易忽略真实的体验问题。新模型赋分则采用了区间映射法。简单理解,当期要测量值在度量标准区间内完成的情况。我们也是在对比多种赋分方法后发现该种赋分方式最直观、清晰反映数据变化情况。

采用该种赋分方式需要注意两个方面内容。

  • 数据分布要符合正态分布特征:在我们选取的指标中,大部分的数据直接呈现正态分布特征,显著性检验p值大于0.05。而小部分的数据并未呈现这种特征,需要进行数据特定函数关系转化使其呈现正态分布特征。

  • 度量值范围选取2个标准差:我们选取2个标准差的原因一方面是依据正态分布特征,95.45%的数据是在2个标准差范围内,另一方面也是结合实际情况尤其是历史数据变化的覆盖有余,既不好高骛远也能实事求是。

以上是我们升级模型的全过程,那么最后我们介绍下升级后的度量模型在实际产品运行的情况。

五、小结

最后,通过一张全景图我们回顾下度量模型升级的内容。对比旧模型,新的模型在分数映射上更加敏锐,增加双面感知评估框架更科学,丰富后的指标库对问题的洞察更聚焦。

升级后的度量模型在C端产品上已经运转近一年了,它以全新的视角让我们看到了真实的业务发展的情况。在大环境的变化、业务的变化、用户需求变化下,度量出来的内容第一时间能让我们观测到这种变化。既而我们能够有效的抓住时间窗口期,迅速做了响应的策略进行体验改进落地。

作者:京东物流 穆倩雯

来源:京东云开发者社区

与C端用户体验度量实战篇-京东快递小程序体验度量全面升级相似的内容:

C端用户体验度量实战篇-京东快递小程序体验度量全面升级

本文通过介绍体验度量模型升级研究过程、研究方法及研究结果等内容,结合实际C端产品应用,观测新模型运行周期的表现,验证了其在高速发展的业务形态和日益变化的用户需求上的适用性和有效性。

记一次RocketMQ消费非顺序消息引起的线上事故

应用场景 C端用户提交工单、工单创建完成之后、会发布一条工单创建完成的消息事件(异步消息)、MQ消费者收到消息之后、会通知各处理器处理该消息、各处理器处理完后都会发布一条将该工单写入搜索引擎的消息、最终该工单出现在搜索引擎、被工单处理人检索和处理。 事故异常体现 1、异常体现 从工单的流转记录发现、

【交付高质量,用户高增长】-用户增长质量保证方法论

本文基于C端用户拉新的业务场景,以质量保证的全视角,总结了质量保证过程中的框架、策略、流程、规范、方法、工具以及实践,全面阐述了用户增长质量保证的价值观、方法论以及我们所理解的内涵,即高质量=质量策略多样化+质量流程标准化+质量活动规范化+质量工具平台化+质量运营常态化。

[转帖]性能优化经验分享

https://maimai.cn/article/detail?fid=1773648919&efid=5xfDOW5OR3tSS0iyVW2ukA 近期,开发 C 端 h5 页面时,发现首页白屏时间比较长,并且用户也多次反映了这个问题,优化这个首屏加载时间是迟早的事,所以在开始优化前先做一些必要

用Rust手把手编写一个Proxy(代理), 动工

用Rust手把手编写一个Proxy(代理), 动工 项目 ++wmproxy++ gitee 传送门 github 传送门 设计流程图 flowchart LR A[客户端] -->|Http| B[代理端] --> C[代理服务端] --> D[服务端] B -->|直达| D A -->|Htt

基于C#和Blazor开发的前后端分离框架

Known是基于C#和Blazor开发的前后端分离快速开发框架,开箱即用,跨平台,一处代码,多处运行。 [![star](https://gitee.com/known/Known/badge/star.svg?theme=dark)](https://gitee.com/known/Known/s

Blazor前后端框架Known-V1.2.1

# V1.2.1 Known是基于C#和Blazor开发的前后端分离快速开发框架,开箱即用,跨平台,一处代码,多处运行。 - Gitee: [https://gitee.com/known/Known](https://gitee.com/known/Known) - Github:[https:/

Blazor前后端框架Known-V1.2.2

# V1.2.2 Known是基于C#和Blazor开发的前后端分离快速开发框架,开箱即用,跨平台,一处代码,多处运行。 - Gitee: [https://gitee.com/known/Known](https://gitee.com/known/Known) - Github:[https:/

Blazor前后端框架Known-V1.2.3

# V1.2.3 Known是基于C#和Blazor开发的前后端分离快速开发框架,开箱即用,跨平台,一处代码,多处运行。 - Gitee: [https://gitee.com/known/Known](https://gitee.com/known/Known) - Github:[https:/

Blazor前后端框架Known-V1.2.4

# V1.2.4 Known是基于C#和Blazor开发的前后端分离快速开发框架,开箱即用,跨平台,一处代码,多处运行。 - Gitee: [https://gitee.com/known/Known](https://gitee.com/known/Known) - Github:[https:/