产品经理就业班，12周特训，测、练、实战，22位导师全程带班，200+名企内推，保障就业！

如果把平台比喻为一颗树，那么需要投入足够的养分才能快速生长，而业务风险则是寄生于树木窃取养分的角色，只有能够充分抵御这种风险的才能成长为参天大树。这就是业务风险在平台发展中扮演的角色。

作为一名前业务风控产品经理，一直想找个机会说说我对业务风控的一些业务及产品上的理解。

由于业务敏感性，有些东西不能写的太详细，还请大家见谅~

如果把平台比喻为一颗树，那么需要投入足够的养分才能快速生长，而业务风险则是寄生于树木窃取养分的角色，只有能够充分抵御这种风险的才能成长为参天大树。这就是业务风险在平台发展中扮演的角色。

在大部分场景下，风控意味着阻断用户操作，在大部分人眼里与用户体验是背道而驰的存在。单就电商领域而言，竞争逐渐白热化，用户体验成为了吸引用户的重要因素，此时风控如何在尽可能少打扰到用户的情况下，能阻断尽可能多的恶意行为？这是一场善与恶的博弈，也是关乎生死存亡的博弈。

在这里，需要提出行业内一个著名的原则：轻管控，重检测，快响应，私以为基本能实现用户体验与风控需要的平衡。怎么来理解这个原则呢？个人认为：

轻管控：在出现风险，需要阻断用户操作时，阻断动作宜轻不宜重。能验证码校验就不短信校验，能短信校验就不禁访。同时被阻断后文案，下一步出口都需要照顾用户感受。看似简单，其实背后涉及到对用户风控行为以及对用户风控阻断动作的分层管理。

重检测：通过尽可能多的获取用户信息（包括静态及动态数据），由规则引擎进行实时或离线计算，来动态分析每个用户及采取行为的风险程度。这里需要尽量全的数据来源，以及非常强大的规则引擎，才可以实现良好的检测效果。

快响应：是指在检测出用户存在的风险后，如何快速的进行阻挡。这里的重点是快，则意味着对业务的理解要细，提前在关键动作进行布局，才可以做到尽可能减少损失。

业务风控的业务模型设计

说完了原则，我们怎么具体来看业务风控的业务模型设计呢？

在我理解，业务风控的业务模型主要分为六层，分别为数据输入层，数据计算层，数据输出层，运营管控层，业务接入层以及用户触达层。

大家可以看到，下面三层，是偏向于数据，研发的；上面三层，是偏向于业务，运营，产品的。做风控其实就是做数据，因此数据的接入、技术、处理是其中最核心的模块；但现阶段，由于算法模型的限制，还需要有人为的因素进行规则模型的校正，以及特殊样本的审理，因此会有运营层的存在；最上面的触达层，是拿结果的一层，产品的部分工作也在于对此进行良好的设计。

这六层侧重的点也各有不同，下面为大家简单说明：

如何获取数据？获取什么数据？数据准确性如何？这是数据输入层需要解决的三个问题。

目前获取数据主要有两种方式，一种是主动获取，一种是被动获取。

主动方式是自己去业务方数据库、日志里面去读，这样可以拿到最全的信息，而不用依赖消息报等被处理过的二手数据。有些比较成熟的公司有自己的消息总线，风控可以去实时的订阅信息然后作为数据源进行分析；但在公司没有消息总线的时候，风控可以发挥自己横向，跨业务的优势，建立自己的消息总线，去获取数据进行分析。这样的好处是对业务方依赖降低，数据来源最全，能进行深入的数据挖掘；坏处是建立难度较大，需要大量资源支持，适合较为成熟的公司。

被动方式就是提供接口给业务研发，让业务把消息按格式标准传过来。这种配合周期非常长，但成本较低，可以按照标准来拿到高质量的信息，所以是比较常见的风控系统搭建方式。

鉴于目前大部分公司都采用第二种方式，因此与业务方如何合作，获取高质量的数据就很重要了。对数据种类的要求是能全就全，能深就深。以笔者做过的账号安全业务为例：

往往风控关心的信息比如IP地址、referer这些信息业务都是不关心的，但这些信息的缺失可能造成很多策略没法做，所以在采集信息开始的时候就要有个明确的信息列表。

以注册登录行为为例对数据详细程度进行深入：

