朱江畢業(yè)于上海交大計算機系，2009年加入觸寶，經歷了從技術到產品的轉變。先后負責觸寶云服務的研發(fā)，觸寶電話生活黃頁業(yè)務，現(xiàn)在負責觸寶電話的產品管理及商業(yè)化工作，是觸寶電話主要產品負責人。以下為演講實錄：

謝謝大家，我叫朱江，我今天給大家演講的題目是《觸寶的數(shù)據驅動產品實踐》。非常抱歉，剛才主持人對我們的商業(yè)化轉型比較感興趣，但是我今天的轉型沒有涉及到。因為這次大會主題是數(shù)據驅動，作為一個工具類的產品，也有大量的用戶，我們確實也在數(shù)據驅動這方面有很多想要跟大家分享和探討的部分，這就是今天我的演講主要內容。

我的演講分四部分，第一部分介紹一下我自己，第二部分講一下對于數(shù)據驅動的理解。第三部分講一下實戰(zhàn)案例，最后是我們的總結和反思。

我是上海交通大學計算機碩士，2008年的時候我在谷歌實習，實習很興奮的時候就告訴我不招人了。然后工作就沒有著落了，那個時候我在交大的BBS上發(fā)現(xiàn)一個帖子，有一家公司拿了全球創(chuàng)新大獎。我就抱著好奇的心理，投了一個簡歷過去，我就加入了觸寶。那時只有一個創(chuàng)始人，沒有一個員工，現(xiàn)在觸寶已經完成了D輪融資，投資我們的有紅山資本、IDG，觸寶今年到了用戶體量比較大的規(guī)模。我們的目標是兩年左右的時間再上一個臺階。我有個外號叫觸寶教主，我聽到這個詞的時候總想到一個人，就是照片上的人，就是東方不敗，總感覺自己哪里少了點什么。

直到有一天我看了一篇文章，阿里的螞蟻金服的老大講，創(chuàng)業(yè)者一定要有一種特質，就是雌雄同體，后來我知道了，我就是觸寶教主。接下來講講我對數(shù)據驅動的理解，我認為數(shù)據驅動產品迭代的關鍵，是建立一套強調實驗和追求結果的文化。并且利用數(shù)據分析，直接和間接的對產品的核心指標去進行增長。核心指標包括我們比較關注的用戶規(guī)模、留存，像觸寶的撥打電話的數(shù)量。旁邊這張圖是推特當年引入了所謂的增長團隊之后，加大了迭代速度，它們的用戶增長規(guī)模的斜率發(fā)生了明顯的增加。我認為數(shù)據驅動的關鍵因素是這么幾個，第一個是要有高效的工具。因為我們要完成實驗，要完成迭代，可能不能完全靠人力，需要有一套方法論，有一套成熟的工具支撐你。所以這套高效的工具是重要的因素之一。另外有高效的流程讓各個環(huán)節(jié)迭代起來，比如一到兩個周期，比如這個團隊里面每個人都有明確的目標，每個人都有自己可以去利用的資源。利用就是要能夠提出假設，去把它切割成一個相對比較可行，又比較小的集合去做試錯。在試錯之后，要能把方案進行總結提煉。然后進行發(fā)布，要減少對用戶的影響，最后形成一個循環(huán)。

我講講觸寶曾經用過的數(shù)據分析工具，我相信很多人也都用過。首先傳統(tǒng)的方式是用數(shù)據庫和日志的方式來分析。數(shù)據庫的分析和日志的分析，很多人做過技術有一定的了解。這種分析方法在團隊小的時候，或者用戶規(guī)模小的時候很實用，數(shù)據庫都在服務器上面，隨時可以拉數(shù)據。日志一般也是在服務器上本來就有的，就順帶利用它做分析。這種方法的問題是效率很低，一旦有需求要跑到數(shù)據庫去查。因為數(shù)據庫的設計是為用戶分析的，不是為分析服務的。另外數(shù)據隨時都有可能丟，比如宕機了，就查不了。我們用過SDK，它是一個完整的解決方案，可以提供從分析到報表，有一整套的分析。但是用戶體量比較大的時候，對隱私會非常關注。如果這個數(shù)據被泄露到第三方平臺上，對于企業(yè)或者用戶，都是有風險的。

