App 數據埋點與事件追蹤指南：先定問題再定事件，做出看得懂的漏斗與留存

App 上線後，老闆最常問的問題是：「為什麼下載的人很多，真正下單的人很少？」這時打開後台，才發現App 數據埋點只有預設的開啟次數與活躍人數，看不出使用者到底卡在哪一個畫面。

另一種狀況剛好相反：開發時把能想到的點擊全都埋了，事件清單長達好幾頁，名稱各自為政，結果每次想分析都要先花半天搞清楚哪個事件代表什麼。

事件追蹤做得好不好，關鍵不在工具，而在順序。以下說明怎麼從問題倒推事件、怎麼寫事件命名規格表、漏斗與留存怎麼看，以及隱私同意與上線前驗收的做法。

先定問題，再定事件

埋點最常見的錯誤，是先問「要追蹤哪些按鈕」，而不是「我們想回答什麼問題」。正確的順序是：

1. 列出商業問題：例如「新使用者註冊後，有多少人完成第一次下單？」「推播帶回來的使用者，會不會比自然開啟的人更常購買？」
2. 定義衡量方式：這個問題要用哪個比例或數字回答？分母是誰？時間範圍多長？
3. 倒推需要的事件與參數：要回答上面的問題，至少需要「註冊完成」「首次下單完成」兩個事件，以及事件上的來源參數。
4. 確認誰會看、多久看一次：沒有人會看的數據，就不必埋。

建議一開始只挑三到五個核心問題。問題清楚了，事件自然不會失控；問題模糊，埋再多也只是噪音。

問題與事件對照範例

設想一間做預約服務的 App，可以這樣整理：

• 問題：預約流程卡在哪一步？ → 事件：查看服務、選擇時段、填寫資料、預約送出、預約成功。
• 問題：哪個來源帶來的使用者最常回訪？ → 事件：首次開啟（帶來源參數）、之後每次開啟。
• 問題：推播有沒有用？ → 事件：推播開啟（帶推播類型參數），再看後續是否預約。

推播成效的設計細節，可以搭配App 推播通知策略一起規劃。

事件命名規格表：讓所有人講同一種語言

事件一旦上線就很難改名，改了就會讓前後數據斷裂。所以命名規則要在開發前定好，寫成一份規格表，開發、行銷、產品都依它溝通。

命名原則

• 統一格式：例如一律用英文小寫加底線，採「物件_動作」結構，像 booking_submitted、signup_completed。
• 用過去式表示已完成：purchase_completed 代表交易真的成功，不是按下按鈕而已。按鈕點擊與結果要分開記。
• 不要把變數塞進事件名稱：不要建立 view_product_123，而是 product_viewed 加上 product_id 參數。
• 跨平台同名：網站與 App 的同一個行為用同一個事件名稱，才能合併比較。

規格表欄位

每個事件在規格表上至少要有以下欄位，業主明天就可以開一份試算表照填：

• 事件名稱：依命名原則。
• 觸發時機：精確描述，例如「伺服器回傳預約成功後」，而不是「按下送出時」。
• 參數：名稱、型別、範例值、是否必填。
• 對應的問題：這個事件是為了回答哪個商業問題。
• 平台：iOS、Android、網站哪些需要。
• 負責人與狀態：規劃中、開發中、已驗收。

觸發時機寫不清楚，是數據對不起來最常見的原因。同樣叫「下單」，有人在按鈕被點擊時送，有人在付款成功後送，兩個數字自然天差地遠。

漏斗分析：找出使用者在哪一步離開

漏斗是把一連串步驟排起來，看每一步有多少人走到下一步。建立漏斗時要注意：

• 步驟要有先後順序：漏斗只對線性流程有意義，例如註冊、結帳、預約。
• 設定合理的時間窗：使用者今天查看、三天後才下單，算不算同一次轉換？要依產品特性決定。
• 依條件切開看：新舊使用者、iOS 與 Android、不同 App 版本、不同來源。整體數字常常掩蓋問題，切開後才看得出是某個版本或某個平台出狀況。

