物流产品体验诊断与优化




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

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



文为此系列第三篇文章,前两篇见——
第一篇:淘宝用户体验分析方法论
第二篇:VOC数据洞察在淘宝详情页的应用与实践


业务背景

物流服务是电商平台的生命线,贯穿在用户购买旅程中的各个环节,而产品端面向用户表达的物流信息,会直接影响用户在淘宝购买的决策依据和复购倾向。以下是摘自淘宝体验平台关于物流的用户“吐槽”原声:

“付款5天了,物流信息3天没有更新”

“这么多天了,是物流出问题!还是送货人私吞掉!我没有收到货物!我要退款!请进快解决问题!”

“物流一直不更新好烦”


当物流信息表达不清晰,且用户无法通过平台快速解决问题时,会引发用户极大的焦虑和不安全感,使用户在平台整体的消费购物体验受损。不同于自营物流,淘宝物流目前更多依赖四通一达、顺丰、邮政等三方快递服务商,对于物流服务体验的保障强依赖上下游多方角色的协同建设。

淘宝交易物流产品团队将提升物流产品体验做为重要的业务命题,明确核心目标为提升淘宝物流产品满意度 X%。那么,业务的难点体现在“ 如何设计合理的物流信息产品表达策略,并配套自助服务能力(如物流工单服务能力),在不超出有限的服务成本下,还能最大程度管理用户预期,缓解用户对物流的焦虑情绪?

在本文中,笔者将简要介绍如何通过数据的力量,协助业务看清体验问题全貌,挖掘业务机会点,并设定合理的产品解决策略。

问题发现


  业务梳理


结合用户调研报告和用户VOC原声标签,我们梳理了用户在购前、购后、逆向三大业务环节与物流产品触点及主要体验舆情;梳理了用户在物流服务“支-发-揽-运-派-站-签-退”八个重要阶段中会经历的各种“折磨”。针对这一系列体验问题,我们也盘点出淘宝物流产品业务的机会点

图2.1 物流体验业务大图


  指标设计


在完成业务的体验问题与机会点梳理后,需要一套完整的指标体系衡量体验,指导判断体验问题的轻重缓急。


图2.2 体验指标拆解金字塔


说明:
NPS:净推荐值(总推荐者百分比-总批评者百分比),用NPS衡量客户忠诚度的前提是被调研的产品/服务对客户来说是可对比、可选择的。
CSAT:用户满意度,衡量用户对特定事件/体验的满意度,通常采用五点量表(非常满意、满意、一般、不满意、非常不满意)采集数据。
CES:用户费力度,衡量用户使用某产品/服务来解决问题的困难程度,通常也采用五点量表采集数据。
VOC:用户原声,通常指用户反馈的舆情、评价、咨询求助等。

图2.2,通常我们会从NPS出发拆解指标,从用户调研相关指标拆解至VOC相关指标,从主观体验指标拆解至客观运营指标,最终形成一个业务域的体验指标体系。基于上述方法,结合图2.1业务大图我们梳理出物流体验指标体系,见图2.3。

图2.3 物流体验指标体系


物流体验指标体系,可以将定性的业务梳理转化为定量的指标衡量,指导我们量化体验现状,判断体验问题的重要程度和优先级。

  量化分析


用户研究报告:淘宝用户研究团队会定期发布关于物流整体NPS的调研,但下拆到物流产品信息表达层面无法用NPS衡量。因此,我们跟用研合作产出《手淘物流表达满意度调研报告》,从CSAT(用户满意度)层面开始分析,图2.4是调研结果,确定满意度基线为X%。向下拆解用户不满意的原因中,物流异常、未按时发货是影响物流产品满意度的核心问题。 

图2.4 淘宝物流表达满意度研究报告


场景化调研:但对于主动调研的数据,由于依赖用研问卷的投放与报告产出,存在投入成本较高、产出周期较长等问题,我们需要有更及时的主观数据采集工具。因此,我们还重点引入场景化满意度调研能力,针对物流异常的场景在物流详情页设计调研入口并投放场景定制化问卷,解决了及时、精细化采集主观数据的问题。具体产品形态见图2.5。