1. 基础的登陆注册数据，就可以从频率、登陆注册特征来进行分析；
2. 进一步拿到登录注册行为的上下文，比如登陆前访问了哪些页面，登陆后去访问了什么，就可以从访问行为轨迹来增加更多的分析维度，例如页面停留时间，是否有访问到必访问的页面；
3. 用户的操作行为数据，比如鼠标移动的轨迹，键盘输入，进一步的从操作过程来增加分析维度，比如是不是输入密码的时候有过多次输入删除？是不是直接复制粘贴的账号密码？

比较常见的例子：需要用户的访问IP，结果拿到的IP地址是内网的服务器IP；或者是想要用户名，结果传递过来的是UID。这点需要大量的前期沟通确认工作。

如何在日常工作中确保数据的准确性呢？

1、对采集回来的数据必须定期的对数据质量进行监控——

已经采集到的数据可能因为技术架构调整，代码更新等各类奇葩原因造成采集回来的数据不准了，如果无法及时发现可能造成后面一系列分析过程都出现错误。

2、采集点尽量选择稳定的业务点，比如采集登录日志，一次性在公共服务采集好，后面出现问题只要找一个点。但如果是去前端从WEB、移动端等各个调用登录服务的点去采集，出了问题要改动的工作就会成倍增加，还有可能出现新业务点的日志无法覆盖的情况。

1. 宜早不宜晚，宜全不宜少；
2. 数据分层处理：实时数据与离线数据分离。实时数据接入需要评估RT时间及准备一旦被降级的预案。

数据计算层是由各种规则、模型等算法形成的计算核心，一般都依附在一个强大的规则引擎之上。

为什么采用规则引擎？因为黑产的反应速度实在太快了。如果把风控规则都硬编码进业务代码中，那一旦规则被绕过，反应速度就会非常慢。规则引擎必须能把策略逻辑从业务逻辑中解藕出来，让防御者可以灵活配置规则在静默模式下验证和实时上线生效，并可以去随时调整。

虽然说数据技术层主要是研发和算法同学处理的，但作为产品可以做的，除了了解基本的规则，模型及实现原理外，还可以增加对规则的生命周期及健康度的评估，比如：

风控系统的规则有多少？哪些已经很久没有触发了？产生误判投诉的对应规则有哪些？

一个新规则在建立起初的效果肯定是最有效的（因为这时风险问题正在发生，而规则正好对应了风险），但随着时间其有效性是快速下降的，比如攻击者都知道网站三次输入密码错误触发验证码，那么他们会傻傻的尝试第三次猜测密码的概率有多大？那么是否有人在定期的去统计分析这些规则的效率就是风控产品的重要运营环节了，而运营风控产品所要付出的代价是往往大于常规互联网业务产品的，并且是保证项目能够持续产出价值并不断迭代进化的一个前提。

数据输出层是将数据计算层的计算结果转化为可以被下游使用的分数，主要的输出为用户的风险画像，风险分数及风险等级。

数据输出层主要的原则是数据可读性高（因为会直接被运营及下游业务方消费，需要降低使用方的使用成本，提高效率）以及可复用性（一个输出的数据，可以在多个场景下被使用。比如垃圾注册的数据可以同时被反欺诈，反作弊等场景使用）。由于用户分层及用户画像展开来说内容比较多，就不展开了，大家可以自行百度~

如果说上面三层主要靠技术的手段来实现风险管控，那么运营管控层主要是靠人为经验来对技术尚无法处理的风险进行管控。

技术尚无法进行处理的风险主要分为两种，一是样本较少，计算准确度不足，然而危害较大的风险行为，比如金融盗卡，诈骗等；二是人为，非机器行为的风险行为，比如工作室层次的大量人工刷单等。以上两种都是需要运营的经验来进行判断会更为合理。同时运营层的处理结果也会反馈到数据输出层，优化数据输出的准确性，也有利于为算法及模型提供较为准确的样本进行学习。

运营管控层主要是风控运营后台的设计，由于各个运营后台设计的特点不一而足，因此在这里只说明主要的涉及原则，主要包括可读性以及案件存档。

让分析人员可以快速的查询原始日志：日志并不是简单的存下来，从风控分析的需求来看，通过IP、用户名、设备等维度在一个较长的跨度中搜索信息是非常高频的行为，同时还存在在特定类型日志，比如在订单日志或者支付日志中按特定条件搜索的需求。

