稍微簡單的描述下這樣圖。該技術棧有三個層次，分别用來實作三個主要的目标。
新使用者（acquisition）
留存 (engagement/retention)
變現 (monetization)
而這三個目标的實作都依賴于最底層也是最核心的第四層：分析和洞見(insight & analytics)。下面就參考mobilegrowthstack對insight&analytics的分析來看看reactnative在這其中能起到什麼樣的作用。
還是覺得有必要将mobilegrowthstack關于這一層的描述翻譯出來。
在web的世界中，一般可以使用浏覽器的cookie來跟蹤使用者，分析其安裝來源，但native apps中跟蹤使用者用的是裝置唯一的id，例如idfa或者android id。因為react native還是需要一個native的殼，是以這一部分和native app是基本一緻的。
ok，deeplink這個詞有點太時髦了，一般我還是習慣把他叫做schema跳轉，從app外跳轉到app内的特定頁面，app内從一個頁面跳轉到另外一個頁面都可以叫做schema跳轉。react native其實在這一方面有非常大的優勢。native app的構造比較複雜，建設完善的schema機制并不是一件容易的事，考慮到現在需求變更的速度，想要保證schema的時效性的确是一件比較頭疼的事情。然而結合native和react native，做一點點微創新，可以讓這一切變得非常美好。因為schema拉起的一般都是一個完整的頁面，我們可以讓這個頁面内包含一個react native的rootview，然後在schema的參數上帶上module的名字，通過這個module在拉起該頁面的時候展示不同的single page app。
其他的比如追蹤schema跳轉的來源、以及其他一些屬性和native都是一樣的，但顯然要簡單的多，畢竟我們現在天生有了module這個屬性來區分不同的頁面，我們所需要維護的，僅僅是一個schema連結，僅此而已。
這裡的事件是比較通用的概念，也許大家更加熟悉的概念就是埋點。埋點就是将使用者的一些操作記錄下來，背景分析使用者的操作，最終通過展台的方式提供給app開發者做決策。react native可以複用native的埋點方式，基本的原理都是一樣的。做過埋點的開發者都知道，埋點是一項極其瑣碎的事情，非常容易出錯，當我們遺漏或者埋錯了點的時候，react native的優勢就發揮出來了，因為可以在發現錯誤之後實時的修改埋點錯誤，讓資料變得準确。這個意義還是非常大的。
這一塊其實跟deeplink和事件追蹤非常相關的，在我們通過活動推廣之前，我們需要知道我們這一次活動的目标是什麼，我們的roi怎麼樣？這都是需要資料分析的，react native除了具備在deeplink和事件追蹤的優勢之外，更重要的是其建構活動的靈活性。因為活動有其特殊性，時效短、變化快，是以目前我們大部分活動都是采用h5來實作的，h5實作的最大弊端就是體驗相比于native會遜色一些，而react native的出現，就是折中了h5的動态性和native的體驗，that's what he borned for。自然react native在這方面優勢很大。
這一塊是native app特有的，app的開發者大多時候都被版本所累。使用者不願更新，最新版本都已經10.0還有使用者在使用1.0，沒有辦法。react native可以很大程度上解決這個問題，因為react native部分依賴于native，是以其并不能完全解決這個問題，但相比于native，那不要好太多，也許我以前的10個版本，我現在兩個版本就可以搞定了。隻要使用者安裝了我們的app，我們就可以一直讓使用者享用最新最好的特性，讓使用者和我們都擺脫更新的煩惱。
搜尋關鍵字對于react native來說也許是個問題。應用市場在某種程度上來說是一個免費的廣告平台，我隻要把我的app放上去，使用者就可以在應用市場上搜尋到，這對開發者來說的免費的曝光，而react native的弱化版本會使得這個優勢丢失，尤其是創業小公司。不過，你依然可以直接用react native的離線包來打造一個新版本app，然後去發版，寫一些新的關鍵詞，沒有人會反對你這麼做的。
使用者分組的概念其實很早就已經有了，最簡單的就是區分付費使用者和非付費使用者，一般來說，針對付費使用者，我們會提供更多的特性或者更爽的體驗。傳統上做這件事主要依賴的還是背景來控制開關，這樣做最大的弊端是，針對新使用者，或者免費使用者，我們需要内置很多他們可能很久以後才會用到，甚至永遠不會用到的特性，導緻包體積變大，而包體積變大這件事兒，會導緻很多不良的影響。那我自己來說，16g的機器一旦空間不夠，那哪些不太常用的app總是我删除的首選。使用react native的好處就在于，對于目前使用者用不到的feature，我不用内置代碼，我可以讓新使用者已非常小的代價下載下傳app，然後再他使用的過程中逐漸的更新其app，讓其能享用更多的特性。目前這一切的前提是背景需要對使用者有足夠的資訊，能夠支援做這樣的決策。
對不同的使用者進行分組，超越總使用者、mau、dau等資料去對使用者進行細粒度的分析主要依賴的是背景的資料分析，無論什麼web、native還是react native都是一樣的。
again, react native提供動态化的内容更容易。
客戶滿意度很重要，因為很可能有意見領袖在使用，一言不合直接就将app搞死在萌芽狀态也不是不可能。是以使用者滿意度調查是件挺重要的事情，讓app在應用市場的評論數和分數都提升是件很重要的事情。react native可以在特定時候通過自定義的popup，讓使用者參與滿意度調查，并進一步引導其到appstore評論。這裡和native最大的不同在于，該popup中顯示的是可以實時更新的内容，想怎麼變就怎麼變，接近h5的表現，卻擁有native的體驗。在有新特性和内容的時候，可以更好的引導使用者回報。
在項目早期，找真人測試原型或者在雛形初現的時候找真人現場體驗回報。這個native、web還是react native其實并無多大差別。
a/b testing對于grouth的作用是毋庸置疑的，甚至可以說是最重要的一部分。想要做好a/b testing是一件很困難的事情。使用者的分組是否合理、衡量的名額是否合理、如何制定a/b test方案等等都會影響結果，甚至影響使用者體驗。
a/b testing最傳統的方式可能就是背景控制開關，針對a使用者開啟a特性的開關，針對b使用者開啟b特性的開關，所有的a/b testing都必須預先規劃好，然後發版，然後測試，再統計結果。這個流程是非常非常長的，尤其是ios，經過稽核上架再到使用者更新，可能2周就過去，這個是非常不靈活的。react native能在這方面提供非常好的幫助，因為其動态性，分分鐘就把一個頁面改了。結合背景的使用者分組，能非常快的試錯。react native簡直可以說是a/b testing的不二之選，快速試錯，快速響應。
native的app跟蹤界面流主要是在界面出現的時候埋點，界面銷毀的時候再埋一個點，然而因為native的實作的多樣性，想要跟蹤完整的界面流是比較麻煩的。遺憾的是，react native雖然有schema機制，能應對大部分的界面跳轉，但其還是存在很多不能解決的界面跳轉問題，因實作而已。
這個在growth中還是很有名的，可以根據關鍵路徑建立各式各樣的漏鬥，來優化使用者留存和體驗。
無論做什麼，對錢一定要敏感而且有良好記錄，要不然總有一天你會死定的。
将團隊内對growth的認知模型化，這樣才能傳承，才能不斷的優化。
ltv是對一個使用者終生能對app産生多少價值的模組化。相當于貼現計算。
growth模組化是為了預見未來，而growth統計則是為當下和曆史的資料的總結。比如
<code>活躍使用者 = 新使用者 + 反複出現的使用者 - 某段時間内上線的使用者</code>
對cpu、battery、network以及crash等等的性能跟蹤是非常重要的，尤其是對于移動端的使用者來說。其實這裡面native和react native是各有利弊的。比如native無論是在cpu、battery還是在memory上都是有一定的優勢的，但react native在crash上有一定的優勢，因為其大部分異常都會在js層面被捕獲，僅僅導緻該頁面不能使用，而不會導緻整個app不能使用。
兩句話：
如果你已經在使用react native，那麼還猶豫什麼，趕緊落地growth，做真正的growth hacker。
如果你想嘗試落地growth，那麼還猶豫什麼，趕緊嘗試使用react native。
<a href="http://www.mobilegrowthstack.com/the-mobile-growth-stack/">what is the mobile growth stack?</a>
<a href="http://www.anzhibao.com/appxinwen/42417.html">網際網路營銷和分析專用名詞速覽安利</a>
![Android中Webview使用經驗總結[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)