查看原文
其他

淘宝用户体验分析方法论

朱琦(拳拳) 大淘宝技术 2024-03-28




本专题共10篇内容,包含淘宝APP基础链路过去一年在用户体验数据科学领域(包括商详、物流、性能、消息、客服、旅程等)一些探索和实践经验,本文为该专题第一篇。

在商详页基于用户动线和VOC挖掘用户决策因子带来浏览体验提升;在物流侧洞察用户求助时间与实际物流停滞时长的关系制订表达策略带来物流产品满意度提升;在性能优化域构建主客观关联模型找到启动时长与负向反馈指标的魔法数字以明确优化目标;构建多源VOC标签体系综合运用用户行为和用户VOC洞察、落地体验优化策略,并总结出一套用户体验分析方法论



背景与现状


存量竞争时代,体验重要性日益提升。来自决策层的声音:“全面提升用户体验”、“把重视客户体验变成发自内心的习惯”、“回到用户最根本的体验指标”突显了提升体验决心。


如何全面、及时和精细化地衡量体验好坏?如何讲清体验好坏和生意的相关性?如何有效地优化体验,优化到什么程度合适?如何验证解决方案的有效性?本文主要介绍数据科学同学在基于产品体验、服务体验、性能体验等项目经验总结出的一套分析框架与方法,可系统、高效地为发现、诊断及推动体验策略优化与落地,供参考学习。


整体分析框架



打一个形象的比喻:数据科学家医生,医生给病人看病,数科给业务看病。用户体验分析过程可抽象为发现问题(体验)、问题诊断(门诊)、策略落地(治疗)、效果验证(复诊)4个步骤。

首先,给病人做一轮初诊/体检,体检报告中身体状态指标可比作用户体验指标;其次,进入门诊阶段医生会基于检查报告中指标异动(如:白细胞偏高)结合病情进行诊断开方子,类似数科运用各种诊断方法进行根因探寻并生成数据策略;再者,病人基于诊断方案进入治疗阶段,可能存在不信任、不配合、未按疗程服药等问题,类似策略落地阶段数科会面对业务支持力度低、跨团队协同困难等问题;最终,一通疗程下来医生需跟踪复诊了解病情是否缓解,类似数科需通过科学地方法(如:AB、因果推断)进行验证价值。

用户旅程梳理


要优化体验首先要发现体验问题,很多组织都有自己收集和洞察用户体验评估的方式,包括:VOC数据收集、专家走访、问卷调研等方式,但是基于这些方式通常会存在体验改进片面化、不可持续性,无法系统地发现和解决问题。特别地,当面对“如何提升物流产品满意度10%”这类某一产品整体满意度提升命题时需要有一套体系化的业务梳理方法。

用户体验地图(User Experience Map - UEM)是梳理业务和用户旅程核心工具和方法之一。为什么评估用户体验先要梳理用户体验地图呢?因为用户体验是用户的整体感知,必须了解用户在产品/服务的整体路径、交互方式和各触点的情况,否则体验评估设计会缺乏系统性,无法准确定位问题及发现问题根因。

来自Pointillist公司的调研:超过 95% 的组织已经采用了基于旅程的客户体验方法,而且80%受访者表示,基于旅程的战略对其业务的整体成功至关重要。超过90%的受访者表示,基于旅程的方法对他们发现改进客户体验的机会、根据目标和指标调整团队,以及理解关键旅程信号有积极影响。超过 50% 的公司也有专门从事旅程管理或旅程分析的角色或团队。

备注:客户旅程管理软件服务公司 Pointillist 发布了《2020 客户旅程管理和客户体验测量报告》调查了全球 1050 位客户体验、客户服务和营销专业人士,以揭示关键趋势、洞见和基准。


▐  体验地图结构


用户体验地图的主要结构分为如下几层:行为阶段、用户目标、用户行为、用户需求、痛点、机会点


▐  体验地图案例


  • 案例:物流体验地图



▐  梳理要点


绘制用户体验地图之前
  1. 定性分析、用户访谈
  2. 用户画像
  3. 确定体验方向、体验主题,它是整个体验地图的主题,很多产品的方向可能不止一个,用户的使用场景也完全不一致。所以确定主题是整个产品的奠基石。

