埋点系统产品需求文档 V2.14.0（十页图文完整版）#

本文将来源信息分为三种：【原文】表示现有需求明确提出；【设计】表示为完成埋点系统而补充的产品方案；【待确认】表示源版本缺失、跨版本冲突或需要业务决策。缺失版本不阻塞首版设计，但不得把推断直接当成生产规则。

版本适用规则：第 1-22 章完整继承【埋点系统需求 V1.2】的系统建设、对象、事件、指标、风控、质量、权限、非功能和实施要求；第 23-28 章为 V2.13.0 整合后的页面与交互要求；第 30-40 章为本次按最新线上原型逐页复核后的现行要求。发生冲突时，以章节号较大的要求为准；未冲突内容全部继续有效，不得因后续页面迭代而省略。

1. 建设背景#

现有 SaaS 包网产品已覆盖多站点、多渠道和多国家，核心业务包括用户注册登录、游戏大厅与游戏订单、充值提款、VIP、代理裂变、活动、消息推送、PWA/W2A 投放、域名运维及运营后台。已有需求中存在部分 Pixel、Adjust、Appsflyer 事件和业务报表，但尚未形成统一事件模型，主要问题如下：

1. 前端页面事件、服务端业务事实和后台操作日志分别建设，用户全链路无法稳定串联。
2. 同一指标在不同版本中名称或正负方向不一致，例如“用户输赢”“充提比”。
3. PWA/W2A 事件名依赖外部平台映射，内部业务语义不稳定。
4. 现有风控信息分散在会员详情、关联查询、提款审核、会员分组和操作日志中，缺少规则命中、案件处置及结果回流闭环。
5. 多站点、多渠道、多国家环境下，channel、appcode、PID、投放渠道等概念容易混用。
6. 多个旧版本材料缺失，需要一套可扩展、可配置、可追溯的埋点体系承接后续迭代。

2. 产品目标#

2.1 业务目标#

1. 统一采集用户从获客、访问、注册、充值、游戏、提款、留存到召回的完整行为链路。
2. 以服务端事件作为资金、订单、游戏结算、奖励和佣金的事实源，支持经营指标准确核算。
3. 建立用户、设备、指纹、IP、银行卡/钱包、代理关系和广告归因的关联视图，支持多账号及套利风险识别。
4. 对后台人员登录、权限校验、资金操作、配置变更、批量导出等高风险操作形成不可抵赖的审计记录。
5. 提供漏斗、路径、留存、分群、用户 360、风险规则、预警和案件处置能力。
6. 建立事件字典、版本、质量监控和验收机制，降低新站、新渠道和新功能接入成本。

2.2 首版成功标准#

3. 需求范围#

3.1 本期范围#

• 仅新站接入；老站需求、历史数据和旧报表不纳入维护或迁移范围。
• 后续产品需求和埋点版本统一从 V2.11.5 开始管理，不再为 V2.11.5 之前的老站版本追加兼容需求。
• 站点、APP、国家、币种和推广渠道维度。
• H5、PWA、Android APK、iOS APP、iOS 书签、谷歌上架包等渠道类型。
• 前端行为采集、服务端业务事件、外部回调事件、后台操作审计。
• 获客归因、注册登录、安全中心、游戏大厅、充值、提款、账变、VIP、代理、充值/投注返利、邀请/挑战、救援金、票券、月卡、消息、域名及后台权限。
• 行为分析、用户 360、指标看板、风险特征、规则、预警、案件和处置记录。
• 埋点管理、数据质量、权限、隐私与验收。

3.2 暂不纳入首版#

• 全量页面录屏、键盘输入回放等高隐私会话重放功能。
• 使用模型自动封禁或自动罚没。首版仅允许确定性规则自动拦截，其余进入人工审核。
• 广告预算、广告消耗和 ROI 的完整闭环；广告成本不纳入首充单价或充值单价。
• 游戏风控、游戏公平性算法、赔率算法和反作弊模型；本期仅保留游戏行为采集、经营分析和订单对账。
• 与现有黑名单、完整设备/IP 报表的兼容迁移。
• 替代业务系统订单库、账本或支付系统。埋点平台只做观测、分析和风险决策，不作为资金记账主库。

4. 角色与权限#

权限沿用“APP/站点权限 + 页面权限 + 按钮权限”的思路，并新增：

• 数据域权限：行为、资金、风控、后台审计。
• 行级权限：site_id + app_code + promotion_channel_code。
• 字段权限：手机号、IP、账户姓名、银行卡/钱包等分级脱敏。
• 动作权限：查询、导出、规则编辑、案件审核、执行处置、查看敏感值。
• 所有查询、导出、规则修改和案件处置均写入后台审计事件。

5. 核心设计原则#

5.1 事实源原则#

5.2 事件与状态分离#

• 用户点击“充值”是行为事件；订单创建是业务事件；订单变为已支付是状态事件；账本入金是账变事件。
• 同一业务状态允许多次尝试，但最终事实必须通过业务对象版本号和幂等键去重。
• 订单状态不得只记录最终值，必须保留合法的状态流转历史。

5.3 内部事件与外部映射分离#

平台内部事件名保持稳定，例如 deposit_order_created、first_deposit_succeeded。Pixel、Adjust、Appsflyer 的事件名及 token 仅作为可配置映射，不允许反向决定内部事件语义。

5.4 站点隔离#

本系统忽略 tenant_id，所有事件必须带 site_id。跨站点查询默认禁止；共享设备、IP 或支付账户的关联分析不得跨站点展示。

6. 业务对象与标识体系#

6.1 核心业务对象#

6.2 渠道字段标准化#

不得继续使用一个 channel 字段同时表达渠道类型、渠道名称和渠道码。

6.3 活动对象与统一枚举#

