Google Analytics 的事件(event)功能讓我們可以在頁面層級下，更細緻的管理、查看我們所需要的使用者行為資料。但當你的產品規模愈來愈大、功能愈來愈多，你的事件也就愈來愈難以管理。特別是在你的團隊不只一個人需要進行事件蒐集的時候。
本文旨在分享筆者的事件管理經驗，以四個步驟去避免一些事件設定常見的問題，如命名模糊、重複命名、事件功能重疊以及跨團隊溝通。
步驟一：建立唯一真實來源（Single Source of Truth）
一個數位產品可能會區分成多個組成模塊，並由不同的團隊負責。有些時候行銷人員也需要對行銷相關功能進行追蹤以衡量行銷活動成效（如Banner點擊）。不同團隊各自為政、訊息不流通，就會讓資料變得難以閱讀，也可能造成相同資料重複搜集的情況。
建立唯一真實來源就可以解決這個問題 — 意即讓所有的事件追蹤都統一的在同一份文件、或同一組文件之中進行管理。這份文件應該詳實紀錄事件的追蹤目標、需求方、提出日期、設置者、生效日期等。
這樣一來，所有新的事件設置前，都可以參照此份文件以考慮到過往的事件設置，並讓所有部門保持訊息的一致。也可以讓負責設置事件的夥伴有單個、可信賴的參照目標。
筆者的做法是使用Google Sheets，方便各個相關團隊進行查看。
步驟二：建立檢索邏輯與命名規範
GA事件提供了四種資料維度：Category, Action, Label, Value。除了Value限制了只能傳送數值之外，其他三個維度都沒有形式的限制，給予了使用者很大的自由。因此你可以依據不同的檢索邏輯去建立自己的事件歸類系統。
但分類邏輯若不一致就會造成災難。考量以下的例子：
產品：襪子電商
頁面：商品列表
需求：搜集使用者的篩選行為
這個事件就可以用至少三種檢索邏輯設定，舉例如下：
- Category: Product List（頁面）
Action: Filter（行為）
Label: Used Filter (輔助資料) - Category: Filter（功能）
Action: Apply Filter（行為）
Label: Product List （輔助資料） - Category: View Product List （使用者階段）
Action: Filter （行為）
Label: Used Filter （輔助資料）
不同的命名慣例也會造成衝突。如Product List就可以被命名成Product List、ProductList、Product_List_Page。
由上可見，如果不建立一個統一的檢索邏輯與命名規範，在多個部門與時間的齊心協力之下，事件管理文件亂成一團指日可待。
至於該用什麼檢索邏輯，筆者認為依據不同產品的業務需求與企業文化，會有最適合的方式，不必依照他人的規範來做。命名規範方面，建議用首字大寫、空格分字的形式，較方便閱讀。
步驟三：指派事件文件管理員
為了確保管理文件的精確性，並簡化問責機制，最好指派一個、或少數的夥伴擔任文件管理員的角色。
文件管理員應該要是唯一可以編輯事件管理文件的人員。對文件的品質全權負責。文件管理員的工作包涵但不限於：
- 確保事件資料沒有重複搜集
- 審閱事件檢索邏輯與命名是否遵循規範
- 紀錄事件開始追蹤、更新的時間
步驟四：建立事件設定流程
最後只需要根據你的團隊結構與組織文化，設計一個可以通用的事件設定流程即可。
以下以筆者的團隊為例：
團隊基本訊息
- 設置需求來源：行銷團隊、產品團隊與其他團隊
- 事件設置實踐者：開發團隊
- 設置方式：前端程式碼與GTM通用
設定流程
- 向文件管理員提交事件規則與命名
- 檢查合規後，管理員將事件需求記錄於待設置文件
- 通知開發團隊
- 進行設置
- 上線後，管理員將該事件由「待設置」移至「線上」
Tips: 建議可以將設定流程也記錄於事件管理文件中，以方便事件需求方隨時查看。
結語
事件的管理方法並不複雜，真正複雜的是在實踐的過程。
如果你的團隊已經進行事件追蹤一段時間，那要建立這套制度更是有可能遇到重重的困難與阻擋，畢竟每個人都有自己的做事方式，而且沒有人喜歡改變。
除此之外，合適的檢索邏輯也需要時間去研究與規劃，並且也需要定時檢討，確保現下的規範、邏輯符合業務需求。最重要的是文件管理者需要扮演好自己的角色，嚴格執行規範與流程。