绘制用户体验地图中
  1. 确定用户需求,拆解用户行为
  2. 补充纵坐标中各类节点的内容
  3. 找准机会点

其他
  1. 注重前期对产品的思考,包含发展策略、目标定位等;
  2. 不要根据自己的经验或认知来确定用户行为过程中的阶段;
  3. 不要过早将聚到信息加入到Map中,用户达成某个目标而使用的媒介;
  4. 注重团队合作、头脑风暴;

体验指标设计


没有标准就没有问题,评价用户体验好不好,首先要建立一套标准,符合标准才能代表用户体验好,并且把这个“好”尽可能以量化的指标表达出来,否则无法测量,管理也就无从下手。


▐  名词解释


  1. NPS:净推荐值(总推荐者百分比-总批评者百分比),用NPS衡量客户忠诚度的前提是被调研的产品/服务对客户来说是可对比、可选择的。
  2. 用户满意度:衡量用户对特定事件/体验的满意度,通常采用五点量表(非常满意、满意、一般、不满意、非常不满意)采集数据。
  3. 用户费力度:衡量用户使用某产品/服务来解决问题的困难程度,通常也采用五点量表采集数据。
  4. FCR:首次解决率(FCR),简称首解率,含义是:【人工客服处理的问题中,客户首次接通人工客服就可以解决的问题比例】,计算口径为:【在规定时间内仅进线一次的用户数占比总进线用户数】。
  5. VOC:用户原声,通常指用户反馈的舆情、评价、咨询求助等。
  6. MOT:Moment Of Truth,即关键时刻,体验领域有个重要定律-峰终定律,它告诉我们客户不会关注到体验旅程的全流程,他只会在意在最高峰、最低谷以及最后终点这三个关键时刻,能否给他留下一个深刻的印象,并且深刻的印象可能是正面的也可能是负面的。


▐  指标设计流程


体验指标金字塔模型


如图,围绕用户体验“可衡量、可运营”,归纳出一套体验指标金字塔模型,指导如何设计体验指标体系。


该模型将指标区分为用户体验业务运营两类指标,用户体验类指标解释“用户体验如何衡量”,业务运营指标解释“用户体验如何驱动”,希望结合内外部视角找到体验提升的机会点,包括重塑用户旅程、改造内部业务流程、优化信息表达等。

  1. X-metrics = 用户体验指标:倾听“客户之声”,站在外部客户视角衡量用户体验。

  2. O-metrics = 业务运营指标:站在内部运营视角,针对用户旅程的关键触点挖掘驱动用户体验提升的关键因素。


整体流程如下:


Step1. 梳理用户旅程
梳理用户旅程,识别旅程的关键时刻(MOT)。

Step2. 用户体验指标设计
  1. 【面】整体NPS:用于衡量整体品牌的推荐度,涵盖所有用户群及各个产品/服务
  2. 【线】满意度/费力度:针对影响整体NPS的某个产品/服务的整个用户旅程进行满意度/费力度调研,如:导购、客服、物流、基础操作、品质、价格满意度等。
  3. 【点】驱动因素/VOC:针对用户旅程的关键触点结合满意度下钻的驱动因素及VOC明确体验指标,如:负向反馈率、VOC求助量/占比等。

Step3. 业务运营指标设计
针对用户旅程的关键触点挖掘驱动用户体验提升关键因素,完成指标详细设计及口径定义。


▐  指标设计原则


指标设计需以MOT为核心

用户对产品/服务的体验更多是事后回忆,不会记得所有流程,因此体验评分不是平均分,也不是总分,而是关键时刻(MOT)的体验分数。


体验指标与运营指标应保持对应关系

X的衡量与O的驱动需协同,保证对体验提升的衡量与指导意义。


体验指标无需严格从“面”开始设计

按照业务需求及分析师发现的体验问题规模,大多以“线”、“点”作为起点开始设计。例如:在物流体验场景中,业务明确需提升“淘宝物流产品满意度”;支付体验场景中,明确基于支付VOC中top1问题“无法使用微信支付”展开治理。


