產品埋點筆記- Google Analytics 和Mixpanel埋點工具分析

產品埋點筆記- Google Analytics 和Mixpanel埋點工具分析

本文以獨立開發者@文彬設計開發的桌面端翻譯產品「多譯」為例,介紹了使用Google Analytics 和Mixpanel 兩款產品數據分析工具,進行數據埋點的相關心得.

閱讀本文你可以了解:
- 什麼是產品埋點?相關的基本概念
- Google Analytics和Mixpanel兩款產品的結構與優劣
- 如何制定產品埋點方案?以Mixpanel為例

2020-02-22 更新本文約4700字閱讀需要20分鐘

前言

在完成產品的開發後,我們需要迅速收集產品的諸多使用數據,以完成迭代改進產品的目標。以“產品改進”為目標,我們可能會提出許多問題,比如:

  • “是哪些用戶購買訂閱了我們的產品?是在什麼情況、情境下購買訂閱的呢?”
  • “產品的新手指南效果如何?用戶是否閱讀了?是否易於理解呢?”
  • “產品的主要功能使用體驗如何?會不會在哪裡造成誤解或不良體驗呢?”
  • “這樣的功能與按鈕,這樣設計是否合理呢?多少用戶可以接受這樣的改變呢?”

......

問題導向可以使我們的思考更有條理,而諸如此類的問題,有許多辦法來回答。比如通過用戶訪談、問卷,通過繪製用戶旅程地圖,通過可用性測試等等。而使用數據分析工具,對產品進行“埋點”和數據收集,成為了一種性價比極高的方式

在軟件「多譯」 (官方網站: duoyi.io )開發的過程中,我們了解了市面上多款產品埋點與數據收集的解決方案,先後比較深入地嘗試了Google AnalyticsMixpanel兩款產品。本文主要會討論關於兩款產品的異同,以及使用上的一些心得體會。

給多譯插播個廣告感興趣的可以用用看

關於數據“埋點”

對“埋點”的基本了解可以從“埋點”的一些概念開始,參考《流量統計的基礎:埋點》以及《如何掌握產品埋點》 ,也要弄明白“代碼埋點”、“可視化埋點”和“全埋點”三者的異同,參考《如何做好數據埋點》

“埋點”的概念是很容易理解的,它能夠為我們帶來以“事件”為中心的分析和以“用戶”為中心的分析。但需要將埋點方案製定、代碼開發和後續分析三者統一起來,會在工具、埋點方案等方面遇到很多困惑和困難。比如,不同的工具分別支持什麼樣的埋點?支持怎樣的數據分析?埋點方案應該如何制定?有哪些坑和建議?埋點方案和開發之間會存在哪些需要協調的問題?後續應該怎樣分析相關數據?後文將努力解答它們。

在這一部分,需要額外注意的有以下幾點:

  • 本質上,我們關注“埋點”,是希望能夠通過數據產生洞察,進而提出改進。工具的不同、埋點方式不同、埋點方案的不同,都會影響數據質量的好壞,進而影響決策的好壞
  • 高質量的數據便於分析,並且關注最有價值的部分(比如轉化、購買、核心功能和流程)。低質量的數據難以分析,可能會因為某些數據的缺乏數據過於龐雜,導致難以給出有效的結論。
  • 埋點方案與實際埋點大概率會存在出入,需要產品側和開發側協商協調進行。 (暫時沒有機會到大中廠中看產品的埋點解決方案,本文討論的內容僅在獨立開發者或小團隊級別)

埋點工具簡析

Google Analytics (GA) 和Mixpanel 都是非常強大、老牌的產品數據收集平台,都有非常多的分析功能。只是把它們的每一個標籤頁都過一遍已經是一個蠻花時間的事情了。在諸多的分析工具中,GA 和Mixpanel 屬於免費類型工具,比較適合小團隊使用。

