数据埋点方案怎么设计提示词（从分析问题倒推事件、事件与属性命名规范、埋点文档表、上线验收清单）
新功能上线前要设计埋点、或者现有埋点乱七八糟（同一个按钮三个事件名、属性缺失、数据和后端对不上）时用：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 条评论
还没有评论，来抢沙发～