另外就是這種數(shù)據分析平臺通常只能解決一部分的數(shù)據分析緯度，舉個例子百度的統(tǒng)計。我在網頁上可以拿到它的數(shù)據，但是服務器還有下單、訂單的數(shù)據，客戶端還有用戶行為的數(shù)據，這些東西沒有辦法打通。我用這個工具只有解決一部分問題，當我想連在一起看的時候就發(fā)現(xiàn)不行了。所以后來我們也開始搭建自己數(shù)據分析的體系，最早用的就是hadoop，這是一個山寨版的谷歌大數(shù)據處理平臺。那時候我們的數(shù)據就TB級別的數(shù)據，每次分析需要由開發(fā)來配合寫一個腳本，然后就上平臺跑這個腳本，大概一兩個小時可以出結果。因為公司有很多產品經理有這個需求，所以大家需要排隊去跑。我們也有一個數(shù)據報表的體系，就是rainbow，就是把一些常態(tài)化的數(shù)據呈現(xiàn)為報表，把一些關鍵的數(shù)據點做監(jiān)控。這樣的方法持續(xù)了很長時間，到了去年，我們對現(xiàn)在這套方案又做了升級。也是響應之前的圖，如果我們想要把整個迭代的流程加快，數(shù)據驅動速度加快，就要有更高效的工具。一個小時或者小時級別的分析，已經不能滿足我們的需求了。

同時產品和開發(fā)配合的方式，也有這樣那樣的弊端。所以我們在原來的基礎上做了一次升級，引入了一套開源的方案，druid、dril、superset，這是一套在線的實時分析。drill搭建了類似于數(shù)據庫查詢的腳本。superset做可視化的展示，我們現(xiàn)在的數(shù)據規(guī)模是TB級別的。數(shù)據查詢效率非常高，基本是秒級別的。對于大部分產品的查詢，沒有那么復雜，哪怕數(shù)據量是千萬級別或者億級別，要查很多用戶的數(shù)據，依然可以在秒或者十幾秒的時間里面，就把結果出來了。這樣有一個好處，一旦發(fā)現(xiàn)我原來假設的數(shù)據不對的時候，我不需要再用復雜的方法去提交需求，然后做分析。同時因為引入了這套系統(tǒng)之后，它的查詢方式實際上可以變得比較輕量級。所以在整個公司普及，讓產品經理自己學習語句，去查詢自己有權限的數(shù)據。用這樣的方式去做，每個產品經理都可以找到每一個用戶在觸寶平臺的數(shù)據，而且他可以做非常多的分析。引入這套系統(tǒng)，我認為我們數(shù)據驅動的整套體系速度提升很多。

這是一個簡單的截圖，上面就是舉個例子。上面是一個命令行，實際它有一個網頁，可以打一個語句。比如我要查昨天在上海激活的，并且還打過我們的免費電話等等，就可以把這些通過一個語句查出來，下面可以出結果，可以是億級別的，它跑的很快。下面是一個rocord的數(shù)據，里面可以把報表接到數(shù)據倉庫里面，用自定義的方式展現(xiàn)出來。這樣可以做出滿足自己產品需要的業(yè)務報表。

另外我們在數(shù)據分析這塊，引用了一些算法或者引用了一些方法。首先第一個比較常用的就是經營創(chuàng)業(yè)的概念就是同期群分析。就是我想找出兩類差不多一樣的人，但是讓他們去體驗產品里面有一定差異的功能，這樣的情況就可可以知道到底是功能的問題還是其他問題。所以同期群是一個常用的方法，比如我一個功能升級的時候，我就用一個用戶畫像的方式把人抓出來，讓他們體驗有一定差異的功能，我最后就能看到一個結果。另外我們也建立了流失模型，流失模型指的是我們把現(xiàn)在存量用戶行為數(shù)據和他的流失數(shù)據做了一個建模，也就是說可能這個人他裝了觸寶電話，他沒有打交道。他可能搜了一個聯(lián)系人沒搜出來，他可能就流失掉了。我們可以通過海量的行為數(shù)據，用函數(shù)建模?？梢岳斫獬梢院髞硪粋€用戶，我就知道他的流失概率有多大。當我知道他的流失概率大的話，我就可以做一些有針對性的運營，比如贈送一些觸寶分鐘數(shù)或者額外的一些激勵。

