Q3.11.2Instrumentation-limited question space设计研究
埋点设计决定日后可回答的问题
别名: 埋点方案 · 事件设计 · analytics taxonomy
概念解释
日后能用数据回答的问题，不会超出当时声明过的事件、属性和标识符。埋点设计就是在划定这个提问空间：有没有“应用筛选”、筛选项是否作为属性、能否把同一次会话串起来。没设计进去的问题不是“还没分析”，而是仪器看不见。先堆点击再问研究问题，等于让仓库的货架决定能卖什么。
机制
每个事件是一次对世界的切割：触发条件、携带字段、主键、时间戳。切割之外的状态变化等于没发生。属性的基数和粒度决定能切到哪一层——有商品类目才能问类目，有实验分组才能问处理效应。会话、用户、设备哪一层标识稳定，决定分析单位能站在哪一层。团队往往按当前看板要的几个数字埋点，于是六个月后的新问题撞上空白字段。提问空间是设计产物，不是数据长出来之后才有的性质。
怎么研究
从研究问题和决策倒推：要区分哪些答案，必须看到哪种状态变化，必须带上哪些键。把候选问题写成“若有该事件和这些属性，则可以估计什么；若没有，则只能停在哪一层”。评审埋点表时检查空属性、无法拼接的标识，以及只有总量没有分母的事件。用一小段真实任务走查：该任务的关键动作是否都有事件、是否能在事后复原路径。发布后用这些问题做验收，而不是用“事件条数是否增加”。
边界
并非每个可想象的问题都值得占用客户端性能和隐私预算；提问空间应当故意小于可能的世界。探索期可以先埋较粗的事件，但要承认细问题不可答。第三方分析工具的默认事件是它们的提问空间，不是产品的。法律禁止采集的字段会永久挡住一类问题，应在研究计划里删除，而不是指望上线后再“想办法”。
怎么落地
- 埋点评审会从“下个季度必须能回答的三个问题”开场，逐条对照事件和属性是否撑得住。
- 每个关键任务写一条期望路径，路径上每一步对应一个事件；缺一步就补埋，而不是事后用页面浏览冒充。
- 拒绝没有属性字典和标识策略的“先埋着”。
- 上线后用那三个问题各跑一遍查询；跑不出来就视为埋点未完成，而不是分析未完成。