美團技術架構

追求極致：從技術細節看美團架構

 不少人認爲，電商都沒有什麼技術含量，沒有什麼門檻。但是，美團能從千團大戰中脫穎而出，成爲國內最大的本地生活服務平臺，必然不是靠運氣。美團網技術委員會主席夏華夏爲InfoQ的讀者分享了美團內部的思考：「技術團隊的努力、不斷追求極致的努力」是公司走向成功的重要緣由。

Q訪談：十分鐘瞭解美團大牛

夏華夏，現任美團網技術委員會主席，負責基礎技術架構、大數據等相關工做。曾任Google高級工程師，百度主任架構師。關注基礎架構、雲計算、運維、大數據等技術。

本文分紅三部分：

一、美團的技術架構，架構是如何演變的。

二、美團的業務架構，在業務方面如何作一些業務流程的優化。

三、O2O技術，如何實現線上和線下都用技術來作優化貫通的。

技術架構

其實在初期的時候，美團的技術架構很是簡單，的確在最初2010年、2011年的時候，技術是沒有門檻的，任何一我的均可以寫一個電商的網站。

圖1最初的技術架構

這就是一個最初期的架構，一個比較典型的LAMP架構，前端加上Apache/PHP，後端是MySQL，固然咱們會有一些運維的工做在裏面。可能你們若是本身寫個網站的話，一開始都是這種架構，這種架構一開始也很好用。而後慢慢的，當業務量大了以後，咱們發現整個系統的性能跟不上。那時候咱們也只是作一些簡單的優化就夠了，好比說一開始咱們是在前端，就是在Nginx和Apache之間加一些Varnish的緩存，而後在後端，咱們可能用Memcached來減小MySQL的壓力，這些都是緩存，整個架構仍是沒有太大的變化，仍是一個優化了的LAMP架構。

圖2簡單優化

而後到2011年的時候，咱們開始作移動端，這時候架構仍是沒有太大的變化，只不過是在Apache這種已有服務的API前面，又包了一層。就是咱們在提供給PC端的同時，咱們也包了一層移動的API，這樣咱們能夠繼續給手機端的用戶提供服務。

圖3 2011年的架構

這個時候其實也就是簡單地把LAMP架構作了一點點擴展，可是已經能夠支撐不少不少的用戶，不少不少的容量了。咱們在這種架構的前提下發展，直到咱們想去作新的業務。美團一開始起步是個團購公司，後來咱們去作一些新的，好比說酒店業務、電影業務，直到如今你們可能使用過的美團外賣的業務。

當咱們去作不少不一樣的業務的時候，咱們發現作每個業務彷佛須要添加一些新的部分，這樣一個部分、一個部分堆積，對不少技術的同窗來講，這是不能容忍的，那咱們怎麼去改進它呢？咱們但願把中間的不少的公共的東西，與業務無關的東西抽取出來，造成一些公共的技術的組件，這樣能夠爲不少的不一樣的業務來使用，發展到如今，造成這樣一個看起來稍微複雜的架構。

圖4如今的技術架構

在最底層會有云平臺，對內對外都有服務，會有云主機、雲存儲、虛擬網絡，包括一些負載均衡的東西。在雲平臺上面，咱們會有一些基礎的組件，這些基礎組件跟業務的邏輯相隔比較遠，它會有好比配置，隊列中心，註冊中心，包括一些SQL和NoSQL的存儲等等，這些技術組件咱們在全部的業務裏都會使用，因此咱們把它提取出來，做爲咱們的技術組件提供給業務能用。

再往上，確實有一些東西是與業務結合比較多，好比說用戶中心、支付、搜索、推薦、風險控制，以及創建用戶的一些地理位置的庫，這些東西是與業務是有交互的。可是咱們去分析以後發如今不一樣的業務裏面，這些組件仍是差很少的，因此咱們也是把它抽象出來，如今叫業務組件，這些業務組件在全部的業務之間也是共用。

再往上纔是咱們各個不一樣的業務的，真正的比較獨特的一些邏輯。在這些業務邏輯前面，是前端的接入，這個前端接入其實對不一樣的業務也是同樣的，它會有前端的接入和轉發，會有前端內容的過濾，就是一些防抓取，防攻擊這樣的內容過濾。

