跳转到内容

系统支撑 + 度量指标 + 实施路径

系统支撑 + 度量指标 + 实施路径

Section titled “系统支撑 + 度量指标 + 实施路径”
模块核心能力优先级状态
角色管理三类角色的申请、审核、开通、停用、转换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规划中
  • 角色档案、代理合同、客户归属记录、报备单、等级变更记录、费率版本、激励明细、结算单、发票记录、积分流水、风控事件

✅ 已定稿(提成率部分)〔决策 D-25〕:提成率采用「版本 + 生效日期」的拉链设计,历史订单按成交时点的版本计算,避免调价追溯争议;提成率调整由公司总经理审批。 📌 假设(折扣率部分):代理商折扣率亦拟采用同一套「版本 + 生效日期」拉链设计,待渠道负责人 + 财务确认。

  • 三权分立建议:规则配置(商务运营)与结算付款(财务)权限隔离
  • 所有费率修改、归属变更、手工调整激励需二级审批并全量留痕 〔自动〕

本章包含两部分:营销策略度量(§11.1–§11.2,渠道角色 KPI 与策略健康度)与平台运营度量(§11.3–§11.4,合并自原独立文档《saas运营指标设计》《saas系统埋点监测》)。后者为平台级口径,覆盖范围超出营销策略本身,仅在数据来源与推荐官专项上与本策略强相关。

角色核心指标辅助指标
内部营销人员回款额、新签客户数、目标达成率客单价、销售周期、提成占回款比、计提发放差额(应付提成余额)
代理商累计加权营收(营业收入 × 产品线权重)、活跃率(季度有单占比)、续费贡献等级分布、单代理产出、回款周期、流失率
外部推荐官有效线索数、注册至付费转化率、获客成本活跃推荐官数、积分核销率(兑换 + 充抵)、裂变系数
  • 渠道获客成本(CAC):分渠道激励成本 ÷ 新增付费客户数
  • 激励占收入比:(提成 + 折扣让利 + 积分成本)÷ 总收入,建议设定红线
  • CAC 回收期:CAC ÷(ARPU × 毛利率)
  • 代理商集中度:头部代理商贡献占比,衡量渠道依赖风险
  • 归因质量:撞单率、归属申诉率、归属变更率
  • 结算健康度:结算周期时长、异议率、坏账导致的激励追回金额
  • 计提兑付差(仅内部提成):应付提成余额及其账龄,反映「已确认成本但未回款」的规模,是现金流风险的前瞻指标

❓ 待明确:激励占收入比的红线阈值(建议按产品线分别设定,需财务测算)。 ❓ 待明确:应付提成余额的账龄警戒线(如超过 12 个月未回款即转入坏账评估)。

📚 本节合并自独立文档《saas运营指标设计》(saas_operation_metrics.md)。原文档中与本文已拍板决策冲突的指标,一律以本文决策(D-x)为准;不冲突的指标口径、看板设计与指标治理细则已吸收并入。合并涉及的主要冲突见「§11.3.8 合并说明」。

指标口径以业务库为权威来源,行为路径类指标依赖本节 §11.4 埋点监测提供的埋点数据;推荐官的业务规则见 role_referrer.md §7,具体功能与流程见《saas运营管理详细设计》。

  1. 分层结构:北极星指标 → 一级指标(5 类)→ 二级指标(过程与专项)
  2. 北极星指标:年度化回款额,即当期所有 #已支付订单的实付金额按服务期折算到年度后的合计;它同时反映新签能力与存量续费能力,是运营决策的第一依据
  3. 一级指标:
一级指标回答的问题主责角色
获客潜在客户从哪里来、来了多少、成本多少运营端运维
转化客户在哪个环节流失、转化效率如何运营端运维
交付交付是否及时、验收是否一次通过运维主管
留存租户是否真正用起来、是否续费运营端运维
收入回款、应收与积分成本是否健康运营端财务
  1. 指标口径三原则:
    1. 结算与财务类指标以业务库为准,埋点数据不参与
    2. 行为路径类指标以埋点数据为准,业务库无法覆盖
    3. 所有指标须在指标字典中登记口径、数据源与责任人,未登记指标不得进入看板
  1. 漏斗环节与《saas运营管理详细设计》的租户生命周期一一对应:访客 → 注册 → 创建租户 → 企业认证 → 试用激活 → 下单结算 → 确认收款 → 实施交付 → 上线激活 → 续费
  2. 各环节转化率作为运营周会的核心复盘对象,环比波动超过 20% 须给出归因说明
