你有哪些「做過某功能的改進之後，數據得到大幅提升」的經歷？

12-06

對此你是怎樣總結的？

數據大幅縮減能說嗎？我曾經把一台近20kg重的德國設備優化到「看不見！看不見！看不見！」
讓德國母公司的同事對中國人工程師刮目相看。

把時間軸拉回2007年，我在德國工作了幾年後，回到國內分公司，在測試科工作。這個科室當時很小，有3個人，其中有一個操作員由於會用德國進口的踏板特性測試機，就得到了一個很好的工種，時不時跑外地出差試車，工作強度比較輕鬆，而其他人就在公司里和笨重的台架測試打交道。

圖：德國原裝進口的踏板特性測試機 MK0

說起這台測試機，購置費用近30萬人民幣，有兩個大箱子和一台筆記本電腦組成，總重量16kg，由於提著費勁，公司就配了一個兩輪推車，總重逼近20kg。要是遇到出差去試車，它會佔掉一個人的託運限重，攜帶極其笨重。

當時我想多一些出差機會去見見世面，就巴結著這位哥學會了如何用這台設備。結果一次小拖車輪子壞掉，我不得不提著這套裝備，從奇瑞工廠的北門走到南門，我才知道為啥這位哥們願意教我了。

我發誓要把這套設備「瘦」下去！

回到公司，我開始打這個設備的主意了，裡面到底是TM什麼東西？！

我承認我沒有做什麼功課就冒然把設備拆開了，很多電纜、插頭、模塊，複雜程度大大超過我想像。怕拆壞了，就趕緊把它蓋回去了。

不知道設備里是啥，保守的德國人也不一定願意給線路圖，改造估計不現實了，但是我可以換一個更輕的箱子吧~於是第二天，我再一次打開了設備，把裡面的電子元件仔細地拆出來，再把空箱子稱了一下，6kg！有希望~

同時，我注意到德國設備上有16個插孔，完全可以接16個感測器，同時做採集和處理，但是我們平時使用功能單一，只用到了其中兩個通道，也就是說，我至少可以去掉14個沒用的通道和信號處理模塊！

於是我去宜家買了一塊砧板，切掉了一半，把需要的那兩個通道的模塊掏出來，釘在砧板上，第一個版本就問世了！

圖：DIY第一版測試儀 MK1

插頭插好後，竟然可以使用！Oh-Yeah！

這下子，這套砧板設備就可以直接裝在筆記本背包的前面袋子里了，瞬間少了一個箱子，減重9kg。

問題來了，我第一次帶著這台改進版出差時，在南昌機場安檢時被帶到一邊盤查好半天，才知道因為這玩意太像自製炸彈了，後來回到公司果斷決定修改造型。

第二個版本，我給這套砧板做了一個殼子，但是顯得比較笨重，加上後來公司固定資產盤點，我又不得不把這些東西塞回德國人的箱子里，終究逃不掉要自己另作一台的命運。

德國人要是知道一個中國工程師在研究如何超越他們的設備，絕對不會支持的，所以這個改造一直是「非法」的，沒有公司的預算支持，也沒讓更多人知道。全憑興趣和自掏腰包，所以一切都得精打細算。

第三個版本，我買了一套NI的採集卡，我還記得是NI最入門的6008採集卡，價格比較便宜，新的1600塊左右吧，我從江西一個中學老師手裡買了一塊二手的，1200元。接下來，我自己畫電路板，做了信號調理和電源處理電路，焊好元件，把這些東西裝到了一個新的盒子里，
這下子就真的算我自製的設備了。

雖然試車員用起來也挺不錯的，但我還是覺得不夠純粹和極致，一直在琢磨下一代產品怎麼改型。

因為試車的環境比較惡劣，時常是高溫高濕，顛簸，還有雨雪天氣的室外操作，這台富士筆記本電腦不久出現了偶爾半身不遂的跡象。我又自費買了一台松下的軍用筆記本（當然也是二手的），雖然重了一些，但可靠性提升N個級別！要知道試車中如果電腦掛了，絕逼是個災難啊！

軍用筆記本配上改進後的設備，就顯得更加專業，耐用性、耐氣候性全面升級。試車員提出去也感覺倍有面子。

有了這個胖墩墩的軍本，我突發奇想，拆開看看裡面是啥，為啥可以做到防摔防塵防水呢？我又買了一個更便宜的二手本，專門用來拆卸研究。

這一拆，我可樂壞了，發現顯示屏的殼子裡面還有4mm左右的空間，可以放一大塊電路板！好，下一個版本，把整套設備的核心電路做得更小，更扁，塞到筆記本裡面去！

我根據筆記本顯示屏A殼下面的空間和安裝孔，定製設計了新的電路板，選了超薄的貼片元件，把原來的電路做得更加緊湊，裝在了進去。

又專門選購了超小的多芯插座，在側面的塑料緩衝區打了三個孔，把插座固定好。

電路板上方做絕緣處理，免得跟筆記本殼體發生短路，然後把筆記本外殼裝起來，最新版本的踏板測試機就完成了。

這樣一來，整個設備主機就剩一台筆記本電腦了！感測器直接插在顯示屏上，出差隨身背走，所有試車員頓時全部解放，出差用的內褲也可以多帶幾捆了。

圖：最終的測試儀 MK6

細數一下，這已經是第六代DIY產品了，包括方向盤上的感測器固定裝置，我也重新設計了一套，試車員可以在30秒內完成安裝，10秒拆走，而原來德國人的裝置需要3分鐘。

2013年，我去德國出差，聊上海分公司現有測試能力時，我show了這台設備。在場的德國工程師和試車員看到這張照片，好久沒有人說話，我聽見幾個試車員在小聲地叫「wow~cool…」，而他們技術主管的眉頭卻皺了很久，然後問了我好幾個「關鍵技術難題」是不是在設計時考慮到了，顯然是略有不服。其實我對這台設備早已吃透，在軟體上也已採用更加高效人性化的版本。