好比說爲了作用戶訪問性能的優化，咱們會作大量的各類各樣內容的緩存，包括CDN也好，包括咱們內部不一樣層次之間，包括一些驗證碼的服務。因此在這種架構下面，當咱們再要去作一個新的業務的時候，咱們就關注在中間業務邏輯這一塊就能夠了，這樣能夠很快地去拓展新的業務邏輯，並且每個人，每個團隊，只關注真正最有價值的那一部分的軟件的開發。那固然兩邊會有咱們的，運維的工做，安全的工做，是在每一層都會涉及的。

可是整個這樣一個邏輯發展到如今，咱們是以爲最適合咱們美團如今這個階段的一套技術架構，那從一開始的最簡單的LAMP，到如今可能咱們分了不少不少個組件、不少不少層，這些架構看起來是很是很是不同的。可是咱們如今回想起來並不以爲說，原來的就很差，如今的就好。

咱們以爲在公司發展的不一樣的階段，一開始就最適合那種最簡單的狀況，若是說咱們一開始，好比說美團2010年成立的時候就上這種很複雜的架構的話，那可能咱們2010年末才把軟件開發完，那時候上線的時候，可能已經有五千多家團購網站在線上了，因此這是不切實際的。因此總體來講，咱們以爲在整個技術架構的演變過程當中，就是找當前真正可以知足咱們業務需求的。

另一個特色，你們也能夠看到，在咱們的整個的架構裏面，大量應用了一些開源的東西，從最初的LAMP架構的時候，包括MySQL、Apache，到如今咱們一些很複雜的架構裏面，好比說搜索，如今會用到Lucene，會用到Solr，在雲主機、雲平臺這一塊，咱們會用到好比說OpenStack的一些個組件，包括好比存儲的Swift等等，用到不少的開源的東西。

開源產品拿過來固然會加速咱們的這種開發的週期，可是開源產品咱們也不只僅是單單把它拿過來，由於任何一個開源的產品，若是你要拿到一個比較複雜的業務裏，你就會發現它不是那麼匹配的，它老是有些邊邊角角，好比說要與系統的集成，或者不少開源產品，它在大規模的狀況下，高併發的狀況下，考慮地並非那麼周到。

因此咱們在開源的基礎上作了大量的優化，一方面能讓咱們的整個系統能作更好地水平的擴展、系統的擴展、系統的優化，同時也讓整個的用戶體驗可以更好。

總結下來，就是在技術架構方面，想跟你們分享這麼幾點，一個就是整個技術架構老是在不斷地結合業務在不斷地演化，還有就是至少從美團來講，咱們是在開源軟件的基礎上，而後不斷地作集成，不斷地作優化，最後，軟件開發的時候，無論是在對用戶體驗來講，仍是對工程師本身的體驗，咱們老是在追求一些極致，這樣的狀況下，咱們的技術架構就天然而然的在不斷地演變了。

業務架構優化

圖5複雜的業務架構

這個圖是一個比較複雜的圖，咱們也不去講它的太多的細節，大概分析一下，上面這一塊實際上是剛纔給你們看的，對用戶訪問端，它所涉及到的一些組件，一些部分。可是對於電商來講，其實它還有一個很複雜的生產系統，這個生產系統就是說咱們怎麼去跟生產商談單，談完以後，咱們怎麼把這個單子錄到線上，怎麼去編輯，怎麼去審覈等等，這個單子的生產咱們叫生產系統。

除此以外，還有整個公司的運營，一些市場的營銷推廣，咱們怎麼去拉動咱們新的用戶，怎麼去拉動咱們的新的商家等等，因此就涉及到不少的業務的模塊。整個的這個框架，細節咱們不關注，可是第一感受確定是很是複雜，這個複雜的業務架構有一個什麼後果呢？

通常來講，它會讓整個流程很是複雜，當流程複雜了，那天然而然帶來的整個效率低下，因此對於技術團隊來講，咱們一個努力就是在不斷地去優化咱們的業務架構，不斷地讓流程簡單，讓效率更高，那怎麼來優化呢？

圖6業務架構的優化

咱們有一些本身總結出來的方法論：

1.把複雜的事情簡單化。一個很複雜的業務架構，咱們但願對它作不少理解和梳理，梳理的過程當中，咱們就會發現一部分步驟實際上是不須要的，能夠省略的，這是一種簡化；還有一個就是，當咱們梳理完了，發現每個步驟都須要的時候，咱們會盡可能地把一個複雜的東西拆成不少比較小塊的，易於把控的一些東西，這就是一個把複雜東西簡單化的一個過程。

