数据埋点表
产品：行政通
整理：刘洋
确认：陈静
版本：V1.0
日期：0000-00-00
一、埋点目的
埋点用来核对员工是否在浏览器里把会议室、请假、访客、用品办完，并给每周的办结件数提供事件级证据。刘洋负责上报，张伟负责对账，陈静决定要不要新增事件。
V1.0 只埋主路径上的展示、提交和结果。按钮悬停、滚动深度先不埋。事件名用英文小写加下划线，属性名与办结记录里的字段一致，避免同一件事两套叫法。
二、公共属性
每条事件都带下列公共属性。缺任何一项，张伟在周一对账时把该条算作无效，不进入办结件数。
- account_id：员工账号。导出给陈静时换成部门，不出现姓名。
- dept：产品研发中心、市场部或财务部。
- event_time：状态发生的时间，精确到秒。
- record_id：事项编号，和办结记录同一套。
三、事件列表
下表是 9月29日 的事件。完成表示已经在线上报且和办结记录对得上；进行中表示代码已写、还在对账；未开始表示还没有开发。
四、触发规则
提交类事件在服务端确认成功后上报，不在按钮点击的瞬间上报，以免把失败点进去。首页展示每人每个自然日只记第一次。通知打开要等企业微信回跳带来 record_id 才记，回跳失败的周记在进行中，刘洋 10月9日 前补上。
- room_submit 与办结记录一对一，取消另记状态，不删原事件。
- leave_submit 在员工提交时记一次，主管通过不另起事件名，用同一 record_id 的状态变更。
- supply_submit 只在扣减成功时记，库存不足被拦住的次数先并进提交失败，用品侧还没有单独事件名。
- room_block 计划与冲突提示同一天加，当前页面有提示、事件未开始。
五、对账
张伟每周一用上周的事件和办结记录按 record_id 对账。9月23日至9月27日，办结 312 件，四条提交事件合计 318 条，多出的 6 条是周末测试账号，已从正式数里剔除。差异超过 3% 时，刘洋当天查上报日志。本周差异 1.9%，记为通过。
9月18日 上线前，刘洋用市场部、财务部、产品研发中心各一个账号走通四条提交，张伟当天对上 12 条事项编号。其中访客有 1 条因周敏尚未确认、状态仍是处理中，按口径不计入办结，但 visitor_submit 已经留下，两边都能解释。
六、验收
新事件上线前，刘洋用三个账号各走一遍主路径，张伟在当天的导出里能按 record_id 找到。陈静只验收两件事：事件能对上办结件数，导出里没有员工姓名。notice_open 还在进行中，room_block 未开始，这两条不进入 9月29日 的对账分母。