统一活动模型必须把“任务完成”“生成可领资格”“用户点击领取”“审核通过”“奖励到账”“稽核流水生成”拆成不同事实。活动、票券和月卡配置修改只生成新版本；已参与、已领券或已购卡用户继续使用其绑定的旧版本，历史事件不得因下架、重新上架或配置删除而物理删除。

6.4 身份合并规则#

1. 匿名阶段使用 anonymous_id + device_id + fingerprint_id。
2. 注册或登录成功后，将当前匿名行为挂接到 user_id，保留原匿名标识。
3. 同一用户跨端登录，可按 user_id 汇总，但设备记录仍分开。
4. 两个不同 user_id 仅因同 IP、同设备或同指纹不得自动合并；应建立“风险关联边”。
5. fb_finger_id/adid/gps_adid 与用户的绑定需记录绑定时间、来源和置信度。
6. 用户变更手机号、绑定账户或后台修改资料时，保留历史版本，不覆盖关联证据。
7. 三类流量均必须完成归因：存在有效 fbc 或 fb_finger_id 等广告来源证据时记录 direct；存在有效邀请码或邀请关系时记录 referral；两类证据均不存在时记录 organic。直推和裂变证据同时成立时均写入 attribution_types，不得按单一优先级覆盖。

7. 事件模型#

7.1 事件命名#

• 使用英文小写蛇形命名：业务对象_动作，例如 withdrawal_order_created。
• 成功事实使用过去式语义：user_registered、deposit_succeeded。
• 状态统一使用 *_status_changed，旧状态和新状态作为属性。
• 页面与通用交互使用 page_viewed、element_clicked、list_item_exposed，通过稳定的 page_code/element_code 区分。
• 禁止把中文文案、按钮显示文本或动态 URL 作为事件名。
• 事件升级通过 event_version，不得原地改变字段含义。

7.2 通用事件信封#

7.3 客户端公共属性#

完整 URL 可能含邀请码、广告参数及用户标识，默认不进入通用属性；只解析白名单参数。UA 原文仅进入受控明细库，分析层默认使用哈希或结构化结果。

7.4 服务端公共属性#

7.5 后台审计公共属性#

7.6 幂等、顺序与补数#

• 客户端事件以 event_id 去重；SDK 失败重试不得生成新 event_id。
• 订单状态事件幂等键为 business_type + business_id + business_version + new_status。
• 三方回调幂等键为 provider_code + merchant_id + provider_order_id + callback_id。
• 后台事件幂等键为 request_id + action_code + target_id。
• 活动任务完成幂等键为 user_id + promotion_id + promotion_version + task_id + period_id；重复证据不得重复生成奖励单。
• 奖励到账幂等键为 reward_order_id + grant_version；票券开奖以 user_coupon_id、月卡每日槽位以 monthly_card_instance_id + card_day + reward_slot_type 幂等。
• 随机奖励请求首次受理后必须复用同一 random_request_id 和结果，客户端或服务端重试不得重新抽取。
• 允许迟到事件，但分析窗口需同时保留 event_time 和 received_at。
• 服务端补数必须标记 source_type=batch、backfill_job_id 和原始业务时间。
• P0 资金、账变、游戏结算和后台审计事件不得采样。

8. 埋点管理后台#

8.1 信息架构#

8.2 事件字典生命周期#

事件状态为：草稿 → 待评审 → 开发中 → 测试中 → 已上线 → 已废弃。

每个事件至少维护：中文名称、英文事件名、业务说明、触发时机、事件来源、负责人、事件版本、属性及枚举、示例、优先级、关联指标、适用站点、上线版本和废弃替代事件。

8.3 发布门禁#

1. 事件名、属性名和枚举通过 Schema 校验。
2. P0 事件必须提供成功、失败、重复提交、断网重试和跨端场景测试。
3. 服务端事件必须给出幂等键和业务表对账规则。
4. 包含 PII 的属性必须通过隐私检查。
5. 修改已有字段含义必须升级 event_version。
6. 上线后 24 小时内进入重点质量观察。

9. 埋点事件字典#

9.1 优先级说明#

9.2 通用前端事件#

通用事件用于低价值、重复性 UI 交互；核心业务仍使用后续语义事件。

9.3 获客与 PWA/W2A#

外部事件映射要求#

外部映射在后台按 site_id + promotion_channel_code + platform 配置。以 Pixel、Adjust、Appsflyer 当前生产映射为迁移基线，PageView、ViewContent、Lead、StartTrial、AddToCart、CompleteRegistration、InitiateCheckout、AddPaymentInfo、Purchase、Donate 等外部事件必须先绑定内部事件。外部映射变更只生成新配置版本，不修改内部历史事件；不再保留任何“虚拟赋值”事件。

9.4 注册、登录与安全中心#

注册和登录方式仅包含 username（用户名）与 phone（手机号），系统不设置昵称字段。

9.5 大厅、游戏发现与游戏订单#

9.6 充值链路#

充值订单取消或超时后的 24 小时内，仍允许通过验签、金额及幂等校验的成功回调入账；超过 24 小时不得自动入账，进入人工处理并记录审计。24 小时从订单进入取消或超时状态的时间开始计算。

9.7 提款链路#

自动出款仅在订单通过单笔人工配置的提款限制且未被判定为高风险时允许执行；高风险订单必须强制关闭自动出款并转人工处理。稽核流水倍数 N 支持全站、会员分组、活动、充值渠道和用户五个配置层级，每次校验必须记录实际生效的 audit_config_level、audit_config_id、audit_config_version 和 audit_turnover_multiplier。

9.8 钱包、活动、VIP 与代理#

活动类型关键口径#

