埋点需求单

产品：行政通

提出人：陈静

实现：刘洋

日期：0000-00-00

状态：2 个事件已上线，2 个进行中，1 个未开始

一、需求背景

行政通要每周回答办结了多少、订房时有多少次撞上已占时段、访客确认用了几分钟。页面状态能回答单张单据，回答不了一周的次数。陈静列出五个事件，刘洋按提交成功或确认动作上报。用品事件等申领入口打开再做。

二、事件清单

预订的提交和冲突已在 9月18日生产环境可查。访客的提交和确认正在对市场部 12 人验证。用品事件还没有入口，保持未开始。

三、属性说明

每个事件都带账号、时间、单据号。时间用东八区，精确到秒。
booking_submit 的时段写成开始和结束两个字段，日期单独一个字段，不用拼成一句话。
visitor_confirm 的用时分钟由服务端计算，从该单据最近一次提交成功到点击确认。
属性名用英文小写加下划线。取值里的楼层用「3F」「东」这种短码，与页面显示可以不同，但要在说明里对照。

四、验收标准

陈静按脚本操作 5 次，刘洋在当天能查出 5 条，单据号与页面一致。
故意制造一次冲突或一次退回，对应事件出现 1 条，且不会把失败记成提交成功。
booking_submit 和 booking_conflict 已在 9月20日按这个方法通过，各 5 条。
visitor_submit 9月25日查出 14 条，与当天登记数一致。visitor_confirm 少 1 条，刘洋在 9月26日补查原因。

五、实施安排

访客两个事件在 9月27日前补齐确认那 1 条的差额，并写成已上线。supply_submit 等周敏交齐 18 个规格、入口打开的当天再加上，目标是 10月8日。陈静在每个事件改为已上线之后，才把它用进周五的数据表。

5 次验收脚本由陈静本人操作，不用测试账号批量造数。booking_submit 的 5 次覆盖了三个楼层、两个日期。booking_conflict 的 5 次都选了已经被占的周三 14:00，事件里带了冲突时段，页面停住。访客事件的验收放在真实登记上，9月25日的 14 条就是第一批样本，不再另造。

事件上报失败时，刘洋记在当天的差额里，不把失败算成一次成功提交。9月20日预订两类事件各 5 条，差额为 0。访客确认少的那 1 条，先查是没上报还是单据号写错，9月26日中午前给陈静一个原因。

属性对照表由刘洋维护一页：3F 表示总部三楼，东、西表示城东和城西。页面上仍显示「总部三楼」。陈静验收时按这张对照读事件，不按页面上的中文去对字段名。