该阶段指标不是终版

该阶段的指标设计更多是依赖业务先验知识、历史问卷调研等,尚未有明确数据校验体验指标与运营指标的严格相关性,需在后续的流程中持续更新。


▐  指标设计案例


  • 案例:性能指标体系



数据准备


▐  体验数据架构


同体验指标设计方法,我们将支撑体验分析的数据分为两类:

  1. O-data = 运营数据,包括DAU、销售额、下单转化率、留存率、复购率等,属于滞后数据,代表着现阶段的经营现状。

  2. X-data = 体验感知数据,包括净推荐值、满意度、用户原声等,属于先行数据,代表收入或利润的未来风险。


体验分析的核心思维就是O数据与X数据的协同分析,基石是用户体验旅程。缺少O数据会让我们偏离商业本质,缺少X数据会让我们“盲猜”用户。兼顾到采集SDK和数据平台的规划设计,数据准备阶段我们需要有体系化的视角实现全面的体验感知。

O&X协同的体验数据架构

在“用户是谁”环节,O与X协同能够让我们知道同一款产品Android/iOS、男/女用户满意度分别有何差异;结合用户反馈数据,我们还能获知本次旅程真正的用户是谁,例如:帮女朋友买生日礼物、帮儿子买书包等。在“如何了解产品”环节,O与X协同能让我们了解用户在某一页面关注度最高是哪个功能模块,关联进线咨询VOC数据还可获知该模块中具体是哪类信息缺失、模糊不清,影响用户购物决策。

▐  VOC标签体系


用户体验偏主观且因人而已,与用户自身的预期强相关,通常很难通过绝对客观数据来评价用户体验好坏。VOC(Voice Of Customer)是一种能够直接获知用户体验的数据源。淘宝VOC是多源、多模态的,一方面,数科同学需要了解多源VOC的产生场景以便在合适的案例进行选择和使用;另一方面,需要将VOC加工成标签以便高效进行分析。

分析应用层面需要注意各类VOC的特点以便合理选择:
  1. APP用户反馈:偏购前,大多为用户在使用APP过程中遇到的产品、性能体验的问题反馈,同时也包含部分热心用户提出的诚恳建议。
  2. 商家客服咨询:偏购中和购后,大多为用户购中咨询商品,购后咨询订单和物流状态的场景,其中购后约50%以上语料为咨询物流。
  3. CCO求助原声:偏购后纠纷求助,大多围绕订单和物流异常求客服。
  4. 评价:购后评价商品,使用时注意存在大量刷评数据。
  5. 问大家:购前基于商品的C2C的咨询,回复比较真实,但数据总量不大。

问题发现

有了评估指标和数据,如何基于这些数据评估体验好坏、发现问题?

日常生活和工作中,我们之所以会评价,是因为我们内心对每件事情都有个标准,这个标准可能是潜在的或显性的。例如:我们对美丑的评价标准就是潜在的,而对考试成绩(60分为及格分)的评价标准就是显性的。之所为能够发现问题,是因为我们内心有一套清晰或模糊的标准,看到现实与标准有差距,就知道存在问题。显性标准很多来自历史数据和经验的总结,例如大名鼎鼎的NPS指标,业内有一个基本评估标准:

经过长期调研和总结形成一个关于产品满意度的评估标准:需改善(<50%),良好(50%-60%),优秀(>60%)。而大多数体验场景缺乏显性标准,故需要一套分析方法来判断体验好坏。


▐  分析方法


问题发现阶段主要通过指标的趋势、排名、波动监测,以及未知原声异常监测(聚类检测、词云),跟踪老问题,发现新问题。


通常涉及两类指标:用户调研为主的满意度、驱动因素类指标,用户原声及其加工后标签统计类指标。对于满意度这类单一汇总类指标,通常可以跟自己比(看趋势)、跟竞对比(看标杆)发现问题。对于用户原声这类非结构化数据,通常应用于跟踪、发现和诊断“点”层面体验问题,可通过文本分类方法加工成体验问题标签,再基于标签的声量/占比的趋势变化、排名变化发现问题;此外,也可通过文本聚类方法挖掘新标签,实时检测未知问题的发生。