圖：我正在給BMW 320Li測試踏板特性

後面的會談，就略帶醋意，他們的結論是：全球子公司配備的設備應該都是統一的標準，統一的形式，統一的報告，這樣方便大家在一致的平台上做產品參數的探討比較。

德國人挺可愛的，當你水平跟他們接近時，他們更願意用這種相互挑戰的方式跟你平等交流；而當他們覺得你什麼都不會時，反而不願意傳授什麼東西。

很多合資企業抱怨自己從合資方拿不到技術，把這個封鎖歸結為外方的企業行為，固然企業有這個傾向，但是企業也是由個人組成的，企業行為最終會細化到個人行為上去演繹。其實如果中方有幾個可以跟德國工程師平等過招的牛人，德國人在日常工作中就願意多掏乾貨出來交流切磋，生怕顯得自己比較弱，畢竟這是全球理工男的共性嘛。

好吧~~這個場景是我YY的

...更多精彩知識請看我的汽車課堂

...更多精彩知識請看我的維修解析

：）

兔姑娘在上家公司做的是社區類 APP，說幾件對數據提升比較大的產品改進。

1、登錄註冊流程的一點點改進，說不定可以很大的提升進入首頁的成功率

我們 APP 是用戶首次激活打開後，需要進行登陸或者註冊的操作，才可以進入到首頁的（雖然一般不提倡這樣做，但是我們當時有不得已的原因）。

那幾個月我們的 DAU 進入了一個瓶頸期，數據曲線很平，幾乎不怎麼增減。

但是我們觀察到，每天都有幾千的新用戶下載了我們的APP，為什麼數據依然不增長呢？難道我們每天的用戶流失率剛好等於用戶增長率？

所以我們就一步一步的根據每個頁面的轉化率進行排查，我在整理「登錄註冊」模塊的時候，發現我們的流程之複雜，步驟之長竟然導致登錄註冊的成功率只有60%！

也就是說，每天的幾千名新用戶下載了我們的APP，打開了之後，被登錄註冊擋在門外的就有40%！

這是我當年根據功能邏輯畫的流程圖，並且把每個頁面的轉化率和流失率都標註了出來。大家也可以大致看出來，用戶最複雜要經過7步之久才能成功進到首頁。我們都知道漏斗原理，是吧？

找到了癥結之一，我們就開始著手進行修改。下圖是我修改後的登錄註冊流程圖：

這個小版本上線後，我統計了一下數據，新用戶進入到首頁的成功率由62%上升到了82%。DAU曲線也逐步的開始上升。

這事給我的感觸很深。一是數據太重要了，每個產品經理手中都有大量的產品數據，但是怎麼將這些數據轉化成生產力，可能需要我們持之以恆的鑽研下去。我把數據花成了流程圖，大家看著很清晰，也感覺很震撼，但是將這些數據仔細的甄別標註出來，也花費了我很多的時間和精力；二是別忽視產品的舊功能，大部分產品經理手中的產品，可能是從上一任接手過來的。這導致很多已有的功能會被我們忽略掉，而光顧著做一些新功能。給自己一點時間，把產品從頭的檢視一遍，也許會有事半功倍的效果。

2、用戶反饋，也很重要

我還在做產品助理的時候，每天來上班的第一件事是去友盟後台回用戶的反饋信息，回完了才能安心展開一天的工作。

關於回用戶反饋這件事，還有一個很有意思的小事被我寫在了這個回答里：有個計算機大神的男朋友是個什麼感覺？ - 知乎用戶的回答

一般APP的用戶反饋，都是在設置頁面的列表頁中，有一個不怎麼起眼的入口。

我們在某一個版本迭代中，在用戶常用的幾個頁面增加了3個用戶反饋的入口（設計美觀，不打擾用戶）。

上線的那半個月，用戶反饋量增加了70%，之後大約在翻1倍的基礎上保持了穩定。

對PM們來說，這些都是非常寶貴的數據。之後我們又適時的增加了調研問卷的入口。

3、大殺器，微信 OAuth2.0 介面

這個需求不是我做的，但是數據增長非常可觀，所以我也寫一下。不過由於不太了解細節，就寫的簡單一點。

由於我們是一個社區類產品，裡面的很多帖子經常會被用戶分享到朋友圈，好友們在朋友圈點開這個帖子後，如果想評論下，勢必要在wap頁面上，重新走一遍登錄註冊的流程（這個流程幾乎斬殺了90%以上想評論的用戶）。

這時微信 OAuth2.0 介面展示出了它大殺器的一面，獲取用戶授權，拉取用戶基本信息，之後以微信登錄的方式進入到wap頁面。

此舉對社區的活躍度提升非常大，我記得上線後的wap上產生的評論、點贊等數據，應該翻了十幾倍不止。

以上。暫時就先寫這3個，之後如果想到再做補充。

看了系友 @周含露的回答，不禁心潮澎湃，想起作為工科學生利用技術吊打各路神仙的快活歲月：科學技術改變世界。為我系感到驕傲的同時，也分享一個自己剛工作時候的故事，其實之前在文章（用戶百分百：大數據改變管理諮詢（一） - 數據冰山 - 知乎專欄）也提到一些。

因為從小喜歡數據分析，向來對市場調研有所保留，感覺抽樣太不靠譜。特別是後來知道調研中還混雜中各類會蟲（「會蟲」，一般為社會遊手好閒人士，偽裝成各類調研所需要的用戶，參加各類調研以賺取調研的勞務費），這種保留越多。而且市場調研成本不菲，聘請一些大牌公司來做，定量和定性全套下來，幾百萬人民幣是打不住的；不算調研公司的人力成本，還要考慮投入己方的數人進行配合，甚至要全國到處出差。

但苦於沒有想到更好的方法來取代傳統的市場調研，直到我經歷如下的巔峰體驗：

通過技術大幅度降低成本，將原來需要十多個人投入數月的工作並牽涉到數千人的調研，變成兩個程序員一個月的雙飛雙宿
通過系統大幅度提升可擴展性，下一次進行類似的工作，額外的成本從一比一的線性複製變成幾乎於零

