顯示具有 分析 標籤的文章。 顯示所有文章
顯示具有 分析 標籤的文章。 顯示所有文章

2016年10月13日

有時候 你不該作數據分析


前幾天去 AppWorks 分享數據分析時,有人問了一個接觸數據分析的人都會遇到的問題,「當數據量很小時該怎麼分析?」

這個問題的背景是,萬丈高樓平地起,所有服務一開始使用的人一定不多,因此收集到的數據量也不會太大,在數據量小的情況下(也就是分母小的情況下),算出來的數據很容易失真,造成誤判。

這個問題在我剛開始分析數據時也遇過,我還記得我問過神來也的創辦人這個問題,他給的答案是「累積」。也許你一天只收集到 10 個人的數據,但累積 10 天就有 100 個人的數據,100 人的數據會比 10 人準確許多,就可以稍微避免數據母體過小的問題。這是我的第一個回答。

第二個回答是,相信你的直覺。根據我的經驗,在數據的準確度還不高的時候,人的判斷往往超越數據。當你開始建立一個服務,到處收集資料、接觸市場、訪談身邊好友、了解客戶,這樣的情況下,我相信人的判斷絕對遠遠超過初期收集到的資料。所以你該相信你的直覺勝過數據。

回答完後發問者也沒更進一步的提問,問題看似就這樣結束了。但其實這個問題在我心裡還一直停留著,雖然以上回答早就瞭然於胸,但我一直對這些答案都不太滿意,直到問題被提起,才又讓我回頭去想有沒有更好的解答。

人總在問題發生才會認真面對

最近重新開始一個新的服務(MyToy 兒童玩具店商平台),由於剛開始,一樣資源很少、人力吃緊、一人當十人用,每天要嘛就是開發新商品,要嘛就是寫文案下廣告,不然就是寫商品企劃,偶而還要弄弄 Banner,雖然知道數據分析很重要,但實在沒心力每天去作數據分析,一週能認真看一次報表就偷笑了。

偶而在安排時間時,會檢討自己要不要把數據分析列為每天必作的功課,就像每天要盯營收報表一樣,但又覺得每天花時間在數據分析上好浪費,把時間拿去改廣告文案、改廣告素材都還來得有直接的效益。但又覺得這樣好像跟以往的觀念有衝突,應該是要重視數據才對。

這兩邊的拔河其實一直困擾著我,直到最近我才想通這件事,有時候,你不該碰數據分析。為什麼?原因是機會成本。

有接觸過數據分析的都知道,真的捲起袖子來認真測試、認真想、認真分析,也就是 Lean Startup 中的 Build → Product → Measure → Data→ Learn → Idea,每一步驟其實都非常花時間。而花了時間的結果,往往都是沒啥效果,也就只是測試出一條死路,讓我們知道這樣作不行。收集越多不可行的路對長期來說是有幫助的,但短期來說,整體其實是沒有前進的。

花了大把時間卻沒有效果,在剛開始創立事業時是很浪費的花費。與其浪費時間在那不可知的結果上,不如把時間花在比較有把握的事上。

以 MyToy 為例,因為剛成立,所以找到一個熱賣商品可能隔天馬上帶來兩倍、三倍的業績。而數據分析再怎麼會分析、再怎麼會改善也沒辦法瞬間達到兩倍、三倍的效益。更何況使用者不多的情況下,即使透過數據找到一個可以增加業績 10% 的關鍵點(能找到提昇業績 10% 的點真的很少見),一個月原本業績 100 萬,增加 10% 也才 110 萬,都遠不及找到一個熱賣商品帶來的效益。

分享會結束後,回來時我重新想這個問題終於有了比較滿意的答案,如果你心中有同樣的疑問,「當數據量很小時該怎麼分析?」,我的答案是你不該作這件事,因為時間還沒到,這時還有更多值得作的事,而效益會比數據分析來得好。

當然,你不該去分析數據,但別忘記收集數據,失去的數據就像變了心的女朋友一樣,回~不~來~了~

業配時間

雖然殭屍粉絲沒啥用,但傳統產業很多人還是吃這套。舉手之勞幫忙當一下殭屍粉絲,加入後別忘了去取消通知,才是合格的殭屍粉絲喔。

https://www.facebook.com/mytoytw



業配時間2

難得寫 Blog 就是要業配回本。雖然有時候你不該花時間在數據分析上,但不代表你可以不學這件事。AppWorks 的團隊中有一堆數據相關神人,從廣告、數據分析、行銷數據,任何面向都找得到該領域的神人可以請教。

平常在寫廣告文案時,最後都會加上溫柔婉約的 CTA,想要用戶點擊卻又不能寫得太直接,「立即點擊」、「心動不如馬上行動」、「來去瞧瞧」,現在的用戶已經對這些老梗免疫了。但這次我必須要說,如果你在創業,立即點擊馬上點擊不要心動又不行動不要只會瞧又不點https://appworks.tw/accelerator/