由于指标的复杂度不高(如高维、多周期等),该阶段整体以原子分析方法为主:


问题诊断


通过性能体验、物流体验、客服体验、商品体验等多领域的案例总结,我们将体验诊断及优化过程中存在的问题进行如下分类:

▐  诊断分析方法


诊断分析主要是通过用户洞察、归因分析、价值衡量等方式,挖掘问题发生的原因,给出体验优化建议和策略。基于体验问题本身的不同类别,我们梳理了一套面向体验场景诊断分析方法,其特点在于对X-data的灵活运用:


▐  诊断分析案例


  • 主客观关联分析


案例:目标定义-性能优化目标


  1. 业务问题定义:如何针对不同人群设定差异化性能优化目标,能兼顾技术投入与用户预期满足,达成ROI最大化。
  2. 数据问题定义:如何找到一个与性能满意度强关联的指标,围绕这个指标设定合理的目标,再按一定的维度下拆指标找到差异化目标。
  3. 找出与满意度强相关的指标
    通过用户问卷调研并作结构分析可得出:影响用户的核心因素为“功能加载速度慢”、“打开APP速度慢”,由于“功能加载速度慢”是由一系列功能(如各类页面、模块)组成,明确“打开APP速度慢”是首页因素。
  4. 建立主客观指标模型,寻找两者之间的关联关系
  5. 观指标:负向反馈率( 问卷中反馈“打开手机淘宝APP的速度慢”的样本数/总样本数)
    客观指标:冷启可交互耗时


如上图,通过主客观关联分析发现某款机型下某App负向反馈率在冷启耗时x ms出现拐点。可得出,性能差于拐点时,性能优化能明显带来负向反馈率下降;性能优于拐点时,性能优化对于体验的提升效益不再显著。因此,可以设定x ms作为该机型下该APP性能优化目标。


  • 用户动线分析


案例:策略制订-详情用户动线分析


  1. 业务问题定义:如何基于用户在详情页面的行为数据找到产品改进机会点以提升用户决策效率。
  2. 数据问题定义:如何围绕“什么样的用户”进入“什么商品”产生了“什么样的浏览行为”梳理详情页各模块的浏览、点击、停留时及行为时序数据,挖掘主流用户的行为路径及关注点差异,交付详情决策因子的补全、调序和表达优化策略,提升详情决策效率。
  3. 分析思路:
    前提假设:不同人群、类目、场景的用户决策因子的差异化和增强表达,可提升详情用户浏览体验,提升购物决策效率。
    假设树:
  4. 分析结论(示例):


策略落地

问题诊断阶段类似医生的门诊、开方子,策略落地阶段类似于治疗。数科同学在该阶段需要总结的更多是如何推进策略落地的工作方法。我们分别定义如下几个问题,并阐述解决方法。

问题1、如何让业务支持我们的分析?
  1. 首先,要证明你的分析是正确的;
  2. 其次,需要有非常准确的、可靠的价值描述;
  3. 最终,必须有清晰明确、成本可控的落地方案。

问题2、业务认可我们的分析,但不协助推进,如何处理?
  1. 确定是否真认可?任何业务方做成事都是梦寐以求的,假设结论靠谱、能落地,绝对不会置之不理;
  2. 业务方质疑分析,或者觉得价值不大,疑惑是和自身关系不大,需要鼓起勇气再次咨询意见,解决质疑;
  3. 价值不足够大,当前有更加紧急的事情要做,代表结论可能要凉;
  4. 没找对人,需要换一个业务再营销一遍,有时候策略搁置无法执行的原因是数据同学本身没有充分推动。

问题3、如何让其它团队配合数据策略落地?
  1. 前期充分了解和识别相关团队的OKR、定位和合作意愿度,做好沟通工作;
  2. 重要策略需申请PMO资源,组织正式KickOff,特别地要拉上业务和技术老板压阵,传达大家重视程度,明确各团队职责分工,达成一致;
  3. 过程中做好项目管理,PMO投入不足时数据负责人要主动补位做好协调工作。

