數據埋點方案怎麼設計提示詞（從分析問題倒推事件、事件與屬性命名規範、埋點文檔表、上線驗收清單）
新功能上線前要設計埋點、或者現有埋點亂七八糟（同一個按鈕三個事件名、屬性缺失、數據和後端對不上）時用：AI 從你想回答的業務問題倒推需要哪些事件和屬性，按統一規範命名，輸出開發和測試都能直接使用的埋點文檔表和驗收清單。
通用大模型 對話模型通用
你是一名數據產品經理，擅長設計「少而精」的埋點方案。請為下面的功能設計埋點。 - 產品與功能：[產品與功能]（例：App 新上線的優惠券中心） - 上線後想回答的問題： [分析問題] - 使用的埋點或分析工具：[埋點工具]（例：神策、GrowingIO、自建埋點、GA4） - 已有的命名規範或公共屬性（如果有）： [已有規範] - 端：[端]（例：iOS、Android、小程式、Web） 請輸出： 1. 指標倒推：把每個分析問題拆成需要的指標，再列出計算這些指標需要的事件和屬性。沒有對應分析問題的事件不埋，避免「先埋了再說」。 2. 採集方式選擇：每個事件在前端採集還是後端採集。原則：與交易、支付、狀態變化相關的「結果」以後端為準；曝光、點擊、瀏覽時長等行為在前端採集。 3. 命名規範： - 事件名統一格式（例如「對象_動作」，全部小寫加下劃線），動作用過去式或統一的動詞表； - 屬性名、屬性值的取值枚舉，避免同一含義多種寫法； - 公共屬性（用戶編號、裝置、版本、渠道、頁面）與事件專屬屬性分開。 4. 埋點文檔表：事件名 | 中文名 | 觸發時機（寫清楚「點擊時」還是「接口成功返回後」）| 採集端 | 屬性名 | 屬性類型 | 取值說明與示例 | 對應的分析問題。 5. 曝光事件的定義：什麼算一次曝光（出現在螢幕多少比例、停留多久），列表中如何去重。 6. 驗收清單：測試同學如何逐條驗證（觸發時機、屬性是否完整、取值是否在枚舉內、是否重複上報），上線後核對埋點數據與後端數據的差異範圍。 7. 私隱合規：不採集不必要的個人資料，涉及用戶標識時的處理方式，提醒遵守私隱政策與相關法規。
高亮處換成你自己的內容：[產品與功能]、[分析問題]、[埋點工具]、[已有規範]、[端]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[分析問題] 是整個方案的起點，寫成上線後真正要回答的問題，例如「領券的人中有多少在 7 天內用了券」「哪個入口進來的用戶領券率最高」。問題越具體，埋點越精簡。
常見坑：
- 不從分析問題出發，什麼都想埋，結果事件幾百個，真正要用時卻發現缺了關鍵屬性。
- 「領券成功」在前端點擊時就上報，接口實際失敗了也算成功，數據和後端對不上。結果類事件以後端為準。
- 不同端、不同開發人員給同一個動作起不同的事件名，分析時還要手工合併。命名規範和文檔表就是為了解決這個問題。
追問技巧：追問「根據這份埋點文檔，寫出領券率和用券率的計算 SQL」，或「審查我們現有的埋點表，找出重複和命名不一致的事件」。
示例輸出
示例，僅供參考（埋點文檔表節選）
| 事件名 | 中文名 | 觸發時機 | 採集端 | 屬性 | 對應問題 |
|---|---|---|---|---|---|
| coupon_center_viewed | 瀏覽優惠券中心 | 頁面加載完成 | 前端 | entry_source：入口（home_banner / my_page / push） | 哪個入口帶來的用戶最多 |
| coupon_claim_clicked | 點擊領取 | 點擊「領取」按鈕 | 前端 | coupon_id、position（列表中第幾個） | 領券轉化 |
| coupon_claimed | 領券成功 | 領券接口成功寫入後 | 後端 | coupon_id、user_id、claim_channel | 領券率（以此為準） |
| coupon_used | 使用優惠券 | 訂單支付成功後 | 後端 | coupon_id、order_id、discount_amount | 用券率 |
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～