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 吧!

2015年10月23日

先求有、再求美 不要低估有、不要高估美


最近一個月,博客來商業類排行榜空降了一本書 - 大數據玩行銷,這本書特別之處在於用很淺顯易懂的方式讓讀者了解什麼是大數據。原本就對書很有興趣的我,前幾天趁著作者 Tony 到 AppWorks 演講,跑去旁聽。

Tony 是個小留學生,在美國念 Computer Science,工作後自己創業,多次成功出場。之後因為家裡的關係回到台灣發展。從小就在美國唸書、工作,回到人生地不熟的台灣要發展談何容易,還好留著以前的名片。

聽 Tony 說他拿著手上一萬多張名片分類,最後只分出 7 張台灣公司名片,分別打去後 3 家倒了,剩下 4 家的其中一家就是現在的功典資訊(Migo),Tony 到 Migo 幫忙後沒多久就受到董事長的邀請,擔任執行長至今。

特殊的經歷背後,一定有可以令人啟發的故事,以下是幾個對我特別有影響的段落

拼命還是拼格局

一開場就聽到這句令人省思的話!

我們一直在想如何努力工作,但努力工作背後在拼的是什麼?拼命的意思相信不用解釋,但拼格局的意思是如何兜出一個局面,讓大家一起參與、一起獲得想要的東西,這跟拼命是完全不同的思考方向

共享、共創、不獨吞:利他無我

Tony 在演講中多次提及「利他無我」。出社會多年後回頭看一看,很多機會其實是在利他無我的狀態下產生的。

幾年前手機遊戲代理商開始大量代理國外遊戲時,有廠商請我幫忙撰寫會員登入、金流 SDK,要內嵌在代理的遊戲內。因為我們的營收來自於遊戲的 IAP、並不靠代工賺錢,加上我對代工一向很排斥,一直不想做代工這件事,但基於合作夥伴的關係還是答應了。

目的很單純,只是想幫個朋友的忙,價錢開的非常非常低,報價時對方嚇了一跳,主動稅外加給我。做好之後免不了修修改改,對方還直接請我另外報價,不算在原本的工作內,讓我多賺一筆。

這件事其實我沒有放在心上,只是覺得可以幫忙就幫忙,後來此遊戲廠商有個開發新產品的機會,優先找我們談,最後促成合作。

某一天我回想起來,如果不是一開始好心幫忙,也許就沒有後面的事發生。我想,這就是「利他無我」的例子吧!

減法:決定要做什麼事很簡單、不做什麼事很難

黑幼龍曾經出過一本書 - 黑幼龍的加減乘除,書中的減法篇跟 Tony 說的減法有異曲同工之妙。以做遊戲來說,往往整個開發過程都是在加功能,加功能誰都會,但如果問說要把什麼功能拿掉,這就困難許多了。

做事也是這樣,但我認為最困難的不是知道減法這件事,而是常常會忘記,往往做事作到一半才想到自己一直在做加法,因此時時刻刻提醒自己減法是很重要的。

一切的安排都是最好的安排

有位前輩曾經幫忙我們募資,在募資過程中什麼狗屁倒灶的情況都發生了,只有安排好的劇本、設想好的情景不會發生,不發生就算了,還常常有意想不到的結果。

有時候我們笑看來時路,他常常跟我說「這劇本比世間情還精彩,只有上天寫的出來」,的確,人再怎算終究不如天在算。

拿最近政治上的事來說,四個月前國民黨黨內初選時,只有柱柱姐一人領表、全代會也鼓掌通過,誰知道後來發生了那麼多事,最後竟然在選前 90 天換人,相信這也是所有人始料未及的。

效率

所有成功人士對於效率都是非常重視,從開會上就可以略知一二。Tony 的作法是開會時設個鬧鐘,時間到、鬧鐘響,所有人就知道目前開會是不是有效率。

如果預期一個小時可以討論完的會,鬧鐘就設定一個小時後,等鬧鐘響時大家會有自覺,目前討論的進度是否跟預期的一樣,不一樣,是差多少?慢慢的,大家會培養出對於開會時間的觀念,不能再無止盡的討論。

臺北市長柯文哲也曾說過:「開會是鼓掌跟蓋章用的,不是要討論的」、「把會議的議程,在前一天就送給大家先看」

