四步打造数据驱动体验度量体系

原创 精选
开发
在收集大量企业和品牌的痛点诉求后,基于多个项目实践经验,我们打造出了一套以数据驱动的体验度量解决方案,旨在解决企业以下体验问题。

作者 | TWInsights 

体验度量的趋势洞见

在过往与企业进行体验优化项目合作时,我们发现企业就如何验收并解读结果常常存在诸多困扰。此外,多数企业也错误认为体验度量只能作为后验数据存在,具备滞后性。然而,正如有长远目标牵引和完善业务度量的企业更具生命力,品牌和企业的体验如能兼具明确的策略和体系化的度量框架,自然也更易在“体验制胜”的大环境下构筑壁垒。

作为一个相对新兴的概念,大多企业对体验度量的认知仅停留于NPS(净推荐值)分析的阶段。诚然NPS能够较好反映用户对产品体验的整体感受,但其却不能作为一个良好的问题定位工具。此外,NPS在数据回收中往往存在幸存者偏差,导致我们难以获取到不愿提供反馈的用户群体对产品的体验感受。因此,为了能够更客观、全面、持续和精准的了解和洞见用户体验(建议回顾上期​​数据驱动体验度量的挑战与思考​​),在收集大量企业和品牌的痛点诉求后,基于多个项目实践经验,我们打造出了一套以数据驱动的体验度量解决方案,旨在解决企业以下体验问题:

  • 如何以业务目标为驱动定义和搭建完整的体验度量体系
  • 如何在缺乏统一标准的语境下明确体验指标的好坏与否
  • 如何通过度量结果了解和洞察指标背后的根因并提炼改进方案
  • 如何对改进方案进行快速验证与分析

四步打造数据驱动体验度量

图1:四步打造数据驱动体验度量

数据驱动体验度量之度量体系搭建

在搭建体验指标体系前,我们的首要任务是明确品牌和企业独特的体验策略:一个与企业长期愿景、品牌形象、企业文化相吻合的体验策略。在此基础下,拆解并定义最符合品牌当下阶段的体验指标。不同于我们常见的财务指标和运营指标,体验度量体系是动态的,它需要伴随品牌和企业商业目标的迭代、受众喜好的变迁、科技发展等因素进行不断的调整。

数据驱动体验度量之体系搭建三部曲

常见的体验指标体系搭建,不是自上而下即是自下而上。然而体验本身既关乎用户整体感知,又在意细节感受。因此在实践中,我们通常采用结合模式:先自上而下,以北极星指标出发轻量级拆解体验维度;后自下而上的关注细节感受,向上总结和调整体验维度。

指标拆解方式-自上而下与自下而上的结合

图2:指标拆解方式-自上而下与自下而上的结合

第一部曲 - 基于业务目标定义体验北极星指标

体验为因,而业务为果。作为业务目标外化到用户可感知层的体现,体验北极星指标(即反映体验目标的唯一关键指标)的定义通常需要借助业务指标进行明确。常见的定义方式是通过业务目标分化出最具代表性的体验指标,例如常见的NPS(净推荐值)、CSI(用户满意度指数)。甚至我们可以直接将业务目标与体验指标画上等号,通过忠诚度、复购率等进行整体监控。

第二部曲 - 体验维度的拆解

北极星指标作为体验整体结果反映的第一要素,更强调与业务目标的相关性。为了获取用户更全面的感受,则需要对体验进行多维度的拆建和细化。我们基于多年经验总结了以下两种维度拆解方式:

  • 已有模型的优化:在资源、时间有限且体验要求趋同的情况下,我们可以基于已有模型进行变形和拆解。业内有不少头部公司基于自身业务推出了普适性较强的体验维度模型:例如UES模型,是阿里云产品设计中心推出的B段技术类体验模型;Google推出的HEART模型,则面向C端产品的初期阶段。因此我们可以从北极星指标入手,寻找较为适合当前业务现状的度量模型,并对其进行拆解重构。通过去掉对体验目标影响权重较小的指标,加入对体验目标影响权重较大的指标,确保指标的全面性、完整性、客观性,从而构建适合自己产品的体验度量指标体系。
  • 构建自有模型:在产品具备更明确和独特体验策略的情况下,仅基于市面已有模型进行优化往往不能凸显产品希望突出的体验特质。我们需要更深入的分析,提炼该产品独有的体验维度模型。可以通过体系化的用户原声调研、专家走访以及团队设计和体验目标回顾,总结体验的核心维度;抑或是基于产品属性和用户需求类型从更学术的视角进行拆解。