另外也會做相關性的分析，主要指的是想了解這個產品的功能和我們核心數(shù)據之間的關系，相關性有多大。舉個例子在觸寶電話里面換過皮膚的用戶他的留存率，他對留存的幫助到底是正相關還是負相關。是換過皮膚的人更愿意留下來，還是沒換過的更愿意留下來。我們通過這樣的行為，它對于核心指標是有幫助還是有害的，有利于我們做產品的改進。

接下來我講一個實戰(zhàn)案例，在觸寶里面真實發(fā)生的。去年8月份增長團隊做了一個小型的戰(zhàn)役叫做八月會戰(zhàn)。目標就是大幅提升觸寶電話的留存率，那個階段觸寶電話出現(xiàn)了稍微下降，增長團隊當時接到了任務，怎么能夠在一個月的時間把留存率提升，目前是把新用戶的七日留存率的絕對值提升8%。舉個例子七日留存率是50%，就要提升到58%。如果大家做過產品肯定是了解的，就是要把七日留存率在一個月的時間里面提升百分之8個點，幾乎是不可能的。這個戰(zhàn)役持續(xù)了四周，這次戰(zhàn)役一共發(fā)布了6個灰度版本，1個正式版本，直到找到產品穩(wěn)定了，這是概括的數(shù)據。那么我們做了什么呢？

第一周，我們是這么想的，我們要降低流失率，流失的人少了，留的人就多了。我先要分析流失的人的原因。下面是一個開啟電費電話，下面需要填手機號、驗證碼，再一點就進入到主界面。注入了主界面，大部分用戶都會選擇打個免費電話，就這么四步。第一步打開應用，就是右邊的應用，假設是百分之百。第二步開啟免費電話，只有69%的人。第三步是填好嗎有55%，一直到最后。這就是數(shù)據，問題最大的是第一步，只有69%的人點了開啟免費電話，那31%的人走了，所以就要想辦法把這些人留下。產品的灰度方案是這樣的，我們做了四套方案。第一套方案做了基準，就是右邊原來的界面。后面的三套方案是這樣的，大家看得不太清楚。

這三個共同特點就是換了一張圖，告訴你觸寶可以免費打電話外，還可以免費領流量，換了一個更強的刺激。這三個的區(qū)別在于說，下面開啟免費電話還有一個功能叫贊助開啟。不打免費電話，你也可以進來。第二個變化就是少了贊助開啟。第三個就是把按鈕調下來，你注冊就送你分鐘數(shù)，就是激勵。就是這三套方案，加上原來的方案，我們做了灰度對比。就是到底轉化率能不能提升，大家覺得哪個方案效果最好？結果是四個方案轉化率幾乎一樣，還是沒變化，然后就分析數(shù)據。有一部分人是換手機了，他注冊了以后，就變成了我們的老用戶了。因為數(shù)據分析好多細節(jié)，就是一開始進到第一個界面，大家都認為是新用戶，而你登錄以后就變成了老用戶，所以人就變多了。所以發(fā)現(xiàn)第一步的轉化率是很高的，實際上100個人里面有90幾個人都點了。

接下來想改進的方案是用一個強運營的方案，就是今天用觸寶打電話，你明天再用送你流量，后天再用還送你，你就別走了，就用了強運營的方式。就是用戶打開觸寶電話就給他一個大紅包，就是天天有紅包，這個紅包就放到界面的右下角，大家覺得這個方案怎么樣？結果是留存基本沒提升，非常出乎我們的意料。為什么給用戶好處，他沒有留下來的意思呢？后來事后經過很長時間去分析，我們發(fā)現(xiàn)用戶來到觸寶他最急切的事情是打免費電話，因為這是我們的核心功能。你去引導做別的事情的話，不是一個合適的時機。也許他對其他事情有興趣，但是阻礙了他體驗核心功能，這不是一個明智的選擇。

所以到了最后一周，必須要完成這個目標，最后走投無路做了這么一個改版。就是登錄完了以后，第一步是設權限，允許讓我啟動、允許讓我讀通話記錄、聯(lián)系人，設完之后給你一個新手指南，恭喜你注冊成功了，可以去打免費電話。就做了這么一件事情，這件事情對比的方案是這樣的。原來也是注冊完，先彈一個紅包告訴你，你得了一個300分鐘的通話時長，要來學一下怎么撥打免費電話。你點一下，就告訴你撥打之前要設一下權限，設了權限之后進入第三個界面。這個界面沒有通話記錄的，過一會兒可能會刷取。第四個界面就彈出一個小熊貓，你搶到一個小錢包，可以看看有什么東西。這是之前的方案，這個方案現(xiàn)在換成了這個。這件事情實際結果完成了8%的目標，原因是非常曲折的，我給大家解釋一下。

