analytics-tracking
作者 alirezarezvanianalytics-tracking 可協助 agent 規劃、稽核與除錯 GA4 和 Google Tag Manager 實作，涵蓋 event taxonomy、conversion tracking、UTM capture、custom dimensions、dataLayer checks 與 tracking QA。在依賴報表或歸因結果之前，可先用於 Analytics Implementation 相關工作。
這個技能評分為 84/100，對想用 agent 設定、稽核或除錯 analytics tracking、並降低通用提示詞不確定性的目錄使用者來說，是相當可靠的上架候選。此 repository 提供內容扎實的 SKILL.md、針對 GA4/GTM/event tracking 工作的清楚觸發詞、實用的除錯、taxonomy 與 GTM patterns 參考，並附有 tracking plan generator script。使用者仍應預期需要依自身技術堆疊與安裝流程調整相關指引。
- 觸發條件明確：frontmatter 清楚列出 GA4 setup、Google Tag Manager、event tracking、conversion tracking、analytics audits、missing events 等使用情境。
- 實作參考完整：分別提供 tracking 問題除錯、event taxonomy 標準，以及 SaaS GTM implementation patterns 的指南。
- 不只是提示詞輔助：tracking_plan_generator.py script 可依結構化輸入產生 event taxonomy、GTM configuration 與 GA4 dimension 建議。
- SKILL.md 未提供安裝指令，因此使用者可能需要依照 repository 結構自行判斷安裝方式。
- 內容摘錄主要聚焦 GA4、GTM 與 SaaS 情境；若團隊使用其他 analytics stack，可能需要調整工作流程。
analytics-tracking skill 概覽
analytics-tracking 適合用來做什麼
analytics-tracking skill 可協助 AI agent 規劃、稽核與除錯分析追蹤實作，特別適用於 GA4、Google Tag Manager、事件分類法、轉換追蹤、UTM 擷取、自訂維度與資料品質。對於需要先確保埋點可靠，才放心使用報表、廣告最佳化、歸因或漏斗分析的團隊來說，這項 skill 特別合適。
最適合的使用者與任務
如果你是創辦人、行銷人員、產品經理、analytics engineer 或開發者，正在確認：「我們是否用正確的名稱、參數與工具，追蹤到正確的客戶行為？」那麼可以使用這個 analytics-tracking skill。它最擅長 Analytics Implementation 類任務，例如建立追蹤規劃、標準化事件名稱、檢查 GTM 設定、診斷 GA4 事件遺漏，或把商業目標轉成可衡量的轉換事件。
比一般提示詞更有用的原因
這項 skill 內含帶有實作觀點的參考資料，不只是泛泛而談的分析建議。repository 提供 debugging playbook、event taxonomy guide、GTM SaaS patterns，以及 Python tracking plan generator。這讓 agent 能依循具體流程：定義商業脈絡、對應事件、套用命名規則、建議 GA4/GTM 設定，並從 app 的 dataLayer pushes 到 GA4 DebugView，逐層驗證資料是否正確通過整個追蹤鏈路。
什麼情況下不適合使用這項 skill
如果你的主要目標是分析活動成效、設計儀表板，或在資料已經乾淨之後解讀產品使用趨勢，就不建議安裝 analytics-tracking。它聚焦的是埋點與追蹤品質。若要做活動報表，請使用 campaign analytics workflow；若要做 BI 或產品分析探索，請使用 product analytics workflow。
如何使用 analytics-tracking skill
analytics-tracking 安裝方式與 repository 路徑
使用以下指令從 GitHub repository 安裝 skill：
npx skills add alirezarezvani/claude-skills --skill analytics-tracking
原始路徑是 marketing-skill/skills/analytics-tracking。安裝後，請先閱讀 SKILL.md，接著在要求 agent 產出實作內容之前，先檢視這些支援檔案：
references/event-taxonomy-guide.md：用於命名與參數標準references/gtm-patterns.md：用於 GTM tag、trigger 與 variable patternsreferences/debugging-playbook.md：用於診斷事件遺漏scripts/tracking_plan_generator.py：用於結構化 tracking plan 產生邏輯
需要提供哪些輸入，才能產出有用結果
若要讓 analytics-tracking 發揮效果，不要只要求「設定 GA4」，而是提供實作脈絡。請包含：
- 商業類型，例如 SaaS、ecommerce、marketplace 或 lead generation
- 主要頁面、routes、產品流程與表單
- 主要轉換與次要 micro-conversions
- 目前技術堆疊：GA4、GTM、server-side tagging、Segment、RudderStack、custom code
- consent mode、GDPR/CCPA 或 cookie banners 是否會影響追蹤
- 既有事件名稱、已知缺口、重複事件或失效轉換
- 需要維持 UTM 或轉換一致性的 paid channels
較弱的提示是：「Set up analytics for my app。」
更好的提示是：「Use analytics-tracking to create a GA4 and GTM tracking plan for a B2B SaaS app with homepage, pricing, signup, onboarding, dashboard, demo request, trial start, and subscription purchase. We use GTM, need consent-aware tracking, and want event names that follow a consistent taxonomy。」
實作時的建議工作流程
請先從 event taxonomy 開始，而不是直接設定 tags。要求 agent 依照 repository 的 object-action convention 定義事件，接著指定 triggers、必要參數、選填參數、是否列為 conversion，以及優先順序。下一步，再把每個事件對應到 GTM pattern：重要動作最好使用 app 層級的 dataLayer.push() events，而不是只依賴容易失準的 click-only triggers。
除錯時，請要求 agent 使用 playbook 中由下而上的堆疊檢查方式：app code 或 dataLayer、GTM firing、network requests、GA4 processing，最後才看 GA4 reports 或 DebugView。這可以避免常見錯誤：一開始就看 GA4 reports，然後憑猜測判斷資料為何消失。
能有效啟用這項 skill 的提示範例
「Use the analytics-tracking skill as an Analytics Implementation guide. Audit our current GA4/GTM setup for a SaaS funnel: /, /pricing, /signup, /app/onboarding, /billing. Current events are SignUp, signup_complete, trialStart, and purchase. Problems: signup conversion is missing in GA4, pricing views are duplicated, and paid campaigns need reliable UTM capture. Produce: 1) corrected event taxonomy, 2) GTM tag/trigger/variable changes, 3) GA4 custom dimensions, 4) debugging checklist by layer, and 5) a rollout QA plan。」
analytics-tracking skill 常見問題
analytics-tracking 適合初學者嗎？
適合，只要你能描述自己的網站或產品流程。這項 skill 可以把初步的商業目標轉換成事件與參數，但你仍然需要有 GA4、GTM、網站程式碼的存取權，或能聯繫到負責這些工具的開發者。初學者應要求 agent 提供逐步計畫，並解釋 dataLayer、custom dimensions、DebugView 等術語。
這比一般 GA4 提示詞好在哪裡？
一般提示詞可能只會產出通用事件清單。analytics-tracking skill 更偏向實作：它會推動 agent 標準化名稱、避免重複事件、定義 GTM 架構、考慮 consent 與 UTM 處理，並從源頭事件一路往上除錯。這很重要，因為分析追蹤失敗通常不會明顯報錯，而且高度依賴實際設定。
它可以產生完整 tracking plan 嗎？
可以。內含的 scripts/tracking_plan_generator.py 顯示了一套流程，可根據 business type、key pages、conversion actions、paid channels、consent requirements 等結構化輸入，產出 event taxonomy、GTM configuration 與 GA4 dimension recommendations。請把輸出視為草稿，並交由工程與行銷利害關係人共同審閱。
採用時最常見的阻礙是什麼？
最大的阻礙通常是脈絡不完整、缺乏工具存取權，以及商業定義不清。如果團隊尚未一致認定什麼算 conversion、lead、signup、trial 或 purchase，這項 skill 可以提出 taxonomy，但無法替團隊解決商業歸屬與決策責任。此外，除非網站具備穩定 selectors 或 app-level event pushes，否則 GTM click triggers 可能不夠可靠。
如何改進 analytics-tracking skill
用更完整的脈絡改善 analytics-tracking 結果
改善 analytics-tracking 輸出的最快方式，是提供真實流程與限制條件。加入 URLs 或 route names、GTM tags 截圖、目前 GA4 event lists、失效事件範例、consent banner behavior，以及業務或行銷實際使用的精確 conversion definitions。這樣 agent 才能產出接近可直接實作的建議，而不是停留在理論性的 tracking plan。
常見失敗模式與檢查重點
請留意事件膨脹、命名不一致、參數遺漏、過度依賴按鈕點擊 triggers、single-page apps 中重複 page views，以及太早在旅程中標記 conversions。也要檢查個人可識別資訊是否可能外洩到 GA4 parameters。請要求 agent 標示隱私風險，並定義哪些 parameters 絕對不應送出。
初版輸出後如何迭代
第一版計畫完成後，請用三個角度進行審查：商業價值、技術可靠性與報表可用性。可以問：「哪些 events 對決策最關鍵？」、「哪些需要開發者埋點，而不能只靠 GTM tracking？」以及「哪些 parameters 應該成為 GA4 custom dimensions？」接著要求 agent 產出 GTM Preview、browser network requests 與 GA4 DebugView 的 QA checklist。
值得考慮的 repository 改進方向
若要改進 analytics-tracking skill 本身，可以為常見情境加入 example input/output files，例如 SaaS signup、ecommerce checkout 與 lead generation。範例 tracking-plan.json、consent-mode checklist，以及精簡的 GA4 custom dimensions template，都能讓這項 skill 更容易導入。現有 references 已經有幫助；若再加入 end-to-end examples，將可降低新使用者在設定時的不確定性。