携程产品设计如何应用数据分析的？

问题导读

1.携程的数据体系是什么样子的？
2.要让数据分析真正有效地推进产品设计，它的必备条件有哪些？
3.携程民宿频道是如何进化的？
4.客栈通APP订单详情页是如何优化？

数据与设计的关系，业界向来颇多热议——有“数据驱动设计”之说，有“数据引导设计”之论，也有类似“数据关注削弱用户体验”的抱怨。看似感性主观的用户体验设计与理性客观的数据分析，究竟怎样才能相互作用进而碰撞出产品的灵感火花？

本文试抛一砖，将通过酒店产品设计中的两个案例来介绍数据在携程产品设计过程中的应用实践，以及携程所构建的专业数据体系。

产品设计的数据观

作为互联网产品设计者，首先要树立对数据的正确认知，我们称之“数据观”。

• 数据贯穿设计全过程，产品设计要学会用数据说话
• 数据是人创造的，只有人会解释和分析数据
• 明确业务/设计目标，根据需求来采集、分析数据
• 上线后关注数据变化，发现问题，快速迭代
• 持续监测、评估数据，以检验设计目标是否达成
• 数据不能替代用户体验，改进仍需结合多种手段
  

而要让数据分析真正有效地推进产品设计，又有以下必备条件：

首先是数据源，“巧妇难为无米之炊”，完善的数据采集、展示体系，是进行分析的先决条件。

然后是数据感，也就是从数据中捕捉、挖掘、分析的能力。林彪当年在辽沈战役听取一场遭遇战的战报时，敏锐地发现缴获短枪长枪之比、小车大车之比、俘虏军官士兵之比，都显著高于平常，于是判断敌军指挥所就在附近。果然，经专门部署，在后续战斗中俘获了主将廖耀湘。林彪并没有大数据分析工具，但是他有经验的积累，数据感出色，当数据异于平常时就能做出准确预判。

再次是对数据的分析法，常见的专业方法有多维分析、路径分析、留存分析、回访分析等，将多种方法结合使用会更有助提升数据支撑的深度。

最后，如何将从数据分析中洞见的用户行为与态度，在设计中予以体现，那就需要设计师的设计力。

携程的数据体系

数据分析在携程有着重要地位，这或许与携程创始人梁建章系出计算机专业又曾在Oracle任职的经历有关。在携程，数据既是考量工作绩效的指标，也是未来业务拓展的探针。

在携程产品的整个生命周期中，数据始终贯穿其间。始自一个创意的诞生，需求分析阶段就有基于数据的诊断性研究；随后在产品设计环节，又会有数据做出价值预估，并给出目标建议；在产品上线初期，海量数据环境的A/B测试，数据波动关注，一直到产品上线稳定后的运营监控、定制报表，数据无一不是重要的考察因素。

工欲善其事，必先利其器。携程平台打造了多款数据利器，帮助员工善用数据：

• 利器之一，UIP用户洞察平台。它将主要数据指标一网打尽，产品设计可根据需要，基于频道、页面、地理位置、提交渠道、流量来源等，逐一查看各种PV、UV指标，以及跳出率、二跳率、退出率、转化率、页面停留时间等数据。
• 利器之二，页面点击插件。点击页面上的每个模块，可以查看到它的点击概要、访问趋势、统计数据明细、浏览器统计、页面热力图等信息。
• 利器之三，A/B 测试，也就是切取部分流量，采用科学取样方法，让新旧设计版本在同一时间段同质的用户群体内“以实践来检验”，直观地从转化率数据评判出设计的价值。这种方法稳定、高效，目前在酒店产品线已得到广泛应用，测试的成功率达到15%以上。由于A/B测试仅在一定样本内进行，不致对全局业务产生影响，于是设计师获得更大空间去发挥他们的创意，敢于试错；数据比对会帮助他们不断修正设计中的方法偏差。当然，A/B测试着力相对短期，不能过度依赖，且更适用海量用户的测试。
• 利器之四是定制开发的KPI Portal，它根据各个项目的具体需求，将与项目相关的各类数据指标集成在一起，做出趋势看板，供项目中人快速、直观地了解项目目标达成情况。有趣的是，这些指标还可换算成收益！
  

然而光有这些数据分析工具，不免还有所欠缺。比如酒店详情页上展示的房型和设施信息，要从点击数据上分析用户对它们优先级的排列和分组的看法，就非常困难。因为定性的问题很难通过定量的分析工具来得到解决。此时，携程的用户研究团队就受命登场了。

用研团队会通过对典型用户的访谈、焦点小组、卡片分类、眼动追踪等一系列专业手段，挖掘出用户的行为与态度特征，帮助产品设计理解表象行为后的内在原因，为优化设计提供依据和佐证。

携程民宿频道的设计进化或许就可归因于这种定量与定性分析的结合。

案例一，携程民宿频道进化史