故事背景
2005年，我司博士屯接到某國際超大運營商的一項目，要求規劃其呼叫中心戰略。聽起來無比高大上的項目，其實背後的故事很有（fu）趣（za）。某大領導提出天才想法，要求對呼叫中心的流程及菜單做出重構。這個重構還不是一般的重構，而是雙重重構。

第一重如下圖，整個改變呼叫中心的流程。

第二重是重構呼叫中心的菜單。

大老闆的想法實在是太顛覆了，手下們都是虎軀一震嬌喘連連。誰都不敢立即推廣而扛雷，於是只好請來了國際知名大諮詢公司做項目給建議。

故事展開
拿到項目之後，大趴們（合伙人，partner）自然很開心得想著數鈔票。至於項目嘛，國際先進經驗、經典客戶調研理論和實踐等都可以輕鬆上場嘛！其實他們不知道，那個時候的某國手機市場已經吊打全球了。歐洲最大的電信運營商在整個歐洲的手機用戶還沒有該國一個聯邦的用戶多。愛立信的定價專家曾經來給該國的運營商們講課，直接被掃地出門：該國的手機資費複雜程度，已經遠超世界各國，漫遊+被叫主叫+增值服務+親友號+小區號……

公司的一個項目經理很快帶著我們幾個小夥伴兒開始項目了，項目組共6個人，也準備按照常規套路展開：組織用戶調研+Focus Group、從集團公司拿經營數據做分析、巴拉巴拉。我當年也是年少輕狂不知愁滋味，斗膽給項目經理建議：

傳統方式太low，首先調研的樣本有限，而且面對面問用戶某個呼叫中心的服務好不好，實在不靠譜，不具備參考性
呼叫中心應該能收集到用戶的海量數據及唯一ID（手機號），可以試試用純定量的方式來評估效果和解決問題

以當下的眼光來評價上述建議實在是太稀鬆平常了，這不就是一套統計系統而效果評估嗎，現在哪個App或者網站沒有這些？但是這個項目發生在2005年，CNZZ也僅僅是在當年成立，友盟是在2010年成立。而且即使如此，目前幾乎所有的諮詢公司還是在用客戶調研的辦法解決類似的問題。

幸運的是我們項目經理是畢業於美國名校的生物PhD而且從事多年數學奧賽，對於我這個瘋狂想法表示支持，讓我放手去做。我也只提了兩個條件：找一台伺服器跑海量數據；找一個清華計算機系的本科生和我配合寫程序。

項目就此啟動。

故事發展
當年，運營商總部的數據都是宏觀數據，很難微觀去觀察每個用戶的行為，特別是每個用戶在每個時間段的行為。所以我只好要求呼叫系統的開發商——華為定製開發，給我們增加輸出詳細日誌的功能。華為真是NB的公司，居然同意並快速響應了我這個要求。也得益於10年前我還是小鮮肉，華為工程師實在架不住我們這般軟磨硬泡和恩威並施。

我們提出的數據收集方式和數據格式如下，要求系統詳細記錄用戶的每次操作行為以及操作時間。

通過華為的日誌輸出，每天得到上百萬的session（基本等於網站的UV），已經上千萬的行為數據（基本等於網站的PV）。為了處理這個海量的數據，我們兩用上了SQL Server和C++。（抱歉那個年代還比較土，不知道去用MySQL）。

同時基於多年做科學實驗的研究方法論和經驗，非常注重對比測試control test，而且受到了學生物的項目經理的指導（搞生物沒有盲測怎麼玩兒）。在華為工程師的幫助下，在呼叫中心的前端做分流，比較不同控制組。現在這套理論和方法叫做AB Testing。

故事產出
這套新方案的核心思路是：在同等資源投入情況下（資源投入=投入的坐席人數及服務時間），用戶體驗如何變化。數據要反映的核心落在用戶體驗，因此需要用相應的數據指標來表徵。電信行業一般用接通率（略等於用戶的等待時間或者服務質量），因為我們的數據能夠微觀到每一個用戶，所以我們又加了一個全新的指標，即同一用戶在一定時間內的重複撥叫概率。因為它和用戶的問題未被解決而需再次服務的概率正相關。該概率越高，表示用戶體驗越差。

下圖是我們的一個分析結果，以及對各個試點區域進行了純定量的總結。恰恰是海量數據幫助我們發現了真正的問題：

新方案上線後，接通率提升，按照傳統思路這是好現象，可立即執行
但是微觀的數據同時顯示，同一用戶在一定時間內的重複撥叫概率卻提高了。真正的解釋是：新方案降低了服務質量所以騰挪出坐席資源，但是話務員並未能解決用戶的問題，造成許多用戶再次撥打人工坐席

下面是對呼叫中心新菜單的分析（這個類似於今天對網頁及App的各種UI的優化），實現了整套的轉化漏斗（感覺是不是很超前）。

下圖是用戶進到呼叫中心，第一次按鍵的時間分布圖，幾乎是開了上帝視角來觀看用戶的行為。

可惜當年還不夠瘋狂，其實應該能想到NLP以及各種情感分析的黑科技。

故事高潮
當這些結果呈現在客戶面前的時候，他們再次虎軀大震，沒想到呼叫中心的優化及數據分析還可以這麼玩兒。沒有基於海量數據的各類數據分析，傳統分析套路是：

大量人肉發問卷，讓大家一個個填寫問卷覺得哪種菜單設計好，然後拿Excel或者SPSS做統計
找一堆人做深度用戶訪談（Focus Group），覺得菜單哪裡好為啥好，然後寫定性的報告

以上工作大概需要兩三個管理諮詢顧問加上一個專業的市場調研公司忙乎一兩個月，才能形成一個極小樣本的報告，同時還要運營商配合，邀請使用過新菜單的用戶來某高大上的場所進行面談。問卷調研的苦逼狀及深度用戶訪談的超高成本，見下圖。

