# 丹阳公益婚恋服务平台
# V1.0 数据统计、运营指标与管理驾驶舱详细设计

版本：V1.0  
适用范围：平台管理后台、机构管理后台、公益红娘工作台、活动管理后台  
核心目标：统一指标口径、服务运营决策、发现业务问题、避免虚假繁荣、不过度建设大数据平台

---

# 第一章 设计目标

V1.0的数据统计不是为了做一个“很炫的驾驶舱”。

真正目的只有四个：

1. 看平台有没有人在正常使用
2. 看用户有没有真正形成有效匹配
3. 看公益红娘和活动有没有产生服务价值
4. 看哪里存在安全、服务或运营问题

因此V1.0坚持：

> **少而关键、口径统一、能够追溯、服务运营。**

不追求：

- 大屏动画
- 复杂BI
- 数据湖
- 实时数仓
- AI运营分析
- 百余项KPI

---

# 第二章 数据统计总原则

所有统计必须遵守：

> **同一指标只有一个正式定义。**

例如：

“注册用户数”

不能：

用户模块算一个数字。

后台Dashboard又算一个不同数字。

活动统计再算一个第三种口径。

---

# 第三章 指标定义结构

每个正式指标必须定义：

```text
指标名称
指标编码
指标解释
计算公式
数据来源
时间口径
去重规则
数据范围
是否实时
权限范围
```

---

# 第四章 建议指标目录

V1分为七类：

```text
01 用户增长与基础盘
02 认证与审核
03 推荐与匹配
04 沟通与关系进展
05 公益红娘服务
06 公益活动
07 安全与风控
```

---

# 第五章 时间口径

统一使用：

> 中国大陆业务时间。

建议：

```text
Asia/Shanghai
UTC+08:00
```

数据库仍使用：

> TIMESTAMPTZ

统计时按业务时区归属日期。

---

# 第六章 “今日”的定义

今日：

```text
当天00:00:00
至
当前时间
```

不是：

> 过去24小时。

---

# 第七章 “昨日”

```text
昨日00:00:00
至
昨日23:59:59.999...
```

---

# 第八章 “近7天”

建议定义：

> 含今天的连续7个自然日。

例如：

8月28日查看：

```text
8月22日～8月28日
```

---

# 第九章 月度口径

自然月：

```text
当月1日00:00
至
月底
```

不要把：

> 过去30天

叫“本月”。

---

# 第十章 用户总数

指标：

```text
USER_TOTAL
```

定义：

> 历史创建且未被物理删除的平台注册账号数量。

但Dashboard展示时更推荐：

> 当前有效用户

而不是单纯累计注册。

---

# 第十一章 当前有效用户

```text
ACTIVE_ACCOUNT_TOTAL
```

定义：

```text
account_status NOT IN (closed)
```

是否包含banned：

建议拆开统计。

更清晰：

```text
有效服务用户
封禁用户
已注销用户
```

---

# 第十二章 新增注册用户

```text
NEW_USERS
```

公式：

```text
COUNT(users.id)
WHERE created_at ∈ 时间范围
```

---

# 第十三章 新增实名用户

```text
NEW_VERIFIED_USERS
```

定义：

> 在统计期内首次实名认证成功的用户。

以：

```text
verified_at
```

为准。

不是：

> 当前所有已实名用户。

---

# 第十四章 新增审核通过用户

```text
NEW_APPROVED_USERS
```

定义：

> 在统计期内首次完成基础婚恋资料审核并通过的用户。

---

# 第十五章 可参与匹配用户

```text
MATCHABLE_USERS
```

定义必须同时满足：

```text
实名认证通过
+
资料审核通过
+
账号正常
+
婚恋状态允许匹配
+
未退出服务
```

这是比“注册用户数”更重要的基础盘指标。

---

# 第十六章 当前寻找中用户

```text
SEARCHING_USERS
```

条件：

```text
relationship_status = searching
AND
account_status = normal
AND
profile_review = approved
```

---

# 第十七章 暂停寻找用户

```text
PAUSED_USERS
```

用于观察：

> 有多少用户主动停止新推荐。

不能把他们算成“流失用户”。

---

# 第十八章 成功牵手用户

```text
SUCCESSFUL_USERS
```

定义：

> 已经通过双方成功牵手确认流程的用户。

不是：

- 双向Like
- 开始聊天
- 活动互选

这些都不能算“成功牵手”。

---

# 第十九章 成功牵手对数

```text
SUCCESSFUL_MATCH_PAIRS
```

公式：

```text
COUNT(matches)
WHERE status = successful
AND successful_at ∈ period
```

以：

> 对

为单位。

不要把两个人算成两对。

---

# 第二十章 注册转实名率

```text
VERIFICATION_RATE
```

建议使用同批用户漏斗口径：

```text
完成实名的新用户
/
对应注册用户
```

但V1 Dashboard可以先提供简单时期转化：

```text
统计期实名成功人数
/
统计期新增注册人数
```

需要在页面明确：

> 期间转化参考值。

---

# 第二十一章 实名转审核通过率

```text
PROFILE_APPROVAL_RATE
```

建议：

```text
审核通过人数
/
提交资料审核人数
```

比：

> 审核通过 / 实名人数

更符合审核流程。

---

# 第二十二章 首次审核通过率

```text
FIRST_REVIEW_PASS_RATE
```

定义：

```text
首次ReviewTask直接approved数量
/
首次ReviewTask完成数量
```

用于判断：

> 用户资料填写是否容易理解。

如果非常低：

可能不是用户质量差。

也可能是：

> 表单和规则设计不清楚。

---

# 第二十三章 审核退回率

```text
REVIEW_NEED_EDIT_RATE
```

用于发现：

- 头像问题
- 简介问题
- 资料矛盾

---

# 第二十四章 审核原因TOP

统计：

```text
AVATAR_NOT_CLEAR
CONTACT_INFO_INCLUDED
PROFILE_CONFLICT
...
```

帮助优化前端引导。

---

# 第二十五章 平均审核时长

```text
AVG_REVIEW_DURATION
```

建议：

```text
completed_at - submitted_at
```

同时看：

```text
P50
P90
```