第三步 - 指标的具体落地与拆解

指标拆解是数据驱动体验度量有别于传统主观用户评分和可用性测试的核心差异点。相较通过用户或专家主观评分总结各维度得分的度量方式,数据驱动体验度量体系更重视如何通过用户行为、消费和产品使用等客观数据,推测和判断用户的体验感受。

在落地指标拆解上,我们通常带着既已明确的体验维度,实现对功能、场景、旅程和事物项具体指标的层层拆解:从核心场景入手,通过场景分解、旅程拆解与事务项解构保证指标体系的层层细化,以此确保不同业务层级与指标的关系映射。当上层指标不理想,亦可通过下钻的方式明确潜在的根因。

指标层层拆解逻辑

图3:指标层层拆解逻辑

最底层体验指标的拆解总是从一个旅程的事物项起步,结合维度模型与GSM(Goal目标-Signal信号-Metric指标)明确详细指标。另一方面,我们也会使用MOT的方式,通过明确体验的核心关键点,定义关键指标,抽象额外的体验维度。

数据驱动体验度量之指标结果评估标准

一个完整的度量体系往往具备四个要素:策略、维度、指标,以及合理的评价标准。当我们获取指标结果以后,往往需要通过对标了解现实与期待的差距,并明确提升的方向。然而每个企业就体验度量体系搭建的方式不同(例如:使用NPS的企业难以直接与使用HEART模型的企业进行对比),体验拆分维度不同( 希望突出安全感体验的企业,也许不在乎品牌未来感的凸显),往往导致难以建立行业标准或者直接进行竞对比较。

基于现状,我们将指标结果解读的方式分为了“与别人比”和“与自己比”两大类。

建立评估标准的两个大方向

图4:建立评估标准的两个大方向

  • 与别人比 - 参考行业相对成熟和统一的标准:虽然指标体系的构建不同,希望突出的体验核心点也大相径庭。但涉及关乎性能、体验界约定俗成的交互原则、以及通用运营的相关指标,往往会采用统一而客观的度量方式,因此具备较强的可比性。常见的指标有:页面加载时长、信息查找的步长、流失率等。
  • 与自己比 - 通过业务目标树立评估标准:根据部门业务目标制定针对体验和功能的指标要求。常见于与业务绩效(有助于产生直接经济收益)直接挂钩的体验指标,例如功能使用率、功能使用时长、或者服务推荐接受率等。基于业务目标建立的指标好坏标准,往往与产品/功能所处的阶段以及企业整体的业务目标具备强相关性。例如在功能上线的初期,会更关注于使用率,而成熟期更聚焦使用时长。至于具体的目标数值,通常由整体业务目标拆解和测算形成。因此可以与部门制定的目标进行直接对比。
  • 与自己比 - 按照指标结果进行描述性统计分析:反映功能/产品体验关键点的指标往往因为品牌希望突出的体验维度而具备特异性,因此难以进行行业与竞对比较;而又因该类指标直接或间接反映产品/功能用户体验(例如:搜索成本、决策成本),作为影响业务指标的原因(决策成本高导致功能使用率低),我们也不能直接通过业务目标进行映射。因此我们通过结果数据的统计分析,依据百分位进行指标好坏与否的划定(例如:Top 30%定义为优秀)。