在考慮選用的埋點工具時,需要結合所需埋點的產品類型進行選擇。 「多譯」為基於React和Electron封裝的桌面端App,本質上類似於Web網頁,因此所有適用於網頁的埋點分析工具都適用於「多譯」。但如果我們需要分析小程序等不同類型的產品,或將選用不同的埋點分析工具。此處提到的GA和Mixpanel比較適用於網頁與App,小程序則可以選用阿拉丁小程序分析工具等。

《互聯網平台埋點方案對比》一文簡單介紹了Mixpanel,Heap,GrowingIO,騰訊MTA四款數據分析工具,可以簡單了解。至於我們為啥首先選擇了Mixpanel,可能是因為強大又好看吧。 。 。 。

需要寫在前面的是,Mixpanel並不是完全免費的。 1000用戶量以下免費,否則每個月需要約¥620的費用,個人認為這個價格不盡合理。我們以一般產品10%用戶付費來估算,這意味著1000名用戶中100名付費,也就意味著客單價中7元/月的支出用於覆蓋這一費用,這無疑是比較高的。當然,這也可以理解為Mixpanel對於PMF(Product Marketing Fit)產品的篩選——只有優質的、高單價的產品才值得進行這樣的產品埋點。

接下來分別介紹兩款產品的基本框架和能力。

Google Analytics 谷歌分析

GA的分析結構主要為(由於板塊實在太多,附中文解釋的為我們常用的板塊):

# Google Analytics Structure 谷歌分析产品结构├── **Home** 主页用户可以在此处浏览整体的数据概况├── **Customization** 自定义│ ├── Dashboards 可以自定义一些看板,方便查看数据并分析│ ├── Custom Reports │ ├── Saved Reports │ └── Custom Alerts │ ├── **Real Time** 实时数据│ ├── Overview 实时在线用户的概况│ ├── Locations 所在地点│ ├── Traffic Source 用户的流量来源│ ├── Content │ ├── Events 实时在线用户发生的事件│ └── Conversions │ ├── **Audience** 用户│ ├── Overview 所有用户的概况,包括新用户、会话数、所用系统、会话时长等│ ├── Active Users 活跃用户概况│ ├── Cohort Analysis 可以通过一些指标建立用户群体,对特定群体的用户数据进行分析│ ├── Audiences │ ├── User Explorer │ ├── ...略去7项│ └── Users Flow 可以看到用户在网站上页面间的流动,但价值不如事件流大│ ├── **Acquisition** 用户获得│ ├── Overview │ ├── All Traffic │ ├── Google Ads │ ├── Search Console │ ├── Social │ └── Campaign │ ├── **Behaviour** 用户行为│ ├── Overview 概况│ ├── Behavior Flow 基于页面的行为流,价值不如事件流大│ ├── Site Content │ ├── Site Speed │ ├── Site Search │ ├── Events **重点部分**,可以查看埋点时定义的事件,以及事件流│ ├── Publisher │ └── Experiments │ └── **Conversions** 用户转化├── Goals ├── E-commerce └── Multi-channel Funnels

我們關注的核心部分在於Behavior - Events中的內容。我們可以根據一些篩選條件,比如係統、版本、是否付費等,對用戶進行分類,並觀察該類用戶的事件行為流。通過這樣的方式,一定程度上還原用戶在使用產品過程中的4W1H,即Who(哪些用戶)、When(時間相關)、Where(頁面與場景)、What(具體行為)、How(如何進行),進而思考行為背後的原因Why 。下圖是一張用戶行為流的範例,展現了所有用戶進入多譯後,所做的第1、2、3、4件事件之間的流動關係。

GA的弱點之一在於,並沒有針對每一位用戶的訊息,即我們只能根據有限的篩選條件去看一批用戶的行為流,且其事件缺乏具體時間上的順序與數據。此外,GA在每個埋點所返回的值是有較嚴格的限制的,它將每一個Event限定為包含EventCategory,EventAction,EventLabel,EventValue等字段,是一個樹狀結構的Event數據庫。