V1如果实现成本有限：

平均值 + 待审核数量即可。

---

# 第二十六章 待审核积压

```text
PENDING_REVIEWS
```

Dashboard非常重要。

因为它直接影响：

> 用户多久才能进入匹配。

---

# 第二十七章 推荐曝光

```text
RECOMMENDATION_IMPRESSIONS
```

定义：

> 推荐卡实际被用户展示。

不能只是：

> 后台生成了一条推荐记录。

最好区分：

```text
generated
shown
```

---

# 第二十八章 推荐用户数

```text
RECOMMENDED_USERS
```

定义：

> 在统计期内至少看到一次推荐的去重用户数。

---

# 第二十九章 人均推荐曝光

```text
AVG_RECOMMENDATIONS_PER_USER
```

公式：

```text
推荐曝光总次数
/
收到推荐的用户数
```

---

# 第三十章 推荐详情查看率

```text
RECOMMENDATION_DETAIL_VIEW_RATE
```

公式：

```text
由推荐进入用户详情次数
/
推荐曝光次数
```

---

# 第三十一章 Like数

```text
LIKES
```

统计：

> 用户主动表达喜欢次数。

要排除：

- 重复幂等请求
- 系统重试

以最终业务事件为准。

---

# 第三十二章 推荐Like率

```text
RECOMMENDATION_LIKE_RATE
```

公式：

```text
推荐来源Like
/
推荐详情有效曝光或推荐曝光
```

建议正式口径：

> Like / 推荐曝光。

---

# 第三十三章 Pass率

```text
RECOMMENDATION_PASS_RATE
```

不是越低越好。

它只是：

> 用户筛选行为。

如果异常高：

可能：

- 推荐不准
- 用户条件表达不完整
- 用户池不足

---

# 第三十四章 Mutual Match数量

```text
MUTUAL_MATCHES
```

定义：

> 统计期内新形成有效双向Match的对数。

来源：

```text
user_like
activity
```

都可统计。

---

# 第三十五章 Mutual Match来源

必须拆：

```text
daily_recommendation
discover
matchmaker
activity
```

这样才能判断：

> 哪种服务机制有效。

---

# 第三十六章 Like转Mutual率

```text
LIKE_TO_MUTUAL_RATE
```

公式：

```text
形成Mutual Match的有效Like关系数
/
有效Like总数
```

因为一个Match由双方Like构成，统计时必须固定口径。

更简单的管理口径可以定义：

```text
Mutual Match对数
/
至少发出一次Like的用户数
```

但不能两个页面混用。

---

# 第三十七章 推荐到Mutual漏斗

核心：

```text
推荐曝光
↓
详情查看
↓
Like
↓
Mutual Match
```

这是算法效果核心漏斗。

---

# 第三十八章 Chat Started

```text
CHAT_STARTED
```

定义：

> Match形成后，双方Conversation中至少出现一条用户文本/图片消息。

System消息不算。

---

# 第三十九章 Mutual到聊天启动率

```text
MATCH_TO_CHAT_RATE
```

公式：

```text
启动真实聊天的Match
/
新形成Mutual Match
```

---

# 第四十章 为什么这个指标重要

如果Mutual很多，但没人聊天：

可能说明：

- Like过于随意
- 双向匹配质量一般
- 用户不知道怎么开场

红娘服务和破冰提示可以针对优化。

---

# 第四十一章 双方均发言会话

可定义：

```text
TWO_WAY_CHAT_STARTED
```

条件：

> Conversation中双方都至少发过一条用户消息。

这个比单方发“你好”更有意义。

---

# 第四十二章 不建议用消息总量作为成功指标

某两个人一天发500条：

不代表比另两个人更成功。

因此Dashboard不要突出：

> 总消息数。

只用于技术容量监控。

---

# 第四十三章 Getting To Know数量

如果用户正式使用：

```text
getting_to_know
```

状态，可统计：

```text
GETTING_TO_KNOW_USERS
GETTING_TO_KNOW_MATCHES
```

但需要确认最终业务状态模型后再固化。

---

# 第四十四章 Unmatch数量

```text
UNMATCHED_MATCHES
```

用于分析：

> 形成Match后又结束的关系。

---

# 第四十五章 Match解除率

```text
UNMATCH_RATE
```

建议按Match cohort分析更合理。

V1简单：

```text
统计期解除Match
/
统计期活跃Match
```

作为参考。

不要过度解读。

---

# 第四十六章 成功牵手转化漏斗

```text
Match
↓
Chat
↓
Getting to Know
↓
Successful
```

其中成功牵手必须：

> 双方确认。

---

# 第四十七章 成功牵手不能由运营手工累加

正式统计来源：

```text
matches.status = successful
```

或成功确认事件。

不能后台输入：

> “本月牵手20对”

然后直接作为正式数据。

---

# 第四十八章 公益红娘申请数

```text
MATCHMAKER_REQUESTS
```

定义：

> 新创建MatchmakerService数量。

---

# 第四十九章 红娘服务用户数

```text
MATCHMAKER_USERS
```

去重：

> 接受红娘服务的用户数。

---

# 第五十章 当前服务中数量

```text
MATCHMAKER_ACTIVE_SERVICES
```

状态：

```text
assigned
in_service
waiting_user
```

具体是否全部算active由状态表定义。

---

# 第五十一章 待分配服务

```text
MATCHMAKER_UNASSIGNED
```

是管理Dashboard的重要待办。

---

# 第五十二章 首次处理时长

```text
MATCHMAKER_FIRST_RESPONSE_TIME
```

定义：

```text
首次有效处理时间
-
service.created_at
```

不是简单：

> 红娘打开页面时间。

有效处理可以是：

- 接单并记录
- 首次推荐
- 首次跟进

需要研发统一。

---

# 第五十三章 红娘推荐数

```text
MATCHMAKER_RECOMMENDATIONS
```

统计：

> 正式发送给用户的人工推荐。

不是红娘看过的候选数。

---

# 第五十四章 人均人工推荐

```text
AVG_MATCHMAKER_RECOMMENDATIONS
```

只是运营参考。

不能作为：

> 红娘越高越好的绩效指标。

