【51CTO.com原創(chuàng)稿件】在這個(gè)快速消費(fèi)的時(shí)代,互聯(lián)網(wǎng)已經(jīng)和人們的日常生活緊密相關(guān),隨著人們的需求和產(chǎn)品功能的細(xì)分,消費(fèi)被重新定義,如何"留住用戶",成為牽系企業(yè)于互聯(lián)網(wǎng)立足生存的首要課題。本文將從兩個(gè)方面：分析和思路、技術(shù)實(shí)現(xiàn)，講述如何把您的用戶留下來(lái)。

【講師簡(jiǎn)介】

[[173435]]

郭煒: 畢業(yè)于北京大學(xué)，加入易觀智庫(kù)之前，曾任聯(lián)想研究院大數(shù)據(jù)總監(jiān)，萬(wàn)達(dá)電商數(shù)據(jù)部總經(jīng)理、并曾在中金、IBM、Teradata公司擔(dān)任大數(shù)據(jù)方向重要崗位。在大數(shù)據(jù)采集、存儲(chǔ)、處理、挖掘、應(yīng)用研發(fā)等方面具有豐富的理論和實(shí)踐經(jīng)驗(yàn)，對(duì)大數(shù)據(jù)前沿領(lǐng)域研究，包括視頻、智能Wi-Fi, Beacon等大數(shù)據(jù)軟硬數(shù)據(jù)處理一體技術(shù)有獨(dú)特的見解與實(shí)踐。在電商、移動(dòng)互聯(lián)網(wǎng)、商業(yè)地產(chǎn)、百貨、移動(dòng)通信、零售、院線等多個(gè)業(yè)務(wù)領(lǐng)域大數(shù)據(jù)方面具有搭建團(tuán)隊(duì)、系統(tǒng)以及分領(lǐng)域的分析與算法經(jīng)驗(yàn)。

生命周期管理

想要留住用戶，首先要回答三個(gè)問題：一，這個(gè)用戶是從哪里來(lái)的。二，流失的用戶去哪兒了。三，針對(duì)這些流失的用戶如何爭(zhēng)取回來(lái)。回歸到如何做數(shù)據(jù)分析，主要有四個(gè)步驟：生命周期管理、運(yùn)營(yíng)轉(zhuǎn)化分析、用戶分析、應(yīng)用評(píng)級(jí)。如下圖所示：

“7天法則”分析不同事件下的用戶留存

使用“7天法則”，首先是，分析每一次活動(dòng)之后，七天之內(nèi)用戶留存的趨勢(shì)怎么樣，這個(gè)用戶在七天之內(nèi)是不是又再次激活了App，還是沒有再使用。分析這些用戶單次的使用時(shí)長(zhǎng)，包括日、周、月啟動(dòng)次數(shù)的分布，進(jìn)而分析出來(lái)到底哪些人是羊毛黨，哪些人是忠實(shí)用戶，哪些人會(huì)留下來(lái)成為App用戶，而哪些人是不值得挽留的。不管是自己做還是使用第三方工具，都會(huì)分析這些趨勢(shì)。

第二，什么時(shí)候該換產(chǎn)品思路了。很多產(chǎn)品，特別是在初期，可能在七日內(nèi)的留存不到10%，等于這個(gè)產(chǎn)品的有效價(jià)值并沒有體現(xiàn)出來(lái)，這個(gè)時(shí)候要么需要調(diào)整產(chǎn)品思路，要么調(diào)整運(yùn)營(yíng)思路，證明產(chǎn)品價(jià)值并沒有吸引最終用戶留下來(lái)，這個(gè)時(shí)候可能要對(duì)產(chǎn)品價(jià)格做比較大的調(diào)整，認(rèn)為這個(gè)方向沒有問題，進(jìn)行切口的調(diào)整和切換，繼續(xù)再向這個(gè)方向走。

運(yùn)營(yíng)轉(zhuǎn)化分析

運(yùn)營(yíng)轉(zhuǎn)化分析看似一個(gè)簡(jiǎn)單的漏斗分析，每個(gè)層次都有它的故事，都有它所關(guān)注的重點(diǎn)。

營(yíng)銷渠道：哪些是你的用戶?

瀏覽運(yùn)營(yíng)位：哪些用戶看了就走?你的老用戶是怎樣做的?

提交訂單(購(gòu)物車)：哪些用戶沖動(dòng)消費(fèi)了?

支付訂單：沒支付的這些用戶到哪里去了?

分享：哪些內(nèi)容具有傳遞性?

通過(guò)支付轉(zhuǎn)化率和渠道來(lái)源用戶分析不同營(yíng)銷渠道的質(zhì)量，輔助決策在有限的資源下優(yōu)選哪些渠道推廣。分析頁(yè)面不同位置的轉(zhuǎn)化質(zhì)量，輔助決策產(chǎn)品、運(yùn)營(yíng)改進(jìn)，獲得更好更好的效果。