近年来，住宿市场上独具个性和人情味的民宿、客栈异军突起，深受游客追捧，于是携程应运市场趋势，在携程旅行客户端推出了民宿频道。用户访问的路径是：民宿频道首页（选择城市与时间段）-列表页（选择客栈）-详情页（了解客栈的房型信息）-预订填写页（对具体房型下单购买）。

最初，民宿频道只是将具有民宿、客栈属性的酒店收录进来，其页面样式仍然沿袭常规酒店的模板。很快，数据发现，民宿频道各页面的转换率低于常规酒店。用研给出结论：民宿频道功能照搬常规酒店，没有考虑民宿用户的特定需求；频道定位不清晰，没有凸显特色。

于是，改版优化开始。首先，通过对订单数据的挖掘，我们发现民宿类酒店提前预订天数较之常规酒店更长，预订距离更远，说明民宿用户订单特征跟主频道差异明显，基本是度假出游类型；随后通过用户访谈，对用户特征做出了分类画像；再经过对竞品的对比研究，新的设计方案脉络清楚起来：

• 首页：着重浏览和推荐，弱化搜索功能；整体布局高、大、松；视觉暖色调，小清新
• 列表页：尝试提供大图模式，让用户出行前提前了解民宿特色
• 详情页：增强模块感，每个模块均外露一部分内容，让用户对模块内容有预览
  

第一版的设计方案上线即伴随A/B测试，结果发现订单转化率上升明显，而具体到各页面，转化率变动情况如下：

• 首页：首页-列表页的转化率出现了20%的下降（分析：用户找不到查询模块，迭代时需加强）
• 列表页：转化率上升10%，但是大图效果差于小图列表（后续默认切换为小图列表，同时保留大图列表）
• 详情页：到预订填写页的转化率上升（信息外露对用户有效，后续外露更多内容帮助用户更快决策；同时让价格常驻页面底部，减少用户来回拖动页面寻找的费力度）
  

在第一版基础上的迭代在两周后上线，A/B测试的结果令人欣喜，首页到列表页的转化率由原来的下降逆转为上升2%，订单转化率继续上升26%。

面向客户的C端产品在数据指导下获得了明确的迭代方向，而面向商户的B端产品，也可以借助数据分析帮助用户获得工作效率的提升。

案例二，客栈通APP订单详情页优化

客栈通是一款帮助民宿客栈老板管理房态、处理订单的软件，在这款APP上，订单详情的展示对老板至关重要，但是订单内信息较多，在最初的版本上做了逐行展示，用户要看全信息必须上下滑动3屏。

产品上线后就开始监测这个页面所涉及的数据指标，我们发现，进入订单详情的用户大多只是查看信息，做出修改的只占13%；而修改操作中，修改订单状态的又远多于修改订单内容的。订单修改页面的平均停留时长达到11秒，说明用户定位到要修改的信息再完成修改有一定费力度。虽然对订单信息做了逐行展示，但有些字段长度有限，可以考虑合并；而有些字段（如房型名称、房间号）长度可能超出但对用户这全不是问题——客栈老板对自己的房间如数家珍，并不强求完整展示。

于是，改版设计方向明确，我们对订单信息重新布局，分成预订、住客、房间和结算四个小模块，每个模块内信息精简展示，令一屏内能完整展示订单的重要信息；将低频的修改订单内容操作（如添加房间、入住人）通过入口隐藏起来；同时将我们要强化的修改状态操作置底显示，引导用户进入主流程（办理预订-办理入住-办理离店）。

商户端产品的用户数与客户端不在一个数量级，因此设计验证我们未采用更适于海量数据的A/B测试，而是实地走访多家客栈，通过高保真原型演示和任务模拟，直接观察客栈老板的操作，来进行可用性测试。

优化版本上线后的数据令人欣喜，订单查看和修改页面的PV有了30%以上的增长，订单平均修改时长由11秒显著降低至4秒；而与此同时，APP的订单修改量增加了30倍。显然，快捷方便的体验令更多用户把修改订单操作由PC转向手机。

对数据的研究终须落足于人

小结这两个案例，对数据的监测和分析始终贯穿于产品的生命周期。而在对数据的探究中，始终围绕着以下几个问题：

• 问题和目标是什么？
• 影响哪些用户？
• 影响哪些流程？
• 你希望的结果是什么？如何测量？
• 是否有交叉影响（导致此升彼降）？
  

我们的体会是，数据必须与使用场景紧密结合，明确目标来采集分析数据，同时引入用户调查、情境访谈等定性研究，多管齐下，善用数据资源去改进问题和发现新的可能，而非“为数据而数据”，或是被各种数据目标牵着走。

数据贯穿设计全过程，但不可能取代用户体验设计。所有的数据探索、研究和分析，到最后都要落足于人，所谓“设计以人为本”——通过数据和设计的彼此作用、相辅相成，最终去影响人的态度与行为，收获业务目标和良好用户体验的双双达成。

来源：csdn

作者：林传毅

来自群组: Hadoop技术组

谢谢楼主，学习一下，赞~~