---

# 第五十五章 红娘推荐查看率

```text
MATCHMAKER_RECOMMENDATION_VIEW_RATE
```

---

# 第五十六章 红娘推荐Like率

```text
MATCHMAKER_RECOMMENDATION_LIKE_RATE
```

可以判断：

> 人工筛选是不是提供了额外价值。

---

# 第五十七章 红娘来源Mutual Match

```text
MATCHMAKER_MUTUAL_MATCHES
```

来源识别：

> Recommendation source / Match attribution。

---

# 第五十八章 红娘服务完成率

```text
MATCHMAKER_COMPLETION_RATE
```

公式：

```text
完成的服务
/
应结束的服务
```

但V1不要过度追求100%。

有些用户仍在服务中。

---

# 第五十九章 红娘超时服务数

```text
OVERDUE_MATCHMAKER_SERVICES
```

按：

```text
next_followup_at
```

和配置时限计算。

用于工作管理。

---

# 第六十章 红娘质量指标

更适合关注：

```text
首次响应及时率
按时跟进率
推荐查看率
推荐Like率
Mutual Match率
用户服务反馈
```

---

# 第六十一章 红娘绩效明确不使用

不作为主要指标：

```text
电话数
跟进条数
推荐数量
“优质资源”数量
```

---

# 第六十二章 活动发布数

```text
ACTIVITIES_PUBLISHED
```

统计正式发布活动。

草稿不算。

---

# 第六十三章 活动报名人数

```text
ACTIVITY_APPLICANTS
```

定义：

> 提交报名的用户数量。

---

# 第六十四章 活动审核通过人数

```text
ACTIVITY_APPROVED_REGISTRATIONS
```

---

# 第六十五章 活动签到人数

```text
ACTIVITY_CHECKINS
```

是真实到场人数的核心数据。

---

# 第六十六章 活动到场率

```text
ACTIVITY_ATTENDANCE_RATE
```

公式：

```text
签到人数
/
审核通过人数
```

---

# 第六十七章 活动报名通过率

```text
ACTIVITY_APPROVAL_RATE
```

公式：

```text
approved
/
已完成人工审核的报名
```

不要把pending放入分母。

---

# 第六十八章 活动男女结构

显示：

```text
报名男女
通过男女
签到男女
```

用于运营平衡。

不对用户公开。

---

# 第六十九章 活动年龄结构

按年龄段汇总即可。

V1不做过细的个人画像交叉分析。

---

# 第七十章 活动反馈提交率

```text
ACTIVITY_FEEDBACK_RATE
```

建议分母：

> 已签到用户。

---

# 第七十一章 活动意向提交率

```text
ACTIVITY_INTEREST_SUBMISSION_RATE
```

公式：

```text
提交活动意向用户
/
签到用户
```

---

# 第七十二章 活动双向互选对数

```text
ACTIVITY_MUTUAL_INTEREST_PAIRS
```

这是活动核心结果之一。

---

# 第七十三章 活动互选率

可以定义：

```text
至少形成1个双向互选的用户数
/
提交意向用户数
```

比：

> 双向对数 / 人数

更容易理解。

---

# 第七十四章 活动来源Match数

```text
ACTIVITY_MATCHES
```

如果双方活动互选创建Match，则计入。

---

# 第七十五章 活动来源聊天启动率

用于判断：

> 线下见面后是否真的继续交流。

---

# 第七十六章 活动来源成功牵手

长期指标：

```text
ACTIVITY_SUCCESSFUL_MATCHES
```

来源通过Match attribution追踪。

---

# 第七十七章 不把双向互选称“牵手成功”

后台正式术语：

> 双向互选。

只有：

```text
status = successful
```

才叫：

> 成功牵手。

---

# 第七十八章 举报数量

```text
REPORTS_CREATED
```

按类型拆：

```text
虚假资料
婚姻状态疑似虚假
骚扰
诈骗
金钱诱导
广告
其他
```

---

# 第七十九章 举报用户数

去重统计：

```text
被举报用户数
举报人用户数
```

---

# 第八十章 举报成立数

```text
CONFIRMED_REPORTS
```

只有人工处理确认成立。

---

# 第八十一章 举报成立率

```text
REPORT_CONFIRMATION_RATE
```

公式：

```text
confirmed
/
已完成处理举报
```

---

# 第八十二章 风控处置人数

按：

```text
warning
feature_limit
temporary_suspend
ban
```

分别统计。

---

# 第八十三章 当前风险账户

```text
RISK_USERS_CURRENT
```

按：

```text
watch
high
critical
```

分层。

---

# 第八十四章 风险处理时长

```text
AVG_REPORT_RESOLUTION_TIME
```

尤其关注：

> 高风险举报。

Dashboard可显示：

```text
高风险待处理数量
```

比平均值更实际。

---

# 第八十五章 申诉数量

```text
APPEALS_CREATED
```

及：

```text
APPEALS_APPROVED
```

用于发现：

> 风控误判是否过多。

---

# 第八十六章 拉黑行为统计

可以看：

```text
BLOCK_ACTIONS
```

但不要轻易把被拉黑次数做成用户质量排名。

只作为：

> 风控信号和整体平台体验指标。

---

# 第八十七章 安全事件率

例如：

```text
每1000个活跃用户举报数
```

比单纯举报总数更容易跨月份比较。

---

# 第八十八章 MAU

```text
MONTHLY_ACTIVE_USERS
```

V1建议“活跃”定义：

统计期内发生至少一种有效业务行为：

```text
登录进入核心页面
查看推荐/搜索
Like
聊天
活动
红娘服务
```

但为了实现简单，可使用：

> 有有效登录Session并进入小程序。

需要统一埋点。

---

# 第八十九章 DAU

同理：

> 当天至少一次有效平台访问用户。

---

# 第九十章 DAU/MAU

可以观察使用频率。

但公益婚恋不是短视频产品。

不应追求：

> 用户每天都必须打开。

---

# 第九十一章 婚恋产品的特殊成功逻辑

一个成功用户最终：

> 离开推荐系统

其实可能是产品成功。

因此：

> 留存越高不一定越好。