救援金统一使用本文件的会员视角公式：会员净输赢 = 游戏中奖金额 + Jackpot 金额 - 有效投注，亏损金额 = max(0, -会员净输赢)。若配置“扣除其他彩金”，则先按配置把对应彩金加入会员收益后再计算亏损，必须记录被排除的奖励类型及金额。来源材料中“投注退回金额加/减”写法不一致时，不直接使用原式，统一从已定义的有效投注和会员净输赢推导。

月卡额外奖励的计算值由服务端生成并保留快照：固定奖品概率 P = P0 + min(V/T, 1) × (1-P0)；随机现金在 V < Vmin 时按同式提升至最低金额资格，在 Vmin ≤ V ≤ Vmax 时按 (V-Vmin)/(Vmax-Vmin) 在线性区间内从最小金额增加至最大金额，超过上限取最大金额。V 为当日合格有效投注；领取后该奖励槽位停止累计。

9.9 消息与通知#

9.10 后台、配置与运维#

9.11 风控闭环事件#

10. 指标口径与分析需求#

10.1 时间与人数口径#

1. 原始事件统一存 UTC 时间，同时保留 site_timezone 和站点日期分区。
2. site_timezone 按站点所属国家配置，使用 IANA 时区；全部历史与新增报表均使用对应站点国家时间，配置变更不得回写历史日期。
3. 订单归属日期默认按“成功/最终状态发生时间”；创建人数、创建次数按创建时间。页面必须明确选择的时间口径。
4. 已登录业务人数按 distinct user_id；匿名获客人数按 fb_finger_id > fingerprint_id > anonymous_id 的优先级去重，并展示采用的标识口径。
5. 比率分母为 0 时展示 -，不得展示 0% 或无穷大。
6. 金额按事件币种存储；跨币种看板必须选择统一折算币种和汇率日期，首版默认不跨币种求和。

10.2 核心指标字典#

10.3 序次口径#

• lifetime_deposit_seq：用户全生命周期充值订单创建序次。
• successful_deposit_seq：用户全生命周期充值成功序次；successful_deposit_seq=1/2/3 分别定义为首充、二充、三充。
• 首充、二充、三充不因建立或变更代理关系而重新计算。
• 提款对应维护 lifetime_withdrawal_seq 与 successful_withdrawal_seq，订单创建次数和成功次数分别统计。
• 每日提款次数限额默认按 successful_withdrawal_seq 在站点自然日内的成功次数判断。

10.4 核心漏斗#

所有漏斗支持按站点、国家、渠道类型、活动渠道码、投放 PID/广告、设备平台、注册方式、会员分组、VIP、代理类型和风险标签分层。代理分享和消息召回本期不计算窗口归因转化率。

10.5 路径、留存与分群#

路径分析#

• 指定起点或终点，展示前后最多 10 步路径。
• 支持页面事件与业务事件混合，例如“首页 → 游戏详情 → Play → 首投”。
• 自动合并连续相同页面，区分退出、超时和跨端登录。
• 支持对比首充用户与未首充用户、赢钱与输钱用户、风险与正常用户路径。

留存分析#

• 支持注册、首充、首投、游戏品牌/类型首次投注作为 Cohort 起点。
• 回访行为支持登录、任意 APP 行为、充值成功、有效投注。
• 支持 D1、D2、D3、D5、D7、D15、D30 和自定义日。
• 三类流量全部归因：存在有效 fbc 或 fb_finger_id 等广告来源证据记为直推，存在有效邀请码或邀请关系记为裂变，两类证据均不存在记为自然流。直推和裂变同时成立时全部写入 attribution_types；报表使用服务端结果，不在查询层重复推断或相互覆盖。

用户分群#

支持以下条件组合：

• 用户属性：国家、渠道、注册方式、设备、VIP、代理类型、会员分组、风险等级。
• 行为条件：做过/未做过某事件、次数、金额、连续天数、首次/最近发生时间。
• 关系条件：共享 IP/设备/指纹/收款账户人数、代理层级、团队规模。
• 资金条件：充值、提款、充提差、稽核流水、奖励、佣金。
• 游戏条件：有效投注、GGR、RTP、游戏品牌/类型/名称。

分群可用于分析、风控规则和消息触达，但用于触达时必须保留分群版本和用户快照。

10.6 看板需求#

11. 用户 360 与关联关系#

11.1 用户 360 页面#

敏感值默认掩码；具备对应字段查看权限的人员可直接查看完整值，不需要二次审批，但每次查看必须填写原因并写入 admin_sensitive_value_viewed 审计事件。

11.2 关联图谱#

实体节点包括用户、匿名访客、设备 ID、指纹 ID、IP、手机号、邮箱、银行卡/钱包、绑定姓名、代理邀请码、广告标识和后台账号。

关系边至少包含：关系类型、首次发现时间、最后发现时间、出现次数、来源事件、站点、当前状态和置信度。支持一至三跳查询、按时间过滤、导出关联摘要及一键生成风险案件。

12. 风控系统需求#

12.1 风控处理流程#

风险链路统一为：事件进入 → 特征更新 → 规则计算 → 决策 → 预警/案件 → 人工审核 → 处置 → 结果回流。

决策等级：

自动罚没、永久封号和跨业务冻结不在首版自动决策范围，必须由有权限人员人工确认。

12.2 风险特征库#

所有金额、次数和比例特征至少支持 5 分钟、1 小时、1 天、7 天、30 天及生命周期窗口；规则界面只引用特征编码，不在规则中重复实现统计逻辑。游戏相关数据只用于行为分析、经营指标和订单对账，本期不得配置游戏风控特征或规则。

12.3 风险场景与规则矩阵#

下表中的 N/T/A/R 均为后台可配置参数，不是最终阈值。具体阈值、风险等级以及自动/人工处置边界本期暂不定稿，不作为本期验收阻塞项；确定性业务硬规则按业务系统现有配置执行。

12.4 规则管理#

