分享我在数据分析上所建立的思考架构， 而这个思考架构包含了从服务流程的盘点、到数据的建立、再到场景的规划、反覆的实验 。 让产品可以真的因为数据被优化，而不是产品产生的数据造成我们日常做事的困扰。 Medium好读版 : https://reurl.cc/DAOD7R -- 数据在组织中的现况 企业中大家都知道数据的重要性，但一路走来发现很多的PM，甚至是主管对於如何藉由数 据来策略性的推动产品，都还没办法较深入有脉络去运作。 通常组织都会胡乱地埋了一堆数据，网页用GA、App用flurry等，有用外部solution的可 能就看後台提供的资讯，现今的科技复杂度与商业复合运作模式下有这些分散的流程是很 正常的，但是如果没有一个统整的面向来看待整体的用户旅程的话，很可能就只是在建一 堆数据孤岛，然後在某些时候数据出事的时候，再惊慌失措地找原因，但在追踪这些孤岛 时却只增加了疑惑，却找不到可能的解答。 一部份是因为大家的分工趋於精细，行销做获客或是内容经营，产品可能是注意留存或是 部份的转换，然後不同的角色升上主管职，就会以过往的习惯来执行，大部份时候服务流 程需要改善的点是行销、有时候需要改善的点是产品。 举例: 产品升上来的主管，可能继续用产品内的视角在看整体服务流程，但问题可能是出在获客 。 行销升上来的主管，可能用行销的视角在看，但问题可能在於用户留不住，再怎麽寄edm 给用户，还是止不住往下掉的数据。 捧LP上去的主管，就是用各种巧妙的言论来躲避无能运作的事实，久而久之，上司觉得做 得很好，问题都有控制住，然後荣升产品长(可能无误?)。 虽然要产品出身的看行销，或是行销出身看产品，这些事情有点残忍。但我认为只是更有 意识的去认知到服务流程中，哪里出了问题，要去优化时，可以更通盘的去看待整个局面 ，然後进到细节处理的时候，再与相关同仁以逻辑来处理相关议题。因为只要没有整体的 视野，大家很容易各做各的，这对於用户来说，只是一盘散沙的经营。 我会在底下提出方法供大家参考，它会从最一开始的盘点服务流程、数据建置、定义规划 方向、规划执行与反覆实验，藉由这些步骤，可以去反思在工作流程中，怎麽更有脉络的 去定义要优化的策略、钻研的议题、观察实验结果是否有用。另一部份也能藉由数据让团 队同仁可以有更多的机会互相交流与讨论，提升团队感同时也在专案运作上可以有更多不 同的火花。 盘点服务流程 在现有的业务流程下，主管或是业务同仁通常会用过往习惯的做法来执行，而过往习惯的 做法通常是拍脑袋想出来的，而那时可能有成效，所以就一直沿袭下来了。不是说沿袭传 统不好，而是当时代与环境在变动时，要有方法可以重新省视与评估是否有更有效益的做 法，或是该换一条路的机制存在。 通常我会使用大家都知道的AARRR来当基底，看待整体服务流程。 补充:AARRR为Acquisition、Aha-moment(Activation)、Retention、Referral、Revenue 这五个单字。 意指我们获取用户後，用户有使用的动机，然後愿意持续留下来，愿意付钱、好到足以推 荐给其他人的概念。 而根据上述的框架，来看整体的流程结构，就能够更有概念的去思考如何推进。因为现有 的商业模式或是服务流程，当初在形成的时候不一定是很有条理，也不太可能有条理。但 是想要更完整的去探索，或完善商业模式，没条理就看运气，没运气就是各种规划资源与 工程资源砸到水里。 以订阅制的选股软体举例，藉由这些面向来看待服务流程 : A(获客):获取用户时可能用SEO、投广、社群经营、app自然流量 A(Aha-moment):这个产品独到的选股方式是用户最买单的内容 R(回访):用户买卖股票频率为1~2天就应该回来 R(利润):多少用户续订、新订，订阅中的流程怎麽走 R(推荐):有没有对应的推荐机制 从这样的大项目里面就可以再去拆解细节流程， A(获客):(下面建置数据再提) A(Aha-moment):用户在旅程或产品流程中，什麽样的节点会碰到或是认知到这件事? R(回访):(下面建置数据再提) R(利润):我们现有流程或机制是怎麽让新用户做订阅， 旧流程中用户最喜欢用的功能是什麽，最买单的是什麽? R(推荐):用户要推荐APP，或是分享炫耀自己股票，有没有哪些点在执行 而在这些流程盘点完後，对於一个用户怎麽进来，怎麽留下，怎麽离开，团队的心里应该 就会有概念的认知了，但具体用户到底认同我们服务中的什麽机制、不认同什麽，哪一些 和我们预料的有落差，目前还不得而知，而要知道这些资讯，则需要数据来呈现，让我们 可以往更实际的行动方针迈进。接下来在这些节点上是否有可追踪的数据，就进数据建置 的部份了。 数据建置 到这个步骤就以上述了解到的流程，进而确认在对应服务流程的节点上，是否有对应的数 据，让这些数据可以清楚明了的把用户的流程铺张出来，後续才能够对用户做更有根据的 猜想。另一方面也在这个阶段去初步盘点目前有的数据，对这些数据的联想是什麽，是否 有些也可额外记录的(如果技术允许的话)，有可能会帮助到後面的步骤产生洞见。 A(获客) SEO : 现在透过搜寻进来的流量多少? 投广 : 从广告来的用户多少，成本多少? 社群经营 : FB社团上每周新增多少人?大家文章互动的频率?导流时可以转换多少? App自然流量 : 每周下载app多少人?卸载多少人? App内转换 : 注册成会员的有多少人?新访客在产品内页面点注册的怎麽点、多少人? A(Aha-moment) 团队觉得最核心的功能，新用户触及到的比率高吗?每周新用户碰了几次?每天新用户碰几 次? 在提供的服务流程上，有没有哭哭moment，就是我们设计A->B->C三个流程给用户走，在A 有100人，走到B剩25人，走到C剩10人。这种流程上的节点都是要去记录，也包含节点周 遭的一切其他入口，因为常常会有"我们以为的用户"和真实用户的差异，这些点在建置阶 段可以稍做概括。 R(回访) 用户的留存率多少?日周月分别是怎麽样的情形(这边没有绝对的数值，业界都市传说40%( 日)–20%(周)–10%(日)，但随着不同产品场景会有巨大差异，有些KOL的选股软体可能可 以到60~80%的日回访) 未订阅用户的留存? 已订阅用户的留存? R($$$) 新用户: 用户会在什麽地方买单?怎麽买? 我们的试用机制是什麽?他一路走的节点，我们有办法都抓到吗? 订户: 续订率多少?订户主要在用的功能是什麽?那边流程顺吗? 用户流失的原因是什麽?有没有相关记录的机制，来知道用户离我们而去是未什麽?(例如: 问卷、用户怎麽离开页面、具体怎麽使用) R(推荐) 用户有没有什麽炫耀机制?或是在行销上有哪些可以拉客的制度? 上述只是暂提几项提供参考，实际以公司的业务流程来做考量，评估要去记录用户的什麽 数据，可以让团队更有脉络的知道用户在干嘛。经过流程盘点和数据建置後，我们基本上 可以完整的一窥用户从哪个渠道来，来多少，为什麽而用，用什麽，用户为了什麽原因而 买，又为什麽而离去。这些轮廓就可以被更完整的描绘了，而下一步也就可以进到定义规 划方向。 定义规划方向 当我们服务流程定义好，数据也建置完之後。我们基本上对於整个用户旅程会有更完整的 了解，这时候也才有办法具体的知道该往什麽方向推进。而且在推进的方向上才能知道细 节怎麽环环相扣。 一开始我们会从比较大的数据来观看， A(获客):各渠道来的流量 A(Aha-moment):新用户的留存率 R(回访):用户买卖股票频率为1~2天就应该回来 R(利润):多少用户续订、新订，订阅中的流程怎麽走 R(推荐):有没有对应的推荐机制，有多少人推荐出去 在全面看过数据之後，有可能你们的产品相对市场好很多，但知道的人还不多，那就可以 聚焦於获客，在上面提到的SEO、投广、经营粉丝团等渠道，即使产品人无法更细节知道 行销该怎麽做，就直接找团队内的行销同仁来讨论(或是自学…当一个成长骇客)。 也可能投广投的天荒地老、也一直在耕内容让用户流进来，但是产品内的留存率很低，或 是很多人玩了产品不订阅，那这时就是更细节去思考产品里面到底是哪里出了问题，有可 能是UX，也可能是产品定位不对劲，这些都是可能的面向。 但是当你能够有脉络的说出各个面向的数据，通常团队同仁一定也会有相当想法可以和你 讨论，这时产品的氛围和方向就会很棒了。那当我们定义好方向之後，就可以进到更细节 的规划！ 规划执行与反覆实验 通常在前一个阶段定义好方向後，这阶段已经会是比较针对性的问题来求解。在规划求解 的过程中，一定至少会有一个明确的预测会变好的指标，在实验後可以去观察确认的。 例如说: 发现获客部份能做的不多，然後留存转换还有很多可以努力的。 数据发现，新订用户每周只增加50个，但是非订阅用户的活跃人数每周有1万个，日活跃 还60%，那这就代表这产品大家玩得很开心，但是付费、试用机制可能没有做好，那我们 可能就在更多用户常用常点击的核心功能上，加上更严格的使用次数或是使用时间。那我 们的指标就是新订用户要能够大幅增加！ 在这个阶段要规划，尽量让变因相对少，因为这阶段即使我们看了数据，所提出来的概念 都还是假说，一个假说在实验时，如果有很多变因，那麽结果出来会无从验证，甚至做的 不好也不知道到底是哪里出错了。 所以以上面的例子，我可能在A页面加一个次数限制，sprint的时间还够，就在B页面的流 程略改(如果两方在用户使用上不太冲突的话)，然後在上线後，给一段时间做观察，看产 品的用户使用频率，使用场景越高频的用户，可能几天到一周，数据就能明显出来了，数 据出来後证明这个实验的假设是否正确，不过是正确或是错误的都是好事，因为这代表你 已经在探索产品的可能性了，你可能试错了3个sprints，但只要做对一次，那是未来几年 都能以有效益的方式去运作，这报酬风险比非常高，很值得做的! 小结 使用数据分析来优化服务流程，其实是一个算是缜密且有结构与步骤的科学实验，但是这 个思考架构掌握之後，其实对於组织内，不光是产品，很多的商业模式，其实都能够用这 样的架构去思考优化。 如果你是一个PO，那在产品上会更清晰的知道往什麽地方走，这同时能帮助到团队，让团 队知道为什麽而忙，同时也能帮助到用户，藉由用户下意识的行为，为他们打造更好的服 务体验。 如果你是一个PM，提出这些脉络在给管理者时，也能够有更充足的资讯让管理者去做出好 的决策。 希望数据在我们的产品路上，可以是解决问题的神兵利器，而不是只在抄抄写写的绊脚石 ！ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.137.139.99 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1688473694.A.CF8.html