机器语言转化为自然语言：这主要是为了能够让分析人员可以快速的还原风险CASE，例如从客服那边得到了一个被盗的案例，那么现在需要从日志中查询被盗时间段内这个用户做了什么，这个过程如果有一个界面可以去做查询，显然比让分析人员用grep在一大堆文件中查询要快的多，并且学习门槛也要低得多。

如果在日志做过标准化的前提下，也可以进行后续的业务语言转译，将晦涩难懂的日志字段转化为普通员工都能看得懂的业务语言，也能极大的提升分析师在还原CASE时阅读日志的速度。

这里指将实时或离线的计算加工消息成变量&档案。例如在分析某个帐号被盗CASE的时候，往往需要把被盗期间登录的IP地址和用户历史常用的IP地址进行比对，即使我们现在可以快速的对原始日志进行查询，筛选一个用户的所有历史登录IP并察看被盗IP在历史中出现的比例也是一个非常耗时的工作。

再比如我们的风控引擎在自动判断用户当前登录IP是否为常用IP时，如果每次都去原始日志里面查询聚合做计算也是一个非常“贵”的行为。

那么，如果能预定义这些变量并提前计算好，就能为规则引擎和人工节省大量的时间了，而根据这些变量性质的不同，采取的计算方式也是不同的。不过还好我们有一个标准可以去辨别：频繁、对时效敏感的利用实时计算；而相对不频繁、对时效不敏感的利用离线计算，以这样的原则进行指导，就可以尽可能节省时间了。

风控的业务模型是环环相扣的，在已经具备了数据处理能力以及运营后台之后，如果没有业务方接入，那相当于只有内功而无法出拳，这样就只是风控内部的自娱自乐，无法为业务保驾护航。在风控与业务技术的合作中，由于业务为王，一切要以业务为重，因此风控在合作中，需要注意：尽可能避免给业务带来不必要的麻烦。

如何做到与业务进行良好的合作，主要从4点出发：

1、呈现给业务研发直白的判定结果

我们最终从数据中发现的报警和问题最终是要在业务逻辑中去阻拦的，在接入这些结果的时候，往往分析师觉得可以提供的信息有很多，比如命中了什么规则、这些规则是什么、什么时候命中的、什么时候过期，一个code list给他们说明对应希望做的操作，一定把中间结果等等包装成最终结果再给出去。

2、实时与离线计算分离，降低业务系统压力

因为T＋0在接入的时候要额外承担很多计算成本，结果要现场算出来而延时要求又很高，所以一般都只在攻击者得手关键步骤采取实时判断（比如订单支付或者提现请求）。而对于其他场景可以选择T＋1方式，比如登录或者提交订单等。

3、超时及降级预案准备

风控风险判断的最基本原则就是要不影响业务逻辑，所以超时机制在一开始就要严格约定并执行，一旦发现风控接口超过预计响应时间立马放行业务请求。

平时可能流量很小的业务，突然因为某个活动（比如秒杀）流量大增，除了在接入之初要对风险判断请求有了解，对后续的活动也要提前准备，否则如果资源预估不足，突然又赶上这个点接了T+0接口有很多要现场计算的逻辑，那业务分分钟会把风控降级。

终于来到最后一层，用户触达层了。风控的用户触达，主要包括各种C端的安全中心，安全组件以及多样的风控阻断操作。在这一层，需要做的是细化管控手段，以及重视用户体验。

风控管控手段需要丰富，包括图形验证码，语音验证码，实名校验，touchid校验，密保问题，禁访，禁买，禁言等，在不同场景下，采取对应的方式，而不是千遍一律。千遍一律的话，太轻会导致管控效果不佳；太重的话会极大影响用户体验。

这点说起来容易做起来难。在获客成本高昂的今天，假设获客成本是100块，他可能因为被风控之后，文案的简单粗暴，缺少申诉出口或者流程难以继续而选择用脚投票，从而离开。而这些是产品可以做的事情。使用提醒式而非警告式的文案；在被风控后及时提示用户后续的操作；与客服同学加强沟通（
任何风控准确率都不是100%的，所以在和研发沟通好接入后一定要告诉一线同事们风控阻断可能出现的表象（文案提示），以及大致的原因，以避免一线客服们对风险拦截的投诉不知道如何解释，并给出具体的阻断回复措施（CRM后台增加白名单、删除黑名单权限等等）。）都是可以有效提高用户体验的方法。