用戶分析

用戶分析其實(shí)就是分析你的用戶長(zhǎng)什么樣?從哪里來(lái)，到哪里去?通過(guò)10億終端的覆蓋，通過(guò)算法模型計(jì)算出你的應(yīng)用用戶特征，性別、年齡…

應(yīng)用評(píng)級(jí)

認(rèn)清大局，才認(rèn)清自己，你的評(píng)級(jí)是多少?你的用戶價(jià)值是多少?

看行業(yè)趨勢(shì)：確定是否逐漸遠(yuǎn)離風(fēng)口。看行業(yè)均值、TOP10：市場(chǎng)是否已被領(lǐng)頭羊蠶食?長(zhǎng)尾幾無(wú)生存空間?看行業(yè)排行：自己是否還有機(jī)會(huì)?尋求新的切口?

如何實(shí)現(xiàn)大數(shù)據(jù)平臺(tái)

郭煒以易觀為例，詳細(xì)講解了大數(shù)據(jù)平臺(tái)實(shí)現(xiàn)的方法。

首先，底層在讀取數(shù)據(jù)的時(shí)候，SDK嵌入到每一個(gè)開發(fā)的App里，包括H5。數(shù)據(jù)讀取完成以后，肯定還需要把數(shù)據(jù)收回來(lái)，每個(gè)開發(fā)者和創(chuàng)業(yè)者建立自己的平臺(tái)一定也有一個(gè)接收端。易觀目前這個(gè)量級(jí)用的是Openresty(Lua)，中間用Lua做了一些在SDK到上層相互交流的粗加工，目前是每天100億條的數(shù)據(jù)在往上傳，有時(shí)峰值可能還會(huì)更多。哪些能把有效的數(shù)據(jù)迅速采集過(guò)來(lái)，哪些數(shù)據(jù)能夠迅速對(duì)客戶端做出一些反饋，要通過(guò)Openresty、Lua做一個(gè)高效的返回機(jī)制放過(guò)來(lái)。直接進(jìn)Kafka，圖中使用了幾個(gè)虛括號(hào)，因?yàn)楝F(xiàn)在使用的是混合云，主要混合了三個(gè)地方：一，通過(guò)公有云采集收數(shù)，因?yàn)樵诮邮斩说膸捠莾杀叮瑥倪@里做收數(shù)，通過(guò)一些光纖打通的方式打到線下，但是由于像光纖的方式如果萬(wàn)一出現(xiàn)問題，形成單點(diǎn)故障，還有一條互聯(lián)網(wǎng)鏈路做保障。在收數(shù)端的Kafka收完后，還會(huì)在私有云有一個(gè)Kafka，兩個(gè)做對(duì)接，在對(duì)接中間做了一個(gè)開源小工具，Kafka中間有一個(gè)Url的工具能夠去對(duì)跑，但實(shí)際上這個(gè)工具是不靠譜的，特別是在數(shù)據(jù)量級(jí)比較大的時(shí)候，對(duì)跑會(huì)出現(xiàn)各種各樣的企業(yè)問題，后來(lái)易觀自己制作了一個(gè)小程序，為了保證中間傳輸上的穩(wěn)定，做了一些壓縮，可以實(shí)時(shí)傳輸過(guò)來(lái)，目前延時(shí)大約在5-10秒的范圍，同時(shí)能夠從線下收數(shù)到整個(gè)線下集群。

