編輯導語：神策數(shù)據(jù)，主要圍繞用戶行為分析，為用戶完成數(shù)據(jù)采集和數(shù)據(jù)分析。圍繞用戶級大數(shù)據(jù)分析和管理需求，推出神策分析、神策智能運營、神策智能推薦、神策用戶畫像、神策客景等產品。 本文作者從甲方的角度出發(fā)，對神策進行了拆解。

大家好，我是羅文正雄，現(xiàn)在在一家教育公司做數(shù)據(jù)營銷產品，本次我來分享關于神策這個數(shù)據(jù)系統(tǒng)的一些思考。當前行業(yè)里有一句正確的廢話：數(shù)據(jù)分析很重要，數(shù)據(jù)驅動很重要。

但是看了很多圍繞這些話寫的文章，具體咋做卻很少有介紹，看的云里霧里，不夠落地，關于神策的思路和實踐經驗，我會用如下系列文章來進行闡述如何讓數(shù)據(jù)和業(yè)務結合，也歡迎大家指點挑錯，一起成長~

1. 講解神策的產品功能以及架構；
2. 講解神策在部署和對接實施過程中遇到的問題，以及倒推整個SaaS的實施思路；
3. 講解神策實施時埋點的設計思路細節(jié)，與對應的問題點；
4. 神策系統(tǒng)在整個公司內如何賦能業(yè)務，并且作用精準作用于營銷。

然后還有其他比如UML，權限設計的內容會單獨整合到一個新的專題講。本篇文章即為第一篇，主要講的就是神策后臺的產品使用體驗和核心產品結構倒推，下面開始正文：

業(yè)務使用現(xiàn)狀：公司的數(shù)據(jù)系統(tǒng)最初采購的是GIO，因業(yè)務自身的復雜性未完全兼容，內部的實施沒有到位等種種原因，賦能業(yè)務的效果不佳，最后又嘗試采購了神策。

神策現(xiàn)在已經在公司運行了快兩年，有很多業(yè)務和思路都已經深度的和神策融合，并且使用了“全家桶”，有分析系統(tǒng)（SA），智能運營系統(tǒng)（SF），還有用戶畫像系統(tǒng)（SPS）。

神策也在我們業(yè)務中與內部CRM，電商促銷模塊，push/短信/消息中心打通，對營銷過程的每個環(huán)節(jié)提供了數(shù)據(jù)支持和線索支持，使得運營的著力點更加集中，更加高效。

具體如何賦能，我會在第四篇進行詳細講解，并結合實際活動案例，讓大家溝通的更順暢。

一、產品架構倒推

我不是神策的產品經理，但我從一個后臺或平臺產品經理的角度去思考和倒推他們的產品架構，發(fā)現(xiàn)他們的架構做的很靈活，插件化或者說應用化做的已經挺成熟。

比如針對某家客戶的需求，可以控制具體的開關，運維操作一下就會有對應的功能，這也是一個競爭力。

核心是埋點和模型：

在我看來，神策的產品核心的核心，就是事件-用戶模型。事件-用戶模型的數(shù)據(jù)，為后面事件分析，留存分析，歸因分析，運營計劃等功能，提供了數(shù)據(jù)的基礎。

這個模型其實也是從埋點數(shù)據(jù)的格式抽象出來的，你們看，埋點是這么描述現(xiàn)實世界發(fā)生的事情的：“什么人（who）在什么時候（when），什么地點（where），用什么方式（how）做了某件事（what）（可能有how much）”。

舉例：“羅文在2021年1月17日，位于北京的一所破舊出租屋內，用一臺win7的電腦發(fā)布了這篇4727字的文章?！?/p>

這種日志格式的文件，抽象和解耦出來的最好方式，就是將人和事分開，所以神策也采用了“user-event”的數(shù)據(jù)模型，可以輕松做到“人歸人，事歸事”，這就是我認為的核心。

二、架構倒推

接下來的信息量就會很大，我從神策的實際使用和驗證中，倒推出神策的產品結構，如下圖：

如果不清楚，還有個大圖：