每条规则配置：规则名称、场景、版本、适用站点/渠道、触发事件、条件组、特征窗口、风险分、决策、动作、有效期、灰度比例、负责人、说明和变更记录。

规则发布流程：草稿 → 仿真回放 → 待审批 → 灰度 → 全量 → 停用。规则仿真需展示历史命中人数、订单数、涉及金额、与已确认风险的召回率、正常用户误伤率及样本明细。

12.5 预警与案件#

• 相同实体、相同场景、指定时间窗口内的多条预警可自动合并为一个案件。
• 案件状态：待分配、待处理、处理中、待复核、已通过、已拒绝、已关闭。
• 案件必须展示规则命中、证据时间线、关联图、资金摘要和历史处置。
• 处置时必须选择原因码并填写备注；补单、冲正、罚没、退回和人工上下分等资金动作不启用双人审批，由具备权限的单一操作人执行并全量审计。
• 审核结果回流至规则评估，标记真实风险或误报，不得删除原始命中记录。

13. 数据质量与对账#

13.1 质量规则#

以上数值为首版建议，需结合实际峰值和网络环境评审。

13.2 业务对账#

每日自动生成以下对账任务：

1. deposit_succeeded 与充值订单已支付、充值账变金额核对。
2. withdrawal_succeeded 与已支付/已冲正订单、提款账变及实际出款核对。
3. 游戏投注、退回、结算、Jackpot 与游戏订单/账变核对。
4. reward_granted、commission_claimed 与奖励/佣金账变核对。
5. 后台补单、冲正、罚没、退回、人工上下分必须同时存在业务结果事件和后台审计事件。
6. 外部转化回传请求、成功和最终业务转化数量核对。
7. promotion_task_completed 必须能回溯到充值、投注、邀请、绑定或游戏结算等证据事件，并绑定活动配置版本。
8. 每个活动 reward_order_id 的可领、审核、到账和过期状态流转必须合法；reward_granted 与现金账变、实物发放、稽核流水任务逐笔核对。
9. 票券使用数与开奖动作核对，票券奖励到账与审核通过核对；随机奖励结果必须属于对应概率配置版本的候选集。
10. 月卡购买、每日奖励、额外奖励、退回金额和账变逐实例核对；退回后不得存在新的领取成功事件。
11. 救援金结算的会员净输赢、亏损、彩金排除项和累计结转值与源游戏结算、奖励账变逐周期核对。

对账差异需记录：差异对象、期望值、实际值、差异金额、首次发现时间、处理状态、责任模块和补数批次。

13.3 质量告警#

告警支持站内、邮件和 Lark/企业通信工具。P0 告警包括：资金事件缺失、账变不平、订单非法状态流转、回调金额不一致、后台敏感操作无审计、事件量归零和风险事件延迟。告警需支持确认、指派、关闭、重复合并和恢复通知。

14. 隐私、安全与合规#

14.1 禁止采集#

以下信息不得进入埋点属性、审计前后快照或调试日志：

• 用户密码、确认密码、短信/邮箱验证码。
• Google 身份验证器密钥。
• Pixel Token、Adjust S2S 识别码、Appsflyer Token、极光 Master Secret。
• 支付商户密钥、私钥、公钥原文、签名字段和三方密钥。
• 完整银行卡号、电子钱包账号、身份证件等非分析必需原文。
• 消息正文中的任意自由输入敏感内容，除非进入专门内容存储并按权限访问。

14.2 敏感字段处理#

敏感字段哈希、加盐和原文访问策略首版沿用现有安全体系，本期不新增跨站点关联方案，也不单独调整加盐策略。

14.3 数据留存与删除#

• 原始事件、资金数据、后台审计和风险案件均需长期留存，不设置业务侧自动删除期限。
• 产品需支持热存与冷存分层、归档、恢复查询和存储容量监控；转入冷存不得改变事件内容、业务时间和审计链路。
• 聚合指标需与长期留存的原始事实保持可追溯关系；任何清理或匿名化操作必须留下执行记录。
• 用户删除或匿名化请求需保留账务/审计所需最小信息，并对行为分析标识做不可逆匿名化。

15. 外部系统集成#

外部请求统一记录请求时间、结果、错误码、重试次数和最终状态。重试采用退避策略，超过次数进入死信和人工处理队列。Pixel、Adjust、Appsflyer 使用当前生产映射作为初始配置，不保留“虚拟赋值”事件。

16. 非功能需求#

16.1 性能与可用性#

• 容量按新站预估峰值事件 QPS 的 2 倍设计，并支持站点级限流。
• 风险同步决策服务建议 P95 ≤ 150 ms、P99 ≤ 300 ms【待压测确认】；超时必须执行场景配置的降级策略。
• 用户时间线近 30 天查询 P95 ≤ 3 秒；标准看板 P95 ≤ 5 秒。
• 核心采集服务可用性目标 ≥ 99.95%；单一外部平台故障不得阻塞内部业务事件落库。
• 客户端 SDK 支持批量、压缩、断网缓存、重试和版本控制；不得阻塞主业务线程。

16.2 一致性与可靠性#

• 资金、账变、游戏结算和审计事件应采用业务事务后可靠投递机制。
• 同一业务对象的事件保留版本号；乱序到达时按业务版本重建状态，不以接收顺序直接覆盖。
• 事件原始层不可修改；补数和纠错以新版本/冲正事件实现。
• 采集服务故障期间，业务主流程按场景降级；后台敏感操作审计无法可靠写入时应阻止操作【待技术评审】。

16.3 可观测性#

平台自身需监控采集 QPS、失败率、处理延迟、积压、隔离事件、死信、存储用量、查询耗时、规则耗时、外部回传成功率和告警发送状态。

17. 实施阶段与优先级#

阶段一：P0 基础与资金风控#

