编辑导语：神策数据，主要围绕用户行为分析，为用户完成数据采集和数据分析。围绕用户级大数据分析和管理需求，推出神策分析、神策智能运营、神策智能推荐、神策用户画像、神策客景等产品。 本文作者从甲方的角度出发，对神策进行了拆解。
大家好，我是罗文正雄，现在在一家教育公司做数据营销产品，本次我来分享关于神策这个数据系统的一些思考。当前行业里有一句正确的废话：数据分析很重要，数据驱动很重要。
但是看了很多围绕这些话写的文章，具体咋做却很少有介绍，看的云里雾里，不够落地，关于神策的思路和实践经验，我会用如下系列文章来进行阐述如何让数据和业务结合，也欢迎大家指点挑错，一起成长~
- 讲解神策的产品功能以及架构；
- 讲解神策在部署和对接实施过程中遇到的问题，以及倒推整个SaaS的实施思路；
- 讲解神策实施时埋点的设计思路细节，与对应的问题点；
- 神策系统在整个公司内如何赋能业务，并且作用精准作用于营销。
然后还有其他比如UML，权限设计的内容会单独整合到一个新的专题讲。本篇文章即为第一篇，主要讲的就是神策后台的产品使用体验和核心产品结构倒推，下面开始正文：
业务使用现状：公司的数据系统最初采购的是GIO，因业务自身的复杂性未完全兼容，内部的实施没有到位等种种原因，赋能业务的效果不佳，最后又尝试采购了神策。
神策现在已经在公司运行了快两年，有很多业务和思路都已经深度的和神策融合，并且使用了“全家桶”，有分析系统（SA），智能运营系统（SF），还有用户画像系统（SPS）。
神策也在我们业务中与内部CRM，电商促销模块，push/短信/消息中心打通，对营销过程的每个环节提供了数据支持和线索支持，使得运营的着力点更加集中，更加高效。
具体如何赋能，我会在第四篇进行详细讲解，并结合实际活动案例，让大家沟通的更顺畅。
一、产品架构倒推
我不是神策的产品经理，但我从一个后台或平台产品经理的角度去思考和倒推他们的产品架构，发现他们的架构做的很灵活，插件化或者说应用化做的已经挺成熟。
比如针对某家客户的需求，可以控制具体的开关，运维操作一下就会有对应的功能，这也是一个竞争力。
核心是埋点和模型：
在我看来，神策的产品核心的核心，就是事件-用户模型。事件-用户模型的数据，为后面事件分析，留存分析，归因分析，运营计划等功能，提供了数据的基础。
这个模型其实也是从埋点数据的格式抽象出来的，你们看，埋点是这么描述现实世界发生的事情的：“什么人（who）在什么时候（when），什么地点（where），用什么方式（how）做了某件事（what）（可能有how much）”。
举例：“罗文在2021年1月17日，位于北京的一所破旧出租屋内，用一台win7的电脑发布了这篇4727字的文章。”
这种日志格式的文件，抽象和解耦出来的最好方式，就是将人和事分开，所以神策也采用了“user-event”的数据模型，可以轻松做到“人归人，事归事”，这就是我认为的核心。
二、架构倒推
接下来的信息量就会很大，我从神策的实际使用和验证中，倒推出神策的产品结构，如下图：
如果不清楚，还有个大图：
左侧是我们的业务系统，右侧是神策的系统，都是我倒推出来的，不代表神策实际的设计哈！因本文主要讲解的是神策，所以我们的业务系统去掉了无关内容图中神策的系统构成主要有这几个：
1. 外部数据源
即数据汇总层，神策是基于埋点日志数据分析的，所有的埋点数据需要从各端进行上报，包含了4个方面
- 前端web的上报，用到了web的sdk，主要面向前端页面点击等场景；
- 后端java SDK的上报，更多面向前端无法采集的事件，比如支付相关；
- Android和iOS以及小程序的sdk上报，类似web端，都是监控交互层面的场景；
- api导入，这个就有点特殊了，面向的是无法通过埋点来准确抓取或者更新的数据，我们这里业务上会把直播类的数据用T+1的方式上传。
2. 基础数据层
这个层面，就存储的是数据表那层的东西了，也是以开头说的“事件-用户”模型的埋点事件为主，包含用户数据，事件数据，标签和分群数据，元数据（属性和虚拟属性，虚拟事件）。
在这一层，可以向外提供直接查询的能力，也可以给神策自身的神策全家桶提供支持。
3. 数据组件
这层其实可以不写的，但是为了更好理解，还是列了出来，原因是数据存储归存储，查询的时候还是得调用查询引擎的，而且存储也不是割裂开的，所以我列了出来，神策当前用的查询引擎是impala，存储是kudu，都是符合大数据量存储和OLAP查询的相关组件。
4. 神策分析
包含了神策分析系统的各个常用功能，比如事件分析，留存分析，都是在架构图下方的数据基础上才得以运行。
5. 定时任务模块
主要是运行了智能运营，用户分群/标签相关的定时任务，其实这个模块可以为神策内部任何需要定时任务的系统提供支持。
6. 智能运营系统
这个就很庞大了，这个系统解决了业务的痛点，使用神策分析得到的高价值用户无法快捷触达，往往要流转在各个业务系统间由人工操作，这个系统上了以后解决了大部分的人工操作场景。
智能运营的核心逻辑，在我看来有3步：圈选用户——设定触发逻辑和通道——统计触发结果，整个核心逻辑都是基于神策的埋点数据实现。
7. 用户画像系统
用户画像系统是主要针对用户数据操作的系统，为公司的精细化运营提供了很便捷的切入场景。这个系统的核心逻辑也有3步，而且和智能运营的底层逻辑是一致的：圈选用户群——设定分析框架模板——计算分析结果。
8. 权限和账号管理模块
这个算是系统的权限控制组件，包含了用户管理和角色管理，当前的版本做的还是比较粗糙的，面向小企业足够用了，但是内部决策链条复杂的企业，对这部分功能要求的很深，比如一个审核的权限，都要有不同的人来审核不同的内容，不能互相干扰。
三、未来迭代的推测
讲完枯燥的架构图，我说下我对神策未来迭代方向的想法。分两块来讲，一块是当前尚未满足的需求，一块是未来可能会有的需求：
1. 当前尚未满足的需求
1）角色授权的细化
企业内部每个人的负责内容，不是严格的区隔开的，并且公司规模越小，身兼数职的身份就越明显，而且当一个企业从小变壮大时，这个角色的切换，交接，过渡，都会在系统使用中体现出来。这种小企业变成大企业的数量，应该也不在少数。
比如要审核一个运营计划，A项目就想让A项目的领导来审，并且B项目无法干涉A项目的计划。这种场景未来肯定会遇到的，而且经过和神策老师的沟通，其实这部分工作已经开始了，只不过尚未发布。
这部分对我们影响是有一些的，不过不大，我们业务协商就解决了。
2）埋点数据是不可更新的，阻挡了一部分需求的满足
埋点数据就是如实上报的，并且不可更改，这个可以说是神策埋点数据的“基因”，技术逻辑是正确的，但业务却遇到问题。其他以数据埋点为基础的数据服务商应该也都会遇到下面这个问题：
这部分场景遇到的问题，是我们订单数据上报之后，已支付订单又撤销了，想统计之前已经上报的订单中有哪些撤销了。现在只能在事件设计上做一个“订单撤销事件”，但是很难看到一个订单的全量实时表。
这也是我经历和思考到的一个比较尴尬的点，神策在给客户提供分析类服务，但是客户还想在分析的同时，看到类似业务库事实表的结果，因为客户采购神策的原因就是内部的数据系统无法满足拉通的统计，用神策可以直观看到数据的统计，但是想进一步却又无法看到内部业务后台的最新结果。
如果要神策的数据和内部业务系统数据一起对比，又发现，在神策埋点数据不更新的前提上，神策和业务系统的结果往往是不一致的，业务就会疯狂反馈，说“数据不准！以谁为准！”造成很严重的内耗。
这个问题用当前的事件分析 ，是不能解决的。当前我们的解决办法，就是在内部跟同事强调神策是只能做分析的，解决运营问题的，想看最新汇总结果，以自己的业务系统为准。
3）直播预约未出勤类的场景
此类场景的逻辑是用户做了某件事，但在某个时刻尚未做某件事时候需要被触发，来满足直播到课的出勤率。
比如用户预约了直播课，直播课8点开始以后，8点10分仍未出勤的用户，就需要发条短信催一下了，我们之前以为可以使用神策的智能运营，但是这个点尚未满足，他们现在可以满足的是用户做了A之后某段时间未完成B，场景逻辑略有区别。
2. 未来可能会出现的需求
1）微信生态营销和企业微信营销
在朋友圈的营销链条内，用户触达企业主体前，会经过微信引流页或者文章页，转化到公众号，然后进行关注，引流加私人微信，拉群转化，整个过程都是微信生态内进行操作，微信内部的数据对企业来讲，不能很好的和投放以及成单的数据打通，统计与归因误差较大。
针对企业微信，如果神策能提供企业微信相关的数据对接，上报会话事件，那么企业微信这里的场景就能满足。
针对微信和公众号，打通阅读浏览数据，就能有力的赋能微信营销相关的业务，当然这里的核心矛盾在于微信是否提供开放的数据接口，以及神策如何将数据跨端整合，难度会比较大。
2）数据治理
宏观看，神策的基础系统就是神策分析，单有这一个系统不足够的。
神策所服务的对象，是一家家数据成熟度尚且不高的公司，这些公司运营时，根据神策分析的结果，做出一些决策，然后应用于业务中，但这个流程往往并不通顺，因为大多数情况下，数据成熟度不高的公司，业务系统迭代的效率也往往很低，业务系统来不及做可以快速调用神策信息的接口。
拿我们之前的业务流程举例：神策筛选出订单事件高价值的用户，导出uid，然后拿uid在crm里上传，再标记上业务的属性，打标签，这个过程能一步解决的话，绝对是对运营业务提高效率的大杀器！
果然，为了补全运营的短板，智能运营这里满足的就是这个场景，虽然满足的不是非常好，但足以覆盖我们大多数的业务场景了，基于这些场景，还会有一些电销通道，或者说是微信的微销通道的触达，都可以支撑我们业务对当前的用户做存量精细化运营。
3. 神策未来的需求可能出现在哪？
个人认为，当前神策已经有了策略推荐的数据组件，也有了类CRM的组件，都是面向业务前端的，但偏向后端有个不起眼但很影响的环节，就是在于这些公司的底层数据质量差，数据全链路的质量，决定了公司数据驱动的质量，如果数据不行，驱动也无法发挥真正的作用。
中国国内大多数的企业分布是中小企业居多，非一二线的企业居多，这些企业对待数据大概率是不敏感的，对待数据质量的把控态度更甚，出单就行。
并且大多数的企业是以利润为主，公司内的工作都按照问题驱动，数据的治理，在大多数企业的视角里不算是问题，即使是问题，也是一个费力不讨好，得不到绩效的问题。
另外，国内大多数企业都偏向传统，这些企业其实是很缺少，也很迫切需要数据驱动能力，但是在治理方面，也缺少组织上的能力。数据治理是需要在组织中建立共识和规范的，这样数据治理才能贯彻下去。
所以，神策如果能提供一个基于数据治理的平台，企业只需要将内部的需要治理的脱敏数据库开放给神策，对应的数据汇总到神策中，给企业提供一个全局了解自己数据的入口，让这些决策者看到实实在在的问题，企业肯定会重视起来的。
但对神策来讲，这部分确实可以提高他们服务的用户的数据成熟度，但是带来经济效益的可能性，短期不大。
五、关于行业上的竞争力
能力的交付，以及整个使用期间的服务流程。
服务就是到位，这个没得说，我们周六在神策群里反馈问题，都会有人解答，他们的分析师和客户成功都有种拼劲，我们提供的一个关于活动的想法，都会在很晚的时候得到他们的反馈，这个过程很踏实的。
相比于我们采购的某家IM，问题会偶尔出现，但周六日想找到人解决，居然在群里甩给我们一个网页版官方在线客服链接，让我们去找客服，更尴尬的是，还偶尔出现在线客服也下班的情况，这个对比之下，只能造成加倍的伤害，只会越发的不满意。
后续文章预告：
- 讲解神策在部署和对接实施过程中遇到的问题，以及倒推整个SaaS的实施思路；
- 实施时埋点的设计思路细节，与对应的问题点；
- 神策系统在整个公司内如何赋能业务，并且作用精准作用于营销。