总结一个数据策略能否落地,分析本身是否正确占10%,剩下是分析本身的价值;数据同学需要懂得对企业内部、人物关系、环境背景的分析。


效果验证


▐  AB实验


  • 什么是AB实验


AB实验是最直观的一种评估策略因果效应的科学手段,做AB实验需要两个前提条件:同质性与无偏性。实验中的不同组应该是同质的,意味着样本构成需相同或极其相似以确保结果的可比性,这通常是通过平台工具随机分流来实现。实验也应该是公正的,核心指标只受实验策略本身的直接影响。只有控制了全部干扰因素,才有可能接近Treatment和Result之间的因果关系。相对传统的优化前后对比方式,AB实验有以下优势:

  1. 同质 - 保证可比性

  • 可以有效控制其他干扰因素。

  • 可以避免选择性偏差。

  • 无偏 - 保证效果复现


    • AB的一般步骤



    明确AB假设和实验变量

    AB实验不是价值衡量的许愿池,我们先要回答一个问题:如何判断一个策略是否可以通过AB实验来进行评估?避免无用功或引发舆情。AB有其特定的适用场景,如下场景是无法进行AB或者成本过高:
    1. 策略已经全量,需后置评估策略上线效果

    2. 策略渗透率过低,使用AB无法得到置信的样本量

    3. 策略本身不具备随机AB的条件

    4. 进行AB的成本较高,ROI较低


    判断可以AB后需明确实验变量,一个好的实验变量要满足以下几点:

    1. 实验变量需根据假设来创建

    2. 需要符合单一变量原则


    定义实验关键指标


    确定分流方式


    如何确定分流对象及保证分流的均匀性是该步骤需要解决的问题:

    1. 分流对象:分流对象是需根据核心指标来确认,例如:在短视频场景,提升引导GMV则分流对象就是用户,提升创作者活跃度则分流对象是创作者。在端性能优化场景,提升设备顺畅度分流对象就是设备id,而非用户id。

    2. 分流均匀性:AA空跑是检验分流均匀性的常用手段,选定的实验组和对照组,在上实验策略前先空跑一段时间。如果空跑期的样本量和各项指标均无显著差异,则认为实验分流是均匀的。


    最小样本量测算


    实验希望能检测到的指标精度越高,所需要的样本量就越大,这样可以使实验的敏感度大于我们预期的策略效果提升(MDE)。因此,针对我们希望检测到的预估效果MDE(通常由离线测算所得,如5%/10%等),我们需要计算实验所需要的最小样本量。在给定错误容错率下,最小样本量由MDE、均值、方差共同决定。此处需要注意的是不同的指标类型的方差计算方式是不同的,在实操中如果分流单元和分析单元不一致需要特殊处理。


    附:最小样本计算公式及Python实现,也可基于Evan's Awesome A/B Tools在线网站进行测算。


    from statsmodels.stats.power import zt_ind_solve_powerfrom statsmodels.stats.proportion import proportion_effectsize as eszt_ind_solve_power(effect_size=es(prop1=0.30, prop2=0.305), alpha=0.05, power=0.8, alternative="two-sided")


    实验日常监测


    在进入实验期后,需要对实验数据进行日常监测,日常监测主要观察以下几方面:

    1. 样本量。在实验的过程中,应当日常观测实验组和对照组的样本量是否均匀。如果在进入实验期后,实验组相比对照组的样本量出现显著差异,应当立即排查样本量不平的原因(实验策略导致分流不均?实验策略埋点上报有问题?)

    2. 各项实验指标。如果在实验的过程中,实验组和对照组的指标出现不符合预期的差距,也应当立即排查该现象出现的原因。

    3. 核心护栏指标。如果实验策略对实验组的核心护栏指标产生严重的负向影响,例如:广告收入严重下降,也应立即同步各方,决定是否停止实验。


    实验效果分析


    在实验周期结束后,需要根据实验数据进行分析。A/B test分析将显示两个版本之间是否存在统计性显著差异,所以在分析结论时不止要观注实验分组之前的差异性,还要关注置信度和置信区间等统计指标来检测差异的真实性及可信度。在分析实验数据时,通常会有以下问题:

    1. 实验指标不显著怎么办?

      可以看一下核心指标的走势,如果有单调递增的趋势,可以适当延长实验时间再看一下效果,大样本是王道。其次判断统计功效问题,如果在进行了样本量计算后,实验指标依然不显著,则一方面需要通过观察实验指标的相对/绝对差值考虑是否实验策略真的没有显著影响,另一方面可以通过更换监测指标剔除无渗透用户以提高指标检测精度。

    2. 是否可以通过实验数据,找到对实验策略敏感的用户群体?

      找敏感用户群体可以通过维度拆解的方式,观察实验策略对不同用户群体的影响差异;也可以通过causal tree/uplift model的方式,从模型角度计算单个用户群体/单个用户的CATE,从而对实验效果的异质性进行探究。

    3. 关注的多个实验指标有正有负,如何判断是否可推全?

      首先,确认哪边的指标是本实验更重要的指标,同时关注护栏指标和北极星指标的情况(若护栏指标和北极星指标显著负向,拒绝推全)。其次,判断正负指标是否存在相关性或者是否存在兑换关系,综合盘整体收益是如何。

    4. 如果实验效果不好,没有推全,是否说明这个实验没有任何价值?

      很多AB实验结果都是失败的,如果某个实验没有推全,我们依然可以通过实验数据,去探寻本次实验失败的原因,从而发现是否有新的可能的改进点。根据新的改进点继续进行实验,最终进行策略的快速迭代。


    • 如何检验分流均匀性


    网上不少文章介绍如何运用卡方检验来检验实验UV分流均匀性,但在大型APP场景下往往不适用,根因是单个AB实验分桶的UV往往达几十万、上百万,大样本量下卡方检验过于灵敏,p-value容易接近0.0。因此推荐引用效应量函数来辅助决策,通过计算分流系统不同流量下的95%置信的偏差上限,并利用指数函数进行拟合,从而在实际应用中可以给出不同分桶UV样本量下的阈值。

    备注:受不同的实验分流系统中内置hash函数及分流对象本身的均匀性影响效应量函数参数会不同。


    附:效应量函数图


    • 如何检验指标显著性


    网上同样很多文章介绍如何综合运用样本分布+t-test检验指标显著性统计原理,这里不作过多介绍。但鲜有交代如何构建样本,此外,最小样本量计算与指标显著性检验的前提关系是什么?

    针对一个比率型指标(如:浏览转化率),我们首先根据其基线值和预期提升幅度通过最小样本量公式计算其所需的累计样本量,满足最小样本条件后再基于分流对象进行hash分组(一般分为30组以满足t-test的样本量需求),再运用显著性检验UDF进行检验。 


    案例:某AB实验指标显著检验


    ▐  因果推断


    这里主要介绍因果推断中PSM倾向得分匹配法在效果验证中的原理和应用。

    定义:PSM倾向得分匹配法,是通过对数据建模,为每个用户拟合⼀个概率(多维特征拟合成一维的概率),在对照组样本中寻找和实验组最接近的样本,从而进行比较。

    前提:
    1. 条件独立假设。在接受实验之前,对照组和实验组之间没有差异,实验组产生的效应完全来自实验处理。
    2. 共同⽀撑假设。在理想情况下,实验组的个体,都能在对照组中找到对应的个体。如下图,两组共同取值较少时,就不适用PSM了。



    场景:
    无法做严格AB实验的场景
    现实场景中存在一些产品和运营策略不适合做AB实验,例如A组和B组采取不同的价格策略,会损害用户体验造成投诉。
    AB实验中低响应分析场景
    AB实验中实验组真正具有响应行为的用户很少,需要通过PSM和网格化的方法找到相应行为同质的用户作为分析对照组,从而起到缩小分母提升检验显著性的灵敏度。

    实现:
    pymatch:https://github.com/benmiroglio/pymatch#match-data

    参考文献

    1. 黄峰 等 - 《体验思维》、《全面体验管理》

    2. 刑焱 等 - 《客户体验管理 - 知行合一》


    继续滑动看下一个
    向上滑动看下一个

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存