網路公司的工程師或視覺設計師，在公司最怕公司高層宣布一件事：「這個月我們要來大改版」。
如果公司宣布這件事，往往就是預告著公司三個月後的「第二版」上線後，大離職潮的開始。
為什麼要大改版？
需要大改版的原因，往往是以下幾個原因：
- 原先網站太醜
- 原先網站動線不良，有太多結構性問題
- 交易成功率很低，而老闆覺得是「視覺設計」上的問題。
為什麼工程團隊最恨聽到大改版，以及大改版後會有離職潮。通常是因為在改版過程中每個團隊不可避免的照順序會發生這幾件事：
- 因為美、醜、動線的主觀性，所有同事大內戰，戰成一團。
- 內戰過後，最後只產生一個結論：由 PM 主持公道（a.k.a 都他來規劃，大家不要吵）。但是把最後決定權交給他，通常也等於把 deadline 交給他。於是這個大改版就會出現一個完全不切實際的上線日。
- 大家因為這個上線日瘋狂的加班，爆肝撐到終於上線。結果，原先舊的客戶用得非常不順手，信箱內客訴一大堆。但是，原先期待上漲的交易量也跌的更誇張，老闆震怒。但大家實在不想改版第三次。
- 因為大改版，所以網站內有些好用的舊功能，或者是 workflow，消失或爛掉了（當初沒辦法寫 Integration Test 或根本沒時間寫 Test，或寫 Test 也阻擋不了因為 UX 的改變造成的動線問題）。工程團隊忙著修理或 Revert 成原來的動線。
- 最後工程團隊又累又沒成就感又被眾人指責，憤而離職。
所以大家非常痛恨「改版」。
今天這篇文章就是要從 GrowthHack 的角度與手段分享，如何「無痛」的改版。
第一件事：找出關心的產品指標
為什麼要改版？改版說穿了就是希望產品能夠「更好」。
既然是「想更好」，那麼第一件事就是要精確的定義什麼叫做「好」。
產品的服務交易成交量低，那需要改善的地方到底是什麼？
- 你的產品多半是服務一次性客戶，所以想改善的是 Signup Rate 嗎？
- 產品 Signup Rate 很好，但是再買第二項產品的機率很低，所以你想改善的是 Retention Rate？
- 產品回購率可能還不錯，但是回購間隔非常的長，所以想改善的是購買頻率？
- 客戶看到商品往往都加到購物車了，但是購物車 abandon 率高達九成？
如果你想要改版產品，首先必須知道你想要「改善」改什麼。改版絕不不是「請美術新出幾張圖」，就叫改版。
想要改善產品，必須先知道究竟想改進什麼「過低的指標」。
第二件事：建立該指標的行為量測，建立 Funnel
很多做網商的人，很喜歡大談 Conversion Rate Optimization。
每次改版就嚷嚷我們要改善「Conversion Rate」，然後根據網路上搜到的一些懶人包，提出一些天馬行空的改進建議，這些 tips 有時候有效，有時候一點都沒效，還會造成工程團隊的困擾。
「交易成功率」不等於「轉換率」
傳統大家喜歡談的 Conversion Rate 其實講的是「交易成功率」，而不是「轉換率」。
轉換率的定義：在 Funnel 的想法中， A -> B ，B -> C，C -> D，每一個狀態的改變，都算「轉換率」。
比如說註冊量低，我們要改善註冊步驟。
註冊步驟分為
- 從 FB 進到首頁
- 從首頁進到註冊頁
- 註冊頁填完資料進到帳戶 Dashboard
比如說商品成交量低，我們要改善購物流程
購物步驟分為
- 從 Line 進到商品頁
- 從商品頁挑選商品進購物車
- 從購物車頁進到結帳頁
- 從結帳頁填寫地址到付款頁
- 從付款頁到見到交易訊息
很多人會誤認為轉換率就是「註冊數量」以及「購買商品量」。
事實上 Conversion Rate Optimization 談的是，從 1->2,2->3,3->4,4->5 的每一個步驟的優化。
客戶沒有辦法完成交易的原因很多。有可能是
- 加入購物車的按鈕設計的很不好
- 填寫地址的動線很爛，填一填就火大了不想填
- 結帳頁沒有 HTTPS
- 結帳頁看起來就像詐騙集團的頁面
- 看到總金額，突然覺得這個月太花錢了臨時冷靜
如果想要「修」好壞掉的數據，應該確實找出壞掉的部分修好它，比如說 2->3 是好的，3->4 是壞的。
但傳統的「大改版下」，往往是在不明就底的情況下把 2,3,4,5 全改了。
3->4 沒修好不打緊，結果連當初沒壞的 2->3 都壞了，交易量反而下跌是很正常的事。
前端工程師不應該寫 Integration test 而是應該改關心 Funnel 漲跌數據
前端工程師對於改版最頭痛的地方是，Integration test 不好寫，而且改版通常還會牽扯到 CSS 與動線，這個部分幾乎大家不知道測試的尺度要拿捏到哪裡。
Well，我建議前端工程師應該關心的是 Funnel 轉換率的漲跌數據。
因為，「改版」的目的是希望「交易成功率」上升，而不是程式表面上的正確與否。「程式」就算沒有 bug，那也只表示程式設計「正確」，並不代表「程式設計正確的達成或改善目的」。
所以，改版應該關心的是 Funnel 的漲跌數據，Funnel 跌再去處理，比花大把時間寫 Integration test 有意義的多。（通常 Funnel 跌也可以順帶的知道程式爆炸了）
第三件事：一次只改一個部分，並 run A/B testing
前面提及的改版重點：
- 不要大改版
- 建立量測數據，找到哪個指標嚴重偏低
- 掛上量測工具，抓出整個流程步驟間所有的轉換率，抓懷疑病因
所以產品改版必須是小規模的針對性的修，而不是 big bang 式的改版。
接下來這段想談的是實務上「如何實作改版」：
改版通常牽扯到主觀的辯論（除非團隊內有壓倒性的強者），否則最後結論通常最後會有兩三份，再根據誰說話比較大聲，或鹽吃比較多，最後採納他的方案。
但是很多時候，UX 動線是很多天時地利人和的一個巧妙組合，未必這個技巧在 A 網站 work，就會在 B 網站 work。
也未必 C 醜 D 美，D 的轉換率就會比 C 高，可能 C 雖然醜，轉換率卻比 D 整整高了 20%。
所以務必 run A/B Testing。分配實驗比例，確保工程團隊沒有真的因為改版，一瞬間把交易量全滅了。
說得很好聽，如何實行？
有朋友跟我說，xdite，我覺得你現在產品 Tunning 理論最近講的都超漂亮，但是好像不是在矽谷根本做不到，要建這些工具與耗用人力，我們團隊根本負擔不起。
Well，這些技巧其實都不是外星科技，市面上已經都有第三方工具可以快速且容易的實作。
- Chartio 強大的 Query 工具，可以透過簡單的介面或手刻 SQL，拉出團隊關心的指標與數據。
- Mixpanel Funnel 量測工具，透過 event-based 觀測 funnel 轉換率的超強工具，也內建 messaging 與 profile history。
- Optimizely，強大的 A/B Testing 工具，只要有簡單的 jQuery 技巧就可以在網站上改得亂七八糟。可以隨機分配流量追蹤指標。未來還會推出個人化，鎖定具特定消費行為的使用者做 A/B deal testing。
- Geckoboard 之前我在做產品時，一次要盯幾十樣數據，確保今天的 deploy 不會無意中把某 funnel 炸得亂七八糟，還要確保不會發生爆炸了，五天後我才知道的事。我沒有辦法一次在 mixpanl 追蹤這麼多指標，所以我透過 geckboard 拉 mixpanel 去顯示我關心的數據，並且可以更細的針對前一天，每一週的數據去對比決策是否錯誤。
所以做這件事並沒有那麼難，只是需要多加一點功。
Summary : After having growth mind
要說我覺得從學會 growth hack 技巧後，心態上最大的轉變與感想是：
我覺得以「產品交易成功率」的產品改進策略，把軟體開發中的僵持難局，最後一哩路上的缺口都拼起來了。
軟體開發中最常出現的幾個膠著難題：
- 專案管理中的角色切分權責大戰
- UI 與 UX 的最終定案權
- Testing 的顆粒度
都在這樣的模型中，有了很好很實際的解答。
我推薦各位也以這樣的角度，去重新審視產品開發的每一環，我相信你可以突然之間就發現一大塊新的天地。