Agile Summit — Agile UX消費管道入口A/B Testing實戰分享

http://summit.ithome.com.tw/agile/#agenda

這篇文章記錄了我在敏捷高峰會(Agile Summit)中演講的內容,著眼於A/B Testing的實戰經驗分享。準備這場演講的過程,我一直在取捨,因為講我們公司實際的案例,一般聽眾不一定有興趣,但如果只是單純講理論而不講實作,又怕人聽起來有空虛的感覺。所以我在設計演講內容的時候,希望可以把理論和實際有比較緊密的結合,透過一個實際在線上運行的案例當作主角,希望聽眾可以在聽完之後可以馬上運用。

這篇文章會分為兩大部分

  1. Agile UX與A/B Testing實驗須知
  2. 實戰分享(文章最後有附slideshare上的連結)

1.Agile UX與A/B Testing的背景知識

Agile UX

在進行使用者體驗UX(User Experience)研究的過程中,加入Agile的概念,如下圖所示,我們需要加速產品設計前期的準備,在不影響使用者體驗的前提之下,可以把UX的過程分割成「設計」、「建造」、「上線」、「調整」,「再進行測試」。值得注意的是,實驗的過程將會是一個迭代循環的過程。

https://www.agriya.com/blog/lean-ux-vs-agile-ux-shift-working-methodology/

UX與Dev的合作流程分配

在下面這個例子,UX的sprint會比Dev(程式開發)再提前一個衝刺的時間,並在UX sprint1做完後,馬上給Dev進行開發,開發完成上線之後,蒐集相關的資料,再把這些資料回饋給UX sprint 2,持續反覆不斷地演進。

https://www.nngroup.com/articles/doing-ux-agile-world/

進行A/B Testing資源耗費吃重

先前看過很多Google或是Airbnb在網站設計A/B Testing的分享內容,常見的問題是,即使自認為擁有完整的A/B Testing知識,但自身的公司也不一定有足夠的資源去確實執行一套完整的驗證。個人認為主要的原因是A/B Testing的本身,不只牽涉到設計師要做出不同版本的網頁設計,開發端RD也要同時製作多個版本(這邊已經牽涉到PM能否安排好足夠的資源讓RD開發,以及QA testing的部分)。除此之外,還需要有人先定義好要追蹤哪些數據,進而請RD埋追蹤碼,去追縱測試的結果。

在前面的步驟中,商業目標設定、網站設計、程式開發、部署上線完成後,還需要資料科學家蒐集所有數據,去分析數據背後的意涵,彙整好這些洞見呈現給老闆,再決定下一步要如何進行。以上述的分工而言,需要一名UI/UX設計師、一名RD、一名QA、一名PM、一名資料科學家,一名老闆,少說也要6個人才能把一次的A/B Testing做完。聽起來是否有些氣餒?

沒關係,還是先看下去,至少在這裡的分享中,看到我們踩過的坑,大家能少走一些冤枉路。

Designing with Data 提供了Data Driven開發的方向

博客來買

在Designing with Data 這本書中提到了以下幾點,或許可以當作大家在執行A/B Testing時,有個可以依循的原則

a.了解數據、商業以及設計之間的關係
b.找到可以做基底的資料,以及進行A/B Testing的運作方式
c.使用實驗的框架來幫助我們收斂實驗結果
d.建立可以與績效指標連結的假設
e.解釋測驗的結果並決定下一步要做什麼

a. 了解數據、商業以及設計之間的關係

以終為始,在開始進行A/B Testing之前,最重要的是了解自己想要達成什麼目標?這並不容易,一個可行的做法是先把自己當作一位用戶,然後從目前公司既有的接觸管道進入自家的產品,透過使用者行為漏斗,進一步去了解產品到商業間是怎麼連結的?