这是婚恋产品和内容产品最大的差异之一。

---

# 第九十二章 不把“成功用户流失”当流失

如果用户：

```text
matched_successfully
```

停止活跃。

这属于：

> 成功退出核心匹配服务。

Dashboard需要从普通流失中排除。

---

# 第九十三章 用户流失建议定义

V1不需要立即做复杂Churn模型。

可以简单看：

```text
审核通过
+
仍处于searching
+
30/60天未活跃
```

作为：

> 沉默用户。

---

# 第九十四章 沉默用户

可作为公益红娘/活动运营参考。

但不能：

> 自动骚扰用户。

仅在用户同意接收对应服务时触达。

---

# 第九十五章 用户池健康度

平台运营核心应该看：

```text
可匹配用户总数
男女结构
年龄结构
地区结构
近30天活跃
候选池不足用户比例
```

---

# 第九十六章 无候选用户比例

```text
NO_CANDIDATE_USER_RATE
```

定义：

> 当前Required双向过滤后，候选数量为0的searching用户比例。

非常重要。

---

# 第九十七章 候选池较小用户比例

例如：

```text
有效候选 <= 3
```

阈值配置。

帮助判断：

> 本地用户池是不是足够。

---

# 第九十八章 平均候选池大小

```text
AVG_CANDIDATE_POOL_SIZE
```

按性别/年龄段可拆。

这是比“注册人数”更能反映平台是否可用的指标。

---

# 第九十九章 推荐覆盖率

```text
RECOMMENDATION_COVERAGE_RATE
```

公式：

```text
当天获得至少1个有效推荐的searching用户
/
当天应获得推荐的searching用户
```

---

# 第一百章 推荐不足原因

后台可统计：

```text
无符合Required候选
候选已曝光完
用户池过小
隐私/状态限制
```

帮助运营而不是只看到：

> 推荐失败。

---

# 第一百零一章 平台核心漏斗一：用户准入

```text
注册
↓
手机号
↓
实名
↓
资料完成
↓
提交审核
↓
审核通过
↓
进入匹配
```

---

# 第一百零二章 平台核心漏斗二：线上匹配

```text
推荐曝光
↓
详情查看
↓
Like
↓
Mutual Match
↓
聊天启动
↓
进一步了解
↓
成功牵手
```

---

# 第一百零三章 平台核心漏斗三：公益红娘

```text
申请红娘服务
↓
红娘接手
↓
人工推荐
↓
用户查看
↓
用户Like
↓
Mutual Match
↓
进一步了解
```

---

# 第一百零四章 平台核心漏斗四：活动

```text
活动详情
↓
报名
↓
审核通过
↓
签到
↓
意向提交
↓
双向互选
↓
Match
↓
聊天
```

---

# 第一百零五章 Dashboard设计原则

首页不展示50个指标。

平台管理员首页只应该快速回答：

```text
今天有没有积压？
平台有没有正常匹配？
有没有高风险问题？
最近活动和红娘服务是否正常？
```

---

# 第一百零六章 平台Dashboard第一屏

建议6个任务型卡片：

```text
待审核资料
待处理高风险举报
红娘待分配
活动报名待审核
今日新增审核通过
今日新Mutual Match
```

---

# 第一百零七章 第二屏：核心业务漏斗

建议：

```text
近30天
推荐曝光
↓
Like
↓
Mutual Match
↓
聊天启动
↓
成功牵手
```

不要堆复杂3D图。

---

# 第一百零八章 第三屏：用户池健康

展示：

```text
当前可匹配用户
男性/女性结构
主要年龄段
无候选用户比例
近30天活跃用户
```

---

# 第一百零九章 第四屏：公益服务

左右：

```text
红娘
当前服务中
待跟进
本月人工推荐
形成Match

活动
报名中活动
本月到场人数
双向互选
活动来源Match
```

---

# 第一百一十章 第五屏：安全

展示：

```text
待处理举报
高风险举报
当前受限用户
本月封禁
本月申诉
```

---

# 第一百一十一章 不要Dashboard大红大绿

风险使用醒目颜色。

普通增长数据保持中性。

平台不是证券行情软件。

---

# 第一百一十二章 趋势图

V1最有价值的趋势：

```text
新增注册
审核通过
Mutual Match
活动签到
举报
```

按日/周。

---

# 第一百一十三章 图表数量

建议Dashboard同屏：

> 3～5张图以内。

其他数据进入专项分析页。

---

# 第一百一十四章 用户统计页

页面结构：

```text
顶部筛选
↓
核心指标
↓
用户准入漏斗
↓
用户结构
↓
趋势
```

---

# 第一百一十五章 用户结构

V1支持：

- 性别
- 年龄段
- 区域

学历等不是首页必看。

---

# 第一百一十六章 不统计敏感价值标签

不做：

- 高收入用户比例
- 高资产用户
- 高颜值用户
- “优质用户”占比

---

# 第一百一十七章 匹配统计页

建议：

```text
推荐曝光
详情查看
Like
Mutual Match
聊天启动
Unmatch
成功牵手
```

---

# 第一百一十八章 来源拆分

Match来源：

```text
系统推荐
主动找对象
公益红娘
线下活动
```

这是管理层最需要看的一项。

---

# 第一百一十九章 算法版本统计

可按：

```text
rule_version
```

查看：

- 推荐曝光
- Like率
- Mutual率

V1不需要复杂实验平台。

---

# 第一百二十章 红娘统计页

顶部：

```text
服务申请
当前服务中
待跟进
人工推荐
形成Match
```

下方：

> 红娘个人工作视图。

---

# 第一百二十一章 红娘个人数据

可以显示：

```text
服务中数量
首次响应及时率
待跟进
本月推荐
形成Mutual Match
```

但不公开做排行榜。

---

# 第一百二十二章 是否显示“成功牵手数/红娘”

内部可以查询服务贡献。

但不建议：

> 大屏排名“第一名牵手12对”。

避免诱导红娘为了指标过度干预。

---

# 第一百二十三章 活动统计页

每场活动：

```text
报名
通过
签到
到场率
反馈
意向
双向互选
后续Match
```

---

# 第一百二十四章 活动对比