看到某一步流失特別多時，數據只告訴你「在哪裡」，不會告訴你「為什麼」。下一步是去看那個畫面本身、找幾位使用者實際操作，或在那一步加上錯誤事件，例如 payment_failed 帶錯誤原因參數。

留存分析：使用者有沒有回來

下載數與註冊數只代表使用者來過，留存才代表產品有沒有被需要。常見的看法是同期群留存：把同一週首次使用的人分成一組，看他們在之後第一週、第二週、第四週還有多少人回來。

解讀留存時的幾個原則：

• 先定義「回來」的標準：只是開啟 App 算不算？還是要完成某個核心動作？以核心動作定義的留存更有意義。
• 比較同期群的變化：改版前後的同期群留存曲線有沒有變好，比看單一數字更能判斷改版是否有效。
• 產品使用頻率不同，標準就不同：每天用的記帳 App 與一年用幾次的旅遊 App，留存的合理樣貌完全不一樣，不要拿別的產品類型當標準。

隱私與同意：蒐集前先想清楚

App 的分析資料多半屬於使用者行為資料，若能與帳號串接，就可能構成個人資料。幾個基本原則：

• 只蒐集回答問題所需的資料：不記錄輸入框內容、不把電子郵件或電話當成事件參數傳送。
• 在隱私權政策中說明：蒐集哪些資料、用途、是否與第三方分析服務共享、保存多久。寫法可參考隱私權政策與個資法重點。
• 依平台規範處理追蹤同意：iOS 對於跨 App 追蹤有明確的授權機制，商店上架時也要如實填寫資料蒐集說明，這部分在App 上架前檢查清單有整理。
• 提供選擇退出的方式：在設定頁讓使用者可以關閉分析資料蒐集。

不同地區的個資法規要求不同，若服務對象跨國，建議依個案諮詢法律專業人士。

埋點驗收：上線前一定要逐筆檢查

埋點最怕的是上線一個月後才發現事件根本沒送、或參數全是空值，而這段時間的數據再也補不回來。驗收的做法：

• 用除錯模式即時檢視：多數分析工具都有即時除錯畫面，測試人員照規格表逐一操作，確認每個事件都有送出、參數正確。
• 走一遍完整流程：從首次開啟、註冊、到完成核心動作，確認漏斗上的每一步都有事件。
• 檢查例外情況：付款失敗、網路中斷、使用者中途返回，事件是否正確記錄或正確地不記錄。
• 確認沒有重複送出：畫面重新整理或返回時，同一事件不應被送兩次。
• iOS 與 Android 都要測：兩個平台通常由不同程式碼實作，最容易出現不一致。

建議把埋點驗收列進整體驗收清單，與功能測試同等對待，做法可參考軟體驗收怎麼做。

與網站 GA4 的分工

如果你同時有官網與 App，網站的設定方式可以參考企業網站 GA4 設定指南。兩者的分工建議是：網站負責內容與導流的分析，App 負責使用行為與留存；核心轉換事件跨平台同名，讓管理報表可以合併呈現。

每次 App 改版時，也要回頭檢查規格表：新增畫面要不要埋點、舊事件的觸發時機有沒有因改版而改變。埋點不是一次性的工作，而是跟著版本一起維護，這一點與App 上線後的維護與系統更新是同一件事。

埋點規劃做得好，後面每一次改版的判斷都會更有依據。NETVANA 在 App 開發時，可以協助從商業問題倒推事件、整理命名規格表，並把埋點驗收納入上線流程；軟體服務一律採詢問報價制，依你的 App 範圍評估。想討論你的 App 該追蹤什麼，歡迎與我們聯絡，服務項目可參考軟體服務介紹。

延伸閱讀：官網的分析怎麼設定，看企業網站 GA4 設定指南；推播帶回的使用者怎麼衡量，看App 推播通知策略；上架時的資料蒐集說明怎麼填，看App 上架前檢查清單；分析資料的告知與同意，看隱私權政策與個資法重點；改版後埋點怎麼跟著維護，看App 上線後的維護與系統更新。