flowchart TB
    V["访客 UV"] -->|"注册转化率"| R["注册账号"]
    R -->|"建租户率"| T["创建租户"]
    T -->|"认证通过率"| C["企业认证通过"]
    C -->|"试用激活率"| TR["试用激活"]
    TR -->|"下单率"| O["下单结算"]
    O -->|"支付率"| P["确认收款"]
    P --> D["实施交付完成"]
    D -->|"激活率"| A["上线激活"]
    A -->|"续费率"| RN["续费/扩购"]
    RN --> A

1. 获客

指标口径与公式数据源周期主责
访问 UV/PV官网与应用市场页面去重访客数与浏览量埋点日/周/月运维
新增注册账号数当期完成注册的平台账号数业务库 + 埋点日/周/月运维
新增租户数当期创建且状态为 #注册 及以上的租户数业务库日/周/月运维
推荐来源注册占比携带推荐码的注册数 ÷ 总注册数业务库周/月运维
有效线索数当期由企业登记或订单结算生成、进入 EIM 跟进的线索数EIM周/月运维
CAC当期获客投入 ÷ 当期新签付费租户数财务 + 业务库月/季财务

2. 转化

指标口径与公式数据源周期主责
注册→认证转化率当期认证通过租户数 ÷ 当期新增租户数业务库周/月运维
认证→下单转化率当期首次下单租户数 ÷ 当期认证通过租户数业务库周/月运维
下单→收款转化率当期确认收款订单数 ÷ 当期下单订单数业务库周/月财务
商机转化率当期转销售订单的商机数 ÷ 当期商机总数EIM月运维
平均成交周期Σ(收款确认日 − 下单日)÷ 订单数业务库月/季运维
ACV当期新签订单实付金额 ÷ 新签订单数业务库月/季财务

3. 交付

指标口径与公式数据源周期主责
平均交付时长Σ(验收完成日 − 收款确认日)÷ 交付任务数业务库周/月运维主管
一次验收通过率首次验收即通过的任务数 ÷ 已验收任务数业务库月运维主管
待实施积压量当前状态为 #待实施 与 #实施中 的任务数业务库日/周运维主管
超期未交付量收款确认后超过约定交付天数仍未上线的任务数业务库周运维主管

4. 留存

指标口径与公式数据源周期主责
活跃租户率当期活跃租户数 ÷ 当期有效付费租户数业务库 + 埋点周/月运维
应用使用广度已开通应用中使用 ≥ N 个的租户占比(默认 N=2)埋点月运维
到期续费率当期到期且完成续费的订单数 ÷ 当期到期订单数(按到期日归属,宽限 30 天)业务库月/季运维
NRR同一批订单本期续费金额 ÷ 上期成交金额业务库季/年财务
冻结率当期状态转 #暂停 的租户数 ÷ 期初有效付费租户数业务库月运维
流失挽回率冻结后完成续费解冻的租户数 ÷ 当期冻结租户数业务库月运维

5. 收入

指标口径与公式数据源周期主责
新签回款额当期新签订单的确认收款金额合计业务库日/周/月财务
续费回款额当期续费订单的确认收款金额合计业务库周/月财务
回款率当期确认收款金额 ÷ 当期下单金额业务库月财务
应收余额已下单未收款的订单金额合计业务库周/月财务
积分成本率当期发放积分折算金额 ÷ 当期推荐来源回款额业务库月财务
  1. 结果指标:
指标口径与公式周期
活跃推荐官数当期产生至少一次有效推广行为(生成链接、带来注册)的推荐官数周/月
新增有效推荐数当期新增的「有效推荐」关系数周/月
推荐来源付费租户数当期由推荐关系带来且首笔订单确认收款的租户数月
推荐来源回款额当期归因到推荐关系的订单实付金额合计月
推荐来源回款占比推荐来源回款额 ÷ 当期总回款额月
积分 ROI推荐来源回款额 ÷(当期积分发放折算金额 + 当期推荐官运营投入)月/季
积分核销率(已抵充 + 已兑换)÷ 累计入账积分月
积分作废率(违规作废 + 退款扣回)÷ 累计入账积分月
  1. 过程指标:推广链接生成数、推广页访问 UV、推广页注册转化率、推荐官人均产出
  2. 风险指标:待核查推荐关系数、命中风控规则的推荐官数、积分扣回率(扣回积分 ÷ 累计入账积分)
  3. 推荐官的积分规则与归因口径以 role_referrer.md §7 为准,本节只定义度量口径

⚠️ 按本文决策裁剪:原文档过程指标含「分级分布(L1/L2/L3 占比)」、风险指标含「即将过期积分量」、积分作废率含「超期清零 + 超归因有效期失效」,均因 D-8(不设等级)、D-18(不设有效期)、D-17(即时发放,无「待入账积分」) 而删除或修订——积分作废率改为「违规作废 + 退款扣回」。

  1. 运营驾驶舱(运营端工作台,日更新):租户总数与有效付费租户数、当月回款额与完成率、待实施积压量、本月到期租户数、活跃租户率、推荐来源占比
  2. 推荐官看板(周更新):推荐官总数、本周新增有效推荐与付费租户、本周积分发放与核销、TOP 推荐官排行、待核查风险事件
  3. 交付看板(日更新):待实施/实施中/待验收任务数、平均交付时长、超期任务清单
  4. 财务看板(月更新):新签与续费回款、应收账龄、发票开具情况、积分发放量与折算成本、积分 ROI
  5. 积分相关指标统一按 100 积分 = 1 元折算为金额后参与财务类计算,积分本身不计入收入与应收
  6. 周期报表(定时推送至运营群,沿用《saas运营管理详细设计》的提醒规则):
    1. 每日 9:00:昨日新增注册数、新增认证数、新增订单数、收款金额
    2. 每周一 9:00:上周新增租户数、订单数、成交金额、待实施数,附本周到期租户清单
    3. 每月 1 日 9:00:上月新增租户数、成交金额、到期续费率,附本月到期租户清单(租户、@租户管理员、到期时间、续费金额)
  7. 推送内容须同时给出环比与同比,异常指标标注警示色

⚠️ 按本文决策裁剪:推荐官看板原含「分级分布」「即将过期积分提醒」,均因 D-8、D-18 而删除。

  1. 指标字典:每个指标登记名称、口径、公式、数据源、统计周期、责任人、上线时间与变更记录,是口径的唯一来源
  2. 口径变更:变更须经运维与财务共同评审,评审通过后留痕并公告;变更后历史数据不回溯重算,仅在新周期生效,确需回溯的须专项说明
  3. 统计时点:指标以 T+1 离线计算为正式口径,实时数据仅用于监控与告警,两者不一致时以离线为准
  4. 异常排查流程:
    1. 第一步核对事件量:检查埋点上报量是否异常(缺失、重复、激增)
    2. 第二步核对去重结果:按 event_id 去重后与业务单据数比对
    3. 第三步核对业务库:直接查询订单、租户、积分流水表,确认是否为业务真实变化
    4. 三步结论不一致时,判定为数据质量问题并登记缺陷,由数据责任人跟进修复
  5. 数据质量告警:核心指标上报量环比波动超过 30%、关键事件缺失或必填属性为空率达到 1% 时触发告警

