众所周知，用户生命周期一般分为新手期、成熟期、衰退期以及丢失期。
想做用户增加的同学，给予的增加战略便是拉升新用户，稳固老用户，下降衰退期用户去到丢失期，想尽全部办法拯救已丢失的客户。
所以就有了用户监控系统，新用户增加趋势、活泼用户趋势、丢失率趋势等等。
每逢新用户增加趋势拉高，快乐不得了。
每逢活泼用户数在削减，拉着苦逼的脸。
每逢看到丢失率今天又提高了，心中那个苦楚。
苦楚的不是丢失率提高，而是丢失率提高了2%，3%的时分，领导一向追着问“丢失的原因是什么？”“别跟我天天报数据，说原因！”
这些都是做数据的同学，每天都要面临的苦逼场景。
用户剖析的误区1：丢失率提高了2%，原因是什么？
做数据的同学，很少能够实在接触到事务，更不必说接触到用户了。
能够靠近事务的数据同学，最多也只能打个电话多问问产品司理或许产品运营，用户为啥丢失了。
例如，理论上假如咱们知道了用户丢失的每个原因，咱们就能对症下药了。
产品不好用，丢失了，行，那咱们优化产品。
服务不够好，丢失了，行，那咱们主张服务规范系统。
价格没优势，丢失了，行，那咱们做一波回馈老客户的活动。
好像全部都没有什么问题，无非便是如此嘛。
可实践中，或许你也这么做了，但用户依然在不断丢失，从此堕入自我置疑中。
咱们要清晰一个观念，每一个产品都会有用户丢失，这是不能以个人毅力为搬运的，所以咱们没有每天纠结丢失率是增是降，需求重视的是丢失率的动摇是否合理。
丢失率今天提高2%，明日下降3%，后台又提高3%，请问阐明晰什么问题？
并不能阐明问题，咱们只需求重视这个丢失率是否在合理规模内即可。
假定咱们的丢失率在8%内归于合理规模，那只需丢失率不超越8%，咱们都无需放太多精力做细化剖析。
假如有一天超越了8%，那咱们就需求对问题进行拆解，是流量下滑了，是产品bug了，是价格变动了，是商场变化了，逐项剖析即可。
用户剖析的误区2：想知道每个丢失用户详细的丢失原因。
诚如上面举的比如，知道了每个用户丢失的原因，对症下药就好。
但作用或许并不抱负。
原因在于咱们很难知道每个用户丢失的原因，有些用户便是单纯的不想用了，莫非你还非要匹配一个丢失原因吗？
假如丢失率在合理规模内，主张无需深入剖析。
假如某个时刻点上，丢失率猛增，必定会有某个特别原因导致，此刻比较合适深入剖析。
例如，商场上呈现了一个全新的竞品，且价格以及产品体会优于自家产品，导致本应续费的客户没有续费，转向新竞品了。
这样的丢失场景就需求做深入剖析，将新竞品从产品架构、功用列表、对标自家产品优劣势以及价格比照等维度，扒个干干净净，然后拟定对立战略并继续调查丢失率是否降下来。
还有别的一个原因便是信息实在度。
例如，做数据的同学想要知道丢失原因，所以打电话给产品司理或许产品运营了解，产品侧同学又打电话给事务侧同学，事务侧运营又打电话给出售。
经过这种层层搜集和反应的信息，实在度真的牢靠吗，尤其是出售端反应的。
不得不提一句，许多出售端人员十分恶感这种影响自己做成绩的作业，他们连自己的CRM信息都不想填，况且仍是这种非量化的信息，几乎能够脑袋一拍，张嘴就来。
所以，搜集上来的丢失原因只是只能做为参阅，依然需求数据同学自己拉数据去验证这些丢失的原因。
整个进程繁琐冗长，但不出活，一次两次之后，其他部分配合度就会下降了，实在性或许就更差了。
总结下，用户丢失是不可避免的，咱们需求把它控制在合理规模即可，别每天盯着几个百分点苦逼考虑原因，或许你的剖析陈述还没写完，丢失率又降下来了。用户丢失的原因无法尽知，只能依托于事务线反应的丢失头绪，靠自己用数据佐证，无法佐证的丢失头绪说不准便是用户单纯的不想用了，不必太纠结，眼光向前看。
上一年今天运营文章2022:【训练】新司理培育系统(0)2022:裁人之下，大厂想要什么人？(0)2021:头条查找SEO敞开SiteMap提交功用，没有存案的网站也能提交了！(0)2021:想玩常识付费项目先看这篇水文(0)2021:闻名编程技术共享网站被罚款50万!(0)
微信扫一扫 
支付宝扫一扫 
