iT邦幫忙

2021 iThome 鐵人賽

DAY 18
0
Mobile Development

30 天從麻瓜變 Android 工程師系列 第 18

Day 18:數據蒐集、資料視覺化、數據分析

  • 分享至 

  • xImage
  •  

前言


在公司內部總是有大大小小的提案,每個提案都有擁護的人,但是大家各說各話,沒有辦法公平的做出決定,這時候我們應該要採用數據驅動 (Data Driven) 的方式做決定,但在那之前,我們就必須做好數據工作。

數據蒐集


首先,當然是要先蒐集資料,這裡的資料指的不只是像會員資料這種伺服器必須存下來的資料,還有像點擊了什麼按鈕(但是什麼狀態都沒有改變)這種額外記錄的資料,你可能會好奇為什麼已經有必須存下的資料還要再記錄一份,因為我們可能會記錄誰、在什麼時候、在什麼流程下、在什麼平台、做了什麼事作為一筆資料,這樣就多了許多個維度可以觀察,例如使用搜尋功能的次數(Y 軸)趨勢(X 軸),這邊舉例一些情境:

  • 商品頁:誰(之後能 mapping 到會員資料)、什麼商品、如何進這個頁面(例如 banner、類似商品)、是否有優惠活動、停留多久。
  • 搜尋:搜尋什麼關鍵字、全部還是分類搜尋、搜尋後是否切換排序。
  • 選單:點了選單的什麼選項、加入什麼商品。
  • 設定:開啟或關閉了什麼。
  • 甚至有頁面停留時間、往下滑了多少等細節。

對了,埋這些數據是功能未上線時就要做的事,否則可能會遇到資料不乾淨的問題,比如,用戶更新上有新功能但沒有埋數據的版本後,就沒有再更新了(可能前一版是強制更新),這樣就要額外判斷在某個版本之後的數據或是再次強制更新了。

當然,除了 app 內的數據,也有不同的數據蒐集方法:

  • firebase analytics 也有預設的用戶、地區、裝置等數據。
  • 商店上的評分、留言。
  • 用戶訪查、觀察使用者操作。
  • 問卷、市調公司資料。
  • 市場數據,如 App AnnieSensor TowerGoogle Trends
  • 蒐集對象甚至可以是開發成效。

總之從微觀到宏觀的方法都有,調查方式應該取決於想要得到什麼類型的資料。

資料視覺化


數據蒐集後,我們有一大堆看起來很沒用的數據,可能還散落在不同的資料庫、資料表,我們應該要建立自己的 dashboard 來追蹤我們在意的指標的趨勢:例如會員數、月活躍使用者(MAU)、每日下載量/播放/點閱量、商店評分與留言等,也就是把蒐集來的數據做成可以一眼就看出趨勢好壞的圖表,並由機器不斷更新。

也就是說,資料視覺化是幫助我們觀察不同事件帶來的成效,並了解我們的處境。

資料視覺化的工具也有很多,能支援不同資料庫來源,從雲端資料庫服務到手動上傳 csv 格式都有,也能產出各類圖表,但可能需要自己下查詢語法。

每個部門在意的指標不同,所以不同部門應該會有不同的 dashboard,而產出的 dashboard 應該要放在公共的區域,讓經過的同事、甚至是不同部門的同事都能看見,每個人對這些走勢都有不同見解,經常會引起討論。

這邊介紹幾個資料視覺化工具:

數據分析


數據分析是最有趣但也最複雜、困難的一環,它可以說是最有價值的,讓我們知道下一步要往那裡走。

找問題

首先,我們應該要以公司的價值、策略方向為前提出發,接著找出 dashboard 上有問題、趨勢不理想、甚至只是成長力道不夠的數據,或是自己想問題,這個時候,我們會發現 dashboard 上的圖表往往不夠,所以會再根據我們的問題、猜測,再下查詢語法驗證。

理解

基本會懷疑的一些面向,例如:

  • 活動/行銷開始、結束。
  • 節慶、寒/暑假、過年。
  • 商業合作大規模裝置綁定、合約到期。
  • 生活形態改變(例如疫情期間,通勤、美食外送、通訊軟體等 app 會受到影響)。
  • 競業加入/退出/推出功能/行銷/活動。
  • 新上市或停止維護的裝置、作業系統。
  • 產業走向。
  • 被駭客攻擊。
  • 甚至是 app 在更新版本後沒有記錄到數據。

我們也可以用 user story、user journey 等方法來找原因。

要注意的是,有沒有其他可能呢?會不會被數據或自己的理解所欺騙,畢竟這些理解有時候是很主觀的,一個人就有好幾種理解,不同人的理解還不重疊,需要小心驗證。

接下來呢

每家公司面對的課題不同,沒有一個公式或 SOP 可以套用,這邊分享一些思路:

  • 調整版位、功能露出的位置。
  • 改設計。
  • 增加行銷、企劃活動。
  • 直接找使用者使用,並觀察使用者的行為,並在事前事後做產品期望與理解的訪談。

要注意使用者是不是能接受這些改動,如果是比較久或是使用者眾多的服務,通常也會有避免較大改動,怕影響使用者既有習慣的包袱,這時候我們也許可以嘗試 A/B 測試 或發佈早期測試的做法,來避免大量客訴與負評。

另外,別忘了觀察其他環節的影響,比如,如果讓使用者去用某個功能,是不是也可能造成其他既有功能的使用時間變短。其他還有黏著度、轉換率、廣告效益等影響。

結語


不管我們是上架了一個完美的 app,有著大量的付費用戶、良好的商業模式,甚至拿到了投資,又或是一個乏人問津的 app,我們都不會知道下一步在哪裡。
當然,並不是有了數據就會知道,但有了數據就像看到前方或是自己腳下所踩的地方,要伸一隻腳還是用跳的,要踩多大力,都讓我們做出更安全有效率的選擇。


上一篇
Day 17:上架 Google Play
下一篇
Day 19:專案管理
系列文
30 天從麻瓜變 Android 工程師30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言