系统支撑 + 度量指标 + 实施路径
系统支撑 + 度量指标 + 实施路径
Section titled “系统支撑 + 度量指标 + 实施路径”10. 系统支撑:营销管理应用
Section titled “10. 系统支撑:营销管理应用”10.1 功能模块清单
Section titled “10.1 功能模块清单”| 模块 | 核心能力 | 优先级 | 状态 |
|---|---|---|---|
| 角色管理 | 三类角色的申请、审核、开通、停用、转换 | P0 | 待建设 |
| 客户归属与报备 | 报备提交 / 模糊查重 / 审核(1–3 个工作日)、保护期统一 180 个自然日、延期申请与审批、归属变更、公海池分配(含分配留痕)、退出 / 转换时客户自动回流公海池〔决策 D-20、D-22〕 | P0 | 待建设 |
| 费率与政策配置 | 提成率配置(不设金额档位,调整由公司总经理审批)、代理商折扣矩阵、积分规则、产品线权重配置(0/100%/150%);采用「版本 + 生效日期」拉链设计,历史订单按成交时点版本计算〔决策 D-25〕 | P0 | 待建设(其中「提成比例设置」已具备〔原〕) |
| 等级管理 | 代理商档位定义、累计加权营收统计、产品线权重配置、自动升级(只升不降)与达标预警;重新申请时按等级下调一级或回最低级 | P1 | 规划中 |
| 激励计算引擎 | 按订单 / 回款实时试算,支持退款冲回与负数调整 | P0 | 规划中 |
| 结算单与对账 | A 级独立子站模式:A 级代理商向我方的结算单 + 我方对账;A 级以下标准平台模式:我方对账单 + 代理商在线确认与异议 + 冲销处理 | P0 | 规划中 |
| 发票与付款 | 发票登记、三流一致校验、付款申请对接财务 | P1 | 规划中 |
| 积分账户与商城对接 | 积分即时发放(按四节点)、不设有效期、兑换 / 充抵双通道、100 积分 = 1 元、兑换订单与物流(厂家履约) | P1 | 规划中 |
| 风控与审计 | 身份 / 激励互斥校验(同一主体不得以多个角色主张激励,不同角色分属不同主体可各自获激励)〔决策 D-23、D-34〕、关联识别、异常规则、冻结解冻、全量操作日志 | P1 | 规划中 |
| 报表与看板 | 角色业绩、激励成本、渠道健康度、KPI 看板 | P1 | 规划中 |
| 通知中心 | 归属审核、等级升级、结算、积分变动的消息触达 | P2 | 规划中 |
10.2 关键数据对象
Section titled “10.2 关键数据对象”- 角色档案、代理合同、客户归属记录、报备单、等级变更记录、费率版本、激励明细、结算单、发票记录、积分流水、风控事件
✅ 已定稿(提成率部分)〔决策 D-25〕:提成率采用「版本 + 生效日期」的拉链设计,历史订单按成交时点的版本计算,避免调价追溯争议;提成率调整由公司总经理审批。 📌 假设(折扣率部分):代理商折扣率亦拟采用同一套「版本 + 生效日期」拉链设计,待渠道负责人 + 财务确认。
10.3 权限与审计
Section titled “10.3 权限与审计”- 三权分立建议:规则配置(商务运营)与结算付款(财务)权限隔离
- 所有费率修改、归属变更、手工调整激励需二级审批并全量留痕 〔自动〕
11. 度量指标
Section titled “11. 度量指标”本章包含两部分:营销策略度量(§11.1–§11.2,渠道角色 KPI 与策略健康度)与平台运营度量(§11.3–§11.4,合并自原独立文档《saas运营指标设计》《saas系统埋点监测》)。后者为平台级口径,覆盖范围超出营销策略本身,仅在数据来源与推荐官专项上与本策略强相关。
11.1 分层角色 KPI
Section titled “11.1 分层角色 KPI”| 角色 | 核心指标 | 辅助指标 |
|---|---|---|
| 内部营销人员 | 回款额、新签客户数、目标达成率 | 客单价、销售周期、提成占回款比、计提发放差额(应付提成余额) |
| 代理商 | 累计加权营收(营业收入 × 产品线权重)、活跃率(季度有单占比)、续费贡献 | 等级分布、单代理产出、回款周期、流失率 |
| 外部推荐官 | 有效线索数、注册至付费转化率、获客成本 | 活跃推荐官数、积分核销率(兑换 + 充抵)、裂变系数 |
11.2 整体策略健康度
Section titled “11.2 整体策略健康度”- 渠道获客成本(CAC):分渠道激励成本 ÷ 新增付费客户数
- 激励占收入比:(提成 + 折扣让利 + 积分成本)÷ 总收入,建议设定红线
- CAC 回收期:CAC ÷(ARPU × 毛利率)
- 代理商集中度:头部代理商贡献占比,衡量渠道依赖风险
- 归因质量:撞单率、归属申诉率、归属变更率
- 结算健康度:结算周期时长、异议率、坏账导致的激励追回金额
- 计提兑付差(仅内部提成):应付提成余额及其账龄,反映「已确认成本但未回款」的规模,是现金流风险的前瞻指标
❓ 待明确:激励占收入比的红线阈值(建议按产品线分别设定,需财务测算)。 ❓ 待明确:应付提成余额的账龄警戒线(如超过 12 个月未回款即转入坏账评估)。
11.3 平台运营指标体系
Section titled “11.3 平台运营指标体系”📚 本节合并自独立文档《saas运营指标设计》(
saas_operation_metrics.md)。原文档中与本文已拍板决策冲突的指标,一律以本文决策(D-x)为准;不冲突的指标口径、看板设计与指标治理细则已吸收并入。合并涉及的主要冲突见「§11.3.8 合并说明」。
指标口径以业务库为权威来源,行为路径类指标依赖本节 §11.4 埋点监测提供的埋点数据;推荐官的业务规则见 role_referrer.md §7,具体功能与流程见《saas运营管理详细设计》。
11.3.1 指标体系总览
Section titled “11.3.1 指标体系总览”- 分层结构:北极星指标 → 一级指标(5 类)→ 二级指标(过程与专项)
- 北极星指标:
年度化回款额,即当期所有 #已支付订单的实付金额按服务期折算到年度后的合计;它同时反映新签能力与存量续费能力,是运营决策的第一依据 - 一级指标:
| 一级指标 | 回答的问题 | 主责角色 |
|---|---|---|
| 获客 | 潜在客户从哪里来、来了多少、成本多少 | 运营端运维 |
| 转化 | 客户在哪个环节流失、转化效率如何 | 运营端运维 |
| 交付 | 交付是否及时、验收是否一次通过 | 运维主管 |
| 留存 | 租户是否真正用起来、是否续费 | 运营端运维 |
| 收入 | 回款、应收与积分成本是否健康 | 运营端财务 |
- 指标口径三原则:
- 结算与财务类指标以业务库为准,埋点数据不参与
- 行为路径类指标以埋点数据为准,业务库无法覆盖
- 所有指标须在
指标字典中登记口径、数据源与责任人,未登记指标不得进入看板
11.3.2 租户生命周期漏斗
Section titled “11.3.2 租户生命周期漏斗”- 漏斗环节与《saas运营管理详细设计》的租户生命周期一一对应:访客 → 注册 → 创建租户 → 企业认证 → 试用激活 → 下单结算 → 确认收款 → 实施交付 → 上线激活 → 续费
- 各环节转化率作为运营周会的核心复盘对象,环比波动超过 20% 须给出归因说明
flowchart TB
V["访客 UV"] -->|"注册转化率"| R["注册账号"]
R -->|"建租户率"| T["创建租户"]
T -->|"认证通过率"| C["企业认证通过"]
C -->|"试用激活率"| TR["试用激活"]
TR -->|"下单率"| O["下单结算"]
O -->|"支付率"| P["确认收款"]
P --> D["实施交付完成"]
D -->|"激活率"| A["上线激活"]
A -->|"续费率"| RN["续费/扩购"]
RN --> A
11.3.3 核心指标口径
Section titled “11.3.3 核心指标口径”1. 获客
| 指标 | 口径与公式 | 数据源 | 周期 | 主责 |
|---|---|---|---|---|
| 访问 UV/PV | 官网与应用市场页面去重访客数与浏览量 | 埋点 | 日/周/月 | 运维 |
| 新增注册账号数 | 当期完成注册的平台账号数 | 业务库 + 埋点 | 日/周/月 | 运维 |
| 新增租户数 | 当期创建且状态为 #注册 及以上的租户数 | 业务库 | 日/周/月 | 运维 |
| 推荐来源注册占比 | 携带推荐码的注册数 ÷ 总注册数 | 业务库 | 周/月 | 运维 |
| 有效线索数 | 当期由企业登记或订单结算生成、进入 EIM 跟进的线索数 | EIM | 周/月 | 运维 |
| CAC | 当期获客投入 ÷ 当期新签付费租户数 | 财务 + 业务库 | 月/季 | 财务 |
2. 转化
| 指标 | 口径与公式 | 数据源 | 周期 | 主责 |
|---|---|---|---|---|
| 注册→认证转化率 | 当期认证通过租户数 ÷ 当期新增租户数 | 业务库 | 周/月 | 运维 |
| 认证→下单转化率 | 当期首次下单租户数 ÷ 当期认证通过租户数 | 业务库 | 周/月 | 运维 |
| 下单→收款转化率 | 当期确认收款订单数 ÷ 当期下单订单数 | 业务库 | 周/月 | 财务 |
| 商机转化率 | 当期转销售订单的商机数 ÷ 当期商机总数 | EIM | 月 | 运维 |
| 平均成交周期 | Σ(收款确认日 − 下单日)÷ 订单数 | 业务库 | 月/季 | 运维 |
| ACV | 当期新签订单实付金额 ÷ 新签订单数 | 业务库 | 月/季 | 财务 |
3. 交付
| 指标 | 口径与公式 | 数据源 | 周期 | 主责 |
|---|---|---|---|---|
| 平均交付时长 | Σ(验收完成日 − 收款确认日)÷ 交付任务数 | 业务库 | 周/月 | 运维主管 |
| 一次验收通过率 | 首次验收即通过的任务数 ÷ 已验收任务数 | 业务库 | 月 | 运维主管 |
| 待实施积压量 | 当前状态为 #待实施 与 #实施中 的任务数 | 业务库 | 日/周 | 运维主管 |
| 超期未交付量 | 收款确认后超过约定交付天数仍未上线的任务数 | 业务库 | 周 | 运维主管 |
4. 留存
| 指标 | 口径与公式 | 数据源 | 周期 | 主责 |
|---|---|---|---|---|
| 活跃租户率 | 当期活跃租户数 ÷ 当期有效付费租户数 | 业务库 + 埋点 | 周/月 | 运维 |
| 应用使用广度 | 已开通应用中使用 ≥ N 个的租户占比(默认 N=2) | 埋点 | 月 | 运维 |
| 到期续费率 | 当期到期且完成续费的订单数 ÷ 当期到期订单数(按到期日归属,宽限 30 天) | 业务库 | 月/季 | 运维 |
| NRR | 同一批订单本期续费金额 ÷ 上期成交金额 | 业务库 | 季/年 | 财务 |
| 冻结率 | 当期状态转 #暂停 的租户数 ÷ 期初有效付费租户数 | 业务库 | 月 | 运维 |
| 流失挽回率 | 冻结后完成续费解冻的租户数 ÷ 当期冻结租户数 | 业务库 | 月 | 运维 |
5. 收入
| 指标 | 口径与公式 | 数据源 | 周期 | 主责 |
|---|---|---|---|---|
| 新签回款额 | 当期新签订单的确认收款金额合计 | 业务库 | 日/周/月 | 财务 |
| 续费回款额 | 当期续费订单的确认收款金额合计 | 业务库 | 周/月 | 财务 |
| 回款率 | 当期确认收款金额 ÷ 当期下单金额 | 业务库 | 月 | 财务 |
| 应收余额 | 已下单未收款的订单金额合计 | 业务库 | 周/月 | 财务 |
| 积分成本率 | 当期发放积分折算金额 ÷ 当期推荐来源回款额 | 业务库 | 月 | 财务 |
11.3.4 推荐官专项指标
Section titled “11.3.4 推荐官专项指标”- 结果指标:
| 指标 | 口径与公式 | 周期 |
|---|---|---|
| 活跃推荐官数 | 当期产生至少一次有效推广行为(生成链接、带来注册)的推荐官数 | 周/月 |
| 新增有效推荐数 | 当期新增的「有效推荐」关系数 | 周/月 |
| 推荐来源付费租户数 | 当期由推荐关系带来且首笔订单确认收款的租户数 | 月 |
| 推荐来源回款额 | 当期归因到推荐关系的订单实付金额合计 | 月 |
| 推荐来源回款占比 | 推荐来源回款额 ÷ 当期总回款额 | 月 |
| 积分 ROI | 推荐来源回款额 ÷(当期积分发放折算金额 + 当期推荐官运营投入) | 月/季 |
| 积分核销率 | (已抵充 + 已兑换)÷ 累计入账积分 | 月 |
| 积分作废率 | (违规作废 + 退款扣回)÷ 累计入账积分 | 月 |
- 过程指标:推广链接生成数、推广页访问 UV、推广页注册转化率、推荐官人均产出
- 风险指标:待核查推荐关系数、命中风控规则的推荐官数、积分扣回率(扣回积分 ÷ 累计入账积分)
- 推荐官的积分规则与归因口径以 role_referrer.md §7 为准,本节只定义度量口径
⚠️ 按本文决策裁剪:原文档过程指标含「分级分布(L1/L2/L3 占比)」、风险指标含「即将过期积分量」、积分作废率含「超期清零 + 超归因有效期失效」,均因 D-8(不设等级)、D-18(不设有效期)、D-17(即时发放,无「待入账积分」) 而删除或修订——积分作废率改为「违规作废 + 退款扣回」。
11.3.5 看板与周期报表
Section titled “11.3.5 看板与周期报表”- 运营驾驶舱(运营端工作台,日更新):租户总数与有效付费租户数、当月回款额与完成率、待实施积压量、本月到期租户数、活跃租户率、推荐来源占比
- 推荐官看板(周更新):推荐官总数、本周新增有效推荐与付费租户、本周积分发放与核销、TOP 推荐官排行、待核查风险事件
- 交付看板(日更新):待实施/实施中/待验收任务数、平均交付时长、超期任务清单
- 财务看板(月更新):新签与续费回款、应收账龄、发票开具情况、积分发放量与折算成本、积分 ROI
- 积分相关指标统一按 100 积分 = 1 元折算为金额后参与财务类计算,积分本身不计入收入与应收
- 周期报表(定时推送至运营群,沿用《saas运营管理详细设计》的提醒规则):
- 每日 9:00:昨日新增注册数、新增认证数、新增订单数、收款金额
- 每周一 9:00:上周新增租户数、订单数、成交金额、待实施数,附本周到期租户清单
- 每月 1 日 9:00:上月新增租户数、成交金额、到期续费率,附本月到期租户清单(租户、@租户管理员、到期时间、续费金额)
- 推送内容须同时给出环比与同比,异常指标标注警示色
⚠️ 按本文决策裁剪:推荐官看板原含「分级分布」「即将过期积分提醒」,均因 D-8、D-18 而删除。
11.3.6 指标治理与异常处理
Section titled “11.3.6 指标治理与异常处理”- 指标字典:每个指标登记名称、口径、公式、数据源、统计周期、责任人、上线时间与变更记录,是口径的唯一来源
- 口径变更:变更须经运维与财务共同评审,评审通过后留痕并公告;变更后历史数据不回溯重算,仅在新周期生效,确需回溯的须专项说明
- 统计时点:指标以 T+1 离线计算为正式口径,实时数据仅用于监控与告警,两者不一致时以离线为准
- 异常排查流程:
- 第一步核对事件量:检查埋点上报量是否异常(缺失、重复、激增)
- 第二步核对去重结果:按
event_id去重后与业务单据数比对 - 第三步核对业务库:直接查询订单、租户、积分流水表,确认是否为业务真实变化
- 三步结论不一致时,判定为数据质量问题并登记缺陷,由数据责任人跟进修复
- 数据质量告警:核心指标上报量环比波动超过 30%、关键事件缺失或必填属性为空率达到 1% 时触发告警
11.3.7 待明确事项(指标类)
Section titled “11.3.7 待明确事项(指标类)”❓ 待明确:北极星指标是否采用「年度化回款额」,是否需同时考核活跃租户数作为约束性指标(见 decisions.md #52)。 ❓ 待明确:到期续费率的宽限期(建议 30 天)与到期归属口径(按到期日还是按收款日)(见 #53)。 ❓ 待明确:活跃租户的判定门槛——登录并使用 ≥ 1 个应用,是否需叠加最低使用天数(见 #54)。 ❓ 待明确:应用使用广度的 N 值(默认 2)(见 #55)。 ❓ 待明确:看板由 BI 工具实现还是由平台运营端工作台原生实现(见 #56)。 ❓ 待明确:积分折算成本是否计入 CAC 的获客投入,以及积分商场商品成本的科目归属(见 #57)。
11.3.8 合并说明(冲突清单)
Section titled “11.3.8 合并说明(冲突清单)”| 原指标文档规则 | 本文决策裁决 | 结果 |
|---|---|---|
| 推荐官过程指标「分级分布 L1/L2/L3 占比」 | D-8 不设等级 | 删除 |
| 风险指标「即将过期积分量」 | D-18 不设有效期 | 删除 |
| 积分作废率「超期清零 + 超归因有效期失效」 | D-18 不设有效期、D-17 即时发放 | 修订为「违规作废 + 退款扣回」 |
| 推荐官看板「分级分布」「即将过期积分提醒」 | D-8、D-18 | 删除 |
| 名词「积分」不可提现、不可兑现 | D-18 不可提现、不可转让 | 对齐 |
| 指标体系、漏斗、五类指标表、看板、治理细则 | 不冲突 | 吸收并入 |
11.4 平台埋点监测(指标的数据来源)
Section titled “11.4 平台埋点监测(指标的数据来源)”📚 本节合并自独立文档《saas系统埋点监测》(
saas_event_tracking.md)。⚠️ 本节为平台级埋点设计,覆盖范围超出营销策略(含交付、续费、租户使用等平台通用场景),仅「推荐官」一类为营销专属。原文档中与本文已拍板决策冲突的事件与属性,一律以本文决策(D-x)为准;不冲突的分层、命名、属性、清单、链路、质量与合规细则已吸收并入。合并涉及的主要冲突见「§11.4.10 合并说明」。
埋点服务于本节 §11.3 中的行为路径类指标;结算与财务类指标以业务库为准,埋点数据不参与积分发放与财务结算。推荐官相关的推广行为采集规则与 role_referrer.md §7 的归因口径保持一致。
名词解释(埋点监测)
| 名词 | 释义 |
|---|---|
| 埋点 | 在页面或服务端代码中上报用户行为与业务事件的技术手段,是行为分析的数据来源 |
| 事件 | 一次被记录的行为,由事件名与一组属性构成,是埋点的最小单位 |
| 公共属性 | 所有事件均须携带的上下文属性,如用户、租户、会话、来源与设备信息 |
| 结果事件 | 与业务结果强相关的事件(注册成功、支付成功等),以服务端上报为准,参与指标计算 |
| 过程事件 | 描述用户操作路径的事件(页面浏览、点击等),以前端上报为主,用于路径与转化分析 |
| 幂等去重 | 按事件唯一标识 event_id 去除重复上报的机制,保证同一事件只计一次 |
关联术语「归因」「漏斗转化率」「活跃租户」见 index.md 术语表。
11.4.1 埋点分层与原则
Section titled “11.4.1 埋点分层与原则”- 分层:
| 层级 | 覆盖范围 | 实现方式 | 用途 |
|---|---|---|---|
| 前端埋点 | 官网、应用市场、租户端后台、运营端的页面浏览、点击与曝光 | Web SDK 自动采集 + 元素埋点 | 路径分析、转化分析、功能使用度 |
| 服务端埋点 | 注册、认证、订单、支付、实施、积分等业务结果事件 | 业务服务在事务提交后上报 | 指标计算、漏斗分析(权威口径) |
| 定时补数 | 无法改造或历史遗留数据 | 定时任务从业务库抽取 | 兜底与回溯 |
- 原则:
- 结果事件以服务端为准:注册成功、认证通过、支付成功、积分入账等一律由服务端上报,前端同名事件仅作路径补充,不参与指标计算
- 前端只采集行为,不采集业务明细:禁止上报租户业务数据明细,与「运营端不可查看租户业务数据明细」的隔离要求保持一致
- 埋点不影响主流程:上报失败不得阻塞业务,采用异步上报 + 本地队列 + 失败重试
- 一次设计、长期使用:事件与属性一经上线纳入版本管理,变更须登记
- 技术选型(建议方案):
- 轻量方案:事件直接落
tabSaasEventTrack明细表,定时任务聚合为日/周/月指标表,供看板查询;适用于早期数据量较小阶段 - 标准方案:采集网关 → 消息队列 → 实时计算(监控告警)与离线数仓(ODS → DWD → DWS → ADS)并行;适用于数据量与实时性要求较高阶段
- 建议先按轻量方案落地 P0 事件,预留向标准方案演进的接口与字段
- 轻量方案:事件直接落
11.4.2 事件命名规范
Section titled “11.4.2 事件命名规范”- 命名格式:
{端}_{模块}_{对象}_{动作},全部小写、以下划线分隔,如web_market_app_view、srv_order_pay_success - 端标识:
web(官网与租户端)、portal(运营端)、app(移动端)、srv(服务端) - 动作枚举:
view(页面浏览)、click(点击)、expose(曝光)、submit(提交)、success(成功)、fail(失败)、start(开始)、finish(完成) - 命名禁止项:
- 事件名中不得携带变量(禁止
click_button_1,应写作click+ 属性button_id) - 不得使用拼音缩写或无语义代号
- 同一业务含义只允许一个事件名,禁止重复命名
- 事件名中不得携带变量(禁止
11.4.3 公共属性
Section titled “11.4.3 公共属性”- 所有事件均须携带以下公共属性:
| 属性 | 说明 |
|---|---|
| event_id | 事件唯一标识(UUID),用于幂等去重 |
| event_name | 事件名 |
| event_time | 事件发生时间(客户端,毫秒时间戳) |
| server_time | 服务端接收时间(毫秒时间戳) |
| user_id | 平台账号 ID,未登录为空 |
| tenant_id | 当前租户 ID,未登录或未归属租户为空 |
| anonymous_id | 匿名标识(Cookie 或设备标识),用于未登录路径串联 |
| session_id | 会话 ID,30 分钟无操作重新生成 |
| ref | 推荐码,落地页携带并写入 Cookie,用于推荐归因 |
| page_url / page_title | 当前页面地址与标题 |
| referrer | 来源页面地址 |
| ua / device_type / os / browser | 客户端环境 |
| ip | 客户端 IP,入库前做属地化处理 |
| env | 环境标识(#开发/#测试/#生产) |
| app_version | 前端版本号 |
- 业务属性:随事件自定义,须明确类型与是否必填;枚举值采用白名单校验,未登记的值计入异常
11.4.4 关键事件清单
Section titled “11.4.4 关键事件清单”1. 获客与注册
| 事件名 | 触发时机 | 关键属性 |
|---|---|---|
| web_landing_view | 推广落地页浏览 | ref、channel、utm_source |
| web_register_start | 打开注册页 | ref、channel |
| web_register_submit | 点击注册提交 | phone_filled(是否填写手机号,不采集号码明文) |
| srv_register_success | 注册成功 | user_id、tenant_id、ref、ref_source、result(#归因成功/#无推荐码) |
| srv_tenant_create_success | 创建租户成功 | tenant_id、org_name_hash、is_duplicate |
2. 企业认证
| 事件名 | 触发时机 | 关键属性 |
|---|---|---|
| web_cert_guide_view | 查看认证指引 | tenant_id |
| srv_cert_submit | 提交认证资料 | tenant_id、cert_type |
| srv_cert_approve | 认证审核完成 | tenant_id、result(#已通过/#已驳回)、duration_hours |
3. 应用与试用
| 事件名 | 触发时机 | 关键属性 |
|---|---|---|
| web_market_view | 浏览应用市场 | tenant_id |
| web_app_detail_view | 查看应用详情 | app_code、app_type |
| web_app_expose | 应用卡片曝光 | app_code、position |
| srv_trial_apply_submit | 提交试用申请 | tenant_id、app_code |
| srv_app_open_success | 应用开通成功 | tenant_id、order_id、app_code |
4. 订单与支付
| 事件名 | 触发时机 | 关键属性 |
|---|---|---|
| web_order_calc | 订单算价 | tenant_id、app_count、user_count、years、calc_amount |
| srv_order_submit | 订单提交结算 | order_id、amount、discount_amount、coupon_code、points_used |
| web_pay_channel_select | 选择支付方式 | order_id、pay_type |
| web_voucher_upload | 上传支付凭证 | order_id |
| srv_pay_success | 支付成功/确认收款 | order_id、pay_type、paid_amount、pay_duration_hours |
| srv_order_expire | 订单超时失效 | order_id |
| srv_order_refund_success | 退款成功 | order_id、refund_amount、is_partial |
5. 推荐官
⚠️ 本表按本文决策 D-8/D-16/D-17/D-18 裁剪:删除「提交成为推荐官申请」事件(D-16 简化为注册 + 实名认证自动开通)、删除事件属性
level(D-8 不设等级)、删除「积分到期清零」事件(D-18 不设有效期)、「待入账积分失效」改为「归因失效」(D-17 即时发放、无待入账概念)。
| 事件名 | 触发时机 | 关键属性 |
|---|---|---|
| srv_recommender_open | 实名认证后自动开通推荐官账号 | user_id、referral_code |
| web_promote_link_copy | 复制推广链接 | user_id、referral_code、scene |
| web_promote_qr_scan | 推广二维码被扫码 | referral_code、device_type |
| srv_point_accrue | 节点完成积分即时入账 | user_id、referral_code、order_id、stage、point |
| srv_point_attribution_expire | 归因失效(超 90 天未完成节点) | user_id、referral_code、stage、point |
| srv_point_deduct | 积分抵充订单 | user_id、order_id、point、deduct_amount |
| srv_point_exchange | 积分商场兑换商品 | user_id、point、goods_id、exchange_id |
| srv_point_reverse | 积分扣回(退款冲回) | user_id、order_id、point、reason |
| srv_recommender_risk_event | 命中风控规则 | user_id、rule_code、handle_result |
6. 实施交付与租户使用
| 事件名 | 触发时机 | 关键属性 |
|---|---|---|
| srv_implement_assign | 实施任务指派 | task_id、tenant_id、implementer |
| srv_implement_online | 租户系统上线 | task_id、tenant_id、duration_days |
| srv_implement_accept | 验收完成 | task_id、result(#已完成/#验收驳回)、duration_days |
| srv_tenant_login | 租户成员登录 | user_id、tenant_id、is_first_login_of_day |
| srv_app_use | 访问已开通应用 | user_id、tenant_id、app_code |
| srv_tenant_active | 租户日活聚合(定时任务) | tenant_id、active_users、used_apps |
7. 续费与流失
| 事件名 | 触发时机 | 关键属性 |
|---|---|---|
| srv_renew_remind_send | 发送续费预警 | tenant_id、order_id、days_before |
| srv_renew_order_submit | 提交续费订单 | tenant_id、order_id、amount、is_upgrade |
| srv_tenant_freeze | 租户冻结 | tenant_id、reason |
| srv_tenant_unfreeze | 租户解冻 | tenant_id |
| srv_tenant_churn | 租户注销 | tenant_id、retention_days |
11.4.5 数据链路
Section titled “11.4.5 数据链路”- 采集 → 网关 → 存储 → 计算 → 应用 的五段式链路,各段职责单一、可独立扩容
- 网关职责:鉴权、必填与枚举校验、公共属性补全(IP 属地、UA 解析、server_time)、脱敏、按
event_id幂等去重 - 失败处理:校验失败的事件进入死信队列并告警;可重试失败按指数退避重试,重试上限 3 次
- 补数机制:支持按时间区间重跑,重跑结果按
event_id覆盖,保证可重复执行且结果一致
flowchart LR
subgraph 采集端
F["前端 SDK\n页面/点击/曝光"]
S["服务端事件\n业务事务提交后上报"]
L["定时补数\n存量与遗留数据"]
end
F --> G["采集网关\n校验/补全/脱敏/幂等"]
S --> G
L --> G
G --> Q["事件队列"]
Q --> RT["实时计算\n监控与大屏"]
Q --> ODS["事件明细\ntabSaasEventTrack"]
ODS --> DWS["离线聚合\n日/周/月指标"]
DWS --> BI["运营驾驶舱 / BI 看板"]
RT --> BI
DWS --> RP["周期报表\n日/周/月推送"]
G -.-> DL["死信队列\n校验失败告警"]
11.4.6 埋点质量保障
Section titled “11.4.6 埋点质量保障”- 设计阶段:新增埋点须提交事件名、触发时机、属性清单与用途说明,评审通过后方可开发
- 测试阶段:
- 每条埋点须有对应的测试用例,明确触发场景与断言(事件上报、属性取值、上报次数)
- 提测时在测试环境触发并核对上报内容,未通过校验的埋点不予上线
- 上线后:
- 上线后 7 日内每日核对上报量与业务单据量的一致性
- 上报量环比波动超过 30% 触发告警,由数据责任人在 1 个工作日内给出结论
- 必填属性缺失率超过 1% 触发告警并回溯修复
- 变更管理:
- 埋点变更分为新增、属性变更与废弃三类,均须在
埋点字典中登记版本与生效日期 - 已废弃埋点保留采集至少 6 个月后方可下线,避免历史分析断档
- 禁止在未登记的情况下直接修改事件语义
- 埋点变更分为新增、属性变更与废弃三类,均须在
11.4.7 权限、隐私与合规
Section titled “11.4.7 权限、隐私与合规”- 数据权限:
| 角色 | 可见范围 |
|---|---|
| 运营端运维 | 全量行为与指标数据(不含租户业务明细) |
| 运营端财务 | 收入、回款、发票与积分折算成本相关指标 |
| 租户管理员 | 本租户的活跃与使用指标 |
| 推荐官 | 本人的推广数据与积分记录 |
- 禁止采集:密码、身份证号、银行卡号、支付凭证影像、营业执照影像,以及任何租户业务数据明细
- 采集告知:首次访问时通过 Cookie 提示告知采集范围与用途,提供关闭非必要采集的入口
- 存储与脱敏:IP 入库前做属地化处理,用户标识在分析层以哈希值关联;手机号、邮箱等仅采集脱敏后的标识位
- 保留期限:事件明细默认保留 24 个月,聚合指标长期保留;超期数据按策略清理
- 与业务隔离要求一致:运营端仅可查看开通与计费所需信息,埋点数据不得用于还原租户业务内容
11.4.8 实施分期与优先级
Section titled “11.4.8 实施分期与优先级”- P0(支撑核心漏斗与积分发放,优先落地):
- 服务端结果事件:注册归因、认证通过、订单提交、支付成功、退款、续费、租户冻结/解冻
- 推荐官全链路事件:推荐官开通、推广扫码、积分入账/归因失效/抵充/兑换/扣回、风控事件
- 落地页
ref参数与 Cookie 归因写入
- P1(支撑转化与留存分析):前端页面浏览与点击埋点、应用市场曝光与详情浏览、租户登录与应用使用、实施交付事件
- P2(支撑精细化运营):内容素材埋点、消息与通知触达效果、自定义看板与自助分析
⚠️ 按本文决策裁剪:P0 推荐官事件原含「积分到期清零」,因 D-18(不设有效期) 而删除。
11.4.9 待明确事项(埋点类)
Section titled “11.4.9 待明确事项(埋点类)”❓ 待明确:埋点技术选型——轻量方案(明细表 + 定时聚合)还是标准方案(消息队列 + 数仓)(见 decisions.md #58)。 ❓ 待明确:自建采集网关还是接入第三方分析平台(涉及数据出境与合规评估)(见 #59)。 ❓ 待明确:事件明细保留期限(建议 24 个月)与超期归档策略(见 #60)。 ❓ 待明确:会话切分规则(建议 30 分钟无操作重新生成)(见 #61)。 ❓ 待明确:指标字典与埋点字典的载体与维护责任人(见 #62)。 ❓ 待明确:是否需要采集运营端
portal的操作行为用于内部效率分析(见 #63)。 ❓ 待明确:积分商场(待建设)的兑换、退货退积分事件是否纳入本文件统一命名(见 #64)。
11.4.10 合并说明(冲突清单)
Section titled “11.4.10 合并说明(冲突清单)”| 原埋点文档规则 | 本文决策裁决 | 结果 |
|---|---|---|
web_recommender_join_submit 提交申请 + srv_recommender_join_success(含 level) | D-16 简化准入、D-8 不设等级 | 合并为 srv_recommender_open(实名认证自动开通) |
srv_point_accrue 属性 level | D-8 不设等级 | 删除 level 字段 |
srv_point_expire「待入账积分失效」 | D-17 即时发放 | 改为 srv_point_attribution_expire(归因失效) |
srv_point_clear「积分到期清零」 | D-18 不设有效期 | 删除该事件 |
| P0 分期「积分…到期清零」 | D-18 不设有效期 | 删除「到期清零」 |
| 分层、命名、属性、链路、质量、合规细则 | 不冲突 | 吸收并入 |
12. 实施路径
Section titled “12. 实施路径”12.1 阶段一:MVP(0–3 个月)
Section titled “12.1 阶段一:MVP(0–3 个月)”- 落地内部营销人员提成:报备、提成率配置、按营业收入计提 + 按回款对应的营业收入发放、月度结算单〔决策 D-31〕
- 发放节奏与计税通道由员工自选〔决策 D-36〕:节奏支持逐期于回款到账次月随工资发放或年终一次性发放;计税支持随薪资(并入综合所得)或以年终奖形式发(全年一次性奖金单独计税)——系统须将「结算资格判定(30% 门槛等,按各期到账时点)」与「实际付款/计税申报(逐期随工资 or 年终奖单独计税)」解耦,并按每人每纳税年度一次约束年终奖单独计税的使用
- 激励计算引擎需同时输出两个口径:计提明细(成本与应付款)与待发放明细(按回款进度)
- 打通订单与回款数据,建立客户归属主数据与查重能力
- 代理商与推荐官暂不开放线上自动化,由人工兜底
12.2 阶段二:体系完善(3–6 个月)
Section titled “12.2 阶段二:体系完善(3–6 个月)”- 代理商上线:合同管理、A 级独立子站模式与 A 级以下标准平台模式的差异化能力、等级与加权营收计算、产品线权重配置、月度对账、发票核验、自动升级
- 重新申请代理商的等级重置(下调一级 / 回最低级)流程
- 最低限价校验规则引擎
- 退款冲回(累计加权营收扣减 + 代理商收入同步扣减)
- 推荐官上线:邀请码归因(90 天有效期)、积分账户与规则、即时发放(四节点)、商城兑换与订单充抵、退款冲回与防刷
- 建立退款 / 坏账冲回机制与风控基础规则
12.3 阶段三:精细化(6–12 个月)
Section titled “12.3 阶段三:精细化(6–12 个月)”- 数据看板与 KPI 体系、渠道健康度预警
- 风控模型化、政策 A/B 测试与费率优化
说明:因已明确不存在混合模式(见 index.md §2.3),本阶段不再规划「联合打单业绩拆分」能力。
12.4 变更与灰度
Section titled “12.4 变更与灰度”- 新规则上线先灰度(单一区域 / 单一产品线),设新旧规则并行期与切换时点
- 规则变更需设置对存量订单的保护条款(老订单老办法)
❓ 待明确:三个阶段的资源投入(研发人月)与业务侧配套(法务、财务、渠道运营)是否到位。 ❓ 待明确:规则变更的提前告知期(建议不少于 30 个自然日)与代理商异议处理通道。