可以看：

> 不同活动到场率、互选率。

用于改进活动形式。

---

# 第一百二十五章 风控统计页

建议：

```text
新举报
待处理
高风险
处理时长
成立率
处置
申诉
```

---

# 第一百二十六章 风控类型分布

例如：

```text
骚扰
虚假资料
诈骗
金钱诱导
广告
身份冒用
```

帮助安全运营。

---

# 第一百二十七章 组织统计

机构管理员：

> 只看本机构有业务关系的数据。

例如工会：

```text
本机构活动
本机构红娘服务
本机构工作人员任务
```

---

# 第一百二十八章 机构不能看到平台用户全局漏斗

除非明确授权。

组织Dashboard重点：

> 自己提供了哪些服务。

---

# 第一百二十九章 组织服务成效

可以统计：

```text
红娘服务人数
活动场次
报名人数
签到人数
人工推荐
形成Mutual Match
```

---

# 第一百三十章 数据范围继承权限模型

所有Analytics API：

必须调用：

> DataScopeService。

不能因为是“统计”就绕过数据范围。

---

# 第一百三十一章 小样本数据保护

例如：

某机构某年龄段只有1个女性用户。

不要支持：

> 性别+年龄+婚姻状态+职业

无限交叉筛选。

容易间接识别个人。

---

# 第一百三十二章 V1统计维度控制

主要：

```text
时间
性别
年龄段
区域
来源
组织
状态
```

足够。

---

# 第一百三十三章 指标实时性分级

## 实时/准实时

```text
待审核
待举报
待分配
当前活动报名
当前未读
```

## 小时级/日级

```text
推荐漏斗
用户结构
红娘效果
活动效果
```

---

# 第一百三十四章 不要所有Dashboard每秒刷新

增加数据库压力没有价值。

任务型数据：

> 手动刷新/分钟级。

统计：

> 小时/日汇总。

---

# 第一百三十五章 V1数据架构

建议：

```text
业务PostgreSQL
↓
SQL聚合
+
Daily Summary
↓
Analytics Service
↓
Admin Dashboard
```

不需要：

```text
Kafka → Flink → ClickHouse → BI
```

---

# 第一百三十六章 Daily Summary表

建议后续增加：

```text
daily_platform_metrics
```

---

# 第一百三十七章 daily_platform_metrics

建议字段：

```text
metric_date

new_users
new_verified_users
new_approved_users
active_users

recommendation_impressions
likes
mutual_matches
chat_started
successful_matches

matchmaker_requests
matchmaker_recommendations

activity_applications
activity_checkins
activity_mutual_pairs

reports
confirmed_reports
```

---

# 第一百三十八章 是否一张宽表足够

V1可以。

后续如果维度复杂再拆：

```text
daily_user_metrics
daily_match_metrics
daily_activity_metrics
```

早期不要过度设计。

---

# 第一百三十九章 组织日汇总

需要机构Dashboard时，可以增加：

```text
daily_organization_metrics
```

字段：

```text
date
organization_id
...
```

---

# 第一百四十章 指标不要直接存百分比

保存：

```text
numerator
denominator
```

或原始数量。

前端/Service计算比例。

避免后续口径难改。

---

# 第一百四十一章 日汇总生成时间

建议：

> 每天凌晨生成上一自然日。

并允许：

> 后台补算指定日期。

---

# 第一百四十二章 汇总任务必须幂等

重复运行：

> 覆盖/Upsert同一天正式结果。

不能越跑数字越大。

---

# 第一百四十三章 今日数据

当日实时Dashboard：

> 可以从业务表轻量聚合 + Redis缓存。

昨日以前：

> 读Daily Summary。

---

# 第一百四十四章 历史数据补算

如果Bug修复：

支持：

```text
rebuildMetrics(startDate,endDate)
```

重新计算。

这是非常重要的维护能力。

---

# 第一百四十五章 指标来源必须可追溯

例如：

Dashboard显示：

> 今日Mutual Match 12

至少技术上可以追到：

```text
matches matched_at today
```

不能是神秘缓存数字。

---

# 第一百四十六章 Event埋点

建议基础事件：

```text
app_open
login_success
verification_success
profile_submit
review_approved

recommendation_impression
profile_view
like_created
mutual_match_created
chat_started

matchmaker_service_created
matchmaker_recommendation_viewed

activity_view
activity_apply
activity_checkin
activity_interest_submit

relationship_success
```

---

# 第一百四十七章 业务表优先于前端埋点

例如：

Mutual Match：

> 以数据库Match为真。

不能只根据：

```text
frontend event = mutual_match
```

统计。

---

# 第一百四十八章 埋点主要用于什么

适合：

- 页面曝光
- 点击
- Funnel前端行为

不适合替代：

- 实名
- 审核
- Match
- 活动报名
- 举报

这些后端都有正式业务记录。

---

# 第一百四十九章 recommendation_impression

要避免：

> 后端返回6人就算6次曝光。

更准确：

> 卡片实际进入用户可视区域。

V1如果实现成本高：

可先以：

> 返回给首页并实际进入推荐列表

作为近似口径，但必须统一。

---

# 第一百五十章 Profile View

用户从：

- 推荐
- 找对象
- 红娘推荐
- 活动

打开资料时记录source。

---

# 第一百五十一章 Source Attribution

所有关键行为建议记录：

```text
source
```

例如Like：

```text
daily
discover
matchmaker
activity
```

---

# 第一百五十二章 Attribution规则

如果用户先在推荐看到B，过两天主动搜索并Like：

最终source应该如何归属？

V1建议：

> 以实际触发Like的入口为主。

即：

```text
like_source = discover
```

同时推荐历史仍保留。

---

# 第一百五十三章 Match Attribution

如果A从红娘推荐Like，B从每日推荐Like。

一个Match有两个不同来源。

建议保存：

```text
user_a_like_source
user_b_like_source
```

管理统计可以定义：

> 含红娘贡献的Match

只要一侧来源matchmaker即可。

避免强行单一归因。

---

# 第一百五十四章 Activity Match来源

双方活动互选：

```text
match.source = activity
```

明确。

---

