25 | 突发式流量数据暴跌，产品经理应该如何应对？【处理篇】

一直对产品的数据分析感兴趣，我来分享一下我最近学到的方法。 1、用户分析 用户画像分析是获取目标用户的主要方法，也是数据分析里很重要的一部分。一般常见的性别、年龄、低于、职业等信息给用户打上一个个的标签，标签越是精准，越是能对精准化营销起到关键性的因素，据说LinkedIn给用户的标签做的十分精准，所以它的广告系统可以做到几十个亿的收入，而国内的一家用户几亿的厂子，广告系统每年的收入只有千万左右的水平。 再比如说京东、淘宝，他们甚至可以预测你接下来要买什么商品，通过短信、push和首页对用户进行精准的推荐。 2、数据埋点 对数据的埋点监控是从产品诞生的第一天就要开始去做，即使数量小，也能对产品迭代、运营活动都起到至关重要的作用。 对于app来说，每个页面和跳转位置都要放置合理的数据埋点，来监测用户行为，DAU、MAU、Interactions、访问深度等等就是我们需要着重观察的数据，app的数据监控更适合从账户体系着手，每个用户就是独立的个体，用户独立的访问行为； 结合精准的用户画像分析就能分析出不同用户的访问行为，得出产品迭代的方向。 3、收入（转化）监控： 每个产品的最终目的都是商业化，对收入的监控，也会对产品迭代起着重要的影响，同一条赛道内，哪个产品最先增强了变现能力，基本就赢得了赛道。 日常监控的数据一般是收入流水、盈利、盈利率（同比、环比）、客单价、用户首次付费、2次付费数、留存率等等。 这类数据保密性都比较高，都会写在后台数据库中，所以数据产品运营人员都要有SQL的基础能力，这样才方便读取数据。（所说到这，希望极客时间快点出SQL的专栏） 手机码字有点累，先这样，我坚信数据会说话，不论是技术、产品或运营，保持数据敏感度十分重要。

我今天特地回看了一遍专栏框架，现在是第三章，产品经理的数据意识，转眼就一半了。 我对数据不是那么痴迷，但一直认为这是必不可少的分析依据。之前创业时，App 是外包的，虽说后期版本公司来负责，但并没有人能够完整说出分析逻辑与框架，以及当前的基础数据。第一反应就是纳闷，原来产品都是这么做出来的，后来一想，这不是自己的机会嘛。 然后，在新版上面加入了第三方工具，而后发现我们订单的取消数量占比太高，约 35%，进而发现支付流程存在问题，资源锁定型产品在选择时会存在问题，进入确认订单与返回提示容易误点，导致那些不愿意下单的用户，一定要撤单之后才能重新选择。 确认问题后，我们开会讨论，最终改变了原有逻辑。目前的占比下降了 20%，效果还不错。

有启发。

被同事推荐购买课程~ 这一章节大概学到两点： 1、有效沟通的必要性，对于结论性的回答要有依据，对于问题要有解决方案。 2、对于数据问题的解决方案，可以从短期修复为主，中期监控和预警为辅，那么长期就要考虑这个问题本身的权重，是否需要调整业务模式等。

越来越觉得产品经理该是个多面手了，也得是半个数据分析师啦，哈哈，数据中都隐藏着需求，以及做过的需求的不足之处

这几节基于问题的数据分析连贯听下来感觉很是舒畅，有一种在茶馆听说书人“娓娓道来”的感觉。 对比这一节的内容，严谨而有应用价值的数据报告确实有必要性形成习惯。 而短中长期的应对措施和策略更是让我有醍醐灌顶是感觉，之前遇到数据问题是总是有种“好像忘了什么事情没有做却又想不起来是哪一个”，这次才发现是只做短中期的措施、忽略了长期的动作😂😂

之前遇到过要把处于成长期用户转换成成熟期用户(公司主要价值来源)的一个任务，我也是通过数据分析两个用户行为有什么不同，后来发现处于成熟期的用户他们参加团体赛频率比成长期用户要高很多。 所以当时我们提出假设，如果能引入社交关系，会加快用户转换。当时我们也面临两个选择，一个是通过组建社群来实现，另一个是通过开发俱乐部系统来实现。我们选择了几个核心要素，比如开发时常，预期效果等进行打分，最终选择了组建社群，一段时间后将转换率提高了20%

整个数据分析邮件的结构就是很典型的金字塔法则