以上就是我对业务安全风控业务模型的理解。因为风控涉及的东西较为敏感，所以上面的说法都脱敏处理了下，具体的规则、策略，用户画像的构造等均没有细说，大家可以自行百度~

感谢大家看完，是对我最大的支持，比心~

本文由 @启辰菌 原创发布于人人都是产品经理。未经许可，禁止转载。

为了进一步规范社保业务档案管理，市社保局在城乡一体化社会保险管理与服务平台的基础上，以电子档案管理系统为契机，对社保业务经办流程与档案管理流程进行全面整合，实现社保业务档案数字化管理。

10月底我分局各股室的业务骨干代表到市局参加了数字化档案建设工作培训班，11月我分局工作人员正式开始使用档案数字化的相关设备，虽然业务办理增加了扫描步骤比以前更繁琐，但这更有利于档案的保存和查询，接下来我分局将加强培训，提高办事效率。此外，广东万维博通信息技术有限公司和东莞市高地人才服务有限公司将协助我分局把2017年10月前的档案进行数字化归档，11月13日，市社保局档案管理科科长翟敏莹带领外包公司的工作人员到我分局查看场地，根据翟科长的意见和建议，接下来我分局将做好场地布置，协助外包公司做好此项工作，确保尽快实现和完善业务档案数字化管理。

好枪手是靠子弹喂出来的，好分析师是靠大量项目实践沉淀出来的。

我的数据从业历程是从咨询公司切入，那里有稍微学术点的指标体系和方法论。然后在数据服务公司应用，那里有比较成熟的数据采集实现技术。而后在微博数据创业公司将之前的知识技能进行应用和商业。回过头来看，那会的观点暂时经得起这五年时间的考验，同时也正是因为没经历过甲方公司的数据分析，所以彼时对业务的重要性感知不深，上文也就未有过多提及。

一， 不懂业务，分析就仅仅只是提数

借用下大数据的梗，“数据分析要懂业务”这句话就像“Teenage Sex”——人人都在谈论，但没谁知道究竟怎么叫懂业务，人人都觉得别人都懂，所以人人都觉得自己懂业务。请允许我老调重弹，以个人视角阐述下什么叫懂业务，

不妨以别人家的产品为例——

对于头条类的内容产品来说，他的业务模式无非是从(内容)生产到分发再到变现，从而实现从投入到盈利，再到盈利增长这样一个商业闭环，要想将这个模式跑通，他就得有内容（生产者），有用户（消费者），有平台（消费平台），有广告（激励生产者和平台）。

1）如果懂业务，你就不会在日活出现下行趋势时单纯提出加大广告投放这样谁都知道的建议;你就不会在生产者因竞品提升激励费用而出现流失苗头时，只是轻描淡写的报一下同环比;你就不会在关于广告的反馈量异常提升时粗暴建议业务侧全局减少广告频率…. 。

2）如果懂业务，你就会知道数据工作该如何推进，第一阶段应该是基础数据建设，保证数据收集的规范化、全景化和扩展化，保障从打点->收集->清洗->统计->入库这个数据生产流程的效率和稳定。第二阶段重点关注种子用户的数据表现，用户对产品哪些功能使用不顺畅，对哪些品类的内容更加有偏爱，什么样渠道的用户质量更高，并将以上结论同步输出给业务侧，并持续进行PDCA循环，直至通过留存率测算出来的life-time足够支持进入爆发期。在爆发期的分析重点就是不断提升运转效率，比如根据用户偏好特征进行定向组织生产，继而扩大分发场景，从APP内分发再到APP外分发，不断提高单篇内容的分发效率;优化产品的栏目布局、功能按钮等动线设计，满足不同人群的使用偏好，提高”坪效、人效”;从买用户到等用户再到涨用户，目前产品的核心用户群体是谁，在社会人口这个大盘里是否已渗透彻底，如果没有，通过什么渠道可以“捕捉”到他们，以及通过分享/转发这些策略的设计，实现用户的自增长。在第二阶段的种种目的都是为了不断放大用户与内容的规模效应，为商业化做准备。第三阶段的分析重点则是关注商业侧表现，内容无论是自产也好，还是UGC也罢，都是有成本的，成本换作了流量，流量又通过商业化实现了变现，所以需要通过数据优化当前的广告形式和策略，帮助金主爸爸找到最匹配的用户，以及让用户发现最需要的广告，从而实现ROI的最大化;第四阶段则应关注创新发展，国内同行当前的发展模式都有哪些，以及各自的差异化竞争点，国外是否有类似的行业以及当下现状是如何，用户还有哪些延伸需求没有得到满足，内容行业的未来发展趋势是什么，以及可能会遇到的法律法规等政策风险。

