2017 / 01 / 24
Home > News > [活動筆記] HPX73 Super Weekend – 網站與手機App數據分析 (上)

[活動筆記] HPX73 Super Weekend – 網站與手機App數據分析 (上)

文 / Cha Cha

這次的 HPX73 跟過往不同,選擇在周六的下午與大家一起來討論:網站與手機 App 數據分析。同時這一場也把時間拉到4個小時,目的就是為了讓大家有很多交流與分享的時段。

分析路上的溝通課 / 王宛如 Ruby

11751470_10152874165251784_8959156579607866077_n

首先登場,是王宛如(以下簡稱Ruby)講述「分析路上的溝通課」,Ruby 提到自己是因為工作關係,常常需要透過報表來跟高層討論,今天分享的是自己整理的一套心得。

  • 溝通的第一步:由於老闆看到報表會產生問題,這時候就是要留意老闆在意的東西、溝通的對象是誰,因為一個不小心:「insight沒講好就會變成sight」,這樣就等於白講了。
  • 溝通的第二步:有意無意進行持續確認,也就是要會利用資料來佐證自己的想法。但是如果看不到對手資料呢?也要特別留意流量&流量品質、使用者、經營方式與營業額。不過,除了上述四點之外,其實還有自己平日的觀察,因為很多時候目標客群並不知道自己可以做什麼?因此可以透過引導與情境的說明來引導客戶。
  • 溝通的第三步:明確告知當次分析的目標與限制,因為很多時候報表數字一定會和內部資料不同,這時候就是要看長期的趨勢,而不是報表呈現的實際數字,這是相對的結果而不是絕對的結果(可以用長條圖呈現)。同時還要留意 Google Analytics  做不到的事情,如果真的資料不足,問過朋友、原廠也是如此時,請選擇 Lets it go!
  • 溝通的第四步:公司/產業大事記很重要,如競爭資料、瀏覽頁數等,記錄自己做了什麼設計、產生什麼技術,如此才能對照並解釋數據的波動。(Ruby說總不能說:因為天氣好,所以大家都出門不上網了。)
  • 溝通的第五步:果斷放棄無用的報表,也就說要保留目標客群的耐心在於真正的事物上,剔除不相關報表與 insight,但是可以提供附件當作參考。
  • 溝通的第六步:一次以一個工具作為分析主題,因為報表的整合服務是一件很艱困的工程,所以保留主軸,才能避免失焦。此外,Ruby 也適時提醒大家;與其選擇強大的工具,倒不如選用具”親切感”的工具。也就是說要選擇版本好用,同時說明清楚的、服務好的工具。不過這時候大家一定會提出一個問題,如果工具是要付費才能使用該怎麼讓老闆答應呢? Ruby提出首先應該要做一個免費版本,接著清楚說明付費版本的費用與可以解決什麼問題,最後提出其附加價值。
  • 溝通的第七步:報表要視覺化。最重要一個訣竅:引導,不要誤導。

IMG_2265

  • 溝通的第八步:要有能力解釋報表中的所有資訊。因為我們永遠不會知道老闆要問什麼,但是有兩個問題是一定要知道:1.如何蒐集資料 2.樣本數有多大

最後,Ruby 給大家一句話:適時的收斂,下小摘要。這樣才能讓自己在報告時,能針對台下的聽眾,來決定是否要下策略性結論。(畢竟,如果是針對策略長來報告,就不用提供結論了)。

別再 Boss-Centered Design了─ 了解使用者,做出好產品 / 吳憲達

11794445_10152874165381784_4186780734774189991_o

接者上台的講者,吳憲達是以「別再 Boss-Centered Design了–了解使用者,做出好產品」為題,分享如何透過訪談、prototype 測試、MVP 測試、A/B testing 等方法,做出使用者喜愛的產品,並建立完整的產品開發流程。

吳憲達主要是經營「玩運彩」的公司,所以對於運動比賽平台的建立,再熟悉不過,但是吳憲達不言諱地說出在經營的前幾年不斷遇到挫折,甚至有 70% 以上的功能從當初設計到最後上架,結果都是失敗,使用者不愛的(明明是很好用的功能)。

這一個跌跌撞撞的過程中,吳憲達也提到自己做過 UI test、A/B testing 等等方式,直到最後才體悟到其實最重要的核心點:「產品開發流程」。也因為這一個發現,讓玩運彩公司的業績成長 35%,同時流量也提高 84%。

那什麼是產品開發流程呢?  吳憲達說可分成三個部分,探索→製作→發佈。

  • 探索:訪談與產品定義。

首先是訪談,一次大約8人左右,訪談的重點在兩個地方:需要什麼?及遇到困難點是?(吳憲達推薦大家可以去看《贏在用戶》)。產品定義就是使用者遇到的困難,及發想解決方式。

  • 製作:MVP、製作MVP、開發。

首先什麼是 MVP?吳憲達解釋:就是「最小化的適用功能」,也就是最快速給使用者測試,如只是建立在 APP 的手機頁面。然後趕緊去找5~8位的真正受測者(這個是真正的 User,所以有可能要全台跑透透)來訪談,透過他們的經驗談瞭解使用者的感受,同時並請他們給予評分(1~5分)。吳憲達解釋透過 MVP 的製作,其實可以發現:確定產品方向是否正確、使用上有沒有問題、同時避免開發上浪費時間、及發掘出消費者需求。

  • 發佈:A/B testing、問卷、上線、優化。

首先在 A/B testing 時(大約一個月時間),不要忽略統計驗證,在玩運彩來說,如果統計驗證無法達到 95%,就會不斷的進行 A/B testing 與驗證。但是如果 A/B testing 結果一直不理想,其實就必須回到 MVP 或者是產品定義。

接著是問卷填寫(給予1~5分)。為什麼要做問卷呢?其實要等到使用者習慣之後才上架,因為問卷很容易產生正/負效果,這反而是要很小心操作。

上線,其實就是要持續觀察使用者的數據變化,時間大約抓3個月。

最後就是優化,因為產品從0~上線的過程中,會收到很多建議,那要嘗試從中去發掘新的 insight,然後做出產品(記得要去找受訪者,1~2位即可)。那優化需要做幾次呢?吳憲達提到其實大約要2~3次,並且要1~2年後重新檢視。

整合上述所說,才是一個完整的產品開發流程。結論時,吳憲達說:

「創業的前五年遇到很多挫折,透過不斷的摸索、看書,才逐漸從中找到脈絡,所以多看書還是很受用。」

About chacha

留言

您的Email並不會被顯示出來。 * 星號為必填 *

*