极客时间的专栏读者你好，我是邱岳。我们继续来分享与产品经理数据能力相关的内容。
我们在前面的文章中假设了一个场景，想要通过构建自己的流量池，摆脱对搜索引擎流量的绝对依赖，在我们决策究竟是做工具还是做社区的时候，需要数据来做辅助的判断。
在上一次的分享前，我们提到在开始决策前，需要先收集横向和纵向的数据来设定目标数字。
这次我们接着上次的话题，进入到具体业务细节，来看数据如何辅助我们做出决策，以及如何追踪决策成果。
为了防止空对空，我们干脆把故事编得再具体一点，我们假设“极客时间”需要构建流量池，那么应当投入做开发者社区还是开发者工具呢？
我在这里首先要做个免责声明，一方面我并不知道极客时间的具体运营数字，另外一方面，产品方向性决策与团队能力结构，以及经验有很大关系，所以仅作为故事背景使用。好了，声明结束，我们可以继续了。
在上一季专栏中，我们曾经分享过需求价值分析的框架，就是依次去问三个问题，用户是谁，用户有什么问题，我们提供什么解决方案。在这个情境中，我们的数据分析依然会围绕这三个部分来展开。
我们曾经提到过希望构建的流量池可以给带来“精准用户”，这对应在我们设计的情境中，指的就是希望新做的产品特性带来的用户，与极客时间当前的用户相近。
所以我们的第一个问题，就是要想办法了解群体用户的画像，将“用户是谁”这个问题数据化。我们之前从“用户画像”的角度，介绍过这个问题的解决方案，这次我们就从数据的角度看一看。
有两类数据用来描述用户，一种是可以直接获得的属性数据，另一种是需要分析的行为数据。
前一种数据可以直接来自用户提交的表单（比如性别年龄等等基本属性），也可以来自于调研，或者一些第三方数据机构提供的用户画像，总之，这样的数据内容通常只需要做汇总统计，就可以得到结论。
后一种数据需要根据用户的行为数据进行分析和推测，比如我们可以观察用户访问产品的时间段，以及订阅专栏的种类，将专栏内容的标签传递给用户。
比如用户订阅了 Python 和 AI 相关的专栏，我们可以推测他可能对机器学习算法感兴趣，比如用户订阅了多个相对简单通用的专栏，那他可能还处于初学阶段，如果他订阅了一些专业性更强的专栏，那或许他已经有一定的开发经验，等等。
这个过程跟我们在前面“流量骤降”的情境中，提到的“用行为数据做用户分类”很像，目的是在决策过程中，更好地去判断决策到底靠不靠谱。
比如，我们现在要确定社区的信息架构，有一种方法是按照语言来组织社区，那我们可以去分析不同语言用户的交叉程度。如果这时，我们发现大部分用户都是跨语言的，那或许这样的组织形式就可能给他们带来不便。
知道用户是谁之后，再反向去考虑他们未被满足的需求是什么，从而在其中寻找机会构建我们的流量池。
理解需求的过程中，跟数据相关的也是两类，一类是通过调研、访谈和客服等各种渠道收集的用户反馈，另一种还是通过用户行为去分析和推测。
前一种不展开说了，后一种比较有趣，就是如何通过各种蛛丝马迹去推测用户需要什么。我在这里给大家介绍几个有意思的方法。
第一个是去看搜索记录。 大部分产品都会有搜索框，即便没有，也可以去看通过搜索引擎进来的流量上面标记的搜索词。搜索是表达用户动机的一扇非常直接的窗户。它除了可以帮助我们在构建流量池的时候探索用户需求，也可以帮助我们发现更多的机会。
我之前听说有个公司从自己产品的搜索记录里发现，有大量的工作岗位和商品的搜索，于是就做了招聘和电商产品，结果大获成功。
我之前负责某条电商产品的时候，也曾经通过搜索引擎流量标记的搜索词，发现有很多人在搜“xxx 多少钱”这样的东西，于是便规划了一系列跟价格相关的的工具和运营活动，成果也不错。
第二个是从产品假设出发，去寻找逻辑上的“反对意见”。 比如我们想建社区，需要让用户产生内容，那我们的用户是否有足够的表达欲望和行动力呢？想要回答这个问题，我们可以去找行为数据。
这里有一个小诀窍是去找“反对意见”。 因为一旦我们建立假设，提出问题，便有了立场和期望，在这种情况下，当我们收集数据时，就很容易倾向于收集那些能够支持我们决定的信息，从而忽略那些与我们想法相矛盾的证据。
所以当我们形成假设之后，要格式化我们的出发点，尽可能去找能够反驳假设的数据。比如刚才我提到的表达欲望，我们可能会去找用户分享、点赞或评论的频率和比例，甚至去看内容的长度和情绪倾向，并试图证明，用户并没有旺盛的分享欲望。
带着这样的出发点如果依然无法驳斥“用户具有旺盛表达欲”这样的推测时，那我们便可以认为，这一推测成立。
顺便多说一句，这种左右互搏除了发生在自己脑子里之外，也可以发生在同事之间。不要追求那种一团和气的需求讨论会，不断地挑战和质疑才是锤炼需求的最好途径。
第三个方法是去看抽样用户的具体行为轨迹，建立猜想，再倒推回去看整体数据。 这个过程操作起来很有趣味性，方法就是花上一天，不断去抽单个用户的行为轨迹去观察，看看他到了哪里、点了什么、停了多久、又跳去了哪里，等等。
然后像一个戏精附体一样，去把自己塞进用户的脑子里，想象他每一步的处境和心理活动——他为什么打开文章页，快速地滑了一下就退出了？他为什么在搜索结果页停留了这么久？他为什么排着给所有的评论都点了赞？
在这个过程中，可能会发现一些奇怪的行为模式，这时可以返回去整体找一下类似的行为模式是否普遍，如果类似的行为模式只是个别现象可以不用管，但如果有很多，就需要我们去进一步思考和探索原因。
当我们从数据了解用户的需求之后，就可以开始考虑我们提供何种解决方案了。
在设计的情境中，我们可以选择做开发工具，也可以选择做社区。这时跟数据相关的有两个问题，一是竞争现状，二是触达效率。
竞争现状很好理解，比如我们推算用户需求，发现对于工程师来说，需要线上文档协作工具，我们不能直接开工，而应当先去研究一下是不是已经有类似的工具存在，最好能看看市场和用户数据，判断一下是否已经形成垄断了。
如果拿不到宏观数据，我们也可以在自己用户范围里做一些调研和访谈。很多人在做东西之前不研究市场，这其实是个不太好的习惯。
至于触达效率，因为我们想要做的是能够成为流量发动机的产品，所以我们希望它自己可以拥有触达能力，换句话说就是希望它可以自己能独立获取流量。那我们就需要在逻辑和数据上大概推断它自身的流量能力，通常包括自己的获客和留存。
如果大家还记得的话，这时我们需要用到的技能，就是在本季专栏开头讲到的：怎样快速验证产品创意部分的内容了。我们可以用 MVP 做一些测试，快速验证我们的假设，判断方向性的选择是否值得继续重兵投入。
我们从测试中得到支撑之后就可以开始投资源做事情了。
回到我们设计的场景，我们假设从用户的注册和行为数据中，判断极客时间的用户群体主要为工作 1-3 年的一线开发工程师，他们能够稳定投入时间进行学习，而且发现他们在学习的过程中有大量的分享、评论和点赞行为，所以，我们认为他们能够产出内容，并且有分享和交流的动机。
于是我们研究了市面上现有的开发者社区，发现现有产品没有形成垄断，也不能完全满足用户需求，在做了一些小范围测试之后，我们决定在极客时间的内容产品之外，再建立一个社区。
我们希望可以从极客时间当前产品中导入启动用户和内容，并希望社区逐渐具备自行获客和留存的能力，最终反哺当前的商业产品。
根据上一次分享的内容，我们可以给它设置几个目标，比如我们希望它的留存率和新用户数能够超过当前产品。
在此之后，我们就可以定义产品开工干活了，在定义产品的过程中，我们可能依然需要不断回来反查数据，支撑我们具体的特性选择，其实一旦我们形成了良好的数据思维，应当看什么数据，以及怎样通过数据支撑决策，就会变成自然而然的习惯，决策可靠性和成功率便会逐渐提高。
今天我们分享了“用数据辅助你的产品决策”的相关内容，我假设了一个案例，以“极客时间需要做流量池”出发，通过具体的业务细节，来看数据如何辅助我们做出决策。首先，我们通过数据来了解“极客时间”的用户是谁，这里有两类数据用来描述用户，一种是可以直接获得的属性数据，另一种是需要分析的行为数据。
接下来我们通过数据去了解用户的需求，这里我介绍了三个有意思的方法，大家可以尝试一下。得到了需求之后，我们来看看自己能够提供什么样解决方案，具体是做工具还是做社区。
在我们定义产品的过程中，我们可能依然需要不断回来反查数据，支撑我们具体的特性选择。
在我们今天的虚拟案例中，你关注了哪些细节，又有哪些思考呢，你可以给我留言，我们一起讨论，感谢你的收听，我们下期再见。
评论