中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

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

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

神策也在我們業(yè)務中與內(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)做的很靈活，插件化或者說應用化做的已經(jīng)挺成熟。

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

核心是埋點和模型：

在我看來，神策的產(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ā)布了這篇4727字的文章?！?/p>

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

二、架構(gòu)倒推

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

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

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

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導入，這個就有點特殊了，面向的是無法通過埋點來準確抓取或者更新的數(shù)據(jù)，我們這里業(yè)務上會把直播類的數(shù)據(jù)用T+1的方式上傳。

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

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

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

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

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

4. 神策分析

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

5. 定時任務模塊

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

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

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

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

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

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

8. 權(quán)限和賬號管理模塊

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

三、未來迭代的推測

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

1. 當前尚未滿足的需求

1）角色授權(quán)的細化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

并且大多數(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ù)庫開放給神策，對應的數(shù)據(jù)匯總到神策中，給企業(yè)提供一個全局了解自己數(shù)據(jù)的入口，讓這些決策者看到實實在在的問題，企業(yè)肯定會重視起來的。

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

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

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

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

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

后續(xù)文章預告：

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

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

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

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