数据驱动体验度量之指标结果根因分析

当我们定义了指标结果的好坏与否以后,接下来就是整个度量体验搭建意义所在:如何通过指标结果了解造成用户体验不理想的根因,并做出体验甚至产品的优化和改善方案。

基于过往丰富的项目经验,我们总结出了根因分析的三种方式,适用于数据指标体验搭建的不同阶段。

不同阶段的指标根因分析方法

图5:不同阶段的指标根因分析方法

阶段一:指标体验搭建的初期 - 指标间的结合解读

在结合解读之前,必须充分明确单一指标的涵义和指代;接下来则通过漏斗指标、路径指标和功能指标的结合分析,通过逐步下钻的方式了解更宏观指标表现不好的根因。此外,指标之间的逻辑关系( 因果关系或者共同作用的关系)也可以进行结合解读:通常情况下,功能体验指标会是功能业务指标不理想的潜在因素。例如功能的易用性会极大程度的影响功能的留存率。在数据指标有限的情况下,多渠道的VOC分析也是帮助品牌和企业更好的理解用户的情绪倾向,收集具体的描述性反馈的重要方式。

阶段二 - 指标体验搭建的成长期 - 根因排除法

在积累一定产品体验分析的经验后,可以尝试针对产品核心场景或者体验关注点进行详细和全面的潜在影响因素分析。通过数据埋点对潜在根因进行刻画,最后通过回收的数据反映和筛选出影响体验结果的核心因素。

在我们总结的解决方案中,根因排除法通常存在通用与具体的两个观测维度。在通用维度,可以依据四象限分析法,快速定位功能潜在的问题方向:用户需求不成立、功能体验不好、功能因为设计不周导致用户难以触达。通过快速定位,提高根因分析效率。

根因排除法:通用维度分析方式

图6:根因排除法:通用维度分析方式

而具体观测,则需要像构建实验一样建立假设并验证假设,涉及更多的领域经验和分析过程。 通过穷尽体验不理想可能的潜在假设因素,利用数据指标刻画假设因素,最后通过回收数据验证假设。例如在过往项目中,我们为了判断某地点导航偏航率高居不下的原因时,便基于核心因素拆解法将潜在根因归结于:车主因素、功能因素、路段因素、路况因素、天气因素等,并通过数据指标刻画这些因素,最终锁定了体验异常的根因。

阶段三 - 指标体验搭建的成长期 - 因素相关性分析

随着产品数据指标的丰富,我们可以针对性的搭建数据标签体系,实现更广义的根因分析。传统的埋点数据项目更多基于事件与实体的属性进行相关性分析,常见的属性标签有用户标签或者应用标签。为了更深入探究指标的根因,我们的方法论期待去还原一个事件或者指标发生时的具体场景,通过5W+1H的事件还原法清晰的观测事件全貌以及事件发生的前因后果,进行根因的相关性分析。甚至可以通过全方位的数据分析,剖析用户群体、产品适用场景、以及产品创新方向的探索。为此我们构建了根因分析的双转模型,保证分析的成果的同时,注重分析的效率。

因素分析法的双钻模型:通过发散和收敛进行因素类型的明确 - 可控因素(例如功能、内容)和不可控因素(用户与环境),相关因素和潜在因素,最终形成改进的方案与方向:

因素相关性分析:双钻模型

图7:因素相关性分析:双钻模型

  • 第一次发散收敛 - Pareto Principle:通过纯工具手段,以求全的方式通过对变量进行全量分析。一方面可以通过标准化的流程和工具降低对相关领域的知识经验要求,另一方面避免遗漏具备创新价值但是反常识的关联因素。通过纯数理的方式,利用20%的事件获取80%高潜的相关因素
  • 第二次发散收敛 - 传统科研分析方式:基于第一阶段获取的核心相关因素作为基本输入,进行假设建立和迭代实验。通过实验性地加入一些经验判断认为有价值的可控因素和不可控因素进行回归分析,了解影响因素对指标结果是否确有影响以及影响大小,从而明确方案改善的优先级。