但是按照我們純定量的思路，完成我們這個全樣本的工作，總共需要：一個會寫程序的諮詢顧問，一個實習生（實習生工資是每天200元）以及一個華為的工程師（該人在完成生成日誌的模塊後就徹底和這個項目沒關係了）。大概做了兩個月，但是真實只做了一個月，後面一個月的時間我們兩基本在發獃，但是項目確實賣了兩個多月。

在此之後這套方法論及系統，在全國各地基本上是無成本得複製和擴展。

故事體會
大概是中國人的教育背景較單一及商業意識較差的原因，我們這些工科學生在做完這個項目之後，扔下就去做下一個諮詢項目或者出國讀MBA了，完全沒有想到將其產品化甚至是開公司創業，這可是在比CNZZ和友盟還要早的2005年。我們只是悲催得完成了第一步：敢想敢幹，用技術改變世界，提升現狀。但是，沒有想更遠的一步，用產品和商業更大幅度得改變世界，讓世界變得更加美好的同時，也讓自己徹底財務自由；財務自由也會讓自己的創意更自由，利用更瘋狂的技術和創意，去更徹底地改變世界。

不過世界總是變得越來越美精彩，現在越來越多的創業者都是從大公司里走出來，隨之帶出來的都是在工作發現的需求以及自己研發的技術方案，願他們走得更好。

……更多文章數據冰山 - 知乎專欄
……更多回答何明科的主頁

將一個列表控制項的條目容量上限從一萬左右提升到十萬以上。

但並沒有使用任何酷炫的技術和高妙演算法，無非就是對象池和各種緩存，最複雜的部分不過是為了支持拼音和多音字查詢處理了一下拼音碼錶。

將一個圖像處理模塊的處理速度從每秒 10 幀左右提高到每秒 60 幀以上。

所用的方法不過是將中間結果緩存到文件里，以及替換一個計算量過大的插值演算法。

將一個錄像播放器由打開文件後卡一秒播放優化到瞬間播放。

所用的方法不過是修改了一下錄像格式，把幀偏移記錄在文件開頭，和 mp4 一樣。

在 linux 上使用 SDL 渲染多路 1080P/25fps 視頻畫面，目標是 16 路，結果跑到 4 路就卡了。經過優化 16 路流暢渲染。

所用的方法不過是障眼法，SDL 整個平面每秒刷新 25 次，各個視頻畫面刷新時間強行對齊。

最搞笑的經歷是優化一個設備管理服務程序，因為底層介面是同步的，沒法使用非同步 select 那種方式，於是配置的設備一多啟動時間感人。看了一下代碼發現前輩封裝了兩種啟動模式，一種是單一線程排隊連接設備，一個一個來，一種是多線程並發連接設備，一個設備一個線程。但是代碼注釋說併發模式不可行，因為設備一多線程太多程序跑不動……

我曾經發明了個方言成語叫「當即立毛」，意思是「當時我就毛（方）了」。那一次我就當即立毛了——tmd一個線程一個設備跑不動，你不能一個線程十個設備、一百個設備試試？

以上經歷說明，很多時候我們能大幅度優化一個軟體，不是因為我們有什麼黑科技，而是因為現有實現太二了。這是業務驅動的企業軟體開發的常見現象，客戶沒有感知到的問題，便不是問題。所以有人說精英級年輕人要遠離企業軟體開發，我覺得不是沒有道理。

我把 ReactJS 用 Scala 重新寫了一個。
代碼量從近三萬行降到了一千多行。

我在 QCon 上講這句話的時候，台下有幾個聽眾可能是 JS 粉吧，馬上就站起來提前離場了。

大家的例子好高大上。我來幾個是程序員都會做的事情。
故事1：高麗公司工資上報升級效率提升
剛工作的時候，銀行的網路系統還沒有完全普及，本地某高麗大型外資公司幾千員工居然還用EXCEL手工做工資表，然後用優盤拷貝文本文件的辦法交給銀行，再導入、檢查處理。

銀行很苦逼，高麗公司的人力資源更感覺苦逼，每月一次的事情，提供者、接受者都很痛苦。其中銀行方的苦逼是我同學。終於有一天雙方在月底崩潰了，原因是第二天要發工資，而工資計算由於某些規則大幅度改變，人力部門員工無力計算，工資要無法及時發放了。

江湖救急。

那天下班的時候，同學開車把我送進這家企業，一層、兩層、三層的身份驗證和登記，終於起了一個巨大的辦公室，7、8個中方員工和一個高麗方主管，我同學對我簡單地介紹了一下情況，幾千條數據，幾十條規則和人員分類，幾十個數據項，要求是按新演算法精確計算，數據校核導給銀行。

他們預計用EXCEL做，3-5個人還要約2天才能計算校對完畢。

記得當時拿了幾張紙寫了寫表結構，理了理公式，寫了2小時程序，調試和被人測試了2小時，到晚上22點多程序搞定。所有企業部門員工，韓國主管都什麼事沒有在邊上看我寫代碼，後期挑刺看數據對不對。

有了基礎數據，工作幾秒鐘完成。

某高麗大型外資的主管第二天直接電話挖我進他們信息中心，我拒絕了~~~~VFP前途是不大的，其實我是個C++程序員。。。。

故事2：海量數據校驗效率提升
近年來單位有海量數據報表要做，做完大約有幾十張表需要交叉數據校驗。原來是有校驗部門，用不著我們這些程序員，但有一次我自己部門也要交數據，數據量雖然小，但我還是覺得看得眼花，寫了100多行VBA把原來要校對一個上午的工作，幾秒鐘搞定了。

校驗部門誘之以利，於是寫了三天，把3個人3天左右工作量減少成半小時，其中29分鐘是數據準備，程序運行1分鐘不到。

校驗部門爽到什麼地步呢？各部門數據上交後，做一會準備，然後PDF導出校驗結果，郵件發回各部門照單更正，校驗部門喝茶喝咖啡吹牛打屁爽歪歪，各部門忍氣吞聲，因為程序很精準，沒有檢查失誤的情況發生。

