大家好，我是羅文；CRM&數(shù)據(jù)平臺產(chǎn)品經(jīng)理，90后老大爺；

當(dāng)前行業(yè)里有一句正確的廢話：數(shù)據(jù)分析很重要，數(shù)據(jù)驅(qū)動很重要。

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

一、講解神策的產(chǎn)品功能以及架構(gòu)

二、神策實施的實操細節(jié)和經(jīng)驗分享

然后還有其他比如UML，權(quán)限設(shè)計的內(nèi)容會單獨整合到一個新的專題講

本篇文章即為第一篇，主要講的就是神策后臺的產(chǎn)品使用體驗和核心產(chǎn)品結(jié)構(gòu)倒推，下面開始正文

業(yè)務(wù)使用現(xiàn)狀

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

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

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

產(chǎn)品架構(gòu)倒推

我不是神策的產(chǎn)品經(jīng)理，但我從一個后臺或者平臺產(chǎn)品經(jīng)理的角度去思考和倒推他們的產(chǎn)品架構(gòu)，發(fā)現(xiàn)他們的架構(gòu)做的很靈活，插件化或者說應(yīng)用化做的已經(jīng)挺成熟了，比如針對某家客戶的需求，可以控制具體的開關(guān)，運維操作一下就會有對應(yīng)的功能，這也是一個競爭力

核心是埋點和模型

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

這個模型其實也是從埋點數(shù)據(jù)的格式抽象出來的，你們看，埋點是這么描述現(xiàn)實世界發(fā)生的事情的：

“什么人（who）在什么時候（when），什么地點（where），用什么方式（how）做了某件事（what）（可能有how much）”

舉例

“羅文在2021年1月17日，位于北京的一所破舊出租屋內(nèi)，用一臺win7的電腦發(fā)布了這篇2000字的文章”

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

這就是我認為的核心內(nèi)容

架構(gòu)倒推

接下來的信息量就會很大，我從神策的實際使用和驗證中，倒推出神策的產(chǎn)品結(jié)構(gòu)，如下圖

左側(cè)是我們的業(yè)務(wù)系統(tǒng)，右側(cè)是神策的系統(tǒng)，都是我倒推出來的，不代表神策內(nèi)部實際的設(shè)計哈！

本文主要講解神策，所以我們的業(yè)務(wù)系統(tǒng)去掉了無關(guān)內(nèi)容

主要有這幾個

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

（1）前端web的上報，用到了web的sdk，主要面向前端頁面點擊等場景

（2）后端java SDK的上報，更多面向前端無法采集的事件，比如支付相關(guān)

（3）Android和iOS以及小程序的sdk上報，類似web端，都是監(jiān)控交互層面的場景

（4）api導(dǎo)入，這個就有點特殊了，面向的是無法通過埋點來準(zhǔn)確抓取或者更新的數(shù)據(jù)，我們這里業(yè)務(wù)上會把直播類的數(shù)據(jù)用T+1的方式上傳

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

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

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

4、神策分析
包含了神策分析系統(tǒng)的各個常用功能，比如事件分析，留存分析，都是在架構(gòu)圖下方的數(shù)據(jù)基礎(chǔ)上

5、定時任務(wù)層
主要是運行了智能運營，用戶分群/標(biāo)簽相關(guān)的定時任務(wù)，其實這個模塊可以為神策內(nèi)部任何需要定時任務(wù)的系統(tǒng)提供支持

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

智能運營的核心邏輯，在我看來有3步：

圈選用戶——設(shè)定觸發(fā)邏輯和通道——統(tǒng)計觸發(fā)結(jié)果
整個核心邏輯都是基于神策的埋點數(shù)據(jù)實現(xiàn)

7、用戶畫像系統(tǒng)
用戶畫像系統(tǒng)是主要針對用戶數(shù)據(jù)操作的系統(tǒng)，為公司的精細化運營提供了很便捷的切入場景

這個系統(tǒng)的核心邏輯也有3步，而且和智能運營的底層邏輯是一致的：

圈選用戶群——設(shè)定分析框架模板——計算分析結(jié)果

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

