Update from Sync Service
This commit is contained in:
FNS Service
@@ -0,0 +1,112 @@
|
||||
|
||||
1. 远控功能分析：
|
||||
1. 数据情况：
|
||||
1. 车辆销售：10000台
|
||||
2. app下载量：9500
|
||||
3. app注册量：8500
|
||||
4. 远控功能使用：6500
|
||||
5. 30日回访：1500
|
||||
2. 口径定义：
|
||||
1. 北极星指标：
|
||||
1. 30日回访率：30日内回访远程功能用户/新增注册用户数；
|
||||
2. 过程指标：
|
||||
1. app下载率：下载app的用户/新销售车辆数
|
||||
2. app注册率：app注册的用户/app下载用户数
|
||||
3. 远程控制使用率：曾使用远程控制功能的用户/app注册用户
|
||||
4. 回访率：回访远控功能的用户/曾使用远控功能的用户
|
||||
3. 问题分析：
|
||||
1. 漏斗图：
|
||||
1. 发现问题：
|
||||
1. 从车辆销售到app注册中间流失了1500名用户，比例较高；
|
||||
1. 可能原因1：门店没有按sop要求引导用户完成从app下载到注册的全过程；
|
||||
1. 验证的指标：按门店统计未完成注册的车辆情况，查看是否有店铺聚集；
|
||||
2. 解决方案：向门店进一步宣贯提车的sop要求，将app下载和注册率纳入门店考核(这里需要和门店运营协商)；
|
||||
3. 验证：宣贯后持续监控门店的未完成注册车辆占比是否下降；
|
||||
2. 可能原因2：注册步骤过于繁琐，导致用户不愿意完成注册；
|
||||
1. 验证指标：统计注册过程中，用户需要进行的实际操作步骤和操作时长的中位数；
|
||||
2. 解决方案：在保证合规的前提下，推动简化注册步骤；
|
||||
3. 验证：
|
||||
1. 设计A/B TEST实验，验证设计思路是否正确；
|
||||
2. 远控功能的使用率较低：
|
||||
1. 可能原因1: 对远控功能的宣贯不足，用户不了解该功能；
|
||||
1. 解决方案：增加对远控功能的宣传，比如增加手机app的推送信息，如：「夏天天热，可能尝试一下远程开启空调」；
|
||||
2. 验证：
|
||||
1. 设计A/B test实验，验证增加推送用户和未增加推送用户在远控功能的使用上是否有区别；
|
||||
2. 可能原因2: 远控功能入口不够明显，用户不太容易找到：
|
||||
1. 验证指标：统计进入远控功能界面，用户需要进行的实际操作步骤和操作时长的中位数；
|
||||
2. 解决方案：
|
||||
1. 推动app修改远控入口设计，增加远控功能的快捷入口；
|
||||
3. 验证：
|
||||
1. 统计用户通过快捷入口操作远控功能的比例；
|
||||
2. 统计修改前后用户使用远控功能的比率是否上升；
|
||||
3. 可能原因3: 用户确实没有远控功能的需求：
|
||||
1. 验证指标：
|
||||
1. 用户是否在实际用车中使用了远控提供的功能，如：用户在上车后是否在高温环境下有以下操作：
|
||||
1. 空调开启，但是乘客未上车，运行一段时间后，乘客才上车；
|
||||
2. 车辆刚启动时，空调风速开到最大，温度也设置的很低，行驶一段时间后，空调风速调小温度也调高；
|
||||
2. 在设想的使用场景下，远控功能的使用率是否有上升；
|
||||
2. 解决方案：
|
||||
1. 复盘并进一步下钻没有需求的用户情况，比如：用户年龄、用车地域等，分析总结产品定义的问题
|
||||
3. 30日回访率极低：
|
||||
1. 可能原因1: 用户使用的需求不足，同上一节的可能原因3；
|
||||
2. 可能原因2: 操作繁琐，同上一节的可能原因2；
|
||||
3. 可能原因3: 操作失败的概率较高，导致用户不愿意使用该功能：
|
||||
1. 验证指标：
|
||||
1. 远控设置成功率：远控功能设置成功的次数/用户设置远控功能的次数；
|
||||
2. 解决方案：
|
||||
1. 进一步下钻分析远控失败的原因，并推动业务部门进行修复：
|
||||
1. 用户请求远控之后，车辆是否整车唤醒；
|
||||
2. 唤醒后，TBOX是否正确发出了请求信息；
|
||||
3. 网关是否正确转发了请求信息；
|
||||
4. 控制器是否正确响应了对应的请求；
|
||||
5. 统计失败原因占比，如整车状态是否满足远控功能的使用前提，如电量/油量是否充足等；
|
||||
6. 前四项可以做成一个漏斗图，第五项可以做成饼状图；
|
||||
|
||||
|
||||
2. 数字钥匙：
|
||||
1. 数据情况：
|
||||
1. 车辆销售：10000台
|
||||
2. app下载量：9500
|
||||
3. app注册量：8500
|
||||
4. 数字钥匙注册：5000
|
||||
2. 口径：
|
||||
1. 北极星指标：
|
||||
1. 数字钥匙解锁渗透率：用户使用数字钥匙解锁车门的次数/用户解锁车门的总次数
|
||||
2. 辅助指标：数字钥匙使用用户占比：使用数字钥匙解锁车门的用户/数字钥匙注册用户数；
|
||||
3. 问题分析：
|
||||
|
||||
1. 数字钥匙注册量较低，从app注册到数字要是注册流失3500名用户，流失率41.2%；
|
||||
1. 可能原因1: 店铺未按sop要求引导用户完成数字钥匙的注册；
|
||||
1. 验证方法：按门店统计未完成注册的车辆情况，查看是否有店铺聚集；
|
||||
2. 解决方案：向门店进一步宣贯提车的sop要求，将数字钥匙注册率纳入门店考核(这里需要和门店运营协商)；
|
||||
3. 验证：宣贯后持续监控门店的未完成注册车辆占比是否下降；
|
||||
2. 可能原因2：注册数字钥匙过程过于繁琐导致用户放弃注册；
|
||||
1. 验证方法：统计在数字钥匙注册过程中，用户操作步骤的中位数和操作时长的中位数；
|
||||
2. 解决方案：
|
||||
1. 设计a/b test实验，验证注册过程繁琐是用户放弃注册的原因；
|
||||
2. 验证后，推动业务部门优化数字钥匙的注册流程；
|
||||
3. 验证方案：
|
||||
1. 除a/b test以外，在优化后流程上线后持续监测数字钥匙的注册率是否上升；
|
||||
3. 可能原因3: 手机品牌系统、蓝牙标准等差异导致注册时产生兼容性问题；
|
||||
1. 验证方法：按手机品牌、系统、蓝牙标准等方案对数字钥匙的注册情况进行统计，检查不同的品牌、系统之间是否存在注册差异；
|
||||
2. 解决方案：
|
||||
1. 对销量前20的手机进行专门适配，确保保有量大的手机可以稳定的使用数字钥匙功能；
|
||||
2. (假设)注册用户中，数字钥匙解锁渗透率低：
|
||||
1. 可能原因1：数字钥匙解锁成功率较低；
|
||||
1. 验证指标：验证流失用户(定义为：使用过数字钥匙解锁，之后30日之内未再使用该功能)在流失前曾遇到解锁失败的比例；
|
||||
2. 解决方法：
|
||||
1. 进一步下钻失败原因，探寻占比高的问题，推动业务方解决；
|
||||
1. 手机系统信息，如品牌、操作系统版本、蓝牙协议版本等；
|
||||
2. 蓝牙等信号强度变化情况，验证手机与车机连接稳定性；
|
||||
3. 车辆执行层：tbox、网关、执行器等故障状态；
|
||||
3. 验证方案：
|
||||
1. 持续监控问题优化后，数字钥匙解锁渗透率是否有上升；
|
||||
|
||||
3. 共性分析：
|
||||
1. 从用户画像角度分析用户对远控、数字钥匙等接受程度；
|
||||
1. 基本信息：按年龄、性别等基本信息对用户对远控、数字钥匙等功能的使用和接受程度进行拆分；
|
||||
2. 用户画像：
|
||||
1. 如在周一到周五期间，每日以较为固定的时间在两个坐标点之间行驶，可以打标签为「上班族」；
|
||||
2. 如在每次ota更新时，都在第一时刻更新，并在更新后立刻尝试新功能，可以打标为「科技达人」；
|
||||
3. 目的：为在未来面向不同目标用户的车型设计上提供指导意见；
|
||||
|
||||
Reference in New Issue
Block a user