• 事件/属性字典、SDK/服务端接入规范、调试、质量监控。
• 新站站点隔离、用户身份、注册登录、安全中心和用户关联。
• PWA/W2A 获客归因主链路。
• 充值、提款、账变、支付回调及后台财务操作。
• 活动奖励单、审核、现金/奖品到账、稽核流水及随机结果审计基础。
• 后台登录、权限、白名单、敏感操作和导出审计。
• 用户 360 基础、提款前置风控、多账号关联和风险案件基础。

阶段二：P1 行为分析#

• 游戏大厅、搜索、收藏、启动、投注与结算。
• VIP、充值/投注返利、邀请/挑战、救援金、票券、月卡、代理、消息与推送。
• 漏斗、路径、留存、分群和核心看板。
• 奖励、代理及投放风险规则；游戏风控不在本期范围。

阶段三：P2 平台化与优化#

• 规则仿真、灰度、效果评估和特征管理。
• 关联团伙分析、变更后指标异常检测。
• 多国家/多币种高级汇总。
• V2.11.5 之后的新站扩展；不补录老站历史数据。

18. 验收方案#

18.1 埋点验收#

每个事件验收：事件名和版本正确、触发次数正确、成功失败均覆盖、属性类型和枚举正确、公共属性完整、敏感数据未上报、断网重试不重复、跨端身份关联正确、测试环境与生产环境隔离。

18.2 P0 端到端用例#

18.3 上线门槛#

1. P0 用例 100% 通过。
2. 连续 3 个完整业务日的资金和账变自动对账无未解释差异。
3. 数据质量告警和补数流程演练完成。
4. 本期实际启用的确定性风控规则完成回放及误报评审；尚未定稿的阈值规则不阻塞上线。
5. 权限、脱敏、导出和审计通过安全评审。
6. 事件字典、指标口径、责任人和回滚方案完成归档。

19. 跨版本口径处理#

20. 来源覆盖矩阵#

覆盖原则： 下表所列来源材料中，凡涉及埋点事件、字段、指标、行为分析或风控数据口径的内容，统一使用本文覆盖；来源材料与本文不一致时，以本文为准。来源材料仅作为原业务功能、流程和版本背景的追溯依据，本文不替代其范围外的功能需求。

21. 业务确认结论#

T01-T20 均已形成处理结论。T12 已由 6 份活动需求补充并关闭；标记为“暂不纳入”或“延期定稿”的事项不阻塞本期上线。

22. 评审结论记录#

23. 本次整合范围与现行产品结构#

23.1 整合任务#

本文件一次性整合以下任务，不再拆成互相引用的精简需求：

1. 【埋点系统需求V1】：保留系统建设背景、目标、范围、权限、事实源、业务对象、事件模型、事件字典、指标、漏斗、路径、留存、风控、质量、隐私、集成、非功能、实施和验收。
2. 【埋点系统-用户360】：补齐五类明细、会员信息、加载、导出、权限、异常和专项验收。
3. 【埋点系统-埋点管理】：补齐定义筛选、状态开关、新增表单联动、详情和分页。
4. 【埋点系统-事件查询】：补齐双事件名称、UID／指纹ID、渠道、点击查询、最近 20 条、无分页和复制交互。

23.2 现行页面#

23.3 原型交付#

• 线上交互原型：打开埋点系统
• 用户360：打开用户360
• 埋点管理：打开埋点管理
• 事件查询：打开事件查询

24. 现行事件体系#

24.1 事件规模与职责#

• 前端行为只能表示用户意图，不能代表注册、充值、提款、奖励或佣金成功。
• 同一业务动作同时存在用户操作和业务结果时，必须拆为两个事件。
• 后端结果统一通过 result_status=success/failed 区分，失败必须携带可读 error_code 或失败原因。
• 内部事件名称稳定，Pixel、Adjust、AppsFlyer 等外部平台映射独立版本化。

24.2 104 个前端事件模块分布#

每个事件必须维护：内部事件名、中文名称、埋点类型、业务模块、打点端、触发来源、触发条件、上报时机、必填业务属性、公共字段、去重规则、指标用途与成功判定、负责人、版本和状态。

24.3 16 个后端结果事件#

如果研发实现采用等价内部名称，必须在事件字典中维护名称映射、版本、启用时间和替代关系，不得直接改变历史事件语义。

24.4 公共字段补充#

在第 7 章公共事件信封基础上，现行客户端事件必须补充 page_instance_id、channel_type、app_code、promotion_channel_code、pid、client_version；现行服务端事件必须补充 service_name、trace_id、business_id、result_status、error_code。

浏览器指纹字段统一使用 fingerprint_id：

• 未注册阶段用于匿名识别、重复事件识别和风险关联。
• 注册或登录后继续保留，并关联 anonymous_id、session_id 与 user_id。
• 两个不同 UID 仅因相同指纹不得自动合并，只能形成风险关联边。

25. 用户360完整页面需求#

25.1 页面结构#

1. 页面标题与站点报表时区。
2. 全局筛选：统计周期、归因类型、访问载体、渠道、查询、重置。
3. 用户查询：用户名／手机号／会员 ID。
4. 会员摘要：账号状态、VIP、注册时间、归因来源。
5. 主明细区：行为轨迹、资金记录、活动记录、登录设备、风险记录。
6. 会员信息区：基本资料、资金概要、稽核状态和风险标签。

25.2 全局筛选与用户查询#

• 一个用户查询框支持用户名、手机号或会员 ID，不支持昵称。
• 输入为空时不发起请求；无结果时清空上一会员数据。
• 切换会员后默认进入行为轨迹，五个标签已加载数量全部重置。

25.3 会员摘要与归因#

直推为有效广告来源，裂变为有效邀请关系，二者均无时为自然流；channel_type、promotion_channel_code、app_code、pid 独立保存。

25.4 行为轨迹#