2）如果懂业务，你就会知道在相应的阶段老板的关注点是什么，你就会设计出更符合业务视角的报表，通过相应的专题分析，解答老板还未开口的”需求”。

3）如果懂业务，你就会想到首先要了解各业务角色的KPI，对于团队协作来说，最有力的方法就是驱之以利，而非驱之以理，当业务人员知道你们是利益共同体的时候，良好的协作也就有了保障。

说了这么多，那问题来了，如何检验自己是否懂业务，个人有个小经验，就是看你的主要时间花费和产出都在哪里？如果懂业务，你的主要产出就一定不会是提数，因为老板&业务部门知道，让你提数那就是浪费公司人效&损害自己利益。否则，分析就仅仅只能是提数。

二， 回归本质，数据才能为业务赋能

引用下百度百科的解释，“数据就是数值，他是我们通过观察、实验或计算得出的结果。数据有很多种，最简单的就是数字。”数据的本质是数值，只是属于结果而已，要想改变结果，只能去寻找因，从因上做改变，才能引起数变。

这段话可能不太好理解，举一个大家都知道的流水万能公式----

流水=日活*购买率*人均购买金额，这个公式还可以继续往下拆，并将拆解后的因子交给不同的业务小组负责，美名其曰---KPI。老司机都知道，这个公式最大的意义是跟踪和监控，而不能作为执行目标，初期可能还行，但到了稳定期后，日活一旦大幅提升，购买率和人均购买金额反而出现了下降；业务做了很多优化，好不容易购买率得到了提升，购买金额反而下去了；为了人均购买金额达标，运营推荐了很多高价商品，结果购买率却又下降了。。。为什么，因为流水只是个结果表现，这个结果是由用户决策产生的，决定流水的正确因子应该是用户的需求强度，购买力，以及相应购买力用户与相应价格档商品的匹配程度。如果不从因果关系上想解决办法，而只在当前的存量购买力下，追求各个伪因子，就会出现按下葫芦浮起了瓢。尤其在甲方业务环境里，各个小组都是紧密围绕在核心KPI的基本路线，如果数据侧陷入到各业务小组的KPI分析需求里而没有及时纠错，那后果将万劫不复。

再举一个例子，下图是业务里常用的数据报表视图，并随着业务的迭代和细化，出现各种报表堆砌，泼盆冷水，这种报表哪怕就是有几万份，哪怕就是进行分钟级别的异动监控，可能对业绩提升也于事无补，该跌还是跌

我们不妨将视图变换一下，

以上表头只是示意，并没有详细展开，主要思路是将结果型报表变换成过程型报表，以用户视角将整个报表分成基本属性 、兴趣偏好 、使用特征 、商业贡献四个单元。基本属性主要是以新增日期，渠道，机型，性别，年龄等为代表的用户基础描述。兴趣偏好是用户在使用产品之后表现出来的特性，比如喜欢卡牌、RPG等品类游戏。使用特征则是用户在使用产品时留下的数据行为，比如浏览/点击/搜索次数。商业贡献则是衡量用户对商业化的贡献，比如购买次数，购买金额。商业贡献结合基础属性其实就是用户LTV的整个监控。有了这种视图后，就等于有了自变量与因变量，就可以回到我们熟悉的因子，回归，判别这些多变量分析方法上来，至于RFM、CRM、渠道评估/反作弊等解决方案的产出更不在话下。

正是基于这种过程型数据结构，我们做了很多有意思的项目研究，比如如何提高游戏下载量，如何提高用户活跃度，如何降低卸载率，如何提高PUSH转化效率，如何将当前收入再翻倍，流失用户的再召回等等，并且创新的结合用户反馈等文本数据，很通畅的将定量+定性这些只能在传统市场研究公司实现的研究方法在互联网业务模式进行了再现，至于项目效果，抱歉无法提供太多，但我想说，这个圈子其实没多大，想打听，其实不难。

