从甲方角度，拆解神策

编辑导语：神策数据，主要围绕用户行为分析，为用户完成数据采集和数据分析。围绕用户级大数据分析和管理需求，推出神策分析、神策智能运营、神策智能推荐、神策用户画像、神策客景等产品。 本文作者从甲方的角度出发，对神策进行了拆解。

大家好，我是罗文正雄，现在在一家教育公司做数据营销产品，本次我来分享关于神策这个数据系统的一些思考。当前行业里有一句正确的废话：数据分析很重要，数据驱动很重要。

但是看了很多围绕这些话写的文章，具体咋做却很少有介绍，看的云里雾里，不够落地，关于神策的思路和实践经验，我会用如下系列文章来进行阐述如何让数据和业务结合，也欢迎大家指点挑错，一起成长~

讲解神策的产品功能以及架构；

讲解神策在部署和对接实施过程中遇到的问题，以及倒推整个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端，都是监控交互层面的场景；