行为轨迹按站点时间倒序，页面展示中文业务行为和业务详情，不展示内部事件名与埋点端。必须覆盖分流、落地页、下载页、下载点击、主站、注册、登录、支付拉起、充值成功、提款拉起、提款成功、进入游戏、进入活动、奖励领取、奖励成功、佣金领取和佣金成功。

业务成功必须以后端结果事件的 result_status=success 判定；前端点击只作为行为步骤。

25.5 资金记录#

金额正负表示资金方向，不表示业务成败。

25.6 活动记录#

展示站点时间、活动名称、用户动作、奖励金额、结果和原因。同名活动通过唯一 activity_id 区分；领取点击与奖励到账分开，奖励成功以 activity_reward_result 为准。

25.7 登录设备#

展示最近登录时间、渠道类型、设备／浏览器、IP 和状态。同一设备合并展示，最近登录时间取最新成功登录；IP 默认脱敏，有权限时查看完整值。

25.8 风险记录与会员信息#

• 风险记录展示时间、案件编号、风险类型、等级、处理状态；用户360只读，处置在风险中心完成。
• 会员信息展示用户名、脱敏手机号、脱敏注册 IP、余额、充值总额、提款总额、净输赢、稽核流水和风险标签。
• 查看完整手机号、IP 与导出必须受权限控制并记录审计。

25.9 加载与导出#

• 五个标签首屏各 10 条，上拉每次追加 10 条。
• 切换标签、会员或筛选条件后恢复首屏 10 条。
• 导出当前会员、当前标签和当前筛选范围的全部记录，不受页面已加载数量限制。
• 大数据量使用异步导出任务；不得退化为只导出已加载记录。

25.10 异常处理#

26. 埋点管理完整页面需求#

26.1 汇总与筛选#

• 顶部展示前端 104 个事件、后端 16 个结果事件、打点端及划分原则。
• 筛选项：埋点类型、内部事件名称、中文名称、业务模块、状态。
• 内部事件名称与中文名称分别支持模糊搜索。
• 状态选项：全部状态、已启用、已停用。

26.2 列表与分页#

列表字段：内部事件名、中文名称、埋点类型、打点端、触发来源、上报方式、业务模块、状态、操作。每页 10 条，支持上一页、下一页；筛选后回到第 1 页；无结果时展示明确空状态。

26.3 状态开关#

• 已启用／已停用以开关展示，可直接切换。
• 状态筛选使用切换后的实时状态。
• 发布事件的状态变更必须记录操作者、时间、原因和版本；原型只演示交互，生产实现必须落审计日志。

26.4 新增埋点#

表单包含内部事件名、中文名称、埋点类型、打点端、触发来源、业务模块、上报方式、触发条件、上报时机、必填业务属性、去重／幂等规则、指标用途与成功判定。

• 前端埋点默认浏览器／APP 客户端，触发来源可选页面进入、浏览、点击、输入、选择、停留。
• 后端埋点默认服务端，触发来源可选接口完成、业务状态变化、异步回调完成、定时任务完成。
• 埋点类型和打点端双向联动，并重置不适用的触发来源。
• 内部事件名必须为小写蛇形命名且全局唯一。

26.5 详情与版本#

详情展示基础信息、开发定义和公共字段。发布后的内部事件名、字段语义、埋点类型不得直接修改；语义变化必须升级 event_version，保留历史版本和替代事件。

27. 事件查询完整页面需求#

27.1 筛选项与匹配规则#

UID 与指纹ID的英文字母匹配不区分大小写。未注册用户用户名、UID 显示“—”，通过稳定指纹ID识别和去重。

27.2 查询触发#

• 输入或选择条件时不立即刷新。
• 点击查询后一次性提交当前全部条件。
• 点击重置后清空输入、恢复默认下拉项并恢复默认最近结果。
• 导出使用最近一次已提交条件，不使用尚未查询的草稿条件。

27.3 列表#

• 按站点时间倒序展示最近 20 条。
• 不展示分页，不提供上一页、下一页或跳页。
• 字段：站点时间、埋点类型、打点端、内部事件名、事件中文名称、用户名、UID、指纹ID、渠道、上报来源、状态、接收延迟、操作。
• 用户名、UID、指纹ID可点击复制；“—”不可复制；成功后显示短暂提示。
• 查看详情展示公共信封及客户端／服务端完整属性。
• 导出不受页面最近 20 条限制，按已提交条件创建异步任务。

27.4 身份关联与去重#

1. 未注册事件至少携带 fingerprint_id、anonymous_id、session_id。
2. 同一未注册用户相同环境的事件使用稳定指纹ID。
3. 客户端事件以 event_id 去重；页面曝光同时使用 session_id + page_instance_id。
4. 注册或登录后建立指纹ID、匿名标识、会话与 UID 的关联，不覆盖原始事件。
5. 不同 UID 因同设备或同指纹只形成风险关系，禁止自动合并账号。

28. 统一验收标准#

28.1 系统级验收#

第 18 章原埋点验收、P0 端到端用例和上线门槛全部继续有效，并增加以下专项验收。

28.2 用户360#

28.3 埋点管理#

28.4 事件查询#

29. 本版交付清单#

• 产品原型：埋点系统线上原型
• 产品需求文档：本文档
• 版本变更记录：埋点系统 V2.14.0 版本变更记录

30. 十页原型复核结论与通用页面规范#

30.1 本次复核范围#

本次以 1280px 桌面视口逐页打开正式原型，复核经营总览、转化漏斗、留存分析、获客分析、活动分析、用户360、风险中心、埋点管理、事件查询、数据质量共 10 个页面。检查范围包括：页面标题、全局筛选、指标卡、图表、表格、页签、抽屉、弹窗、空状态、加载规则、横向溢出、字段口径和响应式降级。

30.2 已修正的共性问题#