下圖是我們GA埋點方案的一部分,我們將用戶在多譯中會進行的操作分為了幾大類,如“初始化”、“翻譯核心行為”、“切換語言”等等,即Category;Action則是具體的行為內容;Label則是對行為內容的進一步闡釋,方便我們理解部分埋點;Value則是某些狀態的切換,用值去表示更加方便。在這裡,Category - Action是結構化的,而Label和Value則顯得非常雜亂。這樣的埋點方案和方式不一定是GA中最合理的,僅作簡單的展示。我們發現Mixpanel為我們搭建了一個更好的數據方案。

Mixpanel

Mixpanel為用戶準備了比較細緻的入門教學,但基本都是英文的,如果沒有耐心細細讀的話可以先看一下這篇譯文《Mixpanel埋點入門指南(2020)》 。這篇文章基本介紹了在Mixpanel或者說是大部分的埋點工具中,規劃- 設計方案- 代碼開發的基本流程,但並沒有詳細地指導如何制定埋點的方案(這一部分的內容將在下一節中展開討論)。

接下來,還是先從框架和能力入手,觀察Mixpanel這款產品。

# Mixpanel Structure Mixpanel产品结构├── **Dashboards** 可以新建许多看板,方便进行数据分析,相较GA更加整洁高效├── **Analysis** 分析│ ├── Insights 洞察可以进行数据筛选,产出报告并保存为洞察│ ├── Flows 流动和GA类似,可以看见用户事件之间的关系│ ├── Funnels 漏斗适用于选取事件自建漏斗,以分析转化与流失│ ├── Retention 留存观察用户的留存情况│ ├── Predict 预测付费功能│ ├── Signal 信号将目标与用户行为挂钩进行分析│ ├── Impact 影响衡量某个事件的影响情况│ ├── Experiments │ └── Live View 实时数据可以查看实时数据情况│ ├── **Users** 用户│ ├── Explore 探索查看所有用户的数据訊息以及单个用户的行为情况│ └── Cohorts 聚合筛选聚合某一类用户以分析│ ├── **Messages & Experiments** │ ├── Messages 付费功能│ ├── Journeys │ └── A/B Testing 付费功能│ └── **Data Management** 数据管理├── Lexicon 词汇表管理事件的备注名、描述等訊息├── Data Audit 付费功能└── Intergrations 整合其他云平台、广告商的数据

Mixpanel的主要優勢包括:

  • 非常清晰的埋點方案,帶來的是更清晰的數據與分析
  • 必要的功能齊全,以及更優良的可視化
  • 不僅僅基於“事件”而且基於“獨立用戶”的分析視角,意味著我們可以看到更多細節
  • 付費版具有更多有競爭力的功能,如A/B測試、機器學習預測用戶趨勢等

下面,我們介紹使用Mixpanel進行數據收集,相關的方案製定過程方法與開發相關事宜。

使用Mixpanel制定埋點方案

Mixpanel有給出他們建議的埋點方案製定方法與建議,具體可以在Mixpanel的Help Center和新手教程中找到,下面只是介紹我們基於「多譯」這樣一個桌面端App的埋點方案製定流程。

埋點方案模板

我們首先參考了Mixpanel給出的方法《Creating a Tracking Plan》 ,裡面給出了一張完整的表格,用以製定埋點方案。我們將表格進行了簡單的翻譯和補充,附件如下所示。

理解Event 與Property

在大致瀏覽這份模板的基礎上,我們介紹埋點方案設計中最重要的部分——理解Event和Property之間的關係,這決定了我們設置哪些Event以及它對應的Properties。

為防我的錯誤理解影響大家,這裡先附上Mixpanel官方對於Event Property的說明《Event Properties》

Event

Event(事件)和我們通常理解的“一件發生了的事情”類似,但有一定區別。

舉例來說,我們可以把“退出多譯”作為一個事件,也可以把“點擊程序退出按鈕”作為一個事件。前者更利於我們去理解一件事情,因此我們會選擇將“退出多譯”作為一個事件。