這點我是非常同意的,事前讓與會者把要討論的項目、要說的議題,先拋出來讓大家知道、讓大家有時間消化,開會時因為大家都了解內容了,可以直指核心討論,效率會變高。另外也因為先看過、先想過,討論的品質也會跟著增加,才不會發生開會時想到什麼就講什麼,越討論越發散。

先求有、再求美:不要低估有、不要高估美

這觀點跟減法一樣,不是我們不知道、只是常忘記

Lean Startup 的精神就是先求有、再求好,先做出 MVP(Minimum Viable Product 最低可行性產品),求有,然後慢慢的從 0 到 1,求好,有創業的人都應該知道這道理。

但最令我欣賞的是後面那句「不要低估有、不要高估美」。以做遊戲來說,由於一款遊戲的開發成本非常高,先做出遊戲核心是最重要的事,可能是一場戰鬥、可能是一段演出,做好後先收集大家的意見,用最小的成本決定要不要繼續開發下去還是要轉個彎繼續嘗試,有了初期版本就有辦法評估,這評估影響的是整款遊戲要開發還是停止,重要性不可言喻。

如果是確定繼續開發,那麼開發過程往往會被自我感覺良好欺騙,每天沉浸在美好的假象中,覺得做好這功能會很多人喜歡、做完遊戲會很受歡迎,這時還是回到原點,實事求是,看是要用測試版的名義發布出去、還是找玩家來做意見回饋,才不會高估了美。

Better Tomorrow

明天會更好!積極、正面的對待每一人、事、物,我想成功的人都是這樣的。

演講中,除了包含了 Tony 的創業歷程、大數據的發展以及目前 Migo 正在做的事,還可以感受到滿滿的正面能量。聽演講除了聽到有用的事物外,可以吸收正面能量也是很重要的事,這會讓人生更有動力、更有目標。

最後,工商時間,不管大家對於大數據是不是有興趣,看完這本書絕對會打破你很多固有的想法,推薦給大家!


大數據玩行銷:改變世界的18個大數據新思維,第1本把大數據變營業額的行銷聖經

2015年10月3日

[遊戲數據] 什麼是留存率


留存率,顧名思義就是玩家留下來的比率,這也是所有 App 數據裡們最重要的。
神來也的創辦人 Mike Jiang 曾經說過,ARM 模型內最重要的數字不是把人導進來的 Acquisition、也不是跟錢有關的 Monetization,而是 Retention 留存率。

為什麼

為什麼留存率這麼重要?要說明這件事前得先來探討 ARM 模型內的其他兩個數據 - Acquisition & Monetization。

現在的 App 環境,要把玩家導入 App 內最有效的方式不外乎是買廣告,只要有錢,你可以買到你想要的玩家,而這些玩家下載 App 後、打開 App、把 App 留在手機中,這些行為又進一步提昇 App 在 App Store 或是 Google Play 上排行榜的排名,排名的提升又導來更多流量。因此 Aquisition 這件事大部分取決於你有多少銀彈,也就是說 Aquisition 可以靠非產品面的方式獲得。

再說到 Monetization,什麼樣的玩家比較容易付費,是下載完當天就刪除的玩家?還是七天後刪除的玩家?還是一個月後才刪除的玩家?是什麼樣的 App 營收會比較高?是一款下載後就想刪除的 App?還是下載後玩家會保留七天的 App?還是玩家會留在手機內一個月的 App?答案顯而易知。因此 Monetization 這件事的效果依賴著玩家留存,玩家留得越久,效果越好。

回到 Retention,如果把玩家導進來但留不住,就沒辦法有營收。如果玩家留得不夠久,收費的效力會低。因此可以說 ARM 模型中,Acqusition 跟 Monetization 是依靠著 Retention 才有辦法發揮最大的效力,因此 ARM 模型中最重要的是 Retention。

怎麼算

假設今天有 100 個新玩家打開 App,明天這 100 個新玩家之中有 40 人再次打開 App,那麼次日留存率(或稱為 Day1 留存率)是 40%。
假設這 100 個新玩家之中有 20 人在第 7 天再次打開 App,那 7 日留存率就是 20%。
依此類推,第 30 天時有 10 個玩家打開 App,那 30 日留存率(或稱為月留存率)是 10%。

Day N 留存率



如果我們只看 Day1 留存率,把每一天新進的用戶的 Day1 留存率畫成圖,就成了上圖。