2.把簡單的事情標準化。當把一個複雜的東西拆成了簡單的小的東西以後，咱們就容易地去對這個簡單的模塊，簡單的功能進行標準化。所謂的標準化，就是去制訂一個標準，這個東西該怎麼作，應該實現什麼目的，作了以後咱們怎麼去衡量。因此這三個是很是重要，就是我要去作什麼，我怎麼作，而後怎麼去衡量。若是把每個簡單的東西都處理好了以後，這個簡單的東西就成了一個標準的東西，標準的東西在不少時候就比較容易去推廣。

3.把標準的事情流程化。若是整個的標準比較完善了，那咱們就但願把這個標準固化下來，固化下來就是說整個的工做就會變成一個很簡單的流程。招幾個新的員工，而後給他們一個手冊，告訴他們，照着這個手冊一步一步，第一步作什麼，第二步作什麼，第三步作什麼，這就是流程化的東西。若是發展到這個時候，其實複雜的東西已經能夠比較高效地往下運做了。

4.把流程的事情自動化。對於計算機和搞技術的同窗來講，咱們知道，其實計算機它最擅長的東西就是處理這種簡單的流程，因此咱們若是作到流程化，就有了一個自動化的基礎，咱們能夠用計算機來把這些固化的流程完成，這樣最終就把複雜的事情可以儘可能地作到自動化。

圖7上單免審免寫舊有流程

我來舉一個簡單的例子，尤爲是後面流程化和自動化這個東西，你們可能不是那麼理解。就是咱們在上單，所謂上單就是一個單子，好比一個餐館售賣的東西，就是本地服務的一個產品，咱們叫一個單子。上單的時候，咱們的銷售同窗和商家談了一個問題，最終要上到咱們的整個網站裏邊。

咱們今年上半年曾經作過一個很大的努力就是，上單的時候咱們但願免審覈、免寫、免編輯，爲何要這麼作呢？給你們介紹一下舊有的流程，在舊有的流程裏邊，銷售團隊可能從簽定合同開始，還不算他一開始跟商家去談私人關係，去一次一次的溝通，那時候可能要碰不少壁。

即便是商家已經贊成了要和你合做了，那銷售的同窗就能夠和商家簽定合同，從這個時候就進入咱們生產流程，而後要到咱們的審覈團隊去審覈合同，看這個合同的價格，訂價是否是合理，是否是偏高，或者偏低，由於偏高了損害用戶的這個利益，偏低了以後美團要貼錢，因此要去審覈，包括一些法律的東西，是否是合法，一些條款是否是合法，這是審覈，若是審覈不經過，要打回來，從新籤，若是審覈經過了，回到咱們的編輯團隊，那編輯的團隊會幹什麼？

會把合同裏的東西輸成文檔變成文字，變成一個文本的描述，而後還包括編輯的同窗，攝影師的團隊，他們會去每一個商家去拍不少菜品的照片，或者商家門頭的照片等等，還要把這些照片再去剪切，包括打上防僞的美團的水印等等，這些就是咱們編輯團隊原來要作得，他要把全部的這些東西原材料變成一個網上的單子，上了單子以後，先在一個系統裏給商家看，這是我要給用戶展現的東西，這樣行不行？

商家說能夠，咱們就能夠最終給用戶來賣了，那在這個整個的流程，從簽定合同開始，到最後用戶可以看到這個單子，這之間的時間是7到10天，這是一個很是很是長的時間，由於7到10天就能夠對對商家帶來不少不少流量。咱們如今天天的銷售額是幾億人民幣，若是咱們每一個單子都拖到7到10天的話是不可忍受的。

怎麼去優化這個流程？咱們其實作了幾件事情：

業務流程在線化。好比說離線運行的東西。有的編輯的同窗他原本是去籤一個紙質的合同，紙質的合同寄到咱們編審那邊，編審的同窗要去一條一條的讀這個紙質的合同，這個是很難容忍的，這個是沒辦法提高的。咱們首先就把不少的，好比說合同，儘可能在線上來填合同，還有攝影師拍的照片，儘可能直接傳到網上，不要經過一個其餘的渠道，U盤等等來傳。這樣全部的東西在線上了之後，咱們纔有了全部用計算機處理的一個基礎。

