|
|
# 05 | 通过一个 AI 产品的落地，掌握产品经理工作全流程
|
|
|
|
|
|
你好，我是海丰。
|
|
|
|
|
|
对于任何一家互联网公司来说，用户流失都是我们必须要关注的一个问题。就拿我们公司的电商平台来说，一个很常见的问题就是，新用户的增长逐年缓慢，同时还伴随着老用户的不断流失。当遇到这种情况的时候，作为产品经理，我们该采取哪些措施，来降低用户的流失率呢？
|
|
|
|
|
|
今天，我就通过我曾经主导过的一个预测用户流失的项目，带你了解一个 AI 产品从筹备到上线的全流程。从中，你可以体会到 AI 产品经理的完整工作流程是什么，每一个环节都有什么角色参与，每个角色需要做什么工作，他们的产出又都是什么。这能让你明白自身能力和岗位之间的差距，也是你自己主导一个 AI 产品的时候，可以用来借鉴和参考的。
|
|
|
|
|
|
不过，我今天讲的上线流程是基于我们公司的业务场景和经验总结出来的，不能保证和所有公司的流程都一致，但无论如何，我们做事的底层逻辑都是一样的。
|
|
|
|
|
|
话不多说，我们正式开始今天的课程吧！
|
|
|
|
|
|
## 业务背景
|
|
|
|
|
|
我们公司是一个电商平台，有段时间我们发现，每个月老用户流失的数量已经远高于新用户的拉新数量，为了防止这个缺口越来越大，我们决定对可能流失的用户做提前预警，同时采取一些措施来挽留这些用户，实现这个目标的前提就是要开发一套用于预测流失用户的产品。
|
|
|
|
|
|
那具体怎么做呢？我先把我们当时开发这个产品的流程放在下面。接下来，我再分步骤给你详细讲讲，每一步我们都是怎么做的，以及要重点注意什么。
|
|
|
|
|
|
|
|
|
|
|
|
## 产品定义
|
|
|
|
|
|
当决定实现这个产品之后，首先我们要做的就是定义产品需求，明确做这件事情的背景、价值、以及预期目标都是什么。
|
|
|
|
|
|
在这个环节中，我们会和业务方共同沟通，来决定我们的业务预期目标是什么，期望什么时候上线。这里，我提到的业务方可能是运营同学，也可能是商务同学，这和你是一个 ToC 还是 ToB 的产品经理相关。
|
|
|
|
|
|
在这个预测用户流失的项目中，我的业务方就是运营，我们的期望是通过算法找出高流失可能性的人群，对这些人进行定向发券召回。这个项目的最终目标是，通过对高流失可能性的人群进行干预，让他们和没被干预过的人群相比，流失率降低 5%。
|
|
|
|
|
|
同时，由于我们运营计划是按月为节奏的，所以这个模型可以定义为离线模型，按月更新，每月月初预测一批流失人群。并且，我还期望这个模型的覆盖率能够达到 100%，让它可以对我们业务线所有用户进行预测。这些就是我们对模型的更新周期、离线/实时模式、覆盖率等相关要求了，我们需要把它们都记录到一份需求文档中。
|
|
|
|
|
|
## 技术预研
|
|
|
|
|
|
需求确定之后，产品经理需要和算法同学进行沟通，请算法同学对需求进行预判。具体来说，就是要判断目前积累的数据和沉淀的算法，是否可以达到我们的业务需求。如果现有数据量和数据维度不能满足算法模型的训练要求，那产品经理还需要协助算法同学进行数据获取，也就是后面我们要说的数据准备工作。
|
|
|
|
|
|
当然，**即使数据达到算法的需求，产品经理也还是需要协助算法同学做数据准备，因为垂直业务线的产品经理更了解本领域的数据。**
|
|
|
|
|
|
另外，在这个环节中，你可能还需要根据算法的预估，对需求的内容进行调整。比如，我们原定覆盖率为 100%，但是和算法同学沟通后发现，有部分刚刚注册的新用户是没有任何数据的。对于这部分人，算法无法正常打分，而且新用户也不在流失用户干预范围内，所以，我们后面会根据目前新老用户比例得到新的覆盖率指标，再把它放到需求中去。
|
|
|
|
|
|
## 数据准备
|
|
|
|
|
|
然后，我们就进入数据准备的环节了。这个环节，我们需要根据模型预研的结果以及公司的实际情况，帮助算法同学准备数据。
|
|
|
|
|
|
原因我们刚才也说了，就是因为产品经理基于对业务的理解，能判断哪些数据集更具备代表性。而算法同学，只能根据现有的数据去分析这些数据对模型是否有用，因为有些业务数据算法同学是想不到，所以自然不会去申请相关数据权限，也就不会分析这部分数据存在的特征。
|
|
|
|
|
|
比如说，我们在过去的用户调研中发现，用户一旦有过客诉并且没有解决，那么大概率会流失。如果出现了客诉，用户问题得到了很好地解决，反而可能成为高粘性的客户。这时候，我们就会把客诉数据提供给算法同学，请他们去申请数据表权限，评估数据是否可用。反之，如果我们没有把这些信息同步给算法同学，那么很可能我们就缺失了一个重要的特征。
|
|
|
|
|
|
在数据准备的部分，由于数据的不同，我们的获取方式也会有很大的差别。总的来说，数据可以分为三类，分别是内部业务数据、跨部门集团内数据以及外部采购的数据。接下来，我就分别说说这些数据怎么获取。
|
|
|
|
|
|
**1\. 获取内部业务数据**
|
|
|
|
|
|
内部数据是指部门内的业务数据，如我们的订单数据、访问日志，这些都可以直接从数仓中获取。当然还有一些情况是，我们想要的数据目前没有，你可以提需求让工程研发同学留存相关数据，比如，之前有些用户的行为数据没有留存，那我们就需要增加埋点将这些数据留存下来。
|
|
|
|
|
|
**2\. 获取跨部门集团内数据**
|
|
|
|
|
|
跨部门集团内数据指的是其他部门的业务数据，或者是统一的中台数据，这些数据需要我们根据公司数据管理规范按流程提取。在提取数据的时候，我们需要注意结合业务情况去判断该提取哪些数据。
|
|
|
|
|
|
**3\. 获取外采数据**
|
|
|
|
|
|
最后是外采数据的获取。在公司自己的数据不足以满足建模要求时候，我们可以考虑购买外部公司数据，或者直接去其他拥有数据的公司进行联合建模。
|
|
|
|
|
|
这个时候 ，我们就需要知道市场上不同的公司都能够提供什么。比如极光、友盟提供的是开发者服务，所以它们可以提供一些和 App 相关的用户画像等数据服务，再比如运营商可以提供和手机通话、上网流量、话费等相关数据等等。
|
|
|
|
|
|
直接采购外部数据非常方便，但我们一定要注意，出于对数据安全和消费者隐私保护的考虑，我们和第三方公司的所有合作都需要经过公司法务的审核，避免采购到不合规的数据产品，对自己的业务和公司造成不好的影响。比如说，在用户流失预测模型这个项目中，我们可以去调研自己的用户近期是否下载了竞品的 App，或者经常使用竞品 App，这都可以作为用户可能流失的一个特征。
|
|
|
|
|
|
当然，**在数据准备的环节中，我希望你不仅能根据算法的要求，做一些数据准备的协助工作，还能够根据自己的经验积累，给到算法同学一些帮助，提供一些你认为可能会帮助到模型提升的特征。**
|
|
|
|
|
|
具体到预测用户流失的产品上，我们可以根据经验提出用户可能流失的常见情况，比如我们可以参考客诉表，看看有哪些用户在客诉之后，问题没有解决或者解决得还不满意，那这些用户我们大概率就流失了，或者我们也可以分析用户的评价数据 ，如果用户评价中负面信息比较多，那他们也可能会流失等等。
|
|
|
|
|
|
## 模型的构建、宣讲及验收
|
|
|
|
|
|
完成数据准备之后，就到了模型构建的环节。这个环节会涉及整个模型的构建流程，包括模型设计、特征工程、模型训练、模型验证、模型融合。
|
|
|
|
|
|
|
|
|
|
|
|
即便你不需要进行模型构建的实际工作，你也需要知道这个流程是怎么进行的，这方便你了解算法同学的工作，以便评估整个项目的进度。这就好比互联网产品经理不需要写代码，但也要知道研发的开发流程是怎么样的。
|
|
|
|
|
|
不过，今天我们不会重点来讲具体的过程，我先卖个关子，你今天先记住这几个关键节点的名称，下节课我们再详细来讲。
|
|
|
|
|
|
**模型构建完成之后，你需要组织算法同学对模型进行宣讲**，让他们为你讲明白这个产品选择的算法是什么，为什么选择这个算法，都使用了哪些特征，模型的建模样本、测试样本都是什么，以及这个模型的测试结果是怎么样的。
|
|
|
|
|
|
对于流失预测模型来说，我需要知道它的主要特征是什么，选择了哪些样本进行建模，尤其是测试结果是否能够满足业务需求。当看到流失预测模型的测试结果的时候，我们发现模型召回率、KS 值都达到了标准，但是模型覆盖度只有 70%，比预期低了不少。但是，由于我们业务侧也只需要找到一部分流失用户进行挽留操作，所以，暂时不能覆盖全量人群我们也是可以接受的。像这样的问题，都是你在模型宣讲环节需要去注意并且去评估的。
|
|
|
|
|
|
**在模型宣讲之后，你还需要对模型进行评估验收，从产品经理的角度去评判模型是否满足上线的标准。**那在这个流失用户预测的项目上，我们就需要重点关注模型的准确率，是否模型预测的用户在一定周期后，确实发生了流失。如果模型准确率较低，将一些优惠券错配到了没有流失意愿的用户身上，就会造成营销预算的浪费。
|
|
|
|
|
|
模型宣讲环节的具体内容，以及模型宣讲后，我们对模型进行评估验收的具体指标都有哪些，我会在模型验收的章节和你细说，这里你先不用着急，你只要知道有模型宣讲和模型评估验收这两个环节，以及它们的整体流程，让自己对 AI 产品经理的工作流程有一个整体的理解就可以了。
|
|
|
|
|
|
## 工程开发及产品上线运营
|
|
|
|
|
|
模型通过了验收之后，我们就可以进入工程开发的环节了。其实在实际工作中，工程开发工作通常会和算法模型构建同步进行。毕竟，算法同学和工程同学分属两个团队，只要模型的输入输出确定之后，双方约定好 API 就满足了工程同学开发的条件了。
|
|
|
|
|
|
工程开发完成之后，就可以进行工程测试验收了。这和传统的互联网产品上线流程区别不大，也就是测试同学进行测试，发现 BUG 后提交给工程同学进行修复，再当测试同学测试通过之后，产品经理验收，或者叫做产品上线前走查，这里我就不再多说了。
|
|
|
|
|
|
另外，在工程上线之后，为了评估 AI 产品整体的效果，我们可以通过对上线后的系统做 AB 测试对比传统方案，进而量化 AI 产品的效果提升。这时候，我们需要关注在产品定义阶段对于产品的指标和目标期望。
|
|
|
|
|
|
相比于一般的互联网产品经理，AI 产品经理在产品上线之后，还需要持续观测数据的表现（模型效果）。因为 AI 模型效果表现会随着时间而缓慢衰减，你需要去监控模型表现，出现衰减后需要分析发生衰减的原因，判断是否需要模型进行迭代。
|
|
|
|
|
|
## 小结
|
|
|
|
|
|
一个 AI 产品构建的整个流程是从产品定义，到技术预研、数据准备、模型构建，再到模型验收和工程开发上线。其中，有三个节点是我们需要重要关注的，因为这三个节点和互联网产品开发流程完全不同，它们分别是产品定义、数据准备和模型构建。
|
|
|
|
|
|
在产品定义的阶段，我们需要搞清楚三个问题，这个产品背后的需求是什么，是否需要 AI 技术支持，以及通过AI能力可以达到什么样的业务目标。这需要我们和业务方深入沟通，拆解他们的真实需求。除此之外，我们还要根据自己对 AI 技术的理解，去判断这个项目的可行性，制定相应的目标。
|
|
|
|
|
|
因为数据和特征决定了机器学习的上限，而模型和算法只是逼近这个上限而已，所以数据特征是否全面，数据量是否足够对于算法同学来说是非常重要的。在数据准备阶段，我们不仅需要帮助算法同学获取更多高质量的数据，来提升模型的整体效果，也可以从业务的角度，给出算法同学一些建议，比如哪些特征可能有帮助等等。
|
|
|
|
|
|
数据准备好，就可以进行模型的构建以及评估验收了。模型的构建我们可能没有什么可以介入的地方，但模型的评估验收是一个非常重要的节点，因为模型是一个偏黑盒的工作，它的输出可能只有一个指标值或者分数。
|
|
|
|
|
|
但是，很多产品经理会认为：模型好坏是算法工程师的职责范围，反正自己也不太懂算法，只要算法交付了，对方说达到模型指标就可以了。如果你也这么想，那么你可能最后就变成一个协调性或者执行层的产品经理了，最后整个项目就变成算法主导了，所以我们一定要重视模型评估。
|
|
|
|
|
|
## 课后讨论
|
|
|
|
|
|
你觉得，AI 产品经理的工作流程和你现在的工作流程最大的不同是什么？为什么会产生这些不同呢？
|
|
|
|
|
|
期待在留言区看到你对工作流程的思考与复盘，我们下节课见！
|
|
|
|