左側是我們的業(yè)務系統(tǒng)，右側是神策的系統(tǒng)，都是我倒推出來的，不代表神策實際的設計哈！因本文主要講解的是神策，所以我們的業(yè)務系統(tǒng)去掉了無關內容圖中神策的系統(tǒng)構成主要有這幾個：

1. 外部數(shù)據(jù)源

即數(shù)據(jù)匯總層，神策是基于埋點日志數(shù)據(jù)分析的，所有的埋點數(shù)據(jù)需要從各端進行上報，包含了4個方面

1. 前端web的上報，用到了web的sdk，主要面向前端頁面點擊等場景；
2. 后端java SDK的上報，更多面向前端無法采集的事件，比如支付相關；
3. Android和iOS以及小程序的sdk上報，類似web端，都是監(jiān)控交互層面的場景；
4. api導入，這個就有點特殊了，面向的是無法通過埋點來準確抓取或者更新的數(shù)據(jù)，我們這里業(yè)務上會把直播類的數(shù)據(jù)用T+1的方式上傳。

2. 基礎數(shù)據(jù)層

這個層面，就存儲的是數(shù)據(jù)表那層的東西了，也是以開頭說的“事件-用戶”模型的埋點事件為主，包含用戶數(shù)據(jù)，事件數(shù)據(jù)，標簽和分群數(shù)據(jù)，元數(shù)據(jù)（屬性和虛擬屬性，虛擬事件）。

在這一層，可以向外提供直接查詢的能力，也可以給神策自身的神策全家桶提供支持。

3. 數(shù)據(jù)組件

這層其實可以不寫的，但是為了更好理解，還是列了出來，原因是數(shù)據(jù)存儲歸存儲，查詢的時候還是得調用查詢引擎的，而且存儲也不是割裂開的，所以我列了出來，神策當前用的查詢引擎是impala，存儲是kudu，都是符合大數(shù)據(jù)量存儲和OLAP查詢的相關組件。

4. 神策分析

包含了神策分析系統(tǒng)的各個常用功能，比如事件分析，留存分析，都是在架構圖下方的數(shù)據(jù)基礎上才得以運行。

5. 定時任務模塊

主要是運行了智能運營，用戶分群/標簽相關的定時任務，其實這個模塊可以為神策內部任何需要定時任務的系統(tǒng)提供支持。

6. 智能運營系統(tǒng)

這個就很龐大了，這個系統(tǒng)解決了業(yè)務的痛點，使用神策分析得到的高價值用戶無法快捷觸達，往往要流轉在各個業(yè)務系統(tǒng)間由人工操作，這個系統(tǒng)上了以后解決了大部分的人工操作場景。

智能運營的核心邏輯，在我看來有3步：圈選用戶——設定觸發(fā)邏輯和通道——統(tǒng)計觸發(fā)結果，整個核心邏輯都是基于神策的埋點數(shù)據(jù)實現(xiàn)。

7. 用戶畫像系統(tǒng)

用戶畫像系統(tǒng)是主要針對用戶數(shù)據(jù)操作的系統(tǒng)，為公司的精細化運營提供了很便捷的切入場景。這個系統(tǒng)的核心邏輯也有3步，而且和智能運營的底層邏輯是一致的：圈選用戶群——設定分析框架模板——計算分析結果。

8. 權限和賬號管理模塊

這個算是系統(tǒng)的權限控制組件，包含了用戶管理和角色管理，當前的版本做的還是比較粗糙的，面向小企業(yè)足夠用了，但是內部決策鏈條復雜的企業(yè)，對這部分功能要求的很深，比如一個審核的權限，都要有不同的人來審核不同的內容，不能互相干擾。

三、未來迭代的推測

講完枯燥的架構圖，我說下我對神策未來迭代方向的想法。分兩塊來講，一塊是當前尚未滿足的需求，一塊是未來可能會有的需求：

1. 當前尚未滿足的需求

1）角色授權的細化

企業(yè)內部每個人的負責內容，不是嚴格的區(qū)隔開的，并且公司規(guī)模越小，身兼數(shù)職的身份就越明顯，而且當一個企業(yè)從小變壯大時，這個角色的切換，交接，過渡，都會在系統(tǒng)使用中體現(xiàn)出來。這種小企業(yè)變成大企業(yè)的數(shù)量，應該也不在少數(shù)。