O2O數據結構化。舉一個例子，對於一個餐館來講，咱們可能每每會有不少的條款，好比說他這個餐館是幾點到幾點營業，這個單子是幾點到幾點能夠用，用的條件包括你能夠用包間，或者不能夠用包間，以及是否提供停車位，還有一些菜單的東西，這些東西在最初的時候，就是咱們編輯的同窗一條一條對着那個合同把它用手錄成一大段文字，這樣不是結構化的東西。

咱們結構化的努力，就是咱們把每一項條款都變成咱們數據裏的一個結構化的單元，好比說你的這個單子在什麼時間可用，星期幾，幾點幾分到幾點幾分能夠用，這個自己就是一個數據存儲的項目。當結構化以後，銷售上單的時候，它就是一個表單，一個表格這麼填寫，最後生成的數據就不是一大段文字了，而是不少結構化的數據。

這個數據有什麼好處？好比說咱們生成單子的時候，若是要改版，它很容易作一些改版，或者說咱們商家要調整一個價格，就只把價格那個項目給商家來作調整就能夠了。不用擔憂商家改的時候，把一些條款的其餘東西改掉。而後還包括，好比說如今會在PC端和這個移動端同時顯示一樣的單子，其實由於顯示器的差異，咱們在PC端和移動端的顯示確定是不同的。只有當咱們把它結構化以後，咱們才能自動地匹配不一樣的顯示環境，這就是結構化的一個好處。

量化可量化的一切東西。就是價格咱們不但願輸入一個字符串的幾塊錢，由於這個東西計算機是不容易去理解的，咱們但願若是它是數字的，比方說價格，你就填一個價格，若是進價是多少，我賣價是多少，還有可以使用時間，就用時間的格式來填，這樣的好處就是咱們的審覈就變得很是容易。咱們的審覈團隊，它根本不須要人工的去讀這個東西，只要咱們把規則制訂好了，那計算機就能夠把這個量化的東西一條一條地過一下。

圖8上單免審免寫新流程

因此當咱們作了這些努力以後，咱們新的流程變成什麼樣子了呢？銷售團隊一樣仍是要去填合同，可是他填寫一個表格的數據，填寫好後這個表格的數據，系統會自動地審查，自動地生成一個單子，而後馬上能夠給商家作確認，商家確認以後，就能夠上線給用戶了。而後，作了這些努力以後，咱們把中間的不少環節和步驟，包括人力都省掉了，咱們不須要那麼多編輯的同窗，不須要那麼多審覈的同窗，並且整個的流程會走地很是順暢，很是快，便捷。

圖9上單免審免寫收益

給你們看一下收益是什麼呢？這是從今年1月份到9月份的一個數據，藍線是咱們每月的上單量，從今年1月份，除了2月份，2月份由於是春節，整個的上單量有所降低，其他幾個月份上單量一直是很是快速的往上漲的，一直到如今，每月咱們美團上的單子有40多萬單不一樣的消費單，這種單子作一個假設，若是有一個吃喝玩樂的達人，他天天去吃一單美團的單子的，那40萬單夠他吃一千年。

假設咱們這個單子能持續一千年，咱們會提供很是很是豐富的單子給用戶作選擇，上這麼多的單咱們的單均成本，咱們從原來的很高，如今已經降到了個位數。若是咱們沒有作剛纔那些努力的話，咱們是根本不可能實現這麼多的上單量，咱們的成本也不可能降下來。由於咱們把成本壓的很低，就能夠爲商家提供更好的服務，也給用戶提供更好的優惠，這就是技術給咱們帶來的一些優點。

技術如何貫通線上與線下

最後第三點，給你們分享一下，在線上線下這兩部分，技術都是能夠去作的。咱們說O2O，O2O是什麼？就是Online+Offline，線上加線下。有一部分同窗可能會有一些誤解，可能技術只是在線上的，其實不是那樣，技術它不分線上、線下，它在線上線下都是很是重要的，須要貫穿線上線下。我在這裏給你們舉兩個例子，線上的就不舉了，由於技術都是在優化線上的東西。給你們舉兩個例子，看咱們怎麼去用技術來優化線下的一些東西。