Kafka往上，易觀和大多數(shù)大數(shù)據(jù)企業(yè)是類似的，一個(gè)是使用Hadoop/Hive，因?yàn)閿?shù)量比較大，像MR把數(shù)量變小，變成ODS，其實(shí)是變成底層的基礎(chǔ)數(shù)據(jù)，會(huì)在PDS做匯總層數(shù)據(jù)。再往上就是IDS，為了做產(chǎn)品體系查詢。另一種是做Storm，Spark易觀目前還沒有完全做到自主優(yōu)化，因?yàn)閿?shù)據(jù)的量級(jí)非常大，每天大約100億，數(shù)據(jù)在查詢的時(shí)候，上面還有一個(gè)大數(shù)據(jù)查詢，經(jīng)過(guò)三個(gè)匯總以后，到這一層動(dòng)輒也是千億條的數(shù)據(jù)。舉個(gè)例子，對(duì)于產(chǎn)品來(lái)講，尤其是云端分析師，想看到上個(gè)月晚上9點(diǎn)到10點(diǎn)之間，標(biāo)簽是游戲玩家，淘寶資深購(gòu)物人員，經(jīng)常打開App的排行榜是什么，這個(gè)查詢還是很容易的業(yè)務(wù)，但真正落成千億條的數(shù)據(jù)查詢卻非常難，并且還希望做成一個(gè)比較好的查詢，希望至少在分鐘之內(nèi)的范圍，這個(gè)要求就非常難。這個(gè)查詢?nèi)绻贖ub里，一般是以小時(shí)來(lái)計(jì)，怎么能夠放到產(chǎn)品里，把分鐘級(jí)別的查詢反饋過(guò)來(lái)?目前，在中間做了一個(gè)簡(jiǎn)單的查詢引擎(目前是查詢目錄)，根據(jù)企業(yè)的數(shù)據(jù)量級(jí)分到不同的查詢引擎里解決相關(guān)問題，例如現(xiàn)在的GP，其實(shí)要求的是一個(gè)貴族開源的軟件，好處是在千億條大數(shù)據(jù)查詢的時(shí)候非常穩(wěn)定，兼容性也很好，但是對(duì)硬件的要求很高，不是每一個(gè)初創(chuàng)企業(yè)能有錢去做GP集群。Impala相對(duì)更加簡(jiǎn)單一些，要求硬件沒有那么復(fù)雜，但時(shí)效性不如GP好。對(duì)一個(gè)企業(yè)內(nèi)部，看上去整個(gè)集群大小有千億條，但真正對(duì)于某一個(gè)App或?qū)τ谀骋粋€(gè)開發(fā)者來(lái)說(shuō)，開發(fā)者要分層，發(fā)現(xiàn)有了這些大的頭部應(yīng)用，至少百億。而小的開發(fā)者完全不用，目前很多還有日活不到1萬(wàn)的開發(fā)者，把它直接放到這查詢就可以了。

數(shù)據(jù)調(diào)度資源也很重要，易觀自己用的EMP，對(duì)資源做一些調(diào)度，能保證每天有內(nèi)部分析師查詢，在EMP里和Hadoop做了一些底層的接口對(duì)接，保證任務(wù)按時(shí)優(yōu)先處理完。除此之外，內(nèi)容數(shù)據(jù)量越來(lái)越多，數(shù)據(jù)越來(lái)越復(fù)雜，中間必須要有主數(shù)據(jù)管理、源數(shù)據(jù)管理，像數(shù)據(jù)地圖等等一些相關(guān)工具。這些都包含在整個(gè)產(chǎn)品體系里。

幾個(gè)技術(shù)難點(diǎn)

關(guān)于SDK，首先是不能丟數(shù)據(jù)。用戶網(wǎng)絡(luò)情況不太好的時(shí)候，在本地可能需要一個(gè)Cache，但是不能做無(wú)限大的Cache，用戶就會(huì)把App卸掉，因?yàn)榇媪颂嗟臒o(wú)用數(shù)據(jù)，哪些數(shù)據(jù)要留存下來(lái)，哪些要做循環(huán)處理，都是需要注意的。

第二是如何不變成DDOS。把數(shù)據(jù)放在Cache，而且越來(lái)越多，服務(wù)接收能力還不強(qiáng)，會(huì)形成非常大的DDOS。這個(gè)時(shí)候就需要去控制。在SDK上傳的時(shí)候要做防火墻，真正數(shù)據(jù)在傳到云端時(shí)，如果App上傳的頻次過(guò)高本地要做屏蔽，如果一旦形成DDOS，就沒有辦法很快把App更新，基本上服務(wù)器這套機(jī)制全部就死掉了，在這個(gè)地方要有一個(gè)防火墻。上傳數(shù)據(jù)不是單向，而是雙向，把數(shù)據(jù)傳上去的同時(shí)要有交互，要拿到云端的配置，特別是在中心云，能看到很多雙向機(jī)器，當(dāng)出現(xiàn)一些問題時(shí)，在云端是可控地把數(shù)據(jù)屏蔽掉，這樣才能保證自己的數(shù)據(jù)安全，如果只是一個(gè)小開發(fā)者可能量比較大，但日活如果到千萬(wàn)以后，需要在這個(gè)地方做一個(gè)很好的交互，讓云端的一些配置能夠很快反饋到SDK，把數(shù)據(jù)上傳和拐點(diǎn)機(jī)制能夠做更新，保證不會(huì)形成DDOS，比如作為開發(fā)者來(lái)講或其他部門把點(diǎn)埋錯(cuò)了，或者出現(xiàn)一些問題時(shí)，能控制好相關(guān)的數(shù)據(jù)。

此外，如何做到最小，如何將H5與APP互相調(diào)起，也是SDK需要注意的問題。

在接收端，需要注意的問題有：如何高并發(fā)接收數(shù)據(jù)，如何可以跨互聯(lián)網(wǎng)傳送高頻大數(shù)據(jù)，如何可以做到極致實(shí)時(shí)。而關(guān)于用戶畫像，如何基于小數(shù)據(jù)算大量用戶畫像，如何計(jì)算用戶標(biāo)簽，如何知道你用戶的用戶畫像，是需要注意的問題。