图2.5 物流场景化调研入口及问卷


通过物流异常场景的精细化数据采集和调研分析结果,如图2.6所示,可以发现:物流信息长时间不更新,且不知道原因物流出现异常的时候,没有及时告知,是物流异常场景下导致用户体验不好占比最高的两个原因。


原声分析:进一步,通过CCO物流求助原声标签分析,如图2.7所示,我们同样可以发现:发货慢/不发货运输中物流不更新,是物流体验中两个最主要的问题。


求助所处物流阶段
占比
TOP求助标签
标签占比
已支付
X%
商家发货慢
X%
商家不发货
X%
未按约定时间发货
X%
已发货
X% 商家不发货 X%

物流信息没有/不更新

X%
虚假发 X%
运输中
X%
物流信息没有/不更新
X%
物流查询
X%
买家未收到货
X%
派送中

X%

买家未收到货

X%

物流查询

X%

物流信息没有/不更新

X%
已入站
X% 买家未收到货 X%
物流查询
X%
驿站问题
X%
已签收
X% 买家未收到货
X%

商品/配件少件漏发

X%
空包裹
X%
商家发错货
X%

图2.7 CCO物流求助原声统计-分物流阶段


  问题定义


通过以上一系列的定性和定量分析,结合淘宝业务发展,商家发货慢/不发货的问题已和行业合作在解决,因此,我们选择重点从用户求助量占比最高的运输中这个阶段物流停滞异常这个场景切入,定义出如下物流体验问题:
  1. 业务问题:针对运输中物流不更新场景(即物流停滞场景),该如何通过产品表达缓解用户焦虑,降低用户求助。
  2. 业务目标:降低用户物流万求,提升用户满意度。
  3. 业务痛点:平台无法直接解决异常,且工单服务能力有限(日均最多N万异常工单量)。


将以上业务问题转化为数据问题,我们需定义出:
  1. 业务目标:AB物流停滞异常万人求助量-X%,用户调研物流产品满意度+X%。
  2. 数据问题:
    • 停滞异常的判定标准:即当物流停滞超过多少小时,定义为停滞异常。
    • 停滞异常的表达策略:即在物流X小时不更新时,面向什么样的场景/用户,表达什么内容;
  3. 约束条件:在不超出日均最多N万工单量的服务能力下,最大程度管理用户预期,缓解焦虑情绪;

针对上述定义的问题,我们也发现了一系列困难点:
  1. “物流X小时不更新”中的X的定义。假设X数值过小,物流停滞的信息过早通知用户,可能会造成用户焦虑反增平台求助量,而且X数值小意味着表达的量级大,快递服务商/商家的服务能力难以应对;反之X数值过大,可能用户早已感知异常并发起求助,失去表达的最佳时机,起不到降低平台求助作用。
  2. 表达内容的设计。业务认为表达就一定要给用户确定性,不能空安抚。我们希望尽早表达去干预用户求助,但服务能力又限制了我们尽早表达。能否有一种不通过提供服务的表达方式,但能给到用户确定性。
  3. 精细化的表达策略。从上述数据问题也可以发现,停滞异常需要根据人群/场景做精细化的表达策略,这就意味着我们需要提供一套通用的方法论,让业务能自主分析并定制精细化策略。

数据准备


  基础数据


主观数据:用户物流求助/投诉数据

客观数据:淘宝订单物流节点数据


  指标定义


  • 异常订单占比


定义:X小时不更新异常订单量 / 总订单量
衡量:衡量X小时不更新异常在大盘发生的概率
含义:高,需要表达/服务的量级大;低,需要表达/服务的量级小
标准:根据能提供的工单量估算,我们可针对每日X%以内的订单提供工单服务


  • 求助覆盖率


定义:X小时不更新异常发生之后的求助量 / 总求助量

衡量:衡量X小时不更新异常能服务到的求助量

含义:高,表达/服务能干预到的求助多;低,表达/服务能干预到的求助小

标准:理想覆盖X%以上的求助


  • 异常万求量


定义:X小时不更新异常订单求助量 / 该类异常订单量 * 10000

衡量:衡量用户对于X小时不更新异常的感知强度