圖10原始階段下單方式

第一個就是外賣單子這個流程中，咱們作了一個外賣打印機。先給你們介紹一下背景，美團外賣整個下單是怎麼樣的？好比用戶下單，在咱們的網站上說，我要買一個砂鍋飯，在哪一個餐館買，我要送到什麼地方，咱們就須要通知商家，通知商家的時候，要告訴他用戶要買什麼，他地址是什麼，電話是什麼，而後咱們的商家的廚師去作菜，小二就要去送餐，用戶完成消費。

美團外賣是2013年的11月13號上線的，第一單的時候，咱們怎麼處理呢？那個時候真的很原始，固然咱們一開始仍是作了個手機的APP，用戶在手機的APP上下單，咱們會有美團的外賣的這個同窗，包括一些客服的同窗，也包括一些不少技術的同窗也幫忙打電話，咱們就打電話通知商家說，某某定了一個什麼單子，而後他的地址是什麼，電話是什麼，告訴商家。

商家怎麼辦？就只能用這個紙筆記下來，交給廚師，說你去作飯，廚師作完了，把小紙條給配送的同窗，配送的同窗就去給用戶來送東西，這個裏面過程是很是痛苦的。固然那時候你們作的頗有熱情，很是喜歡打電話，看到咱們有用戶進來，一天從一單十幾單到幾百單，你們打電話打得很興奮。

可是很快發現承受不了，由於打一單，對美團的開銷是說，一單哪怕只須要一分鐘去給商家打電話，幾百單的時候還行。一天一我的8小時工做，哪怕你持續不停的給商家打電話，那一分鐘打一個也就四百多單，你能夠幫用戶定四百多單。可是當這個單子增加很快的時候，咱們就發現咱們人力跟不上了，技術的同窗都去打電話了，技術同窗受不了。

商家也很痛苦，由於打電話的時候，不少的信息是說不許確的，他要記電話號碼，若是記不清的話，他還要再打過來問剛纔那個單子電話是什麼，包括地址，有些地址字還比較難寫。

圖11商家APP階段

咱們爲了解放，首先咱們解放咱們本身，咱們不給商家打電話了，咱們給商家開發一個APP，每一個商家只要安裝了這個APP，他在手機上就能夠接到通知。一旦有用戶下單，APP上就會有通知說誰誰下了一個單，這時候老闆根據APP上的信息，拿張紙，找個筆，把它寫下來，而後給廚師。這個時候你會發現說，至少美團的同窗們這個工做就省下來了。可是商家的工做，他雖然抄得準確一點，不用從電話裏抄，直接從APP上抄，可是仍是要作大量的工做，包括這個小紙條傳來傳去，有的人寫得筆跡不是那麼清楚。

圖12商家APP+聯機打印階段

後來咱們再進一步，咱們APP接到一個打印機上，這個APP有多是一個手機的APP，也有多是電腦上的一個應用程序，這個APP連着打印機，一旦用戶下單，打印機就會打出一個小條來，他拿這個小條，這個信息就很是準確了。商家不用花時間去寫了，這時候就能夠給廚師去作菜，廚師作完了交給配送員去送菜，這個就比較方便了。

後來咱們仍是發現這個也不是很好，通常這個APP老是在老闆那裏的，若是說好幾我的拿着APP會出現問題，好幾我的拿的話，好比老闆和老闆娘都拿着，他們可能都去打，一個定單可能打了兩份；或者說，有時候說老闆拿着這個APP，可是老闆恰好不在，那他就打不了。有的店，他就不得不買一臺電腦放在那，可是電腦對於不少小的外賣店，仍是一筆額外的開銷。由於如今手機上網的多，可是電腦上網的人已經不多了，仍是對商家有不少不方便的地方。

圖13雲打印機階段

今年5月份的時候，咱們的硬件的團隊，他們就說咱們本身來作一個雲打印機。所謂雲打印機就是它本身能夠聯網，聯網的時候有不少聯網的方式，好比說我能夠插一個手機卡，經過手機的網絡來聯網，或者我也能夠經過WiFi來聯網，聯網以後，手機下單的時候，咱們的美團後臺的服務器會把這個單子的信息直接推送到這個雲打印機上，這個雲打印機就像一個POS機那樣，是一個很小的設備，會自動地打印出單子的信息，這樣就大大得解放了咱們美團的同窗和商家的同窗。這是一個咱們用技術來優化商家端這邊的流程的一個例子。