關(guān)于實(shí)時(shí)大數(shù)據(jù)查詢，如果面對(duì)的是上千億條的數(shù)據(jù)，可以考慮模糊計(jì)算，先抽樣，郭煒的建議是做分層抽樣。第二是做預(yù)先計(jì)算，在不同的場(chǎng)景里，用到一些工具，把數(shù)據(jù)變成打橫的，而不是打縱的據(jù)，這樣能做到很多。郭煒在這里舉的例子是轉(zhuǎn)化漏斗。每一個(gè)用戶的交易和點(diǎn)擊是一張縱向的流水表，用戶IP、事件、時(shí)間分點(diǎn)等，當(dāng)量級(jí)變成千億條，如何保證每次都能很快過(guò)濾出來(lái)，這是非常難的，對(duì)于這種情況，易觀會(huì)在這種縱調(diào)做完以后打橫，通過(guò)每一個(gè)事件(過(guò)去都是事件流水)，從ID到時(shí)間，做完打橫以后會(huì)變成用戶ID、時(shí)間周期，每個(gè)事件會(huì)變成0和1。打橫以后會(huì)把原來(lái)的查詢變成并和交的查詢，去關(guān)聯(lián)化，最后再去做整個(gè)數(shù)據(jù)查詢，速度會(huì)快很多，這也是大數(shù)據(jù)查詢經(jīng)常用的一種方法。

每一個(gè)不同的用戶，數(shù)據(jù)來(lái)源和大小不太一樣，當(dāng)自建一個(gè)大平臺(tái)時(shí)，每個(gè)業(yè)務(wù)部門的分析也是不一樣的，究竟哪些業(yè)務(wù)部門真的需要用到這么復(fù)雜的GP和Impala，哪些是真的實(shí)時(shí)性要求高，但數(shù)量非常小?郭煒的建議是在每一個(gè)大數(shù)據(jù)，特別是真的數(shù)據(jù)做得很多以后，每個(gè)地方至少做一個(gè)數(shù)據(jù)擴(kuò)容，最終才能夠根據(jù)查詢的情況選擇適合自己的大數(shù)據(jù)工具做查詢，有的東西用GP合適，哪怕簡(jiǎn)單寫一些日常規(guī)則或者基于后期統(tǒng)計(jì)，把查詢做起來(lái)，都非常有助于整個(gè)大數(shù)據(jù)查詢平臺(tái)的整體效率，從而實(shí)現(xiàn)高性價(jià)比的大平臺(tái)策略。

易觀簡(jiǎn)介

易觀是中國(guó)互聯(lián)網(wǎng)市場(chǎng)領(lǐng)先的大數(shù)據(jù)分析公司。自2000年成立以來(lái)，易觀打造了以海量數(shù)字用戶數(shù)據(jù)及專業(yè)大數(shù)據(jù)算法模型為核心的大數(shù)據(jù)與分析師服務(wù)生態(tài)體系，并致力于幫助所有擁有互聯(lián)網(wǎng)產(chǎn)品及服務(wù)的企業(yè)，洞察自身的產(chǎn)品和用戶，對(duì)標(biāo)競(jìng)爭(zhēng)和市場(chǎng)，并通過(guò)對(duì)數(shù)字用戶資產(chǎn)的持續(xù)運(yùn)營(yíng)，實(shí)現(xiàn)增收，節(jié)支，提效和避險(xiǎn)。

本文由郭煒于2016年8月，在WOT2016移動(dòng)互聯(lián)網(wǎng)技術(shù)峰會(huì)數(shù)據(jù)分析專場(chǎng)《如何巧用數(shù)據(jù)在移動(dòng)創(chuàng)業(yè)的紅海中突圍》主題演講整理而成。WOT2016大數(shù)據(jù)峰會(huì)將于2016年11月25-26日在北京粵財(cái)JW萬(wàn)豪酒店召開，屆時(shí)，數(shù)十位大數(shù)據(jù)領(lǐng)域一線專家、數(shù)據(jù)技術(shù)先行者將齊聚現(xiàn)場(chǎng)，在圍繞機(jī)器學(xué)習(xí)、實(shí)時(shí)計(jì)算、系統(tǒng)架構(gòu)、NoSQL技術(shù)實(shí)踐等前沿技術(shù)話題展開深度交流和溝通探討的同時(shí)，分享大數(shù)據(jù)領(lǐng)域最新實(shí)踐和最熱門的行業(yè)應(yīng)用。了解WOT2016大數(shù)據(jù)技術(shù)峰會(huì)更多信息，請(qǐng)登陸大會(huì)官網(wǎng)：http://wot.51cto.com/2016bigdata/

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】