悲哀的是VBA我是隨手亂寫的，領導嘗到甜頭後功能不斷擴展，屎的一樣的架構和升級困難的C/S結構讓我一直想要重構，但這次沒有經費了。。。。

公司把以前遲到從工資里扣工資變成了遲到者在前台當場交20塊錢罰款，結果遲到的人從原來一周幾十人次降到了一周幾人次。

------------------------------------------------------------

知乎的世界跟我所在的世界確實不在一個次元。在三線城市司空見慣的遲到罰款原來是不合法的，因為遲到罰款還有人會辭職，看來我大鄭州別說跟國際接軌了，即使是跟國家同步都沒達到啊。

不過知友們說的國企遲到不罰款，以前在國企只有早班遲到在嚴查的時候被抓會有罰款記錄，中晚班好像都睜一隻眼閉一隻眼過去了，不過罰款在制度里是有的。

那麼多回復里拿BAT的彈性工作制來證明遲到不該罰款，請問有多少人在BAT這樣的公司里供職呢？

在你們大城市現在為四天半工作制搖旗吶喊的時候，你們是否知道大多數的企業連雙休制都不能實現？

--------------------------------------------------------------

剛問了一些北上做營銷運營的朋友，他們說他們那遲到也罰款啊，看來勞動法在北上執行的也不太徹底。

罰款其實也不是目的，目的只是不讓遲到。

沒拿到手裡的錢就不算錢，很多人扣工資不在乎，但是從兜里掏錢會很心疼；還有些人比較好面子，從工資里扣不算啥，但是自己到前台當著那麼多人的面交錢會就會覺得很丟人；有知友提醒，也許是懶得準備零錢。

「大幅提升」的定義其實挺含糊的，怎樣才算大幅提升？對於某些指標，提升個百分之零點幾就很厲害了，而對於另一些指標，可能一不小心就翻倍，甚至翻個幾倍。在這裡不糾結具體是怎樣的比例才算大幅提升，說說自己做過的一些對數據提升比較有效的功能或改進吧。

▎案例一：導購 app 購買商品跳轉手淘

之前在做一個產品形態上以媒體屬性為主的導購 app，剛開始從 0 到 1 的時候，看其它家的導購 app 在點擊查看商品時，都是跳轉到淘寶的 h5 商品詳情頁。而我看那個商品詳情頁長得奇醜，下單還要填寫好登錄和支付信息，於是毫不猶豫地選擇了調用手淘 app。理由有以下幾個：

1. 產品剛推出市場不久，用戶還沒有建立起對產品的品牌信任度，直接在 app 的 h5 頁面讓用戶輸入淘寶的賬號密碼，其實非常沒有安全感。

2.首次購買需要填寫淘寶的賬號密碼，支付時還需要進行支付寶的相關操作，交互的路徑太長，而且網頁長得實在太丑，跳轉起來頁面渲染時給人的感覺也一卡一卡的，中途放棄的概率太大，而首次成功購買體驗十分重要。

3.在 app 里進行網頁的操作就是不爽，看著網頁的 UI 就是覺得挫，和 app 的操作體驗有一定的割裂。

當然，採用跳轉手淘的方案其實也是有一些劣勢的，比如：

1. 跳轉手淘後，用戶可能刷著刷著就不回來了。

2. iOS 客戶端從手淘不能直接點擊返回跳轉到我們的 app。

然而，在進行用戶調研的時候，發現 iOS 用戶根本不 care 第二點，他們會通過雙擊 home 鍵切換回我們的 app，而且並沒有產生明顯的不滿情緒（後來 iOS 系統支持了點擊屏幕左上角切換回跳轉前的應用）。

說到這裡，有人可能發現我沒有給出兩個方案在數據表現上的對比，而是直接就採用了自己認為好的方案。不著急，我們現在來說說對比的故事。

近兩年，隨著移動互聯網的不斷普及，各色各樣的電商 app 如雨後春筍般大量出現，不可避免地搶走了原屬於淘寶的一部分市場份額。然而，這個事情在 web 時代並沒有特別突出，因為 web 的導流體系和移動互聯網的導流體系是有著明顯差異的。在 web 時代，淘寶通過大量的淘客以及購買各個網站的廣告，很容易就能獲取流量，因為用戶一點擊就跳轉到淘寶商品詳情頁了。然而，在移動互聯網時代，淘寶卻不能通過購買各個 app 里的廣告，然後讓用戶跳轉手淘的商品詳情頁。最長的路徑可能是先讓用戶去應用商店下載應用，下載完後還要啟動，啟動後還要找到商品詳情頁，非常讓人抓狂。這就是為什麼移動互聯網普及後，各互聯網公司開始大量投放起傳統媒介廣告的重要原因之一。

面對各電商 app 的蠶食，阿里也意識到垂直電商、社區電商、媒體電商等更為細分的電商 app 一定會搶佔自己原有的一部分市場份額，這是不可阻擋的趨勢（封殺美麗說和蘑菇街是血淋淋的教訓）。與其一味地抗爭，為何不去擁抱變化？而擁抱變化的措施很簡單，就是把淘客體系移動化，給電商 app 們提供交易的整套基本技術設施。也就是說，電商 app 們只要做好拉客和接客就行，交易可以在自己的 app 內完成，只是底層走的是阿里的交易系統。這就是所謂的為各電商 app 提供「水電煤」的阿里百川計劃。

說了這麼多，怎麼還沒講到兩個方案的數據對比？不著急，現在就來。

如果不是阿里的人來推銷百川計劃，我也不會嘗試跳轉 h5 頁面的方案。與阿里百川的合作方式有兩種，比較深入的一種是把整個伺服器都託管到阿里雲，這樣有讀取淘寶商品各種介面來打造自己的 native 商品詳情頁的許可權；另一種比較淺層的是跳轉到百川版的 h5 商品詳情頁，支持調用手淘進行賬號授權及喚起支付寶 app 支付，從而提升交易的體驗。對於第一種合作方式，我們明顯是不能接受的，所以決定嘗試一下第二種合作方式看看效果。