# 第一百五十五章 成功牵手归因

如果双方最初由系统推荐，后来参加活动，再成功。

不建议V1做复杂多触点营销归因。

可以记录：

```text
original_match_source
```

作为主要来源。

---

# 第一百五十六章 数据质量检查

每天/定期检查：

```text
successful match但successful_at为空
conversation无match
activity registration关联无activity
review approved但profile状态异常
```

---

# 第一百五十七章 数据一致性异常

建立后台技术告警。

不要把脏数据悄悄算入Dashboard。

---

# 第一百五十八章 统计延迟说明

后台可以显示：

> 数据更新时间：10:30

避免运营以为绝对实时。

---

# 第一百五十九章 导出统计

允许：

> 聚合统计导出。

例如：

```text
2026年8月活动运营数据
```

不自动包含个人名单。

---

# 第一百六十章 数据导出权限

依然需要：

```text
analytics.export
```

单独权限。

---

# 第一百六十一章 政府/公益组织报表

未来可能需要：

- 月报
- 季报
- 项目服务数据

V1可以提供：

> 标准汇总导出。

但不要把它做成复杂报表设计器。

---

# 第一百六十二章 建议标准月报

包含：

```text
新增注册
新增实名
新增审核通过
当前可匹配
新Mutual Match
成功牵手
红娘服务人数
活动场次
活动到场人数
举报处置
```

---

# 第一百六十三章 对外公开数据必须谨慎

例如宣传：

> 本平台累计成功牵手XX对。

必须来源：

```text
双方确认successful
```

不能：

> 活动互选也算进去。

---

# 第一百六十四章 对外宣传不得虚构增长率

任何宣传数字：

> 必须能从系统正式口径还原。

---

# 第一百六十五章 Dashboard不显示用户个人排名

不做：

- 最受欢迎用户
- Like最多用户
- 被看最多用户
- 高分用户

这些都不符合公益产品方向。

---

# 第一百六十六章 红娘也不做公开榜

内部管理看：

> 服务任务和质量。

不做娱乐化排行。

---

# 第一百六十七章 风控指标不能成为“坏人榜”

后台可以案件排序。

但不要：

> 公开展示用户“风险排行榜”。

---

# 第一百六十八章 北极星指标

V1不建议只用：

> DAU

作为北极星。

更符合公益婚恋价值的是：

> **有效双向关系形成与进一步了解。**

---

# 第一百六十九章 推荐核心业务指标

建议核心管理层关注：

```text
当前可匹配用户数
推荐覆盖率
Mutual Match数
Match到聊天启动率
正在了解/成功牵手
公益红娘有效服务
活动双向互选
高风险待处理
```

---

# 第一百七十章 “成功牵手率”慎用

由于婚恋周期较长，简单：

```text
成功牵手 / 本月新注册
```

意义很低。

建议按：

> cohort

分析。

但V1不强制做复杂Cohort系统。

---

# 第一百七十一章 简单Cohort建议

可以按：

```text
审核通过月份
```

查看：

> 30/60/90天内形成Mutual Match的比例。

这是未来P2。

---

# 第一百七十二章 V1先记录好事件

只要：

- approved_at
- matched_at
- chat_started_at
- successful_at

完整。

未来随时可以做Cohort。

---

# 第一百七十三章 Dashboard页面结构建议

```text
┌─────────────────────────────────────────────┐
│ 平台运营概览                  时间：近30天    │
├─────────────────────────────────────────────┤
│ 待审核 │ 高风险举报 │ 红娘待分配 │ 活动待审   │
├─────────────────────────────────────────────┤
│ 可匹配用户 │ Mutual Match │ Chat启动 │ 成功牵手│
├─────────────────────────────────────────────┤
│               匹配漏斗                     │
├──────────────────────┬──────────────────────┤
│ 用户池健康            │ 公益服务             │
├──────────────────────┼──────────────────────┤
│ 风控情况              │ 近期活动             │
└──────────────────────┴──────────────────────┘
```

---

# 第一百七十四章 Dashboard交互

点击：

> 待审核 28

直接进入：

```text
/reviews?status=pending
```

Dashboard必须是：

> 工作入口。

不是只能看不能做。

---

# 第一百七十五章 指标卡点击

例如：

> 高风险举报 3

点击：

> 风控列表，risk=high。

---

# 第一百七十六章 平台统计筛选

建议：

```text
今天
昨日
近7天
近30天
本月
自定义
```

---

# 第一百七十七章 不需要“今年/去年”放第一层

使用频率低。

可自定义。

---

# 第一百七十八章 机构统计筛选

增加：

> 组织

但普通机构管理员不能切换到其他组织。

平台管理员可选。

---

# 第一百七十九章 Activity Dashboard

每场活动详情可以有独立数据页。

避免全塞平台Dashboard。

---

# 第一百八十章 Matchmaker Dashboard

红娘本人更关注：

```text
今日待办
```

而不是平台全局数据。

因此：

> 统计和工作台必须分清。

---

# 第一百八十一章 Analytics权限

建议：

```text
analytics.platform.overview
analytics.users
analytics.matches
analytics.matchmaker
analytics.activities
analytics.risk
analytics.organization
analytics.export
```

---

# 第一百八十二章 Data Viewer角色

只拥有：

```text
analytics.*
```

必要只读权限。

不拥有：

> 用户详情敏感查询。

---

# 第一百八十三章 统计缓存

Redis Key示例：

```text
analytics:dashboard:platform:2026-08-28
```

TTL：

> 几分钟。

避免高频聚合。

---

# 第一百八十四章 统计缓存失效

不要求每一个Like都立即清所有统计缓存。

允许：

> 准实时。

减少复杂度。

---

# 第一百八十五章 待办指标例外

如：

```text
pendingReviews
pendingHighRiskReports
```

需要更实时。

可单独查询/短缓存。

---

# 第一百八十六章 数据库索引支持

统计常用：

```text
users.created_at
user_identities.verified_at
review_tasks.completed_at/status
recommendation_records.shown_at/source
user_relations.created_at
matches.matched_at/status/source
messages.created_at
matchmaker_services.created_at/status
activities.start_at/status
activity_registrations.registered_at/status
reports.created_at/status/risk_level
```

