1704851229
机器的优化不是一蹴而就的，需要一个不断改进的时间周期。在机器算法尚未完善前，产品经理应该给出一个保底方案作为基线。
1704851230
1704851231
以反低俗为例，在模型识别不好的时候，我们可以通过用户举报反馈、数据异常波动复审等方式拦截一部分低俗内容。以此作为基线保证用户的基础体验，留给机器学习和优化的时间。
1704851232
1704851233
第三，发现问题。
1704851234
1704851235
与其说是发现机器推荐的问题，不如说是发现产品经理在制定目标时存在偏差的问题。
1704851236
1704851237
在机器优化的过程中，往往会出现为了极致优化目标A，造成其他部分有损的情况。比如，目标设定的是优化用户的阅读完成度，那么机器执行后最直接的结果就是只推荐短文（一屏展现完毕，用户点击后就100%完成阅读）。这样的结果显然不是我们想要的。为了优化，我们需要进一步修正目标的设定方式。比如，内容至少要多于多少字，对哪些内容可豁免（如快讯），等等。
1704851238
1704851239
好的算法结果，既离不开优秀技术研发的实现，也离不开优秀产品经理的投入。
1704851240
1704851241
输给机器不冤，能训练出机器才重要。
1704851242
1704851243
数据分析驱动产品迭代
1704851244
1704851245
如果不能量化，就不要妄论优化。
1704851246
1704851247
随着MVP、growth hacking概念的日益普及，有越来越多的业务在产品迭代中应用了growth hacking的思路。然而在实践过程中，我们也发现了一些问题：设立独立的growth部门，在从业务咨询的角度帮助业务线做分析、提改进意见的时候，难免会出现不接地气、对应用场景缺乏足够了解等业务问题，也会出现随着公司膨胀带来的跨部门沟通协作等管理问题。
1704851248
1704851249
更好地解决这一问题的方法，莫过于产品经理和数据分析师角色的融合：产品经理能够更深度地从业务逻辑出发找问题，用数据分析的方法驱动产品迭代。
1704851250
1704851251
确定核心指标
1704851252
1704851253
“不只为做而做”，产品经理所提出的优化和迭代应该建立在服务核心目标上，即保证所有做的功能，是致力于改进核心指标而不是局部业务指标的。比如，不能为了追平竞品功能，就盲目地给自己的产品画蛇添足。追加的功能，即使功能指标不错，也必须考虑其对核心指标的影响。
1704851254
1704851255
1704851256
1704851257
1704851258
图8–2 友盟后台指标摘录示例
1704851259
1704851260
以图8–2为例，图中的各个指标是从友盟后台随意摘录的，在这些指标里，哪个才是一款产品的核心指标呢？
1704851261
1704851262
我个人给出的答案是：有价值用户的长期留存。
1704851263
1704851264
1704851265
1704851266
1704851267
图8–3 产品的有价值用户和留存拆解
1704851268
1704851269
下面我们将结合图8–3来做简单的拆解。有价值的用户是指能够最终给公司带来收入的用户，长期留存可以保证收入的稳定性和可持续性。
1704851270
1704851271
在价值的定义上，根据具体付费方的不同，可以大致分为C（消费者）端收费、B（企业）端收费，在不同的产品中，其盈利方式和有价值用户的定义会有所不同。
1704851272
1704851273
• 以信息流产品为例，有价值的用户可能是那些点击或浏览信息流广告的用户。
1704851274
1704851275
• 以游戏产品为例，有价值的用户可能是付费的“氪金”玩家。
1704851276
1704851277
• 以直播产品为例，有价值的用户可能是打赏的金主。
1704851278