次日留存率是很先期的指標,新用戶今天進來後,後天就可以看到結果。
因此這張圖除了可以看到次日留存率外,最重要的是當我們對 App 做了調整,後天馬上可以看到調整後的次日留存率。
當次日留存率變好時表示我們做對了一些事,可以繼續加強。變差時因為才過了一、兩天,也可以即時修正,不會因為過了很久才發現做錯事,要改也來不及。

某日新用戶的留存率


留存率的另一個呈現方式是把某一天的新進用戶後續的每日留存率製作成上圖,由圖可以知道某一天進來的用戶在 Day N 的留存率。

如果把每一天的這張圖都拿出來看,可以知道我們的 App 在那一天的落差最大,落差最大的地方代表用戶進來後到那一天的流失最多,要優先把洞補起來。絕大部分的情況都是 Day0 → Day1 的落差最大,所以次日留存率除了是先期指標外,也是所有留存率中最重要的指標。

以上圖來說,假設 Day0 有 100 人進來,Day1 的留存率是 49.49%,意思是隔日只剩下 50 人有打開 App,等於損失了另外 50 人。當我們好不容易找了 100 人下載 App,沒想到隔天有一半的人不再打開 App,這是多大的損失。

當然你可以說這 50 人很有可能第三天、第四天還會再回來,但通常來說,除非 App 是跟時間有高度相關的,例如旅遊類型的高峰是在週末跟週末前幾天、高速公路類型的是在假日,否則離開的用戶很難再回來。
用戶不打開的 App 過沒多久一定會被刪除,被刪除的 App 通常看到也不會再下載。

攤開來看留存率

以上除了各種圖自己的比較外,有時候我們也會想要合在一起比較各圖之間的落差,在各種圖之間切換總是不太方便,因此有了下面這種表現方式。

最左邊的 Install Date 是 App 安裝日,第二行 Cohort Size 是當日安裝數,後續的 1、2、3...是 Day N 的留存率。顏色越接近綠色,留存率越高、顏色越接近橘色,留存率越低。

從表中可以很清楚的比較出

  1. 任何兩安裝日間的差別,例如 9/23/15 的 Day1 留存率有 32.9%,到了 9/24/15 突然降低到 20.0%,從顏色上馬上知道有落差,就可以回頭找 9/24 是不是發生了什麼問題?導致 Day1 留存率變低。
  2. 各個 Day N 留存率之間的差別,9/28/15 當日安裝的用戶,在 Day2 → Day3 之間顏色落差過大,跌了 6.6%,這時候就可以回想到底是什麼原因造成的?如果以遊戲來說,會不會是每日登入送的獎勵改掉了呢?導致玩家留下來的意願降低...,不同的服務會有不同的原因、不同的解釋方式。

40-20-10 法則

上述圖表擷取自知名的手機分析服務 Flurry,不同分析服務,提供的呈現留存率方式不盡相同,但只要把握原則去解讀,八九不離十。

那到底怎樣的數據是好的呢?遊戲 App 中流傳著 40-20-10 法則,次日留存率要達到 40%、7 日留存要達到 20%、30 日留存達到 10%,代表這是一個及格的遊戲。

另外一種說法是,7 日留存率是次日留存率的一半、30 日留存率又是 7 日留存率的一半,其實 40-20-10 法則也符合這樣的說法。

但如果以應用類型的 App 來說,普遍都要比 40-20-10 來得高,因為遊戲可能下載後不喜歡就刪了,但工具型的 App 即使現在用不到,用戶也會有種之後也許會用到的心態,而留在手機內。

當然不同的 App,標準會不太一樣。新聞或社群類型的次日留存率應該要比其他種類的 App 高,且 7 日、30 日留存率肯定不能砍半再砍半,要保持接近次日留存率才是合理的標準。

工具型類型的 App 的次日留存不會太好看,但是 7日、30 日會非常接近次日留存率。

不管怎麼說,把握大原則,留存率沒人在嫌高的,當然是越高越好!

最後還是要強調一點,數據只是讓我們找出問題的工具之一,數據無法解決我們的問題,要解決問題還是要自己去發掘、去測試、去了解用戶才行。

搭配 [遊戲數據] ARM 模型 服用,效果更好!

photo credit: Numbers And Finance via photopin (license)
Related Posts Plugin for WordPress, Blogger...