接下來給你們舉一個，咱們怎麼去用技術優化用戶端的例子。咱們在用戶端也有不少線下的工做，其中一個工做就是用戶運營。咱們有一種需求叫「拉新」運營團隊，他們的任務就是對一些已經註冊了美團的賬號，可是過來逛了一圈，最後沒買東西就走了，可能來逛了好幾回，他仍是沒買，這時候美團就急了，美團急了怎麼辦呢？給你10塊錢，你趕忙買一個吧。

由於不少用戶的確是這樣，他沒買多是由於他不知道網上怎麼支付。他支付流程沒作通，或者說他可能就不太習慣，因此咱們但願把這些用戶轉化成一個習慣於在網上消費的用戶，讓他體驗一下，可能體驗一下他以爲好，他能夠之後接着買。給用戶10塊錢，20塊錢，作一些優惠活動，吸引用戶完成首次的購買。那其實咱們這邊的花銷是真金實銀的，咱們是給用戶不少免費，對於美團來講薄利多銷，利很薄，因此咱們但願少花錢，多辦事，這個錢能少給就少給，能不給就不給，運營的團隊，就跟咱們技術的同窗聊，問這個事情能不能優化？

圖14用戶精準運營

咱們就去分析，先去分析這些用戶究竟是什麼樣的用戶，發現用戶有不少類，一類是有一些用戶他雖然來逛了一圈，或者逛了幾圈，他還沒買，可是假以時日，可能再過幾天，最後他仍是會自動的轉化，因此有一些用戶的這種自動轉化的可能性是比較高的。還有一些用戶，他可能來了幾回，他可能每次就是來逛逛，每次逛逛，就像逛街同樣，雖然他不買，可是逛着也很爽，看着菜單他可能口水直流，也以爲挺爽。因此有些用戶，就是你不給他刺激，他就完不成自動的轉化。

而後還有一些用戶質量低，所謂質量低就是對美團的質量，我給他券的時候他就過來買個東西，好比我給他10塊錢，他能夠過來買個11塊錢的東西，而後轉身就跑了，我不給他券，他就半年不過來，美團又忍不住，又給他10塊錢，他又過來看了看買了個9塊錢的東西就走了。對這種用戶不是說質量低，對美團來講固然咱們但願儘可能留住這種薅羊毛式的這種用戶，他來固然咱們也歡迎，可是不來咱們也就不去拉攏了。

還有一些用戶就是，屬於用戶質量比較高的那些用戶，若是咱們一旦幫助他轉化，就是越過了這個首次消費這個坎的話，他可能就成爲一個很高頻的，習慣於在美團消費的用戶，咱們叫高質量用戶。對於美團來講，咱們但願真正運營的對象，真正拉攏的對象就是在這些，我若是不給他刺激，他本身可能轉化不了，而後同時若是他轉化了，他對美團的銷售額的貢獻會比較大。

這種用戶，對其餘三個象限，好比說第一象限裏邊，這部分用戶我不須要給他發券了，發券就是對美團來講浪費錢了，咱們叫浪費，固然也沒浪費。對下面這兩個象限呢，由於用戶自己質量比較低，因此他來和不來至少對美團的最後的獲利來講沒有大的關係，那咱們怎麼去找出這部分用戶？這是運營的同窗給技術團隊提出了一個要求，那咱們怎麼去作呢？

圖15用戶畫像

作用戶畫像，在美團其實有大量的用戶的數據。咱們能夠看到，他何時註冊的美團，他從什麼瀏覽器，從什麼操做系統，而後包括說，他去看了哪些單子，瀏覽了什麼單子，他作了什麼搜索，他用的是什麼手機，這些信息咱們都有。

有大量的數據，那咱們從這些數據裏面就給用戶畫像，咱們會去判斷用戶的各類屬性，這些屬性有一些是，可能用戶在註冊的時候就會告訴咱們了，好比說性別，年齡，包括郵箱，這些可能自己他註冊的時候就會告訴咱們，還有一些是須要咱們去分析，好比說這個是否結婚了，他的職業是什麼，而後包括他的地理位置。