未來迭代的推測
講完枯燥的架構(gòu)圖，我來說下我對未來神策的迭代方向的看法吧

分兩塊來講，一塊是當(dāng)前尚未滿足的需求，一塊是未來可能會有的需求

1、當(dāng)前尚未滿足的需求

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

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

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

（2）埋點數(shù)據(jù)是不可更新的，阻擋了一部分需求的滿足
埋點數(shù)據(jù)就是如實上報的，并且不可更改，這個可以說是神策埋點數(shù)據(jù)的“基因”，應(yīng)該其他以數(shù)據(jù)埋點為基礎(chǔ)的數(shù)據(jù)服務(wù)商都會遇到這個問題

這部分場景遇到的問題，是我們訂單數(shù)據(jù)上報時，已支付訂單又撤銷了，在事件設(shè)計上可以做一個“訂單撤銷事件”，但是很難看到一個訂單的全量實時表

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

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

用當(dāng)前的事件分析 ，是暫時不能實現(xiàn)的。

當(dāng)前我們的解決辦法，就是在內(nèi)部跟同事強調(diào)神策是只能做分析的，解決運營問題的，想看最新匯總結(jié)果，以自己的業(yè)務(wù)系統(tǒng)為準(zhǔn)

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

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

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

神策能提供企業(yè)微信相關(guān)的數(shù)據(jù)對接，會話事件上報。針對微信和公眾號的閱讀數(shù)據(jù)進行打通，都能有力的賦能微信營銷相關(guān)的業(yè)務(wù)，當(dāng)然這里的核心矛盾在于微信是否提供開放的數(shù)據(jù)接口，以及神策如何將數(shù)據(jù)跨端整合

（2）數(shù)據(jù)治理
宏觀看，神策的基礎(chǔ)系統(tǒng)就是神策分析，但神策所服務(wù)的對象是一家家數(shù)據(jù)成熟度尚且不高的公司，這些公司運營時，根據(jù)神策分析的結(jié)果，做出一些決策，然后應(yīng)用于業(yè)務(wù)中，但這個流程往往并不通順，因為大多數(shù)情況下，數(shù)據(jù)成熟度不高的公司，業(yè)務(wù)系統(tǒng)迭代的效率也往往很低，來不及做可以快速調(diào)用的接口

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

果然，為了補全運營的短板，智能運營這里滿足的就是這個場景，雖然滿足的不是非常好，但足以覆蓋我們大多數(shù)的業(yè)務(wù)場景了，基于這些場景，還會有一些電銷通道，或者說是微信的微銷通道的觸達，都是繼續(xù)滿足當(dāng)前存量競爭的運營需求

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

中國國內(nèi)大多數(shù)的企業(yè)現(xiàn)狀是什么樣？中小企業(yè)居多，非一二線的企業(yè)居多，這些企業(yè)對待數(shù)據(jù)大概率是不敏感的，對待數(shù)據(jù)質(zhì)量的把控更甚

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

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

所以，神策如果能提供一個基于數(shù)據(jù)治理的平臺，企業(yè)只需要將內(nèi)部的需要治理的脫敏數(shù)據(jù)庫開放給神策，對應(yīng)的數(shù)據(jù)匯總到神策中，給企業(yè)提供一個全局了解自己數(shù)據(jù)的入口，讓這些決策者看到實實在在的問題，企業(yè)肯定會重視起來的，但對神策來講，這部分確實可以提高他們服務(wù)的用戶的數(shù)據(jù)成熟度，但是帶來經(jīng)濟效益的可能性，短期不大

關(guān)于行業(yè)上的競爭力
能力的交付，以及整個使用期間的交流過程

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

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

如果說對IM這家我們不講道理，那么對不起，我們是乙方，乙方是可以用腳投票的，花一樣的錢當(dāng)然想自己的問題被有效的及時解決

神策和BI有什么區(qū)別？
不嚴格的說，神策某種程度上替代了部分BI的功能，比如快速查詢業(yè)務(wù)的結(jié)果，變化趨勢，但是BI這里自定義報表，自定義行列維，產(chǎn)出報表的功能，神策是尚未滿足的，或者說這種需求當(dāng)前市場上的優(yōu)先級不高