另一方面,“多譯”是一款翻譯軟件,因此“翻譯”肯定是一個核心的事件,但“多譯”中存在句子翻譯、查詞、OCR翻譯三種翻譯類型,每一種翻譯類型可能是用戶使用快捷鍵調用的,可能是點擊按鈕調用的,按鈕還分界面上和菜單欄上的......那麼在這種情況下,我們該如何定義Event呢?這裡,就引入了Property的概念。

Property

Property(性質/產權/成員描述符)的翻譯並不精確,如果學過面向對象編程(OOP)的同學可能會對這個概念感到熟悉——我理解Event的Properties,就是為了豐富描述Event而存在的各類“屬性” 。這樣講可能有些抽象,讓我們用上文提到的“翻譯”事件的例子來進一步說明。

從圖中可以看出, “多源翻譯(TRANSLATE)”作為一個Event存在,共有11個Properties,這些Properties共同描述了“多源翻譯”這一事件的各個相關因素。比如說“翻譯調用方式”告訴我們翻譯是使用按鈕、菜單欄、快捷鍵或是OCR翻譯引發的;比如說“調用快捷鍵”,如果“翻譯調用方式” == “快捷鍵”,則這裡會出現具體的快捷鍵;比如“文本長度”告訴我們這次翻譯涉及到的文本有多長,這關係到這次翻譯花費的成本和價值等等......

所以說Event往往是用戶層面心理上理解的事情,比如“打開多譯”、“瀏覽新手指南”、“翻譯”、“退出多譯”,而這些單獨的Event其實涉及非常多的相關描述,也就是Property 。比如在“退出多譯”時,你想知道這次用戶使用了多久、翻譯了多少次;比如在“翻譯”的時候,你也關心用戶使用哪種手段來觸發“翻譯”,具體翻譯了多少內容;比如“瀏覽新手指南”時,我們要知道每一頁用戶花了多少時間瀏覽,是認真讀了還是跳過去了,是否影響到後續的操作。諸如此類,都是通過Event與Property的搭配去完成描述的。

Property的分類

理解了Property的基本概念後,還需要理解Property的幾個類別:Super Property,Event Property以及User Property。這在《Event Properties》一文中也提到了。

為了簡化理解,這裡僅作簡單的類比描述:

  • Super Property是全局定義的,在每一個Event中都會返回,不需要在Event中手動添加
  • User Property是關於User的描述,比如是否付費,是否登陸等

埋點方案製定

建立在對Event和Property的理解之上,可以開始根據模板,動手製定具體的埋點計劃。需要注意的是,埋點的代碼實現本質是在用戶操作觸發前端或後端響應時,順便向Mixpanel發送一條訊息,記錄下此時的數據。所以,在考慮埋點方案的同時,也要同步考慮在開發中,這個Peoperty的觸發是否是能夠實現,需要與開發進一步溝通。

此外,在思考方案的時候,可以舉例問題來引導思考,明確方案的目標以及檢查方案缺漏。

  • 使用頻率高的用戶,都是使用什麼方法(按按鈕/快捷鍵/監聽剪貼板)進行翻譯的?
  • 點擊了“訂閱”的用戶,是在什麼情境下點擊的?我需要知道他們的哪些訊息?
  • 用戶是怎麼使用三種翻譯功能的呢?是一般一次用一種,還是會混著用?
  • 怎麼定義活躍用戶?

...... 通過這些問題,制定KPI與關鍵數據點,已完成埋點方案。

最終,多譯1.0.0上線版本的Event總數為22個,Property總數為90個左右。

數據收集與分析

在開發完成埋點後,就像我播下一顆種子,等待收穫著果實,需要一些時間積累數據並進行分析。這部分的內容將在有價值的數據與方案產出後進行介紹。

What do you think?

Written by marketer

將多個谷歌帳號與Google Analytics關聯的好處

如何分析競爭對手的Google Ads?