第一次嘗試是沒有區分新老用戶，直接切換到跳轉百川 h5 的方案，流水掉得很快，用戶怨聲載道；第二次嘗試只針對新用戶進行，這樣他們沒有先入為主的「就應該跳轉手淘」的概念，但數據還是有明顯的下降。所以，對比其它導購 app 跳轉淘寶 h5 商品詳情頁的方案，跳轉手淘能夠明顯地提高購買轉化率。

▎案例二：自有商品詳情頁

剛開始的時候，我們也和其它導購 app 一樣，一點擊查看商品就跳轉去淘寶的商品詳情頁。然而，由於在友盟上看到平均單次使用時長遠小於我們猜想的數值，而這個指標又可能是我們需要提供給投資人看的。因此，我們對此進行了分析調研，發現問題出在每次跳轉手淘再跳回來時，友盟會將此記錄為一次新的啟動，導致單次使用時長遠小於我們實際的數值。於是，基於這個考慮，我們決定新增一個自有的商品詳情頁，裡面的商品信息通過爬蟲抓取淘寶的即可。這樣做除了使單次使用時長提高了好幾倍外，還有以下一些好處：

1. 用戶點擊商品詳情時，其實只是想進一步了解一下這個商品，購買的意願還不是很高。通過跳轉至自有商品詳情頁，依舊可以解決用戶進一步了解商品的需求。而當用戶真正想要購買時，點擊「去淘寶購買」才會跳轉至手淘。這樣一來，用戶不用經常在兩個 app 之間跳轉，瀏覽內容的體驗變得更連貫。另外，對於淘客的數據統計而言，監測到的我們的購買轉化率會有明顯的提升。因為這時候跳轉去手淘的用戶都是經過篩選後的有更高購買意願的用戶。

2. 有自有商品詳情頁後，用戶可以在我們的 app 里對產品進行評論（生產內容），刺激互動和活躍。未來也可以把類似購物筆記或曬單的功能擴展進來，起到輔助購物決策的作用，使 app 的內容類型更為豐滿。

▎案例三：積分獎勵體系

我們的產品以大學生為主，這個群體的一個明顯特徵是時間非常充裕，但手裡的錢卻比較有限（畢竟沒有收入）。針對這個特徵，為了提高活躍度及自然用戶新增數，我們設計了一套積分獎勵體系，以下是幾個積分體系的功能：

1. 在首頁增加每日簽到功能，累計連續簽到次數越大，得到的積分獎勵越多，並在當中加入了「擊敗了 x% 用戶」的簡單激勵。功能上線後，使用率很可觀，用戶的中長期留存率能夠觀測到提升。因此，在同樣的日新增下，平均日活增長數也慢慢地上升到一個新的水平。

2. 用戶分享 app 的內容能夠獲得積分獎勵，但每天有獎勵上限。這個功能的效果可以說是立竿見影，上線後每天的分享數很快就提升了幾倍。所帶來的迴流對於整個日活的體量來說雖然不算非常大，但也是提升產品曝光度從而提升自然新增的一種有效措施。

3. 用戶邀請好友下載使用 app，雙方都可以得到積分獎勵。這個功能每天能夠貢獻不少自然新增，而且這些新增可能是廣告投放難以觸及的用戶。因為並不是每個人都會暴露在你投放廣告的媒體面前，而他的好友卻是他經常接觸的「媒介」。除此以外，被邀請進來的用戶在一開始就體驗了積分功能，僅考慮這個因素的話，他們的留存率會要比其它推廣渠道來的用戶更高。因為正常情況下，積分功能其實不是作用於次日留存的，而是使用過產品一段時間的用戶才會用它。

4. 首個評論內容的用戶能夠獲得積分獎勵，也就是所謂的搶沙發功能。怎麼能夠讓用戶更好地參與搶沙發呢？為此我們做了內容的下次更新時間提示，固定在每天的若干個時間點發布內容。這樣一來，積分的重度用戶們便會如期出現。這個功能既提高了評論數，也提升了 app 的日啟動數。當然，它也帶來一個問題，就是用戶為了搶沙發，評論時只編寫一個標點符號。但這個問題其實是小 case，因為我們可以很快就把無意義的評論給刪除掉。另外，app 里這種搶沙發的文化其實讓人感覺挺可愛的，提升了新用戶對產品的好感度，對提高次日留存有好處（當然，這個效果相對較弱，因為鏈條太長了）。

列了三個，其它的就不繼續想了。只想說，能夠一做上去就明顯地提升產品某項指標的功能是非常少的。拿產品的留存率來說，你再怎麼提高，也會到達一個瓶頸，你可以認為它不是無限增長的。產品的購買轉化率也如此，天花板非常明顯。產品的提升是一個量變到質變的過程，當體驗做得差不多或者極致後（文中所說的 app 大部分指標在友盟的排行里都是前 5%），怎麼繼續提升業務，其實更多是推廣和運營的事情了（相關回答：產品經理的未來在哪裡？ - 鄭堅義的回答）。如果你能輕易地找到很多大幅度改進提升數據的功能點，很可能只是證明了之前的設計多有糟糕。

另外，不是說上面的幾個功能對所有 app 都有同等的效果。還是那句，具體問題具體分析，多熟悉在家產品，多思考用戶的特徵（相關回答：一個優秀的產品經理如何去真正了解用戶需求？ - 鄭堅義的回答）。

說三件事吧。