❓ 待明确:北极星指标是否采用「年度化回款额」,是否需同时考核活跃租户数作为约束性指标(见 decisions.md #52)。 ❓ 待明确:到期续费率的宽限期(建议 30 天)与到期归属口径(按到期日还是按收款日)(见 #53)。 ❓ 待明确:活跃租户的判定门槛——登录并使用 ≥ 1 个应用,是否需叠加最低使用天数(见 #54)。 ❓ 待明确:应用使用广度的 N 值(默认 2)(见 #55)。 ❓ 待明确:看板由 BI 工具实现还是由平台运营端工作台原生实现(见 #56)。 ❓ 待明确:积分折算成本是否计入 CAC 的获客投入,以及积分商场商品成本的科目归属(见 #57)。

原指标文档规则本文决策裁决结果
推荐官过程指标「分级分布 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 术语表。

  1. 分层:
层级覆盖范围实现方式用途
前端埋点官网、应用市场、租户端后台、运营端的页面浏览、点击与曝光Web SDK 自动采集 + 元素埋点路径分析、转化分析、功能使用度
服务端埋点注册、认证、订单、支付、实施、积分等业务结果事件业务服务在事务提交后上报指标计算、漏斗分析(权威口径)
定时补数无法改造或历史遗留数据定时任务从业务库抽取兜底与回溯
  1. 原则:
    1. 结果事件以服务端为准:注册成功、认证通过、支付成功、积分入账等一律由服务端上报,前端同名事件仅作路径补充,不参与指标计算
    2. 前端只采集行为,不采集业务明细:禁止上报租户业务数据明细,与「运营端不可查看租户业务数据明细」的隔离要求保持一致
    3. 埋点不影响主流程:上报失败不得阻塞业务,采用异步上报 + 本地队列 + 失败重试
    4. 一次设计、长期使用:事件与属性一经上线纳入版本管理,变更须登记
  2. 技术选型(建议方案):
    1. 轻量方案:事件直接落 tabSaasEventTrack 明细表,定时任务聚合为日/周/月指标表,供看板查询;适用于早期数据量较小阶段
    2. 标准方案:采集网关 → 消息队列 → 实时计算(监控告警)与离线数仓(ODS → DWD → DWS → ADS)并行;适用于数据量与实时性要求较高阶段
    3. 建议先按轻量方案落地 P0 事件,预留向标准方案演进的接口与字段
  1. 命名格式:{端}_{模块}_{对象}_{动作},全部小写、以下划线分隔,如 web_market_app_view、srv_order_pay_success
  2. 端标识:web(官网与租户端)、portal(运营端)、app(移动端)、srv(服务端)
  3. 动作枚举:view(页面浏览)、click(点击)、expose(曝光)、submit(提交)、success(成功)、fail(失败)、start(开始)、finish(完成)
  4. 命名禁止项:
    1. 事件名中不得携带变量(禁止 click_button_1,应写作 click + 属性 button_id)
    2. 不得使用拼音缩写或无语义代号
    3. 同一业务含义只允许一个事件名,禁止重复命名
  1. 所有事件均须携带以下公共属性:
属性说明
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前端版本号
  1. 业务属性:随事件自定义,须明确类型与是否必填;枚举值采用白名单校验,未登记的值计入异常

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
  1. 采集 → 网关 → 存储 → 计算 → 应用 的五段式链路,各段职责单一、可独立扩容
  2. 网关职责:鉴权、必填与枚举校验、公共属性补全(IP 属地、UA 解析、server_time)、脱敏、按 event_id 幂等去重
  3. 失败处理:校验失败的事件进入死信队列并告警;可重试失败按指数退避重试,重试上限 3 次
  4. 补数机制:支持按时间区间重跑,重跑结果按 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校验失败告警"]
  1. 设计阶段:新增埋点须提交事件名、触发时机、属性清单与用途说明,评审通过后方可开发
  2. 测试阶段:
    1. 每条埋点须有对应的测试用例,明确触发场景与断言(事件上报、属性取值、上报次数)
    2. 提测时在测试环境触发并核对上报内容,未通过校验的埋点不予上线
  3. 上线后:
    1. 上线后 7 日内每日核对上报量与业务单据量的一致性
    2. 上报量环比波动超过 30% 触发告警,由数据责任人在 1 个工作日内给出结论
    3. 必填属性缺失率超过 1% 触发告警并回溯修复
  4. 变更管理:
    1. 埋点变更分为新增、属性变更与废弃三类,均须在埋点字典中登记版本与生效日期
    2. 已废弃埋点保留采集至少 6 个月后方可下线,避免历史分析断档
    3. 禁止在未登记的情况下直接修改事件语义
  1. 数据权限:
角色可见范围
运营端运维全量行为与指标数据(不含租户业务明细)
运营端财务收入、回款、发票与积分折算成本相关指标
租户管理员本租户的活跃与使用指标
推荐官本人的推广数据与积分记录
  1. 禁止采集:密码、身份证号、银行卡号、支付凭证影像、营业执照影像,以及任何租户业务数据明细
  2. 采集告知:首次访问时通过 Cookie 提示告知采集范围与用途,提供关闭非必要采集的入口
  3. 存储与脱敏:IP 入库前做属地化处理,用户标识在分析层以哈希值关联;手机号、邮箱等仅采集脱敏后的标识位
  4. 保留期限:事件明细默认保留 24 个月,聚合指标长期保留;超期数据按策略清理
  5. 与业务隔离要求一致:运营端仅可查看开通与计费所需信息,埋点数据不得用于还原租户业务内容
  1. P0(支撑核心漏斗与积分发放,优先落地):
    1. 服务端结果事件:注册归因、认证通过、订单提交、支付成功、退款、续费、租户冻结/解冻
    2. 推荐官全链路事件:推荐官开通、推广扫码、积分入账/归因失效/抵充/兑换/扣回、风控事件
    3. 落地页 ref 参数与 Cookie 归因写入
  2. P1(支撑转化与留存分析):前端页面浏览与点击埋点、应用市场曝光与详情浏览、租户登录与应用使用、实施交付事件
  3. P2(支撑精细化运营):内容素材埋点、消息与通知触达效果、自定义看板与自助分析

⚠️ 按本文决策裁剪:P0 推荐官事件原含「积分到期清零」,因 D-18(不设有效期) 而删除。

❓ 待明确:埋点技术选型——轻量方案(明细表 + 定时聚合)还是标准方案(消息队列 + 数仓)(见 decisions.md #58)。 ❓ 待明确:自建采集网关还是接入第三方分析平台(涉及数据出境与合规评估)(见 #59)。 ❓ 待明确:事件明细保留期限(建议 24 个月)与超期归档策略(见 #60)。 ❓ 待明确:会话切分规则(建议 30 分钟无操作重新生成)(见 #61)。 ❓ 待明确:指标字典与埋点字典的载体与维护责任人(见 #62)。 ❓ 待明确:是否需要采集运营端 portal 的操作行为用于内部效率分析(见 #63)。 ❓ 待明确:积分商场(待建设)的兑换、退货退积分事件是否纳入本文件统一命名(见 #64)。

原埋点文档规则本文决策裁决结果
web_recommender_join_submit 提交申请 + srv_recommender_join_success(含 level)D-16 简化准入、D-8 不设等级合并为 srv_recommender_open(实名认证自动开通)
srv_point_accrue 属性 levelD-8 不设等级删除 level 字段
srv_point_expire「待入账积分失效」D-17 即时发放改为 srv_point_attribution_expire(归因失效)
srv_point_clear「积分到期清零」D-18 不设有效期删除该事件
P0 分期「积分…到期清零」D-18 不设有效期删除「到期清零」
分层、命名、属性、链路、质量、合规细则不冲突吸收并入

  • 落地内部营销人员提成:报备、提成率配置、按营业收入计提 + 按回款对应的营业收入发放、月度结算单〔决策 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),本阶段不再规划「联合打单业绩拆分」能力。

  • 新规则上线先灰度(单一区域 / 单一产品线),设新旧规则并行期与切换时点
  • 规则变更需设置对存量订单的保护条款(老订单老办法)

❓ 待明确:三个阶段的资源投入(研发人月)与业务侧配套(法务、财务、渠道运营)是否到位。 ❓ 待明确:规则变更的提前告知期(建议不少于 30 个自然日)与代理商异议处理通道。