網路時代的服務都該內建A/B測試

最近讀到一篇報導《柯文哲網路競選策略大揭密 (1)：官網流程改版，成功募 3,000 萬競選經費》，提到甫當選的臺北市市長柯文哲網站透過收集數據，不僅提高網站的到訪人數，也增加了到訪者點擊網頁的頁數，甚至還提高了捐款成功的轉換率，其中轉換率的提高，甚至提高到原來的 5.5 倍，而線上所募集得來的捐款總金額也超過了三千萬元。柯文哲這次在台北市長選戰中獲勝，其團隊高度倚賴網路宣傳甚至募款的方式，被視為是一個新的模式。

應用技術性流量成長工程的方式相當普遍，目的是為了提升網站服務規模

在這篇報導裡，提到其團隊分析所收集得來的使用者行為資料，透過改善網站操作流程、甚至是介面的規畫調整，來達到上述的效果。而現在，這常常是透過所謂「技術性流量成長工程（Growth Hacking）」的方法來達到。

針對不同的產品或服務，Growth Hacking所設定的目標可能不盡相同，從量化的目標來看，有可能是要增加回頭率或轉換率等。而Growth Hacking就是透過操作動線、文案、甚至例如操作介面上按鈕的位置、大小顏色、……等等，都有可能對於這些成長的指標有所幫助，甚至讓網站的規模或營收，完全進到另一個不同的境界。

例如，不論是 Facebook 或Twitter 在成長時，都曾經遭遇到過瓶頸，但是透過Growth Hacking的方法，想出了突破的方式，接著又持續成長了。

因此，對現在的網路服務或產品來說，為了追求不斷的成長，以及獲取更多的營收，Growth Hacking早已成為一門顯學。有些公司甚至有專門的Growth Hacking Team的團隊，或Growth Hacker的職位，專門職司於此一工作。

從觀察記錄、歸納現象、找出問題、推論原因、到設計改善方案這整個過程，都是Growth Hacking所關心的，但是在設計改善方案之後，要怎麼驗證改善方案的效果呢？如果直接修改線上系統，那麼倘若改善方案的確較好也就罷了，若是實施改善方案後反而變差，那不就形同冒然推出一個較差的版本給使用者了？

以A/B Testing來實驗適合的應用模式，協助找出最佳設計

因此，在實驗新的方案時，常常會採用所謂A/B Testing的方式來進行。什麼是A/B Testing呢？所謂的A/B Testing是一種隨機式的實驗，在這種實驗裡，隨機的實驗對象透過控制變因及操縱變因將它們區分為 A 與 B 兩組。憑藉著 A/B Testing 來測試新方案時，也就是一組套用原先的方式，即對照組，而另一組則套用新的方案，即實驗組。

以 Facebook 來說，他們有專門的 Growth Hacking Team，而在做介面的調整時，也會做 A/B Testing，讓少部份的使用者可以先套用新的方案，即做為實驗組的組成，而其他的人則維持原方案不動，做為對照組。

實驗進行一段時間之後，就可以觀察針對兩組對象所收集到的數據，並且進行分析比較，判斷實驗組是否優於對照組，倘若是，則初步可驗證新方案可優於原方案。之後，可以逐步推廣到更多的使用者並持續觀察，或甚至是全面套用所有使用者。

透過這種方式，讓數字說話、讓對使用者介面的設計不致於流於空想，而可以透過實驗的手段來驗證。有了這種方法，盡可能讓每一次的改進都對想要的營運指標像是回客率或是轉換率帶來增長，如此，便有機會持續成長。

不光是使用者介面及使用者體驗的部份可以透過 A/B Testing 的方式來持續改善，有些系統有些功能，像是需要用到演算法的功能，在調整演算法時，也可以使用 A/B Testing 的概念，挑出部份使用者，允許他們套用新的演算法，最後透過實證的數據來評估演算法是否有所改進，或是達到目標。

因此，實施 A/B Testing，可以說是現代網路服務或產品不可或缺的一環。因為服務或產品足以支持變化快速，也更利於透過持續精進，而能更快探索出使用者的真實需求，或導引使用者的行為更趨近服務的營運目標。

在規畫應用系統的階段，納入A/B Testing

既是如此，當我們在規畫設計系統的技術架構時，是否應將上線營運後的 A/B Testing 需求，予以考量在內？也就是說，我們當然也可以把每次要做 A/B Testing 的事情，都寫死（hardcode）在程式裡，也就很局限地只針對當下要做的測試來寫。

但，倘若我們我們可以為 A/B Testing 的需求建立一個更通用性質的子系統，那麼就可以在每次需要做測試時，直接運用此一系統，避免了每次都寫死的問題，也可以用更短的時間來完成測試。

若是試著考量這樣的一個子系統，它需要有那些功能呢？

首先，是記錄使用者的操作動態，最起碼需要記錄使用者在不同的畫面間的移動路徑，以及相關的時間參數。例如，在某畫面停車了 10 秒鐘後，按下了某個按鈕，進到了另一個畫面。有了這樣的系統，就可以進一步發展後臺的分析系統，像是產生報表或是圖表之類的功能，但這不見得是必須的，視實際的情況而定。

以上都只是做為記錄和分析的功能，針對 A/B Testing，最重要的是：（1）系統要有能力，隨機挑出從所有的使用者、或滿足某個條件的一群使用者中，將他們個別分至 A 組或 B 組並且記錄下來；（2）系統要有能力，在特定的操作介面上，分別為被分到 A 組及 B 組的使用者，呈現不同的介面，或甚至套用不同的功能、演算法。

然而，這並不是一件容易做到的事情。

我相信有些做 A/B Testing 的團隊，不見得倚賴一個通用性質的框架、以設定的方式來達到區分 A、B 兩組人所見到的畫面、操作流程或功能。不過，在坊間，其實你也可以找到一些現成的 A/B Testing 工具。

而以 Facebook的網站平臺而言，他們甚至有一個名為PlanOut的框架，供你進行規畫線上欄位的實驗。在 PlanOut 裡，還包括了一組 DSL（Domain Specific Language）供你用高階語言的形式來描述。

在網站以外的平臺導入A/B Testing，所面臨的狀況可能有所不同

我相信在純網站形式的服務，要做 A/B Testing 簡單一些，一來是現成的工具比較多，二來，針對 A、B 兩版的功能改變，只要伺服器端線上部署即可完成。但若是像現在行動裝置上的原生 App，每次要做 A/B Testing 時，很有可能就得重新部署一次原生的程式碼，並且安裝到使用者的裝置上。

若是像 Google Play 這類上架速度快的市集，也就罷了，頂多帶來頻繁的改版，但是，對於像審核時間較久的 iOS AppStore 上的 App 來說，就較難以支持頻繁的改版。因此，你在規畫原生 App 時，必須考量日後若要進行 A/B Testing 時，在技術框架上應如何支持。

總的來說，A/B Testing 是網路服務或產品在探索成長關鍵因素時相當倚賴的工具，而這個活動會反覆不斷地持續進行，為了支持 A/B Testing 更容易進行，在技術端也需要在規畫設計時，予以考量進去，最好是一個足夠通用的子系統，足以滿足日後大部份的需要。這個通用性的架構，不見得容易放諸四海皆準，但是起碼針對特定的應用，可以減少寫死程式碼的機會。