改进方案评估与快速验证

当我们根据根因分析结果输出体验改进方案后,需要对体验改进方案进行评估和快速验证。结合我们的项目经验,对体验改进方案的评估主要有竞品对比分析、可用性测试、灰度测试、ABTesting。对于产品体验改进方案的评估需要根据不同的产品阶段,来采用不同的方法。

原型与上线阶段的改进方案评估方式

图8:原型与上线阶段的改进方案评估方式

在产品原型阶段,通常采用竞品体验对比分析和可用性测试来评估。

竞品体验对比分析主要是依据产品体验五要素,对产品体验从战略层到表现层依次对比分析。另外在功能交互等子维度则可以通过用户视角、业务视角等多角度打分评估,评估出体验改进方案对比竞品的优劣势,找出需要提高的地方并加以完善。

可用性测试主要是通过实验法和分析法,快速找到影响产品有效性、使用效率、满意度的关键影响点。其中实验法主要是通过用户测试获得,分析法主要通过行为分析、认知分析等获得。竞品体验对比分析和可用性测试都可在方案原型阶段使用,但竞品体验对比分析更偏重主观分析,而采用实验法获得的可用性测试结论,更偏重于用户真实反馈。

当体验改进方案已发布上线,通常采用灰度测试和ABtest来进行评估。

灰度测试通常是在新产品功能上线时,对部分用户开放测试,让部分用户直接使用,确认没有问题后再开放给所有用户,其目的一般在验证方案的可用性和正确性,确定产品功能是否能全面推广上线。它对产品的规模要求不高,在产品已上线单位全部发布时可以使用。

ABtesting在整个产品的周期都会使用,主要是因为其本质是通过控制变量法,获取产品变动对产品关键数据指标的影响。通常在体验方案上线前,需要将用户根据需要进行分组,给不同分组的用户不同的方案,在上线后根据不同分组的数据对比,获取各分组方案优劣反馈,然后将数据最优的方案推到全量用户。其目的是通过真实实验获取方案最优数据,进而来获取最佳方案。灰度测试和ABtest都可用于获取方案客观的评估数据,但ABtest对用户属性和数量有较高要求,对实验用户量有较高要求,适合用户体量大,个性化需求多的场景,而灰度测试则对用户属性和用户量要求不高,适用性较强。

最后

随着越来越多的企业关注产品体验的持续优化、管理与创新,我们希望这套数据驱动的体验度量体系能够协助企业有章法、有依据地进行体验策略的制定,体验度量体系的搭建,基于结果分析的体验优化与产品创新。在这个以体验作为核心竞争力的商业环境下,通过体验度量、体验管理和体验优化的闭环,打造持续提升的竞争优势。

责任编辑:赵宁宁 来源: 51CTO
相关推荐

2017-11-10 09:51:23

2022-12-09 11:23:21

2022-11-02 13:16:58

数据分析

2020-02-05 08:47:31

数据科学编程数据库

2012-07-20 09:41:41

IT系统云计算架构

2021-07-26 09:35:26

SQL数据库优化

2010-11-19 15:44:04

IT跳槽

2011-07-07 13:09:04

编程

2017-04-17 12:31:45

SDN网络虚拟化

2010-04-20 10:12:05

2010-06-02 17:29:02

svnserve服务

2011-04-21 14:16:57

笔记本苹果Win7

2010-04-28 12:02:37

Forefront网络优化

2010-06-13 14:19:40

学习UML

2010-09-14 17:35:52

2010-09-06 11:58:39

ppp拨号Linux

2010-06-12 13:49:16

学习UML

2021-11-23 23:43:16

MySQL数据库Docker

2009-07-09 15:41:15

JDBC连接MySQL

2010-06-02 18:22:43

SVN本地设置
点赞
收藏

51CTO技术栈公众号