比如要審核一個運營計劃，A項目就想讓A項目的領導來審，并且B項目無法干涉A項目的計劃。這種場景未來肯定會遇到的，而且經過和神策老師的溝通，其實這部分工作已經開始了，只不過尚未發(fā)布。

這部分對我們影響是有一些的，不過不大，我們業(yè)務協(xié)商就解決了。

2）埋點數(shù)據(jù)是不可更新的，阻擋了一部分需求的滿足

埋點數(shù)據(jù)就是如實上報的，并且不可更改，這個可以說是神策埋點數(shù)據(jù)的“基因”，技術邏輯是正確的，但業(yè)務卻遇到問題。其他以數(shù)據(jù)埋點為基礎的數(shù)據(jù)服務商應該也都會遇到下面這個問題：

這部分場景遇到的問題，是我們訂單數(shù)據(jù)上報之后，已支付訂單又撤銷了，想統(tǒng)計之前已經上報的訂單中有哪些撤銷了?，F(xiàn)在只能在事件設計上做一個“訂單撤銷事件”，但是很難看到一個訂單的全量實時表。

這也是我經歷和思考到的一個比較尷尬的點，神策在給客戶提供分析類服務，但是客戶還想在分析的同時，看到類似業(yè)務庫事實表的結果，因為客戶采購神策的原因就是內部的數(shù)據(jù)系統(tǒng)無法滿足拉通的統(tǒng)計，用神策可以直觀看到數(shù)據(jù)的統(tǒng)計，但是想進一步卻又無法看到內部業(yè)務后臺的最新結果。

如果要神策的數(shù)據(jù)和內部業(yè)務系統(tǒng)數(shù)據(jù)一起對比，又發(fā)現(xiàn)，在神策埋點數(shù)據(jù)不更新的前提上，神策和業(yè)務系統(tǒng)的結果往往是不一致的，業(yè)務就會瘋狂反饋，說“數(shù)據(jù)不準！以誰為準！”造成很嚴重的內耗。

這個問題用當前的事件分析 ，是不能解決的。當前我們的解決辦法，就是在內部跟同事強調神策是只能做分析的，解決運營問題的，想看最新匯總結果，以自己的業(yè)務系統(tǒng)為準。

3）直播預約未出勤類的場景

此類場景的邏輯是用戶做了某件事，但在某個時刻尚未做某件事時候需要被觸發(fā)，來滿足直播到課的出勤率。

比如用戶預約了直播課，直播課8點開始以后，8點10分仍未出勤的用戶，就需要發(fā)條短信催一下了，我們之前以為可以使用神策的智能運營，但是這個點尚未滿足，他們現(xiàn)在可以滿足的是用戶做了A之后某段時間未完成B，場景邏輯略有區(qū)別。

2. 未來可能會出現(xiàn)的需求

1）微信生態(tài)營銷和企業(yè)微信營銷

在朋友圈的營銷鏈條內，用戶觸達企業(yè)主體前，會經過微信引流頁或者文章頁，轉化到公眾號，然后進行關注，引流加私人微信，拉群轉化，整個過程都是微信生態(tài)內進行操作，微信內部的數(shù)據(jù)對企業(yè)來講，不能很好的和投放以及成單的數(shù)據(jù)打通，統(tǒng)計與歸因誤差較大。

針對企業(yè)微信，如果神策能提供企業(yè)微信相關的數(shù)據(jù)對接，上報會話事件，那么企業(yè)微信這里的場景就能滿足。

針對微信和公眾號，打通閱讀瀏覽數(shù)據(jù)，就能有力的賦能微信營銷相關的業(yè)務，當然這里的核心矛盾在于微信是否提供開放的數(shù)據(jù)接口，以及神策如何將數(shù)據(jù)跨端整合，難度會比較大。

2）數(shù)據(jù)治理

宏觀看，神策的基礎系統(tǒng)就是神策分析，單有這一個系統(tǒng)不足夠的。