我們做了留存率的分析，我把關鍵數(shù)據隱掉了。觸寶的留存率有一種階梯性的下降趨勢，它會下降一段時間再平緩，再下降再平緩，是這樣的趨勢。我們分析數(shù)據下降的原因是什么，因為原因有很多，各種各樣的因素。用戶的因素、渠道推廣的因素、服務器的質量因素，包括版本因素等等，都有關系。我們就分析下降的階梯性，他持續(xù)一段時間突然下降，覺得可能是跟發(fā)版有關系。但是發(fā)現(xiàn)每個版本的發(fā)布留存率變化不大。然后我們找到某個版本發(fā)布留存率突然就跳水，我們看這個版本跟之前的兩個版本有什么區(qū)別。區(qū)別在于原來那個版本，留存率高的版本就是圖的這個東西，低的版本就是這個東西。

原來的方案是好的，后來我們改的方案變壞了。當時也是糾結了很久，我們后來發(fā)現(xiàn)原因可能很多，我們分析可能是因為這個流程里面，在第二步權限引導，把它拆開了。先引導一個最重要的權限是打電話的權限。打電話權限開啟的話，就直接進入下一步。而原先的是三步，另外三個被后置，后置就導致用戶找不到了。而這兩個權限會影響到打電話的質量，我們猜測是這個原因。然后就把曾經的好的版本抓出來，投到市場上去看一下留存會不會再漲上來。發(fā)現(xiàn)投放了之后數(shù)據真的漲上來了，所以我們做的事情就是把曾經改壞的東西改回去了，最后的結果就是留存率上升了7個百分點，這個案例還是挺耐人尋味的。

我們也做了事后的總結和反思，也跟大家分享一下。首先數(shù)據分析一把雙刃劍，一旦分析錯了影響決策，這怎么破呢？我剛剛舉的例子，第一周分析錯了，這一周就白干了，歸零了。那怎么辦呢？首先要從多個緯度去分析。實際上你的用戶量大了，一定會在這個領域里面會有各種各樣的問題。哪怕你用槍去指著數(shù)據開發(fā)師說這個點不能錯，他依然會犯錯誤，所以這要從多個角度去分析數(shù)據，要從多個角度去佐證。第二個你做數(shù)據分析通常有目的性的，我認為一個好的產品經理要多做有目的的觀察。就是你只看它的結果是什么，你不帶著任何目的，不帶著任何的假設，只是觀察它們兩個是關系是什么。當你就這樣的觀察之后，可能就會有一種量化的概念。也就是新用戶點擊注冊，進到填手機號里面，他是不是70%？這個事情對于有經驗、有過去數(shù)據觀察的人會直接告訴你，這個數(shù)據肯定是不對的。最后總結下來，是要多建立總結的關系。

上面一個人叫大衛(wèi)·休謨，他說：“我們無從得知因果之間的關系，只能得到某些事物總是會聯(lián)結在一起，而這些事物在過去的經驗里又是從不曾分開過的?！本秃孟裉O果，蘋果從樹枝上斷開和它落到地上，在過去都是永遠在一起發(fā)生的。換句話說，明天你遇到一個蘋果從樹上掉下來，它不能被證明一定會落在地上，它有可能會飛到天上去。說這個例子的意思，我們往往會從數(shù)據分析里面形成一些自己的假設，因為是這個原因，所以是這個結果。其實你要知道每建立一個因果關系，就已經走到了一條岔路了。當你知道相關的關系越來越多的話，就會形成一種感覺，這種感覺會告訴你可能是存在的。

