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

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

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

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

二、神策實(shí)施的實(shí)操細(xì)節(jié)和經(jīng)驗(yàn)分享

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

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

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

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

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

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

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

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

核心是埋點(diǎn)和模型

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

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

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

舉例

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

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

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

架構(gòu)倒推

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

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

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

主要有這幾個(gè)

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

（1）前端web的上報(bào)，用到了web的sdk，主要面向前端頁面點(diǎn)擊等場(chǎng)景

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

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

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

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

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

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

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

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

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

智能運(yùn)營(yíng)的核心邏輯，在我看來有3步：

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

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

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

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

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

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

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

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

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

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

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

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

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

這也是我經(jīng)歷和思考到的一個(gè)比較尷尬的點(diǎn)，神策在給客戶提供分析類服務(wù)，但是客戶還想在分析的同時(shí)，看到類似業(yè)務(wù)庫事實(shí)表的結(jié)果，因?yàn)榭蛻舨少徤癫叩脑蚓褪莾?nèi)部的數(shù)據(jù)系統(tǒng)無法滿足拉通的統(tǒng)計(jì)，用神策可以直觀看到數(shù)據(jù)的統(tǒng)計(jì)，但是又無法看到內(nèi)部業(yè)務(wù)后臺(tái)的最新結(jié)果。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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