30.3 通用页面结构#

所有页面自上而下均由：后台全局顶栏、页签栏、面包屑与页面标题、站点报表时区、页面筛选区、业务内容区组成。除用户360的会员搜索外，查询条件改变后不应在未点击“查询”时隐式刷新数据。所有时间按站点国家时区显示，底层存储 UTC 时间。

30.4 通用状态要求#

1. 加载中：内容区保留原布局并显示骨架，不得造成卡片跳动。
2. 无数据：在原组件区域显示无数据说明，并保留当前筛选条件。
3. 查询失败：显示错误原因和“重新查询”，不得用空数据代替错误。
4. 权限不足：敏感值脱敏；无查看权限时不展示“查看”按钮。
5. 宽表：冻结关键操作列；横向滚动不影响页面整体宽度。
6. 导出：按最后一次已提交的查询条件创建任务，不受当前列表展示条数限制。

31. 页面一：经营总览#

• 原型入口：经营总览
• 页面目标：用一屏概括埋点覆盖、核心经营指标、用户主行为链路、投放转化、获客来源和风险待办。
• 使用角色：运营负责人、产品、数据分析、管理层。

31.1 筛选与指标#

筛选项为统计周期、归因类型、访问载体和渠道。指标卡展示活跃会员、首充人数、充值金额、提款金额、平台 GGR；点击指标卡后，核心指标趋势同步切换到对应指标。金额使用站点币种，比例与上一周期同口径比较。

31.2 内容与交互#

1. 埋点采集状态分前端埋点和后端埋点，展示事件数、成功率、打点端及数据用途。
2. 用户主行为链路按广告入口、落地/下载、主站、注册登录、业务行为、业务结果排列；“查看五类漏斗”跳转转化漏斗。
3. 趋势支持今天、最近7天、最近14天快捷切换。
4. 今日投放转化、获客来源、风险待办均可进入对应详情页。
5. 风险待办必须突出高风险数量与自动出款拦截数量。

31.3 验收标准#

32. 页面二：转化漏斗#

• 原型入口：转化漏斗
• 页面目标：比较从页面分流到业务结果的五类核心漏斗，定位最大流失步骤。
• 五类漏斗：投放获客、注册登录、充值、游戏、提款。

32.1 页面规则#

左侧展示漏斗步骤、人数/次数和相邻转化率，右侧展示选中步骤说明、流失情况、事件类型和可下钻维度。步骤名称必须使用业务中文名，事件名仅在详情中作为开发口径出现。前端步骤使用前端埋点，订单成功/失败等事实步骤使用后端埋点。

32.2 交互#

1. 切换漏斗类型后，步骤、口径说明及摘要同步更新。
2. 点击任一步骤，右侧更新为该步骤的进入人数、转化率、流失人数及下钻维度。
3. 下钻维度至少支持访问载体、渠道、PID、活动、设备和用户分群中与当前漏斗相关的字段。
4. 漏斗条、中文标签和埋点类型徽标不得重叠。

32.3 验收标准#

33. 页面三：留存分析#

• 原型入口：留存分析
• 页面目标：分别观察活跃留存和业务留存，避免把登录活跃与充值/游戏留存混为同一指标。

33.1 指标与表格#

活跃留存以注册或首次有效访问为起点，以后续登录/有效行为为回访；业务留存以首次充值或首次游戏为起点，以后续同类成功业务为回访。页面展示次日、3日、7日、14日等摘要指标和按首日日期展开的留存矩阵。矩阵单元格显示留存率，悬停可查看分母、分子和口径。

33.2 交互与状态#

1. 活跃留存/业务留存切换后，指标卡、定义、规则和矩阵必须同步更新。
2. 无完整观察窗口的日期显示“—”，不得按 0% 处理。
3. 渠道、访问载体和归因类型筛选使用首触归因口径，除非另有明确配置。
4. 导出包含 cohort 日期、分群人数、各日留存人数及留存率。

33.3 验收标准#

34. 页面四：获客分析#

• 原型入口：获客分析
• 页面目标：从直推、裂变、自然流三个一级来源评价获客规模、质量、付费和回收情况。

34.1 数据内容#

顶部指标至少包括新增访问、新注册、首充人数、首充金额和注册首充率。来源分布显示各来源人数及占比。明细宽表按来源、推广渠道、PID、访问载体、渠道、访问、注册、首充、充值金额、GGR 等维度展开；表头与单元格使用同一字段顺序。

34.2 交互与视觉规则#

1. 点击来源图例或来源卡，对明细表应用同一来源筛选。
2. 明细宽表在容器内部横向滚动，页面本身不得横向溢出。
3. 数值列右对齐；人数取整数，金额带币种，比例统一精度。
4. PID、渠道、访问载体均为不同维度，不得以 app_code 直接作为界面标签。

34.3 验收标准#

35. 页面五：活动分析#

• 原型入口：活动分析
• 页面目标：针对单个活动查看曝光、进入、参与、达标、领奖和奖励成功全链路。

35.1 活动选择与摘要#

左侧活动列表展示活动名称、类型和状态；右侧只分析当前选中的一个活动。摘要区根据活动类型展示差异化指标，例如充值返利展示活动达标充值金额，月卡展示月卡退回金额、每日必得和每日额外奖励金额。活动标识和内部事件名不作为运营主信息展示。

35.2 行为漏斗、趋势和用户明细#

1. 标准步骤为活动曝光、进入活动、参与动作、活动达标、发起领奖、奖励成功。
2. 用户分层为曝光未进入、进入未参与、参与未达标、达标未领奖、领奖未成功、奖励成功。
3. 月卡类活动可将 8 个行为节点分两行展示，避免横向挤压。
4. 并列趋势按天展示业务核心指标；图例与柱状颜色一一对应。
5. 点击用户分层打开用户明细抽屉，至少展示用户名、UID、当前阶段、发生时间和结果。

