埋点技术说明

编写人：刘洋

确认：陈静

端：行政协同平台网页

日期：0000-00-00

状态：四条主路径已上报

一、上报目的

网页在预订、请假、访客查看、用品申领的关键步骤上报事件，用来看哪一步放弃的人多。事件进内部统计，保留 90 天。不上报手机号、请假事由和证件号。总部 420 人的正式环境从 9月1日起上报。陈静用 9月第二周的数据核对过预订单量，与数据库成功预订相差 3 笔，在约定的 1% 以内。

二、事件清单

结果码 0 表示成功，非 0 与页面提示一致。booking_submit 比 booking_success 多 48 条，其中 40 条是时段冲突，8 条是员工自己取消了未完成的点击。陈静认为冲突占比正常。

三、公共字段

1. 每条带 emp_id、办公点、事件时间和 traceId。办公点目前都是总部。
2. 时间用东八区，精确到秒。同一秒的两次点击靠 traceId 区分。
3. 失败时带结果码和页面文案的前 40 个字，不带堆栈。

四、验收与变更

新事件先在预发出现 1 天，陈静对得上数据库笔数后再进生产。事件名一旦使用就不改含义，要调整时新起名字。9月没有改名。王芳在回归里看浏览器网络面板，9月19日 Edge 上 booking_success 与新建预订单号一致。下次口径核对定在 10月第一个周一。9月第二周 booking_success 的 812 条对应数据库成功预订 815 条，差 3 条是接口成功但页面在返回前被关掉，陈静接受这个缺口。visitor_open 的 210 条里，行政周敏打开 40 次，其余是接待人本人。埋点与数据库相差 3 笔的原因已写明，陈静不要求当天追平。10月核对时若相差超过 1%，刘洋先查页面在失败时有没有上报结果码。