第二個是發(fā)現(xiàn)數(shù)據異常的時候，如何找到原因？你今天看到這個數(shù)據，要反問這個問題，通常是很難找到原因的。我們能找到這個原因，它是一個綜合性的結果。運氣不好的話，通常是發(fā)現(xiàn)不了原因的。因為數(shù)據的因素太多了，最后反過來推變量太大了，可能就是那天天氣不好。所以反推是很難的，但是怎么樣能盡量去發(fā)現(xiàn)原因呢？第一個就是多維度地去分析，第二個就是要形成直覺。直覺的形成就是多觀測去形成一種感覺，這種感覺聽起來很玄，但是其實是存在的。

第二個，是不是每個產品改動都要做AB測試呢？我個人感覺AB測試一定要做，但是它的效率很低。為什么很低呢？因為你會冒出很多的假設，你會讓開發(fā)不停地做AB測試碼？開發(fā)可能會“殺”了你。所以不能每個都做，但是一定要堅持做。就像你玩游戲屏幕是黑的，你突然把一個屏幕點亮了，你看到一個局部，你就知道了一點點信息。你再從別的局部再點亮一點點信息，你從局部知道多了以后，就會由點形成面，這就是AB測試的作用。所以我自己的總結就是做數(shù)據分析的目的是什么呢？它的質量目的是從數(shù)據中直接發(fā)現(xiàn)問題，指導產品的改進。就像剛才說的我發(fā)現(xiàn)留存下降，去分析數(shù)據，找到原因，問題解決了。

它的主要目的還是從數(shù)據中培養(yǎng)直覺，培養(yǎng)叫接近產品上帝的直覺。產品上帝是什么呢？我自己認為所有的產品假設，都有那么一個人，他可能不是一個人，他可能是個神。他知道這個假設的答案，他知道所有假設的答案，他不會出錯，我就把他定義為產品的上帝。你就要盡量接近這個產品上帝，想的東西要盡量是一樣的。產品經理經常決策的困境是，首先大家知道假設有一種答案是最好的，我們知道有一個最好的答案。

因為大家都是人，人都是會犯錯的，那憑什么你說的是對的，那說的也有可能是對的，那大家就做測試，可能就陷入一個循環(huán)。那怎么辦呢？那就是聽老板的，還有的公司聽老板娘的，還有是聽自己的。我產品經理比較牛，我就聽我的，不聽老板的。下一個就是AB測試，這個很常見，大家吵架沒結果去測試，你們兩個最初的方案，最后開發(fā)就倒霉了。所以一般來講這種情況下，我們認為實際上可能最好的解法，還是想辦法去聽最接近上帝的人。但是這個人是誰呢？誰也不知道答案，所以你要把自己變成最接近產品上帝的人。那怎么形成接近產品上帝的人呢？第一個你自己要有天賦，我承認這個行當里面天賦是很重要的。也許有些人很努力，但是努力只能獲得有限的回報。產品經理的天賦我個人認為很重要。

第二個要有大量的產品實踐，大家看到張小龍講產品經理他的理解，他講到五條，其中有一條也是大量的產品實踐。因為就算是一個再接近產品上帝的人，你依然不是上帝，要通過實驗的方式去進行修正。我相信做到這樣的結果之后，就會從一個開始有一定的天賦能夠定性分析的人，你知道它好還是不好，到最后你會定量去分析一個人，你知道他是好多少。希望大家都能夠成為接近產品上帝的人，謝謝。

最后給觸寶打個廣告，我們也在招產品運營，各位職位的同學們，歡迎大家聯(lián)系我，謝謝。兩位老總的演講非常精彩，因為我一直也在跟數(shù)據打交道，大家在下面聽的很認真。因為我們無數(shù)次的產品迭代中遇到了無數(shù)次這樣的問題，尤其是大版本發(fā)布遇到小版本的迭代，這樣的問題是常常出現(xiàn)的。沒有人能夠說誰是對的，到底產品迭代的時候，這個功能設計聽誰的？聽產品上帝的，還是聽老板、老板娘，還是自己的，還是AB測試的呢？我司其實用的方法也是產品測試，在產品與運營撕逼的過程中，大家有沒有發(fā)現(xiàn)？不管是聽產品上帝還是聽老板的，還是聽老板娘的，還是聽自己的，還是聽AB測試，所有人都會說，這是用戶說的，我們都在聽用戶的。沒有人說會聽我的，每個人聽我的人，他說我們的用戶他們想要這個。

所以這其實是產品，不管是玩產品還是玩運營，甚至是玩營銷，這個里面都有一個萬能的上帝叫——上帝。