舉個例子,像我在這次的演講中提到,希平方有一部分的潛在用戶是透過使用者學習的心得接觸到我們的產品,在心得文中,潛在用戶看到分享心得的學員學習英文的困擾,而攻其不背產品能幫這些學員解決什麼問題?進而產生同理心,想要前往了解課程方案的念頭。在這樣的使用者行為漏斗中,我們可以去了解該如何規劃這個網頁(文案的編排形式、Call To Action(CTA)的安排、延伸閱讀的安排),設定我們的商業目標(點擊了解課程方案、到體驗專區了解課程進行方式),以及預期在過程中需要什麼樣的數據來進行驗證。

在另外一場鄭雅中老師佛系設計的演講中有提到,公司的業務明明是做旅遊資訊網站,卻因為老闆與公司外部的朋友聊天之後,覺得線上訂餐應該也很重要,就要求設計師把訂餐的功能加入到網站內,結果讓所有員工都一頭霧水。結論是,即使是老闆,也不一定每次做決定時,皆可前往對的方向,因此,員工需適時提出建議,有助老闆導回正軌。

了解如何在數據、商業及設計之間取得良好的關係,將會是開始著手進行A/B Testing前一個很重要的準備。

b. 找到可以做基底的資料,以及需要進行A/B Testing的元件

在還沒做A/B Testing前,為何舊版本的網頁要這樣設計?背後是否有任何學理的依據?或是個人直覺的經驗?

直白地說,任何一個新創公司,產品剛上線時,除非有位富爸爸,否則很難有機會執行完整的使用者研究、用戶訪談、脈絡分析、到真正上線、進行A/B Testing。大部分的新創公司,起初都是創辦人想要解決一個與自身相關的問題,接著去設計一個「自己」認為可以解決使用者問題的服務。這樣的方式,如果前提是「這個問題是實際的問題」,那麼解決方案本身是否能打到使用者的痛點,才是最重要的。等到公司的業務穩定了,開始有資源進行下一步的產品開發,才有可能進行完整的使用者研究(A/B Testing)。

因此,在開始進行A/B Testing前,首要先去了解原先設計時的想法。每家公司業務的不同,設計產品的考量也會不同,找到基底的資料,充分的了解之後,再進行A/B Testing的設計,通常可以減少很多阻力。

c. 使用實驗的框架來幫助我們收斂實驗結果

From Designing with Data ,O’REILLY pp.212 Fig. 6–2

實驗的框架,可以讓我們在進行A/B Testing的過程中,了解自己所處的位置。如上圖,一開始先決定在這次實驗中最小可偵測出來的結果是什麼?接著便可以開始規劃實驗測試的內容。

在實驗的過程中要去決定測試樣本的大小,及想要多少的信心水平(信心水平越高,所需測試的樣本數就會更大,這部分牽涉到公司願意花費多少資源,去取得測試的樣本。)

決定樣本數大小後,再區分上線之後有多少比例的使用者會用到測試版的網站,如果像FB或是Airbnb這樣大的網站,可能剛開始3~5%的使用者就已足夠。在台灣的話,可能需提高到10%~20%,才能達到足夠的樣本數。除了多少比例的使用者可以用到測試版的網站之外,還有「時間」這個參數可以利用,需要測試多長的時間?也會決定這個測試品質的好壞。值得注意的是,測試期間不能有其他的變數(例如:一個版本是在促銷案期間,另外一個版本是在非促銷期,因為促銷本身就是一個變數,即使其他參數都保持一致,這樣測試的結果還是不足以信賴。)最後則是需要進行多少次的測試,才能驗證一個想法。

d. 建立可以與績效指標(Metrics)連結的假設

常見的績效指標可以分成三種

  • Key metric : 主要的商業指標
  • Proxy metric : 替代指標
  • Secondary metric : 除了主要指標之外,我們也可以藉由一些次要指標去評估改變的過程是否影響到使用者的行為。

找到關鍵指標(Key metric),並且把這個指標與最後的商業目的做連結是最重要的。比如說:遊戲業會很重視留存率,那7天之內的「留存率」就是關鍵指標。若是線上課程,那可能「完課率」就是一個值得關注的點。若是電子商務,則「回購率」絕對是老闆注意的點。