2016年3月26日

Google Analytics 行為流程 用戶行為全都錄

Google Analytics 中有一個我覺得很好用也很簡單的功能,但一般人很少提到的報表 ─「行為流程」。

什麼是行為流程,官方的說明如下
「行為流程」報表可呈現出使用者從一個「網頁」或事件到下一個所行經的路徑,方便您瞭解哪種內容可讓使用者持續使用該網站
簡單的說就是把用戶在服務內的逛過的畫面、或是發生過的事件一步一步紀錄下來,統計分析成如下方的流程報表。由於是採用圖形化方式呈現,一眼看去,非常清楚地知道大部分用戶在服務內的操作行為。英文稱為 Visitor Flow,這樣應該更好理解。

行為流程報表 Web、App 都可以使用,以下以 App 為例。

行為流程簡介


以上圖來說,可以看到大部分用戶打開 app 進入的第1個畫面是 MoaibotSplashScene,少部份進入 LoadScene,有更少一部分直接進入 /MoaiCity_MoreGame。

進入第1個畫面 MoaibotSplashScene 的用戶,大部分都進入第2個畫面 LoadScene,少部份直接離開(紅色部份)。

而進入 LoadScene 之後的用戶大部分都直接進入第3個畫面 HomeScene,少部份人進入 /MoaiCity_Auth,少部份人則是直接離開。

做服務很怕的是設計出來的流程並不是用戶想要的,透過圖表可以看出用戶在服務內的操作流程是否跟設計當初想像的一致,用圖表來驗證設計的方向跟實際用戶操作的行為。

如果要看到更詳細的資訊,只要把滑鼠游標放在畫面區塊上,就可以看到

有時遇到畫面過多,圖表沒辦法顯示。在每一個畫面的最下方可以把無法顯示的流量展開成表格的方式呈現

切換不同維度入口

除了看總量以外,左上角的「作業系統」下拉選單可以切換各種維度。

切換成「應用程式版本」可以看到不同版本間,用戶的流向。

切換成國家,可以看到不同國家的用戶走向

當然,更有用途的是下列這些跟廣告有關的維度。
假設現在分析的是結帳畫面,可以從不同的通路來源知道,不同通路的用戶,他們進到結帳畫面的比例、流程是否一致,藉此了解不同通路用戶的特性。

詳細程度

在視覺化方面,每個畫面預設只會顯示最主要的流量。想看到更多可以藉由調整「詳細程度」,顯示更詳細的流量。預設如下

展開後可以看到更多流量

要怎麼做呢

在動手之前,先來理解什麼是「畫面」?
在 Web 上很好理解什麼是「畫面」,一頁就是一個畫面,對應到行為流程內的「畫面」。但在 App 上卻不是這樣。App 不像 Web 有一頁一頁的觀念,每一頁還有不同網址。App 內的「畫面」是開發者自訂的,什麼意思呢?就是你告訴 Google Analytics 用戶逛了一頁,Google Analytics 就會紀錄下用戶逛了一頁。

舉個例子,在 App 內常見的對話框,對話框出現的方式通常只蓋住某部份的畫面,背後隱約可以見到原畫面,這樣到底算不算一頁?對於 App 開發者的你來說,只要你想紀錄用戶看過這個對話框,那就可以把對話框當作一頁來看,如果這對話框對你沒有統計價值,那就可以忽略。

了解 App 內對於畫面的定義後,實際來看看怎麼操作、怎麼跟 Google Analytics 說用戶逛了一頁。在 Google Analytics 內,「畫面」的英文稱為「Screen」,在下列位置可以找到 iOS 跟 Android 的設定方式。
iOS
https://developers.google.com/analytics/devguides/collection/ios/v3/screens#overview

Android
https://developers.google.com/analytics/devguides/collection/android/v4/screens#overview
在需要紀錄用戶逛了一頁的地方呼叫對應的程式碼,就可以辦到。

那麼 Web 呢?Web 的 Google Analytics 會自動紀錄每一頁成「畫面」,所以不用手動呼叫程式碼,但如果你要在用戶做某一動作時紀錄用戶的行為,那也可以手動呼叫對應的程式碼,請 Google Analytics 記錄下來。

以現在很流行的一頁式網頁設計來說,滑鼠一直往下滾就可以看完整個網頁,不需要切換頁面。因為不需要切換頁面,所以 Google Analytics 的紀錄上永遠都只有一個頁面(而這個頁面的跳出率還是 100%),這時我想知道用戶是不是真的有往下看怎麼辦?

