日前，雷锋网医健AI掘金志邀请腾讯微保数据智能中心负责人李羽，做客雷锋网公开课，以“保险科技助力用户增长”为题，介绍了互联网用户转化和推荐体系在保险领域的技术实践。
目前，微保平台已经服务上亿的微信用户，自研平台也已经接入36家保险公司，处理超过十亿级别用户会话、千亿级别用户行为。
但微保最开始做保险推荐和获客的时候，也曾经历迷茫试错期。
李羽表示，微保一开始觉得保险推荐和其他互联网领域情况类似，可以很容易上线获得收益，但实际完全不是这么回事。
最开始半年的研发，微保做了三个模型版本升级、15次实验，但只有一次推荐获得收益，效果也仅仅只有1%左右。
这种情况下，微保做了大量分析和行业调研，才一步步找到保险和其他领域推荐的不同，其中差异主要包括SKU规模小、用户认知差、产品复杂且限制多等等。
为了解决SKU规模小、产品复杂的问题，微保引入了组合的概念，将原来单个保险产品做成组合，产品形态上是多个产品组合融合成一种卡片，再辅助一些推荐理由，逐渐让用户产生共鸣，把原来30个保险种类扩展成上千个SKU组合。
针对用户认知差的问题，微保重新定义了问题，从端到端建模更改为意愿度推荐模型，在用户买或不买、点或不点之前，就进行用户认知程度识别，按照认知层级推荐。在认知度模型实验中，这种方法成功对10%的尾部用户点击率造成极大提升。
以下为李羽演讲全文内容，雷锋网做了不改变原意的编辑：
很高兴有这个机会跟大家做些交流，也感谢主办方雷锋网(公众号：雷锋网(公众号：雷锋网))。今天我分享的题目是保险科技助力用户增长的实践，我叫李羽，是微保数据智能中心负责人。
微保的出身
首先，介绍一下微保，微保全称是微民保险代理有限公司，由腾讯控股。
腾讯这几年大概投资了几百家公司，其中绝大多数都是投资公司，例如美团和滴滴，但也有少量控股公司，例如QQ音乐、阅文集团，当然微保也是其中之一。微保是在2017年9月，获批的保险代理牌照，并在2018年1月正式上线产品。
微保作为腾讯的控股公司，自然也可以获得很多独家资源支持，例如微信钱包九宫格里保险服务入口就是腾讯对微保的重要支持之一。
在微保成立之前，就曾有很多保险公司希望和腾讯合作，腾讯自身也希望把自己的互联网能力和保险行业做结合，但过去腾讯每个团队都有自己的主营业务，对于保险的理解和使用并不那么深刻。
而微保出现之后，基本上就能解决这个问题。微保作为一个桥梁，一方面可以承载腾讯自身的互联网能力，一方面也可以和保险公司携手一起为用户创造价值。
微保作为腾讯旗下互联网保险服务平台，目标就是基于腾讯生态体系服务C端用户和保险公司。
我们认为科技的发展有两种驱动方式，一种是热点驱动，一种是需求驱动。
热点驱动类似于为科技而科技，行业首先会出现一些比较热门或比较前沿的技术，随后大家开始跟进前沿技术，再往后才是落地场景的思考。
微保科技成立的第一天，就是致力于用科技创造价值，里面包含几个目标：
首先，用户面向谁；其次，用户有哪些需求点，需要怎样的价值点；之后，针对这些价值点或需求制定解决方案；最后，为解决方案寻找技术，落地实施。
这是微保科技服务C端用户的数字地图。
第一级是保险行业需要解决的问题，例如产品好吗？服务好吗？是否安全？
下一级是具体子问题，例如产品是不是一定很贵？保险这么复杂，需要购买什么样的产品？后续需不需要理赔？针对这些现实问题，微保希望通过科技层面探索解决方案。
再下一级是帮助保险精算师设计更有效、更具有性价比的保险产品，达到风险识别和反欺诈，以及大数据精算定价能力。
这几个环节的问题，都可以通过科技手段解决。
例如，在复杂市场里选择保险产品？就可以通过保险科技帮助用户更快速、更高效找到适配的保险产品。
保险教育层面，也可以通过搜索引擎推荐、知识图谱、智能客服等手段，解决用户购买过程中关于核保和核赔的问题与困惑。
保险赔付疑虑层面，也可以通过保险科技，让服务更直接。微保在这方面已经尝试做智能理赔问诊、保单管家、一键退保等功能。
作为一个保险代理平台，除了面向C端用户，微保还面向再保公司，再保公司的述求集中在两方面，一方面帮保险公司找到更多优质用户，另外一方面帮助驱动用户增长，降低风险成本。
在这种情况下，微保打造一些平台或中台区域，在to B领域跟保险公司合作，例如，个性化的风控平台、BI平台、投放平台等。
综合来看，微保虽然是一个互联网保险公司，但很多情况下，都需要对保险有足够的认知和理解，才可以利用一些互联网、AI技术帮助C端用户选择更好的保险产品，帮助保险公司提升人力效率，做到更精细化的用户运营，同时在这个过程中，也需要运营中台、对话平台、AI语音等技术。
刚才分享的都偏效果和效率，其实整个传统保险投保流程，以及续保流程和用户生命周期管理，都是一个很漫长的过程。
这张图可以看到，具体实现非常复杂，甚至解决方案堆在一起就有几十个格子图。
当然，整个格子图构造核心还是基于腾讯金融云和腾讯公有云等基础设施；在腾讯云之上才是微保Paas层；再往上通过中台或平台服务，降低前端业务开发量，提升研发效率和智能化水平；最顶层则是基于中台和平台构建轻量级业务层，用中台能力快速拼装各种业务，支持服务用户。
保险获客的核心——增长黑客
接下里，从保险获客视角，介绍微保增长黑客的工作。
首先介绍一下增长黑客，增长黑客是一整套体系和方法，近年很多互联网公司都在尝试和研究将增长黑客应用在业务增长层面。
早期尝试增长黑客实践的案例就是 Facebook，以数据为指引的实验方式，系统性在用户在生命周期的各个阶段，寻找当下最具性价比的机会来推动北极星指标（唯一指标）提升，也就是注重通过数据和实验的方式驱动业务，发现业务中的增长点。
具体执行层面，需要横跨市场、产品、工程、设计和数据等团队，把所有人聚在一起，为了共同的目标做实验、想方法，并通过快速迭代的方式达到目标。
我们可以发现，增长黑客需要的数字体系目标分为以下几类：
数字化，通过数据方式甄别业务实际情况，改进策略效果；
实验化，数据比对、核心数据的生成，实验化都是重要的方法；
精细化，技术需要满足用户、运营或产品等不同群体、不同场景和不同策略的精细化诉求，推荐就是精细化的一个重要手段；
平台化和中台化，这部分主要因为增长技术体系构建和实现比较困难、保险业务链条比较长；
例如获客就包括用户购买首单和后续的加购，以及第二年的续保等等，如果里面每个链条、每个场景都做增长和相关技术搭建，那最后整个服务效率和效果一定差异巨大。所以需要很强的平台化或中台化设计，让整个公司健康险产品服务链条统一。
在整个实际实践过程中，还需要注意一些技术之外的问题，例如因为每个业务团队对增长黑客的理解不同，大家对增长的方法论也不是特别熟悉，就需要在磨合过程中，增加一些机制来填补业务方和增长技术之间的空隙。
这是增长黑客的技术体系，主要包含三个层面：
底层是数据中台，主要提供基础和应用能力，包括可视化和多元分析，以及算法和画像能力。
往上是增长平台，可以围绕增长数据化和实验化做一些个性化实验平台、业务平台，以及运营平台。
最顶层是互联网和人工服务场景，互联网场景包括微信场景，运营场景，广告投放场景，人工运营包括售前服务和售后服务。
接下来会重点介绍三点：保险领域的个性化推荐；互联网服务场景的保险领域个性化推荐；人工服务场景和管家智能助手。
前面已经提到实验化是增长体系重要一环，通过实验平台相关工作就可以理解这些工作开展方式，但前面介绍遗留了一个问题，就是整个增长技术体系和真正业务对接过程中存在的缝隙。
关于这个缺口的弥补，微保在实践过程中采用了BP制度，通过BP制度深入和业务紧密绑定起来在一起，弥补业务和增长之间的缺口。
BP的工作核心就是把业务方提出的目标、假设、需求转换成底层中台或平台来承接一些明确技术需求。
目前，微保内部主要有三种BP技术角色：业务分析BP、个性化BP、系统BP。
业务分析BP的核心工作就是发现和评估假设，做专题分析或用户洞察，跟产品和业务方一起讨论，要做哪些优化和优化进展。
个性化BP的核心工作则是把假设转化为可执行的实验，做具体增长策略和实验设计，并配置实验，解读是否有效。
系统BP则是把前面的分析和实验或者有效的策略，固化到系统层面和增长中台。最后增长平台就只需要把系统BP的需求转化成平台方案设计。
右边这张图是使用业务分析BP举例说明BP的工作流程，每个大核心的业务都会有一对一的业务分析BP，深入到产品中跟产品一起讨论需求或假设，再把需求和假设做排期，做相关开发，形成结论反馈到产品层。
健康险用户推荐策略
前面大概介绍了微保增长技术体系，按照刚才的逻辑将展开三个点详细跟大家交流。
推荐技术发展到现在，技术层面和算法层面都已经没有特别大的挑战。
微保一开始也觉得，很容易就可以做一个保险相关推荐，快速上线拿到收益，但实际完全不是这么回事。
最开始，我们一共做了三个模型版本升级，15次实验，但只有一次推荐获得收益，效果大概只有1%左右，整个过程经历了半年的时间。
在这种情况下，微保开始做相关分析和行业调研，半年之后才逐渐找到保险产品推荐和其他领域推荐的差异。差异主要分为以下几类：
第一种差异，SKU规模，电影或资讯领域等其他领域，通常SKU规模比较大，例如电影领域就有几十万候选推荐SKU，而保险领域则少之又少。调研发现，保险行业在售保险产品，甚至还不到1000种。而微保奉行的就是严选和定制策略，能上线的产品更少，大约在三十款左右。
第二种差异，产品复杂度和用户认知。在电影或资讯领域，大家看电影标题或简介就可以很容易理解其中所讲述的故事和含义。而保险领域，因为产品复杂度高和存在大量的条款和计算公式，造成理解保险的时候，对于大多数用户都是很难的一件事情。
第三种差异，产品限制。在电影或者资讯领域，不涉及黄色或者反动，大部分产品都没有太多限制，可以正常做推荐。但保险领域要求非常多，有很多核保规则、地域限制，极大约束推荐过程中的策略生成。
第四种差异，关注频率。资讯大家每天都会关注，但用户即使已经购买保险，也不会经常去看自己的保单，关注频率非常低。
第五种差异，行业经验，电影、资讯、电子产品等行业都非常成熟，网上资料甚至开源代码系统都非常多。但保险领域相对比较匮乏，微保调研了很久，也没有找到适合行业解决方案。
这么多复杂问题情况下，意味着不能再遵循过去的方法和策略，需要提出新的解决方案。
按照增长黑客的方法论，在找到解决方案之前，我们需要做一些假设，以及针对假设做一些实验，验证新的增长思路，假设和猜想是否正确。
我们做了很多关于用户的认知分析。用户首次访问微保之后，前三天付费占比只有不到一半，另外一大半的付费用户是在第4天到第365天才成交，把观察时间拉到更长，前三天成交的比例会进一步的下降。
总结发现，我们的用户有一部分可能很快就买保险，而另一部分可能会过了很久才买，这个分析佐证了用户认知差异的存在：首先，用户准备度差异非常大；其次我们的推荐策略优化方向，还要考虑用户准备度，让用户理解产品、记住微保。
在针对问题做了一系列分析后，我们产生了一些实践思路或者假设，那么我们也通过一系列的实验来验证了这些假设：
第一点，重新定义建模目标，此前我们的工作都是端到端建模，把用户直接扔到模型里面，让模型自己学。
现在我们分开看这个问题，在识别用户买或不买、点或不点之前，就去识别用户认知程度，在认知程度基础上决定推荐策略。建好了认知度模型后，我们针对模型打分尾部10%的用户做了实验，对这些用户不展示产品，而展示一些教育内容或者健康活动。
最终实验下来，我们发现整体保费和转化率并没有没有影响，而最后10%用户点击率又有很大提升，这就证明认知度模型可以比较好的识别出用户对保险的认知度。
第二点，尝试降低产品复杂度，扩展item，引入更多非产品类item。
因为用户的认知差异非常大，并不能为所有用户都推荐高难度的产品，需要循序渐进。所以微保就做了赠险、教育类的文章，发现这比直接给用户看产品更有效。
为此，微保引入组合的概念，把原来单个保险产品做成组合，在产品形态上是一个卡片的形态，那么单个产品用户看起来没有什么感觉，但多个产品组合在一起，再辅助一些推荐理由，就可以逐渐让用户产生共鸣，在引入卡片之后，还可以极大扩展SKU数量，原来30款产品，使用卡片组合之后，可以扩展成上千个SKU组合。
第三点，引入推荐理由元素帮助用户理解，降低推荐产品复杂度，例如卡片标题、产品简介、相关标签。
第四点，降低试错成本。数据驱动或实验驱动本身就非常复杂，一旦实验很慢或试测成本很高，就会导致难以为继。
为此微保采取了两个举措，一方面加强人工规则表达能力，便于引入更多专家经验，其中主要是因为整个行业发展这么多年，在人和人打交道过程中需要更多依靠人工去售卖，而保险专家有更多知识沉淀，这些知识可以通过加强规则表达，跟推荐引擎结合，减少试错成本；
另外一方面，加强实验系统建设，微保最开始阶段整个实验系统都比较笨拙，后续解决实验系统跟保险行业结合的问题之后，产品时间并发度有极大的提升。
举几个推荐实验实例，最左侧是一个健康险相关组合卡片，左边是个性化重疾卡片，可以看到卡片名介绍，底部有卡片文章相关的item，item可以根据用户画像做个性化定制。模型也会帮助专家选择卡片名或卡片介绍的组合，这样卡片上线之后，整体转化率可以提升3.2%。
中间是健康险相关的长期保障卡片，主要实验就是下面底部文章和信息变化。例如用户看过产品，文章就变为什么患了重疾还需要健康保障。如果已经为家人投保，这篇文章就会变为“为什么越早够买终身重疾越划算？”
通过这一系列尝试，长期保障卡片对首页保费提升率造成很大提升，帮助首页产生的保费提升了6%左右，终身重疾转化率提升了77%。
右边是小白用户的案例，我们找了一些认知度低的用户，首先不给他看产品，只在核心位置给他推荐专属福利。
最终目标客群整体点击率提升了23%，用户30天转化率也有大规模的提升。而我们让目标用户记住了微保之后，他们的30天转化率提升了10%。
最后介绍微保推荐系统的整体结构图。底层部分是数据能力层，包括外部联合数据建模专区；
往上是系统层再往上是个性化推荐策略体系，我们把这个体系分为深度场景推荐、多产品推荐以及专家经验推荐。
这样分的本质原因在于，微保本身就是做推荐相关工作的同学还比较少。但微保需要做的推荐场景却非常多，就需要有一部分同学首先服务好一些核心场景，跟场景相关的深度推荐，例如首页场景、投保成功场景；另外一部分同学则专注在通用推荐上，更多推荐场景通过一个通用算法把它满足起来。
很重要的专家推荐场景，则交给专家，把专家知识引入进来，建立一套体系帮助保险专家推荐。
人机辅助智能助手
下一步介绍智能助手怎么辅助提升人工效率和效果，帮助人工做增长工作。
保险产品的复杂性，导致了即使是互联网保险平台，也需要依赖人工客服来解决用户的各种各样的问题，而这些人工客服在互联网场景下服务客户的时候，又面临各种各样的问题。
例如用户可能想要高效和专业的靠谱服务，如果是线下保险代理人在投保过程中，可以根据用户的语态、语速、谈吐、判断需求和对保险的认知程度，并把自己心中之前最好的解决方案给到用户。但互联网保险往往都是隔空服务用户，并不能完整及时的捕获用户的信息。也就很难高效并且合理地给出方案，服务好用户。
怎么去解决这些问题？
微保是通过智能助手来帮助人工客服捕捉用户意图，给出回复建议的。微保的智能助手不是第一天就有一个完整的能力体系的，也是在具体客服、管家服务的支撑工作中，逐渐进行体系化规划，构建工具，让智能助手逐渐可以应用在各个服务环节。
例如接触用户环节、了解需求环节、满足需求环节，数据驱动环节。再下一步，微保会把这些环节所解决的工具或能力沉淀成智能化解决方案。
首先，在了解需求阶段。微保会把用户在全站的行为和留下的数据做成用户画像标签，让客服更好理解用户的对话诉求。
除了用户画像标签，微保还根据用户进线后的一些聊天行为、聊天时间间距抽取关键信息，判断用户形象、对保险了解程度，提高补充需求收集效率。
此次，满足需求阶段。微保会制定一些智能服务助手或智能核保智能理赔方案，给到人工客服，这样用户留下相关信息之后，就可以对他的需求做进一步洞察，例如发现用户服务过程中产生的问题和机会，做产生相应的策略指导。
这张图，从上到下发展展现了微保相关体系的规划，下层有数据，往上是基础技术，再往上是真正提高人效的场景。
这是具体应用场景的截图。
微保目前累计已经服务2千万次保险咨询，帮助客服人员人均服务会话数提升1.5倍。
在人工智能助手服务场景，微保目前还处于打基础、建设基础能力的阶段，还没有完全按照增长方式运作起来，下一步会把之前累积的保险领域增长实践方案跟人工服务场景结合起来，帮助人工服务场景做到数字化和实验化。
最后介绍下微保AB实验系统。
为什么要实验驱动，本质原因是人会犯错误？国外一篇文章统计，普通人判断AB策略好坏的正确率10%~20%，微软5年经验产品经理正确率是30%~40%，谷歌产品经理正确率在33%左右。如何减小犯错误的机会，就需要通过实验驱动的方法。
另外一个原因是，人去判断1%的变化，基本上判断不出来的，但通过实验系统，则比较容易判断其中的变化。增长黑客也是非常强调实验驱动的。
判断1%的变化和提升是不是有价值？如果每天都做1%改进，累计一年就是37倍的提升，但如果每天做负向1%优化，一年下来指标就只剩下原来0.02了。
这是微保实验系统框架，包括面向用户、面向产品经理或者是面向数据分析师，主要界面是实验管理平台。
实验管理平台后端有两个相关子系统做支撑，一个是实验系统后台，实验系统后台包括分流、分桶染色逻辑；另外一个是实验配置逻辑，比较重要的模块就是实验分析。
很多公司可能在实验分析方面投入比较少，但微保的实践过程中发现，实验分析非常重要，因为如果对实验解读不正确，就可能造成很多无用功，这种情况下不如去相信人的经验。
接下来会对微保增长黑客实践过程中遇到的一问题，进行一些回顾。
首先，就是互联网保险领域流量比较小。微保虽然依托腾讯在保险领域流量已经非常大，但跟其它互联网产业比，流量还比较小。
为此，微保主要通过预计算的方式来分层分桶，保证在实验效率和实验效果方面达到平衡。
其次，保险业务流程比较长，实验场景也很多，以推荐为例，已经有28个实验场景接进来。
早期的时候每个场景的上报数据都不一样，给实验科学性和可解读性造成了巨大障碍，因此在这里强调，我们埋点的方案一定要体系化，需要有中台或者平台的视角来看待埋点。
另外业务流程长，需要我们保证用户在多个场景下遇到的实验策略是一致的。如果再某个场景下，给用户说A，到另外一个场景，又给用户说B，就无法让用户形成连贯的体验了。
所以在整个推荐策略中，用户染色策略和用户的实验策略必须全局化，保证全局统一。
再次，保险用户转化周期长。保险和其他商品有很大不同，通常需要设定长周期实验指标，最初，微保曾把精力放在短周期实验指标上，但用户成分或行为发生变化的时候，短期实验效果往往就会发生严重波动。
因此，我们设计了长周期的实验观察指标，也考虑了一些短期行为的长期价值，帮助我们更好的衡量实验。
最后，就是要做到实验结论科学可信，要有实验分析模块，数据出来后，至少要做假设检验。另外在实验结论分析时还要避免辛普森悖论。
。
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/75517.html