做一個Windows版的PDF閱讀器，有些頁面翻頁要幾分鐘的時間，用戶翻下一頁，頁面要一直空白幾分鐘才能最終渲染好。用戶很難等這麼久，都以為程序死掉了，直接關掉，客服收到了無數抱怨。我profile之後發現這些頁面有很多很小的路徑對象，大量時間花費在內存分配與釋放上。於是寫了一個內存管理器，翻頁時間迅速降到秒級。參見內存池除了減少內存申請和釋放的開銷之外還有什麼提升性能或者方便之處？ - QAMichaelPeng 的回答。
在一家公司接手Kindle上的電子書閱讀器。Kindle上的開發流程和PC上大不一樣，沒有編譯，運行，調試/測試這麼舒服的事情。當時我們的開發流程是這樣的
1. 在PC上寫C++代碼。
2. 通過交叉編譯工具在PC上編譯可以在Kindle上運行的binary.因為Kindle上程序區存儲空間有限，還不能編譯成debug版，只能出release版。
3. 通過USB拷貝到Kindle.
4. 重啟程序，有時還要重啟Kindle。
5. 測試。發現功能問題，go to 1。
這種方法雖然慢了一點，從1到4快則5分鐘，慢則10分鐘，但也能解決問題，但碰到多線程環境的野指針問題就抓狂了。正好我接手的時候就碰到了這種問題，經常莫名其妙崩潰，一個組找了兩三天無果。
時間都花在通過USB拷貝數據上可不好玩，要能在PC上搞定豈不可以省掉很多時間，既可以拿gdb利用調試信息調試，也有一大票免費的performance profiler/memory profiler 可以用，豈不美哉。於是俺擼起袖子動手，幹了幾件事情:
1. 在makefile中加入對linux x86的支持，可以編譯到linux x86目標平台，就可以在ubuntu上運行了。
2. 把kindle上的輸入輸出重定向到ubuntu上的share memory/FIFO。
3. 用PyTk做了個簡單的UI，把share memory里的圖像內容渲染到屏幕上，同時把用戶的輸入通過FIFO傳遞給閱讀器。
幹完這幾件事之後上面的1~4就變成了
1. 在PC上寫C++代碼。
2. 直接編譯為linux下可以運行的debug版代碼。
3. gdb/sysprof/valgrind各種折騰。
幾分鐘之內就定位了上面那個野指針問題的原因。
現公司，和某兄弟組合作。兄弟組提供RESTful API訪問數據, 以json格式返回。而這些數據是有層級的，為了拿到最終想要的數據，通常要調用至少四五次API,都是手工拼接，在瀏覽器里敲URL, 中間還涉及到URL轉碼，分頁，列表數據等問題，一不小心就拼錯URL，用的那叫一個痛苦啊。提過做UI的要求，可人家那邊排不上優先順序。偶鬱悶完了自己寫了個TamperMonkey的腳本，只需要在瀏覽器中輸入最頂層對象的URL, 自動AJAX調用子對象的get API,所有對象展現在一個頁面上，一目了然。現在這個腳本已經成了所有用到這組API的用戶的標配了。

很慚愧，就做了一點微小的工作，謝謝大家。

修改了夢幻西遊引擎的一個內存使用的bug，內存佔用降低50%，使得以前只能4開客戶端，優化後可以8開，可惜夢幻組沒有給我發獎金。

分享一個UX Design和金融業務交叉項目的經歷，客戶為加拿大某中高利貸企業。

先說結論：在客戶business model絲毫不變，僅靠UI/UX設計的提升的前提下，借貸服務申請表格完成率比原先提高了30%，相當於為客戶多榨出了每年100萬加幣的利潤。

背景介紹：客戶想要重新設計網站公關頁面和借貸申請頁面來提高用戶的轉化率和申請成功率。加拿大銀行的信貸業務比較嚴格，因此催生了繁榮的民間借貸市場，大部分以Payday loan的形式存在。所以信用記錄不良的窮人因為沒法從銀行輕易借到錢，只能到這些合法的小錢莊去借錢。常見形式是付20元貸給你300加幣，兩個星期以內還清，不然就要吃利息（一般公司兩個星期發一次工資，故得名payday loan）。

此客戶和payday loan有些不同；他們貸款額度從500到15000加幣不等，還款時間最多也可以是三年。所以技術上來說大概算是「中利貸」。他們原先的網站和網路申請表格基本是90年代風格，可填項有200多個，給本來就好不容易下定決心貸款的窮人很大的嚇阻。因此客戶想要找到一種可以優化精簡申請過程體驗的設計，讓更多的人可以獲得公司的幫（qian）助（tiao）。

這個不是原表但是長得差不多。自行想像一下有200多欄，並且每一欄填寫的內容還有可能影響下面幾欄內容的巨大的難看的可怕的表格。

agency研究過客戶提供的數據以後，發現很多人竟然是在手機上完成的填表——暫且不提這些人是多麼有耐心，但是當時判斷這裡是設計新申請流程的一個突破點；所以當務之急是根據移動設備優化。設計大體遵循了這樣幾點：

1. 將200多行的表格逐頁顯示，分成四個大類，divide conquer，減少表格太多造成的mental block
2. 將儘可能多的需要多個觸摸輸入動作的欄變成單選選項；比如摒棄需要手動滾動的日期滾輪，將12個月份都顯示為可以觸摸的按鈕，直接列在用戶面前。單選選項UI不用瀏覽器自帶的UI，而是也做成方便手機使用的大按鈕，方便觸摸選擇，並且選擇後自動往下滾動表格。
3. 在完成當前部分的表格錄入/單選題之前，不顯示之後的表格的內容（同樣用來減少mental block）；但是可以scroll back來更改之前已經選好的選項。全部完成之後，選擇"Continue"上傳數據到資料庫並進入下一部分表格。
4. 屏幕上方保留進度條，時刻給用戶顯示填表進度。

也就是說，我們依靠UX設計，讓更多的人可以更方便地欠錢啦。
同事小哥似乎和自己的良心戰鬥了許久的樣子。

我寫的 otfcc 比 ttx 快 40 倍（載荷為 Inziu 的一個單 ttf，dump + build）

1、同花順客戶端啟動優化，從16秒優化到2，3秒。
主要優化點是：配置讀取方式。有些函數優化的比操作系統提供的Api速度還要快。