35.3 验收标准#

36. 页面六：用户360#

• 原型入口：用户360
• 页面目标：围绕单个会员串联行为、资金、活动、设备和风险轨迹，支持运营、客服、财务和风控联合判断。

36.1 查询与会员摘要#

会员搜索支持用户名、手机号、会员ID精确定位；系统不存在昵称字段。查询成功后展示用户名、会员ID、注册时间、账号状态、VIP等级、归因来源和渠道。会员信息卡展示脱敏手机号、注册IP、余额、充值总额、提款总额、会员净输赢、稽核状态和风险标签；敏感信息仅授权角色可点击查看。

36.2 五个页签#

36.3 加载、导出与布局#

1. 默认展示最近 10 条；点击“上拉加载更多”或滚动到记录容器底部后再加载 10 条。
2. 页签切换时重置为 10 条，不串用上一页签的加载数量。
3. 导出按当前会员、页签和全局筛选范围创建任务，包含全部记录与完整字段。
4. 桌面端记录页签采用约 760px 主记录区和 210px 会员摘要区；原因列至少 150px并允许换行。
5. 资金、活动记录首列不得被裁切；表格不应出现隐藏的横向内容。

36.4 验收标准#

37. 页面七：风险中心#

• 原型入口：风险中心
• 页面目标：集中展示风险案件、命中规则、处置状态和自动出款拦截结果。

37.1 页面内容#

指标卡展示待处理、处理中、自动出款拦截、今日已关闭。案件表包含案件编号、用户名、风险类型、关联金额、命中规则数、风险等级、状态和操作。高风险使用红色，中风险橙色，低风险蓝色。

37.2 案件抽屉与处置#

点击“查看案件”打开右侧抽屉，展示风险分、案件信息、命中规则、用户关联信息和处置记录。高风险提款必须明确标记已关闭自动出款。处理动作至少包括转处理中、关闭案件和填写处置备注；所有动作写入审计日志。

37.3 验收标准#

38. 页面八：埋点管理#

• 原型入口：埋点管理
• 页面目标：维护统一事件字典，明确前端行为事件与后端业务结果事件的定义和生命周期。

38.1 列表与筛选#

列表包含内部事件名、中文名称、埋点类型、打点端、触发来源、上报方式、业务模块、状态、操作。内部事件名与中文名称分别支持模糊搜索；类型、业务模块、状态支持筛选。默认每页 10 条并保留分页，空结果显示明确说明。

38.2 新增、详情与状态#

1. 前端埋点固定打点端为浏览器/APP客户端，可选择页面进入、浏览、点击、输入、选择、停留等触发来源。
2. 后端埋点固定打点端为服务端，可选择接口完成、业务状态变化、异步回调完成、定时任务完成等来源。
3. 新增必填：内部事件名、中文名称、类型、打点端、触发来源、模块、触发条件、上报时机、必填属性、去重规则、指标用途和成功判定。
4. 启用/停用使用可访问的状态开关；停用后新事件不进入生产统计，但历史数据保留。
5. 详情抽屉完整展示基础信息、开发定义和公共字段。

38.3 验收标准#

39. 页面九：事件查询#

• 原型入口：事件查询
• 页面目标：按明确条件人工查询最近事件，支持开发排障、数据验收和用户链路追踪。

39.1 筛选条件#

事件时间、埋点类型、内部事件名称、事件中文名称、用户名、UID、指纹ID、渠道、状态。内部事件名称和事件中文名称支持模糊搜索；UID和指纹ID为固定搜索/精确匹配；渠道使用下拉框且界面只显示“渠道”，底层映射 app_code。

39.2 查询和列表#

用户修改条件时不自动加载，必须点击“查询”。列表按站点时间倒序只展示最近 20 条，不提供分页；数据量过大时提示缩小条件。字段为站点时间、埋点类型、打点端、内部事件名、事件中文名称、用户名、UID、指纹ID、渠道、上报来源、状态、接收延迟、操作。

用户名、UID、指纹ID有值时可点击复制，复制成功给出轻提示；空值“—”不可点击。未注册用户通过稳定指纹ID识别与去重，注册后可通过身份合并规则关联 UID，但不得回写篡改原始事件。

39.3 验收标准#

40. 页面十：数据质量#

• 原型入口：数据质量
• 页面目标：分别监控前端行为埋点和后端结果埋点的覆盖、完整性、重复、接收成功率、延迟和版本/服务覆盖。

40.1 筛选与质量分#

筛选项为统计时间、埋点类型、渠道和事件名称；渠道界面统一显示“全部渠道”。整体质量分由接收成功率、字段完整率、重复率、时效和对账一致率按配置权重计算，分数与状态颜色必须一致。

40.2 检查项与覆盖#

前端检查 SDK 接收成功率、page_type 完整率和前端重复率；后端检查服务端事件接收成功率、订单事件对账一致率、trace_id 完整率等。点击检查项打开异常详情抽屉，可查看影响范围、异常事件、渠道/版本、首次和最近发生时间，并创建导出任务。版本与服务覆盖分别展示客户端版本和后端服务覆盖率，不得合并口径。

40.3 验收标准#

41. V2.14.0 最终交付与评审清单#

1. 产品原型已发布，10 个页面均可从左侧“埋点系统”进入。
2. 本文完整保留系统级需求、事件模型、口径、权限、质量、非功能和实施要求，并新增十页图文详述。
3. 11 张截图覆盖 10 个页面，均取自本次发布后的正式原型，不使用旧版截图；用户360同时提供资金记录和活动记录截图。
4. 用户360资金/活动记录的首列、原因列、金额、结果和失败样式均已复核。
5. 评审时应逐页核对本章验收标准；任何页面、字段或状态缺失均视为未完成。