但有時候關鍵指標並不能在幾天之內就顯現出結果,比如線上課程Coursera的關鍵指標,原本是學員購買證書和完成課程的比例,但上述這兩個指標,都是要等學員快上完課才會發生的結果。線上課程的學習時間,短則1個月,長則要3~4個月才可能上完,要一個新創公司等3~4個月才看得到測試結果,可行性實在不高。因此,Coursera把指標進一步拆成:學員課程單元的完成率、小考成績以及對課程問答的參與度,作為預測的關鍵指標,這些指標可視為替代指標(Proxy metric)。

在實驗結束之後,我們需要觀察的是,到底實驗最初所建立的假設,能否在數據中得到印證?比如說,這次演講中提到的心得文實驗,我們一開始假設在同樣的CTA按鈕下,上色的文章內容型式會比簡潔有組織的內容型式,讓人更想要去點擊。但我們能否在實驗的數據中找到對這個假設支持的數據?在上面這個例子之之中,CTA的conversion rate就會是主要指標,而改變文章的內容型式,是否會影響使用者閱讀的行為?(例如是否有滾動閱讀的行為,閱讀文章到30%、60%、90%的長度),則都可算是次要指標。

e. 解釋測驗的結果並決定下一步要做什麼?

測驗的結果有可能會不如我們原先所預期,但看到結果之後,可以先想想實驗最重要的關鍵指標是什麼?如果該指標仍可在實驗的結果找到答案,就不用太灰心!

通常實驗的過程,不會是一次就搞定。像我這次演講過程中舉的例子,次要指標在不同階段的實驗中,數據結果有小幅度的變動,但我們知道該階段的實驗重點不在次要指標的變化,所以我們就忽略部分不符合預期的結果,專注在關鍵指標,繼續進行下一次的實驗。

2.實戰分享

在進入這次的A/B Testing實戰分享之前,我稍微介紹一下這個實戰的背景。我目前在希平方科技服務,我們主要的產品攻其不背是一套線上英語學習的系統。攻其不背最大的特色就是主打「學英文不用背」。原因是我們把學英文過程中,最難的「複習」做到APP之中,透過多次的複習,學英文不用在靠自己死記硬背。

消費者與我們接觸的其中一個管道,是當他在FB上面可以看到我們創辦人分享的學英文心得,點擊這篇心得文,進到我們的網站,看到更多學英文的秘訣。稍微整理一下這個消費管道的入口漏斗圖,將如下圖所示。我們主要的商業目標,是希望提升使用者從心得頁面(Sharing Articles)點擊進到課程方案頁面(Course Price Page)的轉換率。

消費管道入口漏斗圖

因此,使用者心得頁面設計的好壞(包括網頁設計、文案設計),將會決定該頁的轉換率。使用者心得頁面會長的像下面這篇文章

為了提升這個頁面的轉換率,我們想到兩個問題:

  • 文案的設計樣式(上色、型式)是否會影響潛在用戶的閱讀行為?
  • 潛在用戶是否會因為CTA按鈕的設計及顏色的不同,而產生點擊的行為?

接著我們做了不同的假設,

針對文案的形式

  • 根據舊版的文章投放廣告的經驗,上色文案的設計樣式更加親民,容易吸引潛在用戶點擊。

針對CTA的按鈕顏色,我們假設

  • 潛在用戶會因為紅色的按鈕,提升點擊的動力,增加頁面之間的轉換率。

有了這兩個假設,我們就要想辦法設計實驗去印證這兩個假設是否正確。

實驗目標

相較於一般大公司針對小部分的設計樣式進行A/B Testing,個人認為這次分享的實戰經驗,其實是一種多參數的測試(Multivariate testing)。多數新創公司,或是大公司裡面的新創團隊都會有資源不足的問題,沒有那麼多的資源去拆分實驗,一個一個設計,並且規劃好開發的流程,進而得到最後想要知道的答案。