這時手動紀錄畫面就派上用場了,可以在用戶滾到某一段落時呼叫程式碼,讓 Google Analytics 紀錄用戶逛了一個新頁面,雖然並不是真的新頁面,但就統計分析的角度來說,用戶的確是看到了不同的畫面。這樣在行為流程報表內,就會呈現出多少用戶有逛下一個畫面、多少用戶沒逛就離開,整個用戶行為清清楚楚,這也是 Web 上手動紀錄頁面的一個經典範例。

寫在最後

「行為流程」報表是很簡單又很實用的報表,不需要太多的背景知識就能解讀,也很好理解。採用圖表方式,對於觀察用戶的行為非常直覺,是很好用來追蹤用戶操作流程是否跟設計一致的工具。更可以把用戶依照不同維度分開,各自比較不同維度下用戶行為是否有變化。

「行為流程」報表是 Google Analytics 內比較重操作的報表,但不難上手,實際去操作一定可以體會更多,現在就打開 Google Analytics 吧!

2013年11月13日

手機遊戲的使用時間分析

對於手機遊戲玩家,設計遊戲時通常會先假定玩家不會持續一、兩個小時玩遊戲,而是利用零碎時間在使用手機。因此設計手機遊戲時不會像 PC Online Game 那樣,設計一個副本,玩家一打就是半天。而是會採取讓玩家多次上線、每次上線只花 3~5 分鐘便可完成一件事的設計。

例如 Candy Crush Saga 中每盤棋只花你 3~5 分鐘解,但是等 5 個愛心回復要 2.5 個小時。Clash of Clans 生產一批兵大約 30 分鐘,但帶兵去打玩家系統只限制 3 分鐘內要分出勝負。這樣設計的目的完全是針對手機遊戲的玩家而來。

但 1 顆愛心要等 30 分鐘回復,生產一批兵要 30 分鐘,這些時間到底怎麼算出來的?是企劃自由心證?還是背後有什麼方式可以推導?

前幾天看到 TalkingData Blog 中一篇「移動遊戲的使用時長分析」正好說明了這件事(備份)。這篇文章讀起來比較生硬,我試著用更白話並加上自己的觀點來重新闡述這篇文章想表達的意思。

驗證遊戲時間設計

這是文章中舉的例子,看最右邊的招募項目,每天可以招募 5 次,每次招募後要等 10 分鐘才能再次招募,如果玩家非常有耐心盯著螢幕看,最快也要 50 分鐘才能搞定一天的招募額度。假設這數字是一開始企劃憑經驗設計出來的,上線後該如何調整呢?

首先看到新玩家的每日平均上線次數,新玩家第一天平均上線 2.1 次。如果按照之前的設計,對於新玩家來說是有壓力的,因為新玩家首日平均才上線 2.1 次,不可能用完一天 5 次的招募。

再來看到所有玩家的單次停留時間,以原先的間隔時間 10 分鐘設計來看,下圖 3-10min 跟停留時間更久的玩家,也就是約 78% (78% = 21.2% + 25.3% + 19.3% + 12.1%) 的玩家在上線後可以使用兩次以上招募功能(上線一次,隔 10 分鐘還沒下線可以再招募一次)。

但如果改成間隔 30 分鐘,那只剩下 57% (57% = 25.3% + 19.3% + 12.1%)的玩家可以在上線後使用兩次以上的招募。
因此要讓多少玩家可以較頻繁的使用,可以透過這樣的方式得出一個概略值。

新玩家 vs 活躍玩家

剛剛我們透過單次停留時間可以知道,間隔多久的設計,可能會有多少玩家使用。但別忘了,新玩家跟活躍玩家的行為很不一樣。

以下列每日遊戲時間來說,如果設計一個需要持續 30 分鐘的功能,只有 49% 的新玩家可以完成,但對於活躍玩家來說,有 56% 的人可以完成。因此在設計時需要考量這功能是給新玩家使用的還是活躍玩家使用的,可以使用的玩家數量會有差別。

設計期望 vs 玩家表現

最後一個重點是獎勵跟玩家反應的關係。

通常遊戲企劃心中想的是藍色曲線,給的獎勵越多越好,玩家反應越大、越會去追逐。但實際玩家的反應是黃色曲線,一開始給一點點獎勵玩家反應會很大,但隨著獎勵越給越多,玩家慢慢疲乏,漸漸的提不起興趣。

更甚之,還有可能變成白色曲線,給越多越反感。所以獎勵給的多不如給的巧,以免弄巧成拙。

經過這番解釋,希望各位看倌有比較清楚。

工商時間


  1. 如果你想要幫助我們,成為我們研究的對象,請下載野球大聯盟,可以免費玩遊戲又可以當個白老鼠,何樂而不為 XD
  2. 如果你想更進一步自己來分析數據、改進遊戲,我們正在強力招募 Unity 資深工程師,歡迎到 104 瞧瞧
Related Posts Plugin for WordPress, Blogger...