一直坚信一点，在数据分析这个行当是永无止境的，因为产生数据的主体---人始终在变，所有的经验和方法今天可能是你的利器，明天或许就是伤害你的凶器。熟悉业务的好处是可以有相同的对话语境和立场，但弊端就是常常因走得太近，走得太快而忘记数据的本质，一个优秀的分析师是需要建立起一套属于自己的分析系统，其中，很重要的一个环节是自我纠错机制，这点，我也是在摸索。

三， 数据先行，增长才能更加稳准狠

伴随着人口红利消解，互联网大盘流量增长接近上限这个大背景，增长黑客（Growth Hacker）的概念现在越来越火，这里，我想说两点，

1）对于什么微信裂变，社群运营，用户补贴，拼团这些来说，都是属于增长手段，手段是有有效期和环境的，他的有效往往是在透支行业平均成功率的基础之上,毕竟后来者的复制会加快人群防疫力的构建, 不仅会慢慢失效，还有可能会对自身造成伤害,在模仿手段的这个赛道里恐怕只有第一,没有第二。

电商行业有句打油诗是这么说的----

“用户促活一句话：推送信息把券发，

有事没事发短信：您要登陆把礼拿，优质产品在秒杀，再不来就没有啦~

要是客户不买账，直接拿券头上砸”

这种生搬硬套无脑跟风做增长的后果就是成本越来越高，效果越来越差。用户的购买决策体系发生紊乱，商家的定价权也受到质疑，“价格太虚了，啥时候有优惠啥时候再来买，反正也不着急”。薅羊毛的用户越来越多，平台陷入了饮酖止渴的尴尬境地。

2）增长黑客正确的姿势应当是数据先行，数据的优势是可以客观的，全局的，通过一组指标还原用户场景和动机，进而归纳演绎->找到差异->抓住增长点。再往大了说，数据增长还应包括用户定位，产品设计，价格策略等一系列全链条环节，这个后面有机会再聊。

同时增长类项目能发挥多大效能，还取决两个前提：

a、数据增长是游离在产品、运营、技术、品牌之外的一种高效组织形式，打破常规分工模式和业务惯性，需要跨部门/跨角色间的联动，这种联动越高效越好.

b、正是因为与原有分工体系游离和并存，所以不可避免会有碰撞和交融，那么对增长小组进行直接授权和负责的管理层级别越高越好。

下图是根据淘宝亲情账号的公关稿以及一组假数据结合的增长案例，

如上所说，流水=日活*购买率*购买金额，在存量购买力下，单纯提高某一个因子对总流水的提升都于事无补，但可以做的是通过数据还原用户的需求场景，继而进行场景再造，健康的将业绩目标进行稳定增长。

数据分析师是个孤独的圈子，孤独在没法跟同行交流和切磋，泛泛谈没有价值，说来说去就是那么几点---趋势/细分/对比/多变量，有价值的是背后各种方法的尝试以及遇到的坑，难免不涉及业务细节，也就没法展开进行描述，不得已用了很多别人家的案例，有不太清楚的地方欢迎进行具体交流。

至于数据分析的前景，无需多做宣贯，只提一点，当像充电宝，单车，咖啡，甚至汽车、大卖场这些传统行业都逐渐开始互联网化的时候，意味着互联网从轻资产走向重资产时代，你觉得企业还会不重视精细化运营么？产品有bug我们可以及时回滚，可智能硬件的生产制造都是有成本的，一旦生产多了卖不出去就成了库存积压，生产少了用户买不到体验就不好，至于新零售的本质就更是提高人货场的周转效率，这些可都是数据问题啊。效率运营的精细化程度可能逐渐成为未来产品间的护城河。

好枪手是靠子弹喂出来的，好分析师是靠大量项目实践沉淀出来的，上图是根据资料以及自己的理解进行的归纳提炼—数据应用的三层价值模型&数据人员能力成长体系，耐得住寂寞，才能守得住繁华，在数据分析这个道路，我们一起梦想与前行。

本文为作者原创并投稿鸟哥笔记，未经授权谢绝转载。