實際上,我們希望在越短的時間之內,得到越多有效的實驗成果,並且得出有用的insight,進而提供老闆建議,讓我們可以進行下一階段的開發。演講至此,我引用「發明大王」愛迪生的名言:

真正衡量成功的標準是,你能在24小時內塞進多少次的實驗
http://www.azquotes.com/quote/530630

整個實驗的過程,分成三個階段,每一階段結束之後,我們進行回顧討論,透過分析師將實驗的數據整理,得到insight,接著進行下一階段的動作。

實驗對象及項目

第一階段實驗開跑
實驗對象及條件限制:
測試時間:一天
目標對象:1~65歲 FB使用者 男女都有

實驗種類:
我們可以用下面這張圖,比較不同Layout下,使用者行為的差異,
進而判別哪一個版面較受使用者喜愛。

A:原始文案型式設計,綠色CTA按鈕
B:原始文案型式設計,紅色CTA按鈕
C:新版文案型式設計,紅色CTA按鈕

測試項目Layout圖示

接著我們要嘗試思考哪些參數可以真正代表使用者的行為,並將那些行為描述出來,例如:

  1. 閱讀瀏覽的行為:包括沒有滑動過就離開、或者滑過一次後離開、滑動過程中在整個網頁長度的多少比例(30%、60%、90%)
  2. 延伸閱讀的點擊行為
  3. 前往了解課程方案(CTA)

第一階段結果揭曉

在第一階段實驗過後,我們該如何進行下一步?透過下圖可以解釋:在Experiment 1之中,若已經驗證出結果的假設:Hypothesis 1中的Test Cell A~D及Hypothesis 2中的Test Cell A,對實驗結果沒有影響。若要進行Experiment 2,上述Test Cell都不需要進行測試了。

回到演講中的例子,我們假設:

  • 潛在用戶會因為紅色的按鈕,提升點擊的動力,增加頁面之間的轉換率。

實際的結果,我們發現,不管是B版本或是C版本,最後的CTA表現都來得比A版本來得好,因此我們可以不用再考慮A版本綠色按鈕的CTA,而只要專注在這次的實驗之中,無法驗證假設的部分。

Designing with Data:實驗的過程,已經得到驗證的假設,在下次的實驗之中,就可以不必再重複進行

然而,第一階段(Round 1)實驗的結果也不是那麼順利,尤其是在我們關注的CTA按鈕之轉換率上,看到如下圖所示矛盾的現象:針對「前往購買頁」的轉換率,同樣的CTA按鈕型式設計,PC版的版本C>版本B,Mobile版的版本F>版本G。我們預期在文案設計的形式上,如果原版設計(有上色)比較好的話,那應該PC版和手機版的轉換率要一致才對。這是第一個引發我們想進行下次實驗的因素。另外,在「閱讀瀏覽行為」的P-value這個部分,我們計算出0.0571的數值,這個數值不到學理上0.05的水平。P-Value是用來衡量實驗假說的顯著性,我們預設想要達到0.01的P-Value,這個目標在第一階段是沒有做到,因此需要進行樣本數更多的實驗,來驗證這件事。有鑒於前述兩點,我們建議上級,進行下階段的實驗。

前往購買頁轉換率,因轉換率涉及商業機密,這邊已A%當作基本單位進行表示

第一階段的實驗到此告一個段落,但是要進行第二階段的實驗之前,我又再次請發明大王愛迪生跟我們說句話:

人們最大的弱點在於放棄,最能夠成功的方式,就是再試一次

第二階段實驗開跑
實驗對象及條件限制:
測試時間:1個月
目標對象:1~65歲 FB使用者 男女都有

第二階段實驗結果:

為了驗證第一階段(Round 1)實驗結果,我們增加測驗時間,增加樣本數,讓P-Value達到0.01的信心水平。在這個階段,得到實驗結果之後,我們又發現一個新的問題,如下圖,「滑動90%」這個參數在第二階段(Round 2)的實驗之中,PC版本變差了14%~17%,Mobile版本表現也變差3%~5%,這又造成我們的困擾,到底是否要針對這個部分進行下一次的實驗?

第一階段與第二階段閱讀瀏覽行為關注參數:『滑動90%』

回到我一開始說的,在實驗的過程中,我們需要把焦點聚焦在關鍵指標(Key metric)。所以觀察下圖的「前往購買頁」轉換率,發現當樣本數增加,可以解決第一階段實驗中遇到的PC版本和Mobile版本間轉換率不一致的現象(第二階段不管是PC版本或是Mobile版本的轉換率都是相近的)。由此判斷,既然主要商業指標的改善已經滿足這次實驗的目標,因次認定已經完成這個階段的任務。

主要商業指標「前往購買頁」轉換率,這邊以A%當作基礎轉換率進行表示

第二階段實驗結束,我們討論之後作出決定,將「B:原始文案型式設計,紅色CTA按鈕」的網頁正式上線。這部分是商業上的考量,原因是如果要進行整個網站的文案型式設計變更成「C:新版文案型式設計,紅色CTA按鈕」,可能還要多花1~2個月的時間,修改上百篇學習心得的文案型式。透過前兩次的實驗結果,我們已經知道CTA按鈕的轉換率已經改善,於是決定把這個版本上線,直接進行驗證。

上線後的文章版本CTA改善率

相對於原始的版本,觀察新版本上線後,一個月的期間轉換率分別成長了18%以及73%(每篇文章的轉換率,有可能會因為出現的時間越長開始出現遲緩的現象,不過至少在上線後一個月內,表現是比原始版本來得好。)

結束了前兩階段的實驗,我這次沒有再用發明大王愛迪生的名言,而是在電流大戰中展露頭角的特斯拉,他對於愛迪生的實驗行為有下面的建議

Just a little theory and calculation would have saved him ninety percent of his labor
如果愛迪生有一些學理的依據或是能夠做一些計算,那麼可以節省他90%的工作時間

成果Takeaway

演講到了尾聲,藉由特斯拉的名言,我希望這次的實驗,能給聽眾一些立即帶走的Takeaway:

  1. 當團隊比較小,資源有限,列出重要的點進行測試。
  2. 依照每次的測試結果,進行篩選或調整,下次測試只針對前一次實驗結果未解答的地方。
  3. 專注在關鍵指標的改善,次要指標可以放在未來有資源的時候,再去進行驗證。

最後分享當天的投影片給大家,謝謝收看!

Reference

以下是這次演講中的參考資料,供大家參考

Designing with Data

The Button Color A/B Test:Red Beats Green

Nielsen Norman Group:Doing UX in an Agile World

一分鐘搞懂數據和設計的三種思維

什麼是Agile UX?

AgileMeetup 2017/4 聚會紀錄: Agile UX is good, but can be better

如何開始接觸數據分析

哈囉!我是Jasper,喜歡閱讀,鑽研互聯網產品設計,悠遊於英文學習行為大數據,歡迎追蹤,任何關於學習的想法都可以提出來一起切磋討論,想看更多內容也可以到下面這些地方逛逛!
Facebook https://www.facebook.com/JasperChang.Startup
攻其不背優惠序號 https://www.hopenglish.com/course/products/FXFHW
聯絡我請至 threeche@gmail.com

同場加映:下個月,10/5(週五)由UserXper 悠識數位主辦了一場A/B Testing 數據分析與決策實務研討,歡迎大家一起來聽聽我與其他三位達人的分享!

— — — — — — — 
如果你覺得這篇文章不錯,請給我1~10個掌聲,
如果你覺得這篇文章值得跟你的朋友分享,請不吝於幫我轉發分享,
如果你想繼續看到我的文章,歡迎你按下follow來追蹤我的最新文章。