2、行情通訊協議優化
優化後當時滬深股市的通訊量只有3到4K/s，普通電話線撥號都可以快速傳輸。
其中行情客戶端部分是最先優化的，馬上性能就超過競爭對手了。
主要是新寫了一個壓縮演算法，後來基於這個演算法重新封裝了整個通訊協議，用在了從衛星開始到各個接收，發送，行情，pc和手機客戶端等所有相關環節。

3、同花順手機客戶端架構優化
客戶端大小直接從500多K變到30多K（不加安全模塊），加安全模塊是50K左右，支持潛在的用戶數量一下子多了很多倍。因為諾基亞的S40系列用戶非常多，程序有64K限制。
當時網路是2G，請求從6-7秒，減少到了2-3秒，直接在性能和終端數量上超過了競爭對手，因為靈活的架構，後續功能細化，支持運營商，營業部等許多地方都遠遠超過了競爭對手。

上面的事情都是2001到2007年左右的事情。

這兩年還有一些類似的事情,希望以後有機會給大家分享一下。

京東商城將域名由 http://360buy.com 改為http://JD.COM

公司是某理財平台。

促銷活動，無非就是3種：

1.你投多少錢，直接給你返多少現金；
2.你投多少錢，給你加息多少（或者獲得多少體驗金啊之類的）；
3.你投多少錢，可以得到什麼樣的實物獎勵。

之前在活動頁面上，除了強調收益，就是重點強調返利，強調獎品。比如投1萬直接返100元現金，投5萬直接得Kindle閱讀器這樣子~

後來我說服同事，對主推的活動頁面，嘗試著做了一些改變：活動頁面重點介紹平台實力、優秀項目、收益及退出機制。把活動獎勵放在次要位置。

效果大概提升了3倍。

所以對於理財平台來說，
活動真的是錦上添花的，
甚至連年化收益有多高，都不是最重要的，
拿出有說服力的好項目，讓投資人看得明明白白；
介紹自己是怎樣的平台，有怎樣的實力，獲得了哪些認可；
如何控制風險，如何退出，為什麼可以安心把錢放在這裡。
這些，對還在成長中的中小平台來說，尤其重要。

以上。

分享幾個經驗：

1. 當年寫公司拳頭產品的漏洞掃描引擎，爬蟲是核心瓶頸，後來把所有請求完全模擬瀏覽器的請求優化模式做了改進，尤其是增加了壓縮請求，一通優化下來，速度提升至少一倍，當時的內心是：fuck…

2. 深刻明白軟體工程一些經典設計模式之後，對現有粗糙架構做了優化與必要重構，又是一次質的飛躍。明白了一個道理：努點力，動點小思考，不會死，會更爽

3. 作為黑客，寫生澀的技術傳播量窄，看我這兩年科普性多些，關注面大多了，對吧:)

4. 作為黑客，要傳播量還不容易？年輕氣盛時，傳播靠蠕蟲呀，Web2.0 蠕蟲、主機蠕蟲…不過現在要考慮法律風險，但是，可以去巴西玩，法律風險低，不過要承擔被黑社會砍的風險

總結：優化或進化，要麼掌握目標世界的運行法則，要麼掌握其上的人性。

內幕請關注公眾號：Lazy-Thought

改進了自己的投籃姿勢，出手節奏。空位命中率從20%升到60-70%，實戰命中率40-50%。曾在實戰中投出過20投17中的數據。三分球投出過9中6。罰球基本穩定在10罰7中左右。

做一個遊戲有獎兌換的平台。
1.除了手機號註冊又增加了郵箱註冊。
2.把註冊從第一步放到了最後一步，用戶進入遊戲就有獎勵積分，完成三個任務後才能兌換，兌換前註冊，以前是進入遊戲前就要註冊。
3.各種細節文案等等優化，取消了一些干擾元素。

以前每天註冊量才不到十個，然後第二天直接註冊量4000+，沒過多久積分池耗光了就下線了。。。

前段時間，為了提高某模塊的訪問量，增加了一個簽到和 積分抽獎 的功能。

上線後，該模塊的使用數據：
「簽到」功能使用率70+%；
「抽獎」功能使用率30+%
用戶次日留存增加30+%；
新用戶次日留存增加10＋%；

數據是不是驚人的好看？
在該模塊內部，積分可兌換到物品，實際價值很低；
但一部分用戶就是喜歡干這些0成本付出、看似會有大收穫的事。

滴滴、美團等等，很多app都會在產品內部，增加一個積分商城的功能，並且簽到和抽獎基本是標配。看了數據，瞬間醒悟了，果真這玩意是有用的。還有一個公司的產品，叫做「兌吧」，專門為其他app提供積分商城，很多大公司的app都直接對接～

當然，下一步，你會思考，這部分用戶，是你的高價值用戶嗎？如何轉化他們成為你的高價值用戶....
但是，避免陷入誤區：靠積分帶動產品的核心價值。
需要明確的是：有需求的產品才能夠促進積分體系的持續發展。

剛發生的事情......
我們為了提高用戶的活躍度，增加了簽到、積分兌換等激勵性的功能，同時優化了很多使用細節（登錄方式、智能匹配等）來提高用戶體驗。

上線第二天早上，我如往常的打開百度統計......

卧槽！！！！啟動用戶增加了40倍有木有！！！！
高興的魂都飛出來了，差點在辦公室高歌一曲。

看到商務「看到沒！牛不牛？記得合作談成了請我吃飯啊！！」
商務兄弟一臉疑惑，貌似還沒明白怎麼回事....

路過運營，B當然也要裝「看這曲線，酷不酷！」
運營妹子一臉崇拜....

我剛要跑到老大那裡炫耀一下，提提升職加薪的問題，開發跑過來一臉慚愧的說：「哥，對不住啊，我把統計方式弄錯了...弄錯了...錯了....了.......」

瞬間感覺，我好像被美杜莎看了一眼.......

快改啊！

兩天後終於正常了....

還好啟動量翻倍了...

要不然，不要說升職加薪，工資減半獎金全免是跑不了了。

還是不夠細啊。