神策所服務的對象，是一家家數(shù)據(jù)成熟度尚且不高的公司，這些公司運營時，根據(jù)神策分析的結果，做出一些決策，然后應用于業(yè)務中，但這個流程往往并不通順，因為大多數(shù)情況下，數(shù)據(jù)成熟度不高的公司，業(yè)務系統(tǒng)迭代的效率也往往很低，業(yè)務系統(tǒng)來不及做可以快速調用神策信息的接口。

拿我們之前的業(yè)務流程舉例：神策篩選出訂單事件高價值的用戶，導出uid，然后拿uid在crm里上傳，再標記上業(yè)務的屬性，打標簽，這個過程能一步解決的話，絕對是對運營業(yè)務提高效率的大殺器！

果然，為了補全運營的短板，智能運營這里滿足的就是這個場景，雖然滿足的不是非常好，但足以覆蓋我們大多數(shù)的業(yè)務場景了，基于這些場景，還會有一些電銷通道，或者說是微信的微銷通道的觸達，都可以支撐我們業(yè)務對當前的用戶做存量精細化運營。

3. 神策未來的需求可能出現(xiàn)在哪？

個人認為，當前神策已經有了策略推薦的數(shù)據(jù)組件，也有了類CRM的組件，都是面向業(yè)務前端的，但偏向后端有個不起眼但很影響的環(huán)節(jié)，就是在于這些公司的底層數(shù)據(jù)質量差，數(shù)據(jù)全鏈路的質量，決定了公司數(shù)據(jù)驅動的質量，如果數(shù)據(jù)不行，驅動也無法發(fā)揮真正的作用。

中國國內大多數(shù)的企業(yè)分布是中小企業(yè)居多，非一二線的企業(yè)居多，這些企業(yè)對待數(shù)據(jù)大概率是不敏感的，對待數(shù)據(jù)質量的把控態(tài)度更甚，出單就行。

并且大多數(shù)的企業(yè)是以利潤為主，公司內的工作都按照問題驅動，數(shù)據(jù)的治理，在大多數(shù)企業(yè)的視角里不算是問題，即使是問題，也是一個費力不討好，得不到績效的問題。

另外，國內大多數(shù)企業(yè)都偏向傳統(tǒng)，這些企業(yè)其實是很缺少，也很迫切需要數(shù)據(jù)驅動能力，但是在治理方面，也缺少組織上的能力。數(shù)據(jù)治理是需要在組織中建立共識和規(guī)范的，這樣數(shù)據(jù)治理才能貫徹下去。

所以，神策如果能提供一個基于數(shù)據(jù)治理的平臺，企業(yè)只需要將內部的需要治理的脫敏數(shù)據(jù)庫開放給神策，對應的數(shù)據(jù)匯總到神策中，給企業(yè)提供一個全局了解自己數(shù)據(jù)的入口，讓這些決策者看到實實在在的問題，企業(yè)肯定會重視起來的。

但對神策來講，這部分確實可以提高他們服務的用戶的數(shù)據(jù)成熟度，但是帶來經濟效益的可能性，短期不大。

五、關于行業(yè)上的競爭力

能力的交付，以及整個使用期間的服務流程。

服務就是到位，這個沒得說，我們周六在神策群里反饋問題，都會有人解答，他們的分析師和客戶成功都有種拼勁，我們提供的一個關于活動的想法，都會在很晚的時候得到他們的反饋，這個過程很踏實的。

相比于我們采購的某家IM，問題會偶爾出現(xiàn)，但周六日想找到人解決，居然在群里甩給我們一個網頁版官方在線客服鏈接，讓我們去找客服，更尷尬的是，還偶爾出現(xiàn)在線客服也下班的情況，這個對比之下，只能造成加倍的傷害，只會越發(fā)的不滿意。

后續(xù)文章預告：

1. 講解神策在部署和對接實施過程中遇到的問題，以及倒推整個SaaS的實施思路；
2. 實施時埋點的設計思路細節(jié)，與對應的問題點；
3. 神策系統(tǒng)在整個公司內如何賦能業(yè)務，并且作用精準作用于營銷。

作者：羅文正雄；公眾號：羅文正雄

本文由 @羅文正雄 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協(xié)議