---

# 第一百八十七章 不为了统计重复大量业务数据

业务表是主数据。

Summary只用于：

> 加速。

不要出现：

> 主业务改了，统计表变成第二个业务真相。

---

# 第一百八十八章 数据回溯

如果成功牵手后来重新开启服务：

历史成功：

> 仍然保留。

SUCCESSFUL_MATCH_PAIRS历史不会因为恢复寻找就被减掉。

---

# 第一百八十九章 当前状态与历史事件分离

例如：

```text
当前成功牵手用户数
```

和：

```text
历史成功牵手对数
```

不是同一个指标。

必须分别定义。

---

# 第一百九十章 推荐曝光历史

同一个用户看到B三次：

> 算3次曝光。

去重用户指标另算。

不能混淆。

---

# 第一百九十一章 Like撤回

如果A先Like后取消。

历史Like事件：

> 仍可算行为发生。

当前Like关系：

> 不存在。

因此统计需区分：

```text
like_events
current_likes
```

V1如果关系表只存当前状态，Recommendation action/history需要保留事件价值。

---

# 第一百九十二章 建议增加业务事件表吗

V1不强制建设大型Event Store。

但可以有轻量：

```text
business_events
```

记录关键业务事件。

---

# 第一百九十三章 business_events适用

例如：

```text
USER_VERIFIED
PROFILE_APPROVED
LIKE_CREATED
MUTUAL_MATCH_CREATED
CHAT_STARTED
MATCH_UNMATCHED
RELATIONSHIP_SUCCESS
ACTIVITY_CHECKED_IN
```

---

# 第一百九十四章 是否必须新增

如果开发团队能从正式业务表准确统计：

> 可以先不建。

V1优先简单。

但对：

> chat_started

这种一次性事件，

建议保存明确时间字段或事件。

---

# 第一百九十五章 Conversation建议补充

可增加：

```text
first_user_message_at
two_way_chat_started_at
```

便于统计。

---

# 第一百九十六章 Match建议补充

可增加：

```text
getting_to_know_at
```

如果最终使用该状态。

---

# 第一百九十七章 MatchmakerService建议补充

```text
first_handled_at
```

便于计算首次响应。

---

# 第一百九十八章 Activity建议已有数据足够

报名、审核、签到、互选都有明确时间字段。

---

# 第一百九十九章 数据统计验收原则

对于Dashboard任意数字：

测试人员应能：

> 用数据库查询验证。

---

# 第二百章 统计测试场景一

今天注册10人。

其中：

- 7人实名
- 5人提交审核
- 4人通过

Dashboard应该：

```text
新增注册 10
新增实名 7
提交审核 5
审核通过 4
```

---

# 第二百零一章 统计测试场景二

A/B互相Like。

产生：

```text
2个Like关系
1个Mutual Match
```

Dashboard不能显示：

> 2个Match。

---

# 第二百零二章 统计测试场景三

Match创建时系统自动发System消息。

双方都没说话。

应：

```text
Mutual Match +1
Chat Started +0
```

---

# 第二百零三章 统计测试场景四

A发“你好”。

B没回复。

```text
Chat Started +1
Two-Way Chat +0
```

---

# 第二百零四章 统计测试场景五

活动100人报名。

90通过。

80签到。

50提交意向。

形成10对双向互选。

应：

```text
Applicants 100
Approved 90
Checkins 80
Attendance 88.89%
Interest submitters 50
Mutual pairs 10
```

不能说：

> 成功牵手10对。

---

# 第二百零五章 统计测试场景六

红娘系统里看了20个候选，只正式给用户发2个。

红娘推荐数：

> 2。

不是20。

---

# 第二百零六章 统计测试场景七

一个举报处理为：

```text
insufficient_evidence
```

不应算：

> confirmed report。

---

# 第二百零七章 统计测试场景八

用户成功牵手后一个月重新使用平台。

历史：

> 成功牵手对数仍保留。

当前：

> relationship status按新状态统计。

---

# 第二百零八章 统计一致性测试

平台Dashboard：

> Mutual Match 20

Match统计页同一时间同一范围：

> 必须也是20。

如果不同：

> 说明指标口径或缓存有问题。

---

# 第二百零九章 组织范围测试

机构A管理员：

> 只能看到机构A活动/红娘服务数据。

平台全局注册用户：

> 不能因为机构A管理员能看统计就暴露完整平台画像。

---

# 第二百一十章 隐私测试

统计API不能返回：

```text
某32岁离异女教师唯一用户ID
```

聚合页面只返回聚合数据。

---

# 第二百一十一章 Dashboard性能目标

平台首页：

```text
P95 < 2s
```

可通过：

- Daily Summary
- Redis
- 少量实时待办查询

实现。

---

# 第二百一十二章 Analytics API建议

```text
GET /admin/analytics/overview
GET /admin/analytics/users
GET /admin/analytics/matches
GET /admin/analytics/matchmaker
GET /admin/analytics/activities
GET /admin/analytics/risk
GET /admin/analytics/organizations/{id}
```

---

# 第二百一十三章 Overview响应示例

```json
{
  "period": {
    "startDate": "2026-08-01",
    "endDate": "2026-08-28"
  },
  "tasks": {
    "pendingReviews": 18,
    "highRiskReports": 3,
    "unassignedMatchmakerServices": 5,
    "pendingActivityRegistrations": 26
  },
  "users": {
    "newUsers": 328,
    "newVerifiedUsers": 251,
    "newApprovedUsers": 208,
    "matchableUsers": 1356
  },
  "matching": {
    "recommendationImpressions": 8620,
    "likes": 1148,
    "mutualMatches": 186,
    "chatStarted": 139,
    "successfulMatches": 8
  }
}
```

数字仅为接口结构示例，不代表真实平台数据。

---

# 第二百一十四章 Match Funnel API

建议：

```json
{
  "impressions": 8620,
  "profileViews": 3240,
  "likes": 1148,
  "mutualMatches": 186,
  "chatStarted": 139,
  "successfulMatches": 8
}
```

---

# 第二百一十五章 趋势响应