含义:高,用户负面情绪严重;低,用户负面情绪轻微


  • Y小时恢复率


定义:X小时不更新异常订单在Y小时内重新更新物流状态订单量 / 该类异常订单量

衡量:衡量X小时不更新异常在Y小时内自然恢复的能力

含义:高,自然恢复能力强,无需提供服务;低,自然恢复能力弱,需要服务介入

标准:恢复率超过X%则无须提供服务


策略洞察


从停滞异常的求助数据出发,我们通过主客观数据关联分析方法,洞察用户求助时间与实际物流停滞时长的关系,权衡利弊,最终分析确定表达策略。


图4.1 物流停滞主客观指标关联洞察


如图4.1所示,我们可以分析并得到基础策略
  1. 停滞X小时为最佳安抚表达时机,因为其求助覆盖率超过X%(能干预到大量求助),且恢复率超过X%(绝大多数能短期内自然恢复),我们只需要在这个时间段透出安抚文案且告知预计恢复时间,就能缓解用户的焦虑感。既表达安抚并给予一定确定性,又无需提供工单服务,成功化解了数据问题难点b;
  2. 停滞X小时为最佳催物流服务提供时机,其订单占比控制在X%以内(有相应量级的服务能力),且异常万求突增(用户已经有强烈情绪)。当前产品侧我们打通了CP与PBC,可同时向快递公司与商家发起工单,要求其在规定时间内回复解决方案。
  3. 停滞X小时及以上不更新引导联系商家,其异常万求量极高(用户负向情绪严重),且恢复率低,建议用户尽快联系商家退款或补发。

同样基于上面的分析方法,我们还针对一些特殊场景洞察并上线了一系列精细化策略,例如:针对已抵达收货地城市包裹的停滞,我们发现用户求助进线更早且更猛,所以我们会提前催物流服务表达。

策略落地

业务PD根据上述产出的策略,最终设计形成如下产品形态,并已开始上线,详见图5.1。


图5.1 物流停滞表达产品样式


在产品上线前期,我们也协同业务一起观测产品指标,分析文案的安抚或引导效果,并针对文案和交互做了一系列优化,在此就不逐一展开赘述。


效果评估


我们通过AB实验对产品上线后的效果进行了数据论证,在此不赘述科学的实验设计与效果评估。经分析,实验桶物流万人求助量-X%,异常解决率+Xpt(X%->X%),售后咨询满意率+Xpt(X%->X%)。此外通过定期用户调研,手淘物流产品满意度+Xpt(X%->X%)。


团队介绍


我们是大淘宝技术交易履约数据科学团队,负责面向淘宝交易履约链路(下单、支付、购物车、物流、逆向等)海量数据挖掘DAU、DAC及用户体验增长机会。团队致力于围绕用户行为路径、用户VOC洞察用户需求,基于人货场匹配落地交易链路触达、转化、复购和体验策略,提升消费者购物体验。
目前团队招聘中,欢迎拥有消费者、商品、交易、营销等相关领域数据分析/数据科学背景的优秀人才加入,有兴趣可将简历发送至[email protected]


¤  拓展阅读  ¤

3DXR技术 |  终端技术 |  音视频技术
服务端技术  |  技术质量 |  数据算法


本文分享自微信公众号 - 大淘宝技术(AlibabaMTT)。
如有侵权,请联系 [email protected] 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

RustDesk 1.2:采用 Flutter 重写桌面版本,支持 Wayland 被控 deepin V23 成功适配 WSL 2023 年需求最大的 8 种编程语言:PHP 强劲,C/C++ 需求放缓 React 正在经历 Angular.js 的时刻吗? CentOS 项目宣称“向所有人开放” MySQL 8.1 及 MySQL 8.0.34 正式发布 Rust 1.71.0 稳定版发布 程序员笔记 CherryTree 1.0.0.0 发布 微软:加大力度在 Windows 11 使用 Rust 微软推出新的默认字体 Aptos,替代 Calibri
{{o.name}}
{{m.name}}

猜你喜欢

转载自my.oschina.net/u/4662964/blog/10089616
今日推荐