Embed Size (px)
Citation preview
今天假設各位...
2
● 知道追蹤用戶行為的一個方法是「實作 event tracking」
● 聽過基本的用戶數據指標 & 分析方法，例如：○ Unique Users 和 Total Views○ Active Users 和 Total Users○ AARRR 或 AAR○ Funnel 和 Cohort Retention
● 各位觀摩過「用戶訪談」或「易用性測試」
● 從「沒有數據」到「數據多到分析性痲痹」
如何決定「要搜集哪些數據點」啊？
● 公說公有理
怎麼讓「訪談用戶」和「觀察行為數據」互相搭配？
● 有了用戶數據，然後呢？
怎麼讓團隊採取行動？
3
但大家有類似的問題...
4
KKTV 團隊大概就這麼多人 今天分享的經驗，由 KKTV 團隊合力完成
5
分享的大綱
● 為什麼要追蹤用戶行為？
● 如何追蹤用戶行為？
● 分享更多案例
● 結語
6
為什麼要追蹤用戶行為？
01
7
為什麼要「追蹤用戶行為」？
● 初衷：縮短「團隊與用戶」的距離
● 要達成的目標：○ 逃離「阻礙成長」的陷阱
○ 引導團隊具備「追求成長」的心態
● 陷阱○ 與顧客脫節
○ 團隊內耗
● 質化的特性：○ 若有足夠時間，能深入探索，獲得立體的觀察
○ 難以規模化套用到很多用戶，容易陷入「樣本代表性」的難題
8
● 量化的特性：○ 若有精準的行為數據，能快速大量探索，獲得切片觀察
○ 只有缺乏個性的扁平紀錄，容易陷入「自圓其說」的盲目
● 常用的方法：○ 質化的用戶研究、訪談
○ 量化的用戶行為分析
關鍵：頻繁地獲得用戶回應
● 質化：○ 用戶「在想什麼」？用戶「為什麼」這麼做？
○ 當團隊「完全不知從何開始」的時候
● 量化：○ 用戶「大多數在做什麼」？是否「口嫌體正直」？
○ 當團隊「有幾個方案但都沒把握」的時候
9
● 原則：把用戶回饋，當成「假設」與「學習」，不是答案
● 取決於今天想回答什麼問題，我們想知道什麼
● 需要「靈感」還是「驗證」？
● 需要「深入探索情境」還是「大規模觀察」？
質量互相搭配！
● 初期：主打特定內容，韓劇為主（50%），日劇次之（30%）
● 上線後，觀察用戶數據的收穫：○ 90% 用戶看韓劇，15% 以下看日劇，10% 以下看中劇台劇
○ 外部調查，台灣約 20-35% 的用戶看日劇
○ 看日劇的用戶，在 KKTV 明顯過低
10
● 訪談用戶的收穫：○ 日劇的重度用戶表示，打開 App 都是韓劇，頗惱人，因此以為日劇超少
○ 但後來發現，其實 KKTV 有很多很棒的日劇
案例：「自白偏好」的實驗 - 觀察
● 理想：給用戶「選擇偏好」，提供個人化首頁
● 現實：當時團隊很滿，無法立刻實作機制
11
● 假設：○ 不愛看韓劇的用戶，註冊後較少人吃了第一口
○ 在註冊後「新增一頁」，可能降低用戶吃第一口的比例
案例：「自白偏好」的實驗 - 假設
● 發想：○ 該怎麼驗證，「看劇偏好」跟用戶「是否吃第一口」的關聯呢？
○ 安插一個「假的個人化問卷」，讓用戶自白偏好
● 指標：註冊後「吃第一口」的比率（Activation）○ 定義：註冊後 24 小時內，真的播影片
○ 現象：有吃第一口的用戶（相較於沒吃）註冊次日留存，至少好 5 倍
12
案例：「自白偏好」的實驗 - 實驗流程
● 最近三個月，沒看過韓劇的用戶，比率確實較低
● 男生比起女生，比率確實較低
● 註冊後多了這一頁，比率沒有比較低
● 註冊後，若提供個人化的首頁，可以提高第一口的比例
（讓日劇用戶看到更多日劇）
13
● 覺得「用膝蓋想也知道」，何必做實驗？○ 瞭解「差距有多大」，因此能說明「多值得」繼續改善
○ 初步探索流程 & 機制，瞭解用戶的反應，因此能說明「值得如何做」
案例：「自白偏好」的實驗 - 學習
14
如何追蹤用戶行為？
02
● 詢問跟成長直接相關的部門：○ 瞭解團隊「有什麼問題」
○ 想知道「哪些用戶回應」？
○ 覺得用戶數據，可以如何幫助自己的工作？
15
● 有了用戶數據，但怎麼讓團隊採取行動？○ 用戶數據的主要使用者：正是團隊成員
○ 在設計用戶數據點之前，先知道「團隊的需求」
○ 然後，以「盡量少的數據點」回答「盡量多的團隊疑問」
○ 團隊覺得問題被回應，感受到價值，願意採取行動
追蹤用戶行為的第一步：訪談團隊
● 起頭之後，持續捕捉、挖掘團隊的問題，主動提供服務
● Product Development○ 用戶播放影片的時間 & 看什麼影片
○ 在服務中找影片的時間 & 過程
○ 在什麼環境播放影片（網路狀況、有無網路）
○ 從哪裡開始播放影片 & 按下哪一個播放鍵
○ 收藏影片的情形
16
● Marketing & Content○ 看不同劇種（韓日中台）的用戶，有什麼差異
○ 在不同裝置平台的看劇行為，有什麼差異
○ 看跟播劇 vs 片庫劇，有什麼差異
○ 什麼是用戶付費轉換的前置指標（leading Indicator）○ 基本指標：下載數、註冊數
案例：KKTV 團隊的疑問？
17
案例：KKTV 團隊的問題，集中在...
● 最集中：用戶「看劇」的「播放」行為○ 各種裝置的差異
○ 不同網路環境的差異
○ 各種看劇偏好的差異
○ 因為「劇的特性」而產生的差異
● 視為理所當然：下載、註冊、付費轉換
● 有需要：在服務中「瀏覽」的行為
● 核心價值行為：跟服務的「價值承諾」直接相關○ 「獲得」或「投入」價值的各種行為
○ KKTV： 「用戶在播放器的行為」 x 「影片的特徵屬性」
18
● 轉換行為：為了繼續獲得價值，用戶做了某個「交換」○ KKTV： 安裝、註冊、開始試用、兌換優惠、付費
要追蹤哪些用戶行為？
● 路徑行為：為了享受價值，用戶從首頁開始，可以走的重要路徑○ KKTV： 抵達首頁、點擊分類、搜尋...
● 被觸及的行為：團隊如何觸及用戶？○ KKTV： 推播、服務內提示
● 以「盡量少的數據點」回答「盡量多的團隊疑問」
19
● 不能省略轉換行為
● 把關核心價值行為
● 可以省略路徑行為
精實的用戶行為追蹤
● 經驗：○ 先問問題，接著思考分析方法，再規劃數據點
千萬不要鋪天蓋地插入數據點，沒用到就是浪費，引發分析性麻痺
○ 隨著成長，團隊需要越來越多種類的數據，感受到需求，再增加數據點
最近期的行為最重要，通常過去 30 到 90 天的數據已足夠
○ 重要：轉換行為 x 核心價值行為，永遠都重要，不常增修這裡的追蹤
20
● 約有 14 個轉換行為
● 約有 9 個核心價值行為○ 但分析時極度依賴的只有 3 個
● 約有 17 個路徑行為○ 但目前分析只用了 5-7 個○ 最近才要開始利用
● 總共：61 個 events，169 個 event properties
案例： KKTV 的用戶行為紀錄 - 概括
● 給大家看看實際範例
21
範例： 用戶行為追蹤 - 用戶特徵
22
範例： 用戶行為追蹤 - 用戶特徵
23
範例： 用戶行為紀錄 - 事件 & 事件參數
24
範例： 用戶行為紀錄 - 事件參數 x 用戶參數
● 事件參數：○ 幹了某件事的「人事時地物」等周邊資訊
○ 用來重建事件發生時的情境
● 行為事件：用戶幹了什麼好事，如同前面介紹的類別○ 事件命名：遵循 Object + Action 原則
○ 概念相同的事件，用相同名稱，但以「事件參數」區分
25
● 用戶參數○ 某個人的「身高、體重、三圍、性別」等特徵
○ 用來重建事件發生時，用戶身處的狀態，是個快照（snapshot）○ 因為「不同狀態的人」做了相同事件，應該有不同意義
○ KKTV： 「試用 vs 付費 vs 免費」 狀態下的播放行為
● 交叉儲存：紀錄「事件當下」的「事件參數」及「用戶參數」
如何紀錄用戶行為？
26
如何紀錄用戶行為？
行為事件
事件參數
事件發生當時的用戶參數
● 進階：完成動作○ 前端獲得 API 回應
○ 伺服器端走完程序
● 普遍：畫面與 UI 元件○ 造訪、按鍵、瀏覽
27
● 再進階：結算一段相關行為的狀態，打包存在事件參數○ 花費時間
○ 停止位置
○ 相對完成度
● 好處：已知分析必用的參數，交給前端當下算完，省去事後結算
如何紀錄用戶行為？
28
分享更多案例
03
● 用戶行為分群：依照下列條件，切出一組用戶，進行訪談或實驗○ 在一段時間
○ 做了哪些事件，做了幾次，當時有什麼用戶屬性
○ 沒做哪些事件，或，先後做了哪些事件
29
● 例1：訪談看日劇的 iOS 用戶○ 抓出下面這群用戶，發問卷、邀請訪談
○ 時間：註冊後直到今天為止
○ 事件：在 iOS 上觀看日劇超過 30 分鐘
● 例2：瞭解 mobile 上提示 web 版的有效度○ 時間：註冊後隔天
○ 事件：有回來播放影片
案例：尋找受訪用戶
● 訪談用戶的收穫：○ 很多用戶不知道我們有 Web 版，知道後相當驚訝
○ 使用過 Web 版的朋友，認為體驗相當不錯
30
● 觀察用戶數據的收穫：○ 在 Mobile 註冊，去 Web 上播放的用戶：比例極低
○ 少數橫跨 Mobile & Web 播放影片的用戶，有更高的付費轉換率
（將近 10 倍）
案例：「跨平台播放」的實驗 - 觀察
● 發想：註冊後，發送推播給用戶，提示有網頁版
● 指標：註冊後 14 天內「升級」的比例
● 假設：如果實驗成功，收到實驗推播的用戶，註冊後 14 天的付費
轉換率，在 Android可以提高到原來的 6 倍，在 iOS可以提升到原
來的 4 倍
31
案例：「跨平台播放」的實驗 - 假設 & 實驗
● 有效提高付費轉換率：○ 收到此推播的用戶
○ 打開此推播的用戶
○ 打開此推播，且真的去 Web 播放的用戶
32
● 事前分析用戶行為時，疏忽了：○ 沒有區分「付費前」還是「付費後」到 Web 播放
○ 真正好奇的是：用戶「在試用期到 Web 播放」，是否提高付費意願？
○ 應用：先「行為分群」再看「事件當下」的「用戶參數」及「事件參數」
○ 舉例：「在手機上註冊」的用戶，當用戶為「試用身份」時，「在 Web」的「播放行
為」
案例：「跨平台播放」的實驗 - 學習
● 但是，提高的程度不如實驗前觀察時那麼高，為什麼？
● 初期：產品趕著上線，但盡可能埋設用戶行為追蹤
● 問題：○ 開始有「優化服務」的想法
○ 但是產品團隊滿載，非做 AB Testing 不可嗎？
33
● 假設：○ 發布優化的新流程後，可比較「發布前 vs 後」的數據指標，驗證是否有效
○ 有很多影響數據指標的因素，因橫跨不同時間，難以確認不同因素的消長
案例：AB Testing 的意義
● 指標：註冊後「付費轉換」的比率
● 訪談用戶的收穫：○ 用戶因熱門劇而來用 KKTV，且為了看劇而付費升級
○ 熱門劇完結後，也有不少用戶直接離開，申請退租
34
● 觀察用戶數據的收穫：○ 當 KKTV 有熱門跟播劇時，轉換率顯著上升
○ 播畢後若沒有接力的熱門劇，轉換率就下跌
○ 差距曾經高達一倍，大於許多流程優化的效果
案例：AB Testing 的意義
● 量化驗證和質化觀察，互相搭配補充
● 用戶「說什麼」和「做什麼」要互相驗證
● 做用戶訪談、AB Testing、各種實驗，確實花時間
● 但你願意承受「沒有用戶回饋」而「不知道成效」的後果嗎？○ 開發功能都來不及了，先讓用戶能用，比較重要...○ 功能都發布上線了，但我們「不知道用戶如何用」，跟沒開發豈不一樣？
35
案例：AB Testing 的意義 - 學習
● 無法依賴實驗結果，直接下決定
● 但能提供有價值的資訊，輔助決策
● 關鍵是「以最小化可行」的質化與量化觀察，回應最多的疑問
● 因為有了架構清楚的用戶事件紀錄
● 資料工程師 & 資料科學家可以減少處理資料的時間
● 把更多心力放在探索型的工作
● 資料人員 80% 的時間都花在清理資料，大幅降低這 80% 的時間
36
● 我們不是土豪型的公司，必須極大化每個資源的效益
● 近期：
○ 計算每齣劇被觀看的趨勢，自動標記上升或下滑
○ 計算每齣劇的 CP 值，採購成本 vs 觀看人次或時間
應用：快速調配資源
37
結語
04
● 以「顧客」為中心，打造對用戶「有價值」的服務
● 保持敏捷，逐步「假設與驗證」，實現願景
● 關注並「快速回應」市場變化，擁抱改變
● 為了生存，窮盡手段激發成長
38
● 不論質化或量化的用戶觀察，都是為了進一步強化上述心態
追求成長，需具備的心態
39
Q & A喔對了.....附帶一提....
KKTV 正在招募中！
40
Appendix
行為分群
41
簡單來說：
● 依照用戶「執行過什麼 App 內事件」來分群
● 依照用戶「遭遇過什麼事件」來分群
因為我想知道，下列用戶，誰有較高留存率？（以 KKTV 為例）
● 執行過什麼事件：○ 「註冊後 24hr 內，沒有播放」 vs 「在 24hr 內有播放」
○ 「只在單一平台播放」 vs 「曾在 Mobile 和 PC Web 都播放過」
○ 「沒使用過某個功能」 vs 「使用過」 vs 「使用過幾次」
● 遭遇過什麼事件：○ 「沒收過某個推播」 vs 「收過某個推播」 vs 「收過且點開」
○ 「初次播放遭遇卡頓」 vs 「初次播放流暢」
分析比較後，若發現「做過/遇過某個事件」有較高留存 => 設計實驗，嘗試證明因果關係
42
用 Amplitude 做 Behavioral Cohort Analysis
KKTV 的例子：註冊後 24hr 內，播放影片
已知「註冊後 24hr 內有播放」的用戶，之後更願意回來，繼續播放
但是：
● 因為「註冊後 24hr 內有播放」，所以穩定回來？
● 因為「抓對了用戶」，所以「願意 24hr 內播放」，所以穩定回來？
經驗是：
● 通常兩種情形都有，只是看那一個份量比較重
● 看那一個「交給誰更容易達成」：○ 產品中容易設計「讓用戶 24hr 內找到想看內容」的流程？
○ 行銷上容易找到「已經知道要看什麼」的用戶？
43
為什麼要設計實驗？
44
45
46
47
48
KKTV 使用的工具
● 推播、簡訊： outbound● Marketing Attribution： AppsFlyer● AB Testing： Optimizely● 主要的數據集合中心 & 用戶追蹤： Amplitude Analytics
○ 集合了以下數據：■ 後台 + 3 個 Clients 端的數據（自己串）
■ outbound 訊息推送、打開紀錄（官方串）
■ AppsFlyer 安裝紀錄（官方串）
■ Optmizely 實驗紀錄（自己串）
○ 有 Redshift PSQL 可以做自己客製化的運算，可以匯出 raw events data○ 重度利用 Behavioral Cohorts