```json
{
  "series": [
    {
      "date": "2026-08-27",
      "value": 18
    },
    {
      "date": "2026-08-28",
      "value": 21
    }
  ]
}
```

---

# 第二百一十六章 前端图表规范

推荐：

- 折线：时间趋势
- 漏斗：业务转化
- 条形图：类别比较
- 环形/简单柱状：结构

不要使用：

- 3D饼图
- 3D柱图
- 地球旋转
- 粒子效果

---

# 第二百一十七章 图表必须显示样本量

例如：

```text
活动到场率 88.9%
80 / 90
```

比只显示：

> 88.9%

更可靠。

---

# 第二百一十八章 比例低样本提醒

例如：

只有：

```text
1/1 = 100%
```

不能让运营误以为巨大成功。

界面可以同时显示：

> 1/1。

---

# 第二百一十九章 趋势环比

V1可以显示：

```text
较上一周期 +12%
```

但要确保：

> 周期长度一致。

---

# 第二百二十章 零基数问题

上一期=0时：

不要显示：

> +∞%。

显示：

> 新增 / 无可比基数。

---

# 第二百二十一章 成功牵手展示

平台管理可以：

```text
本月新增成功牵手 8对
```

必须附：

> 双方确认口径。

至少在指标说明中明确。

---

# 第二百二十二章 指标说明入口

Dashboard每项重要指标可有：

```text
?
```

点击：

> 查看指标定义。

例如：

“成功牵手：指双方在平台完成成功牵手确认的Match。”

---

# 第二百二十三章 指标字典

后台最好建设轻量：

> 指标口径文档。

不一定做配置系统。

可以作为开发文档：

```text
docs/analytics-metrics.md
```

---

# 第二百二十四章 指标代码常量

例如：

```text
NEW_USERS
VERIFIED_USERS
MUTUAL_MATCHES
CHAT_STARTED
SUCCESSFUL_MATCHES
```

避免Service到处写中文指标名。

---

# 第二百二十五章 研发红线一

不能：

> 为了Dashboard快，前端自己累计数据。

所有正式数字来自服务端。

---

# 第二百二十六章 研发红线二

不能：

> 删除用户后直接让历史成功牵手、活动数据消失。

历史指标依然应保持一致。

---

# 第二百二十七章 研发红线三

不能：

> 把系统通知算聊天。

Chat Started只能是真实用户消息。

---

# 第二百二十八章 研发红线四

不能：

> 把活动双向互选当成功牵手。

---

# 第二百二十九章 研发红线五

不能：

> 把生成推荐等同曝光。

---

# 第二百三十章 研发红线六

不能：

> 把红娘查看候选等同正式推荐。

---

# 第二百三十一章 研发红线七

不能：

> 将pending举报算成立举报。

---

# 第二百三十二章 V1核心指标建议控制在20～30项

避免建立：

> 200项运营指标。

真正长期需要的再增加。

---

# 第二百三十三章 V1第一优先指标

必须上线：

```text
新增注册
新增实名
新增审核通过
当前可匹配用户
待审核

推荐曝光
Like
Mutual Match
Chat Started
Successful Match

红娘申请
红娘服务中
红娘人工推荐

活动报名
活动通过
活动签到
活动双向互选

待处理举报
高风险举报
封禁
```

---

# 第二百三十四章 V1第二优先指标

```text
推荐覆盖率
无候选用户比例
审核时长
红娘首次响应
红娘超时
活动到场率
举报成立率
申诉情况
```

---

# 第二百三十五章 V1后续指标

P2：

```text
30/60/90天Cohort
候选池健康分析
算法版本对比
长期服务效果
用户沉默分析
机构项目效果分析
```

---

# 第二百三十六章 不建设大型BI平台

V1：

> 后台自带固定统计页面。

数据量和团队规模都不需要：

- Superset复杂开放查询
- Tableau
- Data Warehouse
- ClickHouse

如果后期管理需求增长再接BI。

---

# 第二百三十七章 可考虑内部只读SQL/BI

未来技术人员可接：

> Metabase/Superset

用于内部分析。

但不能给普通运营：

> 随意查询实名数据。

---

# 第二百三十八章 分析数据脱敏

即使以后接BI：

> 默认只连接分析视图/脱敏数据。

不是直接把生产所有表暴露。

---

# 第二百三十九章 最终管理驾驶舱目标

平台负责人打开Dashboard应在30秒内知道：

```text
平台有没有新增用户？
有没有积压审核？
有没有用户能正常获得推荐？
有没有形成真实双向Match？
有没有开始聊天？
公益红娘有没有积压？
最近活动效果如何？
有没有严重风险举报没处理？
```

---

# 第二百四十章 最终指标体系

可以归纳为：

```text
用户池
↓
认证审核
↓
推荐
↓
喜欢
↓
双向Match
↓
聊天
↓
进一步了解
↓
成功牵手
```

辅助两条路径：

```text
公益红娘
→ Match
```

```text
公益活动
→ 双向互选
→ Match
```

安全贯穿全程：

```text
举报
→ 风控
→ 处置
→ 申诉
```

---

# 第二百四十一章 最终设计原则

V1.0数据统计必须坚持：

> **指标是为了帮助服务，不是为了制造好看的数字。**

> **注册人数不是平台最重要的结果，可匹配用户和有效关系才更重要。**

> **双向Like不是成功牵手。**

> **开始聊天不等于稳定关系。**

> **活动互选不等于成功牵手。**

> **红娘推荐数量不等于红娘服务质量。**

> **用户成功离开匹配系统不是“流失失败”，可能正是产品成功。**

> **所有正式指标必须有唯一计算口径和数据来源。**

> **组织只能看到其授权服务范围内的统计数据。**

> **统计数据也必须遵守隐私最小化原则。**

> **V1先把数据记正确，再谈复杂AI分析。**

最终管理驾驶舱不是为了回答：

> “平台看起来有多热闹？”

而是要持续回答三个真正重要的问题：

> **有没有足够真实、可服务的用户？**

> **平台有没有帮助这些用户形成真正的双向关系？**

> **公益组织能不能安全、稳定、持续地把这项服务做好？**