網站追蹤、使用者分析、行為分析
網站使用者行為追蹤與轉換分析 — GA4、實驗分析、CDP
近 5 年網站行為分析的歷史進展，解析每一個創新追蹤方式背後的脈絡與優缺
上一篇我們走過了 GA、GTM、事件驅動分析、熱圖分析、錄影分析，許多電商、自架部落格的朋友們可能就此駐足，因為這已經夠用。
但還有更多的寶藏在後面等著我們，如果我們追蹤的初衷是相同的。
返璞歸真：追蹤分析的初衷
在介紹剩餘的追蹤分析工具前，我們再次自問：
為何要做網站追蹤與分析？
這其實與你的公司是否能長期保有獲利能力有關。
不管你是新創 SaaS 公司，作為一條龍 PM 負責網站的淨利潤率，或是成長型平台，負責電商平台後台的滿意度、幫助客戶賺錢，甚至巨型社交平台，但只負責單一模組新功能的採用率與日活躍人數。
這些最後都會聯繫到「公司獲利能力」，不管是直接、或間接。
因此接下的幾部曲會闡述到，我們對於工具的需求與期待，會橫向往外、縱向往上拓展，要求組織協作性，也要求營運效率與最大化。
五部曲：GA4 (Google Analytics 4) 強勢回歸
上一篇我們提到事件驅動追蹤對 GA 展開猛烈的攻勢，多數 SaaS 紛紛棄用 GA，或僅安裝但不額外埋點。
再不改變，GA 即將淪為時代的眼淚。
Google 畢竟不是省油的燈，在看到網站技術的進展與趨勢後，開始研發同時兼具事件與頁面分析的綜合型追蹤工具，這就是現在行銷界朗朗上口的「GA4」（Google Analytics 4）
經歷時間驗證的 GA4
GA4 非橫空出世的產品，其概念起源是 Google Analytics 360（收費版 GA），主打更多追蹤與分析功能，例如追蹤資料可以串 BigQuery、收集的事件更多、更即時的數據搜集、搭配更多 Google 生態系的支援等等，基本上就是補足免費 GA 的不足。
其中最讓人垂涎的就是「自定義屬性（custom properties）」。
GA4 借鏡 Google Analytics 360 的優點，帶來了自定義屬性，直接趕上事件驅動追蹤競品領先的路程，再加上完全免費，只打算維護一套追蹤工具的公司很大程度會直接選擇 GA4。
有了自定義屬性，GA4 的分析更上一層樓。本身除了提供不錯的模板可以直接套，首頁儀表板也提供不少即時數據推薦，並能自定義想看的維度分析。
新世代的追蹤分析無腦選項，首推 GA4。
強大的環境整合
GA4 的強大在於他累積近 20 年的核心分析模組，除了自定義事件追蹤與分析，還繼承了「頁面驅動」分析時代最強大的頁面追蹤能力，讓人不管是事件還是頁面都能無縫支援，直接捕獲行銷人員的心。
GA4 也支援多平台，網站前端、後端、iOS、Android 都能支援。
其中最棒的地方，莫過於 GA4 支援 BigQuery 匯出與備份，從此不用再擔心幾年前的數據分析不到，也能透過 BigQuery 直接運算，或串到其他可同步的生態系進行細部分析。
例如，可串到 Google 幾乎所有產品，或 BI 常用的 Tableau。大部分支援分析的第三方工具，目前也都支援 BigQuery 的自動匯入。
許多事件驅動追蹤工具一開始不追 utm 流量，因此採用者多半是同時有 web/app 的產品。
如果工程師發事件時，沒有同時發 GA、事件驅動追蹤，分析 web 轉換的行銷團隊則會特別痛苦。搭配 Google Looker Studio 有如神助
GA4 也常搭配 Google Looker Studio 串接顯示。可以直接在 Looker Studio 選擇 GA4 為資料源進行圖表分析，個人體感比 GA4 裡還要好操作。
GA4 搭配 Looker Studio 還可以使用連續技，使用其中的混合資料（blending data）組合兩個以上的資料源，工程術語：join n 個 tables。
例如在 GA4 追蹤時多追蹤使用者的 email，再於 Looker Studio 匯入你產品的各種表單，透過 email 來綁定使用者，如此一來便可以做出一個迷你版 CDP (Customer Data Platform)，進行維度分析。
要串好 Blending data，需要一些技術，但建議 PM 與 MKT 都點一些資料庫技能。
或至少能理解資料庫基礎概念，請工程師或 DA 協助串接。壯大 Google 生態系
以上操作相信不難發現 Google 的野心
透過強化自家產品線之間的連結產生獨創效益，綁住跨平台網路事業。
雖然知道野心，但仍然止不住安裝下去 GA4，就如同我們知道搜尋不能獨大 Google 但還是預設選擇了 Google 做搜尋。
不過可惜的是，Google 不提供分流測試，這也讓其他追蹤工具有機會殺出一條血路，也就是所謂的「A/B testing」。
Google 原本提供 Google Optmize 作為 A/B testing 工具，但在 2023/09 收掉，超可惜。六部曲：實驗分析 (A/B testing)
不管是產品或行銷人，在提案時通常會有 N 種選項。
團隊內對於要出哪一款可能爭執不休，通常弭平戰火的一句話會是
不然都測測看 ：）
既然可以追蹤、分析，能不能一起往前一步做實驗幫助我驗證成效？
實驗分析是為了測試假說、有更好的成效
為了說服眾人、找出最適合的選項，成本最低的方式就是做・實・驗。
從簡單的介面文字、圖片、樣式（CSS）的實驗，到功能的開啟與否、功能的不同，都可以進行測試。
建立實驗其實就是在驗證你的假說，例如下圖，我們可能對於 call-to-action 按鈕的文字要用哪一種有所爭執，心理學或介面設計理論、產品經驗、或易用性訪談都能夠協助我們建立不同的假說。
例如，你可能主張人性化的字可以有更好的體驗，因此提高接受率。
透過實驗讓使用者實際行為幫你投票，驗證假說是否正確。
你可以使用工的具如 Optimizely、AB Tasty、VWO Testing 來幫助你從介面上分群測試。
在做實驗前你需要先確認你這次要實驗的
- 變因
- 目標指標
例如上面的範例，我們想實驗的變因是「按鈕文字」，版本 A 是 Save/Discard、版本 B 是 Yes/No，並在控制住其他變因都相同，測試最後的「點擊率」。
這也會延伸一些可能問題（僅作概念討論不深挖）
- 實驗時長（時間不夠長導致不具統計效應）
- 實驗新穎性（很有趣所以使用者點擊嚐鮮）
- 目標指標的設定（可能點擊的人變多但點的人都不是理想 TA）
以上是比較表層的實驗結果，但如果我的實驗不是文字、圖片這麼單純，而是某個功能是否開啟、或某項使用額度的差異呢？
顯然這需要一個更深度的整合的工具，而且我們還可以做得更科學一點。
做更深度的實驗，找出洞見
一個實驗要被認為有效，需要滿足最低程度的統計需求。白話文叫具有統計效應，專業點叫具統計顯著性。
具有統計顯著性，你的實驗結論也將更有說服力。
我們抓 2 個重點來看進階分析的統計需求
- 量要夠大（多大才夠請和資料科學同仁討論）
- 樣本要隨機（例如性別、購買力、身上的標籤要盡可能平均）
這兩個需求背後衍生的工具需求則是
- 幫我分群（Segmentation）
- 幫我紀錄指定事件（Event collecting）
實驗類的工具如 VWO Testing 就可以做到以上一切，除了透過前後端讓你發送指定事件（如造訪、加入購物車、購買），也可以從後端隨機指定樣本 A 或 B，最後根據實驗者的期待，把不同實驗的成效做個彙整與比較。
看起來實驗很重要，但要消耗的腦力與人力也不少，因此許多公司會放棄、或只挑重點決定去做 A/B testing。
面向企業客戶的 B2B 公司通常也少用 A/B testing，一部分是流量不大恐不具統計顯著性，另一部分則是更依賴質化需求訪談。
如果你服務的是 C 端客戶，請毫無懸念進行 A/B testing。
如果你的產品或平台需要高速自動化 A/B testing，可以參考 Coupang 的 Lambda 架構。
https://www.ithome.com.tw/news/159890七部曲：CDP (Customer Data Platform)
做網站分析久了，自然會有一種王者心態
我能不能只看一個平台就完成所有的操作？
有的，就是無所不能的 CDP。
CDP 顧名思義整合了所有客戶的資料，做單一平台上進行分析、創造洞察、再行銷與留存。本質上 CDP 在協助強化客戶留存的整體價值。
但世間免費仔畢竟是多數，我們是否有辦法利用免費工具兜出一套「迷你 CDP」？
試做迷你 CDP：先處理第一方資料整合
不管是 GA4、錄影分析、事件驅動分析乃至實驗分析，都遇到一個問題：
這無法跟我的會員系統、訂單系統、其他數據串在一起
講到「串資料庫」，我們第一個想到上面討論到的 Google Looker Studio，透過 join table 功能，把幾個重要的會員資料綁在一起。
例如我們可以透過 email 作為唯一值（unique key）去綁定
- CRM 會員系統（email, name, gender, company, etc.）
- Events（email, event name, event property）
- POS 系統（email, name, order）
- 訂單系統（email, name, time, order）
- 客服系統（email, record）
以上不需要每一個表都要有 email，但沒 email 的要和有 email 能透過每個唯一值對應到（沒錯免費仔就得花點時間理解這些技術細節）。
把以上串起來後，你可以得到一張大表，一張紀錄所有會員的行為歷程、訂單紀錄、客服紀錄的資料庫。這樣就不用要分析某個面向時，還要特地去開那張表進行分析，也可以做跨面向進行交叉分析。
但這張大表依然不能滿足成效慾望強大的產品人、行銷人，問題又多了：
- 資料處理速度很慢（畢竟用的是免費資源，過量會被禁止）
- 無法自動化串資料來整合（除 Google 產品，基本上要每天手動處理）
- 僅能顯示、沒有 Insight（很吃分析者的功力）
- 無法進行下一步（例如針對留存低的發信、生日時發送優惠）
- 其他整合性與應用性問題
如果你只需要迷你版 CDP，Looker Studio 已經可以協助你以最低程度整合數據。
但若想把分析與營運做好，挾行銷、營運、產品、工程團隊一起贏得市場，這還遠遠不夠。
CDP 的重點：留存價值最大化
CDP 除了繼承了我們試做迷你版 CDP 能做到的「多方資料統整」外，也解決了上述 5 項問題，帶來多種行銷與營運價值。
從 3 點去看 CDP，分別是 D・I・G。
1. Data：處理速度快、整合性高、安全性穩
一般 CDP 廠商會使用常見的「雲」做資料同步，例如 Google 的 GCP、Amazon 的 AWS、Microsoft 的 Azure，這些雲的處理能力都是國際級的，速度不是問題。
除了自家的第一方數據，你有使用的其他第三方資料也可以一起串進來。例如你可能有使用 LINE 官方帳號如漸強實驗室，Messenger 如 Super 8，或者電商銷售數據如 Shopline、91APP。
你也可以根據自家 IT 團隊的需求，選擇把雲放在自家，增加資料的隱私安全度。
如果你的公司不是 stratup，也請留意國際資料傳輸，確定 CDP 有符合 GDPR、CBPR 等規範。2. Insight：整合分析，發現洞見
CDP 平台多能透過簡易方式協助建立圖表，例如準備好圖表、推薦我們應該分析初階消費者都把哪些商品加入購物車，或者告訴我們一般粉絲轉鐵粉的條件，可能是購物金額要到達指定金額，或是每月購買頻率要多少。
有些則會提供銷售模型協助營運，如提供 RFM(Recency, Frequency, Monetary) 模型，分析指定受眾群的多久消費一次、最近消費是何時、平均消費金額。
除了系統推薦，我們也能如 GA4 主動做多維度分析。
有些 CDP 能整合 GA4 或事件驅動追蹤工具，因此除了繼承他們原有的分析能力，還能再整合自家線下、其他來源的數據來綜合分析，找到更全面的洞見。
3. Growth：採取行動，增進成長
最基礎的 CDP 會提供各種行銷自動化功能，例如 email、SMS、LINE 官方帳號、Messenger、WhatsApp、AppPush 等。
行銷自動化可以減少繁瑣工作、增進效率。例如，我們可以設定在每月 1 號發優惠券給該月生日的壽星。
行銷自動化也能增加銷售。例如在消費者離站 10 分鐘後，透過 LINE 官方帳號提醒還有 3 個商品留在購物車。
若搭配 AI，將能創造更高的價值。例如在發送促銷訊息時，透過 AI 自動幫我們選消費者開啟率高的渠道，或是在消費者最容易查看訊息的時間發送；有些也能透過 AI 找到相似的受眾，開發更多剩餘價值；甚至在內站自動跳提醒，增加結單機會。
台灣市面上有的 CDP 選項不多，如 iKala CDP、Appier、OmniSegment 等。
不過，CDP 不便宜，但相對地也可能提供豐碩的回報，請以認識取代暴衝。
下文雖長但相信可幫助你理解更多：
圓舞曲：痛過才懂的小撇步
廣告追蹤與投放
在做行銷或營運時，當然我們最希望有如 CDP 一樣的方式「直接」觸及到客戶。但多數時候，客戶不會在第一時間信任你、成為會員，也會在消費前猶豫很久。
因此我們需要：
- 捕抓這群猶豫的人
- 透過廣告做再行銷
如何圈這群人？這需要 DMP（數據管理平台）的協助，不過我們簡化以實際案例來談。
例如你最終想透過 Meta 廣告找回那些「加入購物車但沒消費」的人，你可以使用 Meta 的 Meta Pixel 或 Conversions API，當潛在客戶執行以上條件時，發送事件給 Meta。
Meta 在幫我們紀錄後，我們可以在下 Meta 廣告時（廣告組合時設定），把指定事件作為 TA 條件進行再行銷。
以結果來說，那群加入購物車但沒消費的人會看到我們的廣告，而行銷人員也可以在背後做 Meta Ads A/B testing 去找到最適素材。
如果是要透過 Google Ads 的話則更簡單，如果 GA4 事件都有送，只需要在 Google Ads 設定指定事件作為條件去發廣告即可。
事件管理：Spec 與版控
對產品與開發團隊來說，事件管理一直是個問題。
- 維護在自家文件庫很麻煩
- 正要上版和還沒上版的事件會打架
如果追蹤事件的平台能提供事件管理，豈不美哉？
現在多數的事件驅動追蹤平台都提供此功能，例如 Amplitude 與 Mixpanel，很可惜 GA4 沒有支援，要不然其他人真的沒得玩。
在事件管理功能中，PM 與工程團隊可以這樣協作
- 開一個副本（branch），在這裡新增與編輯事件細節
- 每一個事件、屬性都會做命名、型別檢查，以防 PM 寫錯
- 工程師根據該副本的改變作為 spec 去寫 code
- 工具會檢查工程師是否有依照 spec，以防工程師寫錯
- 正式上版，把該副本合回主線（main）
這個美妙的工具在多位 PM、多團隊時尤其有效。
你可以想像當 2 位 PM 對同一個功能加描述時，可能會彼此「覆蓋」，又或者工程師可能埋了錯誤的追蹤事件，弄髒所有資料。
在事件管理功能的幫助下，我們整體降低錯誤，大家也可以各司其職，擁有更好的團隊協作體驗。
曲終人不散：了解、思考、選擇
網站追蹤與分析到此也就告一段落，但關於工具的演化與創新，必定是方興未艾，更多的新工具勢必繼承上一代工具的好處去進化。
不過即便外面世界一直變，不變的是我們追蹤與分析的初衷：更好的公司獲利能力。
這兩篇文的起源，雖說是年輕同事無意的一句話，同時我也想帶出一個解決問題的新方式。
透過瞭解所有選項、以及其歷史，我們可以逐漸掌握該主題的本質，並在理解的過程更了解自己的需求，答案則在我們了解完畢後應然而生。
網站追蹤與分析是個跨團隊的大工程，產品、行銷、營運、工程、資料科學團隊都必須用力參與。
如果大家一起認真研讀這個主題，相信一起做的決定，必定能為你們的產品或服務，帶來最大的收益。衷心祝福！
如果你覺得這篇對你有用，或身邊有對網站追蹤分析有興趣的朋友，歡迎你拍手、留言、分享給你的朋友們囉！