地理位置固然比較好拿，由於不少，如今咱們絕大部分用戶是在手機上的，他一旦在手機上作周邊的這種搜索，咱們就能夠拿到他的地理位置。地理位置的話，咱們就能夠知道，好比說他是一個學校的用戶，是學生，仍是說一個工業園區的一個白領，仍是一個好比金融街的一個比較高大上的一個這個金融界人士。

郵箱也很重要，好比說咱們發現用戶是qq.com的這種用戶，跟gmail.com的用戶，他是兩類不同的用戶，他所關注的東西，感興趣的東西都不同。咱們也會去分析用戶的收入水平和消費水平，收入水平就是咱們可能根據他的職業，根據他的年齡的工做年限去判斷，他是在一個高收入，仍是低收入，而後消費水平相對來講，有可能他雖然收入很高，可是他過來看的單子都是一些好比打折打得很狠，好比吃一頓飯人均20塊錢這種也有。因此收入水平和消費水平咱們是分開來判斷，而後會判斷這個用戶是傾向於最優惠的價格，他仍是講求比較高的質量，就是訂酒店的時候是99塊錢的酒店，仍是說899的五星級酒店等等。

咱們會去作一些分析，咱們根據用戶他瀏覽的歷史，他去看了哪些單子，他去作了什麼搜索，咱們就能夠知道他的品類偏好，他究竟是喜歡美食，仍是喜歡去看電影，仍是喜歡去唱卡拉OK，這些也能夠判斷出來。

再加上一些正常的統計的數據，好比說用戶搜索了多少次了，而後他去瀏覽了多少次，就是來逛街逛了多少次了，他是否是有收藏一些他比較喜歡的一些單子等等，這些不少不少的屬性加起來，咱們就建了用戶畫像的這種數據庫。

而後有了這些屬性，那咱們接到運營同窗的需求的時候，咱們就會對用咱們的用戶畫像裏的數據先作特徵的選擇，作特徵的提取。甚至有一些屬性，好比說年齡這個屬性，咱們會作不少特徵的離散化，就是把一個屬性離散成幾百個，甚至幾萬個這種屬性，放到咱們的機器學習的模型裏面去訓練一些模型。

最後咱們用一些分類模型，好比SVM，就是支持項連機這種機器學習的算法，訓練出的模型，它的準確度相對來講，看起來沒有那麼高，可是效果已經很明顯。沃勒準確率是75%，判斷用戶是否是真的在左上角那個象限裏，準確度75%，召回率能達到68%。有了這個技術支撐，最後咱們運營的單位成本，好比說咱們拉新運營的單位成本就能夠下降35%，總共的拉新運營開支就節省了30%。

因此這個就是咱們在技術，在線下的用戶運營這邊作的一個努力。你們能夠看到剛纔舉了兩個例子，一個是在商家端，一個是在用戶端，其實無論怎麼樣，咱們在線下技術能夠作不少不少的優化，讓咱們線下的效率作不少的提高，那正是全部這些一個一個的優化，加起來就能夠把美團的整個的生產效率提高上去，把咱們的成本降下來，這樣咱們最後的獲利就是美團愈來愈有競爭力。

總結

一、技術架構是要隨着業務的發展而不斷地變化的，不必定一個複雜的的一個完善的架構就是好的，而是看，咱們如今的公司是處在什麼階段，若是是一個初創的公司，那你們仍是要小步快跑，一個簡單有效的方案就好了。

二、咱們是隨着業務發展，在一些開源軟件的技術上不斷的優化，業務流程咱們也不斷的作一些標準化，自動化，剛纔給你們講了四個原則，就是把複雜的東西簡單化，簡單的東西標準化，標準的東西流程化，流程的東西再自動化，這是咱們在業務流程方面的一個優化的原則。

三、技術不只僅對線上有用，在線下的每個操做裏，咱們在不停地看咱們能作一些什麼樣的優化。

最後一句話就是，一個簡單的事情，哪怕像美團這樣，不少人以爲簡單的事情要把它作到極致，就是真正作到極致，也會有足夠多的這種技術挑戰，足夠高的門檻，因此我以爲如今不少O2O的創業的團隊來講，他們作得事情看起來很是簡單，可是隻要你們不斷地優化，不斷地極致，不斷地朝着極致去發展，你就能夠在競爭中勝出。這個就是給你們分享的美團的技術團隊，咱們作的不少的努力。