聊聊营销平台中常见的指标：PV、UV、转化、留存、ROI

Tue, 15 Aug 2023 16:00:00 +0800

数据指标是营销平台的语言

营销平台里所有讨论都围绕几个核心指标——PV、UV、UA、转化率、留存率、ROI、CPA、CPC、CPM、LTV……

新人面对这些缩写常常一脸懵。等到要做：

“为什么这周 UV 降了 20%？”
“这次活动 ROI 是多少？怎么算的？”
“你说留存率不对——具体哪里不对？”

光知道概念是不够的。指标背后的口径、陷阱、计算方式才是关键。本文把营销平台最常见的指标讲清楚，带工程视角看怎么实现、怎么避免常见坑。

一、流量类指标：PV / UV / UA

PV（Page View）

页面浏览量——用户每打开一次页面就 +1。

1
2
3


SELECT count(*) AS pv
FROM event
WHERE event_name = 'page_view' AND date = '2023-08-15';

特点：

同一用户刷新一次页面 +1
不同用户访问同一页面，各 +1

UV（Unique Visitor）

独立访客数——每个用户当天只算一次。

1
2
3


SELECT count(DISTINCT user_id) AS uv
FROM event
WHERE event_name = 'page_view' AND date = '2023-08-15';

PV / UV 的比值叫"人均 PV"——反映用户活跃程度。

UA（Unique Action）

独立动作数——比 UV 更细粒度，按某个具体动作算去重。比如"独立点击数"、“独立购买用户”。

三个指标的关系

1

PV ≥ UA ≥ UV

PV 包含所有访问，UA 是某个动作的去重，UV 是用户去重。

第一个常见陷阱：UV 怎么定义"用户"

未登录用户怎么算 UV？——通常用 device_id / cookie_id / client_id。但：

同一用户用三个设备访问 → 算 3 个 UV？
同一设备多个浏览器 → 算 N 个 UV？
用户清缓存后 → 又是新 UV？

不同公司有不同口径。最重要的是『团队对口径达成一致』——别在数据评审会上才发现你和数据组算法不一样。

二、漏斗指标：转化率

单步转化率

1

某一步动作人数 / 上一步动作人数 = 单步转化率

例：

100 人看到广告（曝光）
30 人点击了广告（点击率 = 30%）
5 人完成下单（购买率 = 5/30 ≈ 16.7%）
整体转化（曝光到购买） = 5/100 = 5%

漏斗分析

flowchart LR
 A[曝光 100] --> B[点击 30]
 B --> C[加购 12]
 C --> D[下单 5]
 D --> E[支付 4]

每一步流失多少——找到漏斗最大流失点对应的优化机会。

漏斗的"窗口"问题

转化是有时间窗口的。“看了广告 N 天内购买"算转化吗？

同会话内（30 分钟）→ 直接转化
当日内 → 当日转化
7 天内 → 7 天归因转化
30 天内 → 30 天归因转化

不同窗口对应的数字差几倍。看转化率必须搞清楚窗口。

三、留存指标

留存率定义

1

某天的某天 N 留存 = 当日新增用户中，N 天后仍活跃的用户数 / 当日新增用户数

例：8/1 新增 1000 人。8/8 这 1000 人中有 200 人当天活跃 → 8/1 的 7 日留存率是 20%。

次日 / 7日 / 30日留存

行业惯例：

次日留存：用户来了第二天还来——通常 30%-50% 算不错
7 日留存：第 7 天还来——15%-30% 算不错
30 日留存：1 个月后还来——10%-20% 是好产品

留存表（Cohort 分析）

	Day 0	Day 1	Day 7	Day 30
8/1 新增 1000	100%	45%	18%	8%
8/8 新增 1200	100%	50%	22%	10%

按 cohort 看留存——比平均留存信息量大得多。可以看出"哪批用户质量好”、“产品改了之后留存有没有提升”。

实现要点

1
2
3
4
5


-- 8/1 用户 7 日留存
SELECT count(DISTINCT u.user_id) FROM users u
JOIN events e ON e.user_id = u.user_id
WHERE u.register_date = '2023-08-01'
 AND e.event_date = '2023-08-08';

注意 join 大表的性能——生产里通常用 Bitmap / HLL 做近似计算。

四、成本类指标

CPM（Cost Per Mille）

每千次曝光成本：

1

CPM = 总花费 / (曝光数 / 1000)

例：花 1000 元买了 50 万次曝光 → CPM = 1000 / 500 = 2 元。

适合品牌广告——目标是触达，不是直接转化。

CPC（Cost Per Click）

每次点击成本：

1

CPC = 总花费 / 点击数

适合点击付费广告——效果更直接。

CPA（Cost Per Action）

每次目标动作成本——比 CPC 更精细，按"注册"、“下单”、“加好友"等具体动作付费：

1

CPA = 总花费 / 目标动作完成数

	CPM	CPC	CPA
含义	千次曝光	单次点击	单次目标动作
适合	品牌触达	点击行为价值	实际转化收益
风险	平台高	投放方高	投放方高（依赖效果）

五、收益类指标

LTV（Life Time Value）

用户生命周期价值——一个用户从注册到流失，给平台贡献多少收入。

1

LTV = 平均订单金额 × 平均购买频次 × 用户存活时间

例：用户平均下单 100 元、年均下单 5 次、平均留 3 年 → LTV ≈ 1500 元。

LTV 是营销最重要的"上限”——获客成本（CAC）必须 < LTV，否则赔本买卖。

ROI / ROAS

投资回报率 / 广告支出回报：

1
2


ROI = (收入 - 成本) / 成本
ROAS = 广告带来的收入 / 广告花费

业内常说"ROAS 1.5"意味着花 1 元广告费换 1.5 元收入——通常 ROAS ≥ 3 才算健康。

CAC（Customer Acquisition Cost）

获客成本：

1

CAC = 总营销花费 / 新增付费用户数

健康的业务：LTV / CAC ≥ 3——付费用户带来的总收益至少是获客成本的 3 倍。

六、归因模型：转化算谁的

某用户在 30 天里：

8/1 通过广告 A 知道了产品
8/15 通过 SEO 搜索访问了产品
8/29 通过广告 B 点击后下单

这一笔下单算哪个渠道？

模型	算法
First-Touch	全归功于广告 A（首次接触）
Last-Touch	全归功于广告 B（最后接触）—— 最常用
Linear	三者各 1/3
Time-Decay	越靠近转化的权重越大
Position-Based	首末各 40%，中间均分 20%
Data-Driven	机器学习算每个 touchpoint 的实际贡献

不同公司选不同模型——但必须明确告诉所有相关方"我们用什么模型"。否则看到的数字会差几倍。

七、营销实验：A/B 测试

新功能/新页面要不要上线？跑 A/B：

flowchart LR
 Users --> Split["流量分流
50/50"]
 Split --> A[实验组
新版本]
 Split --> B[对照组
旧版本]
 A --> M1[转化率 X%]
 B --> M2[转化率 Y%]
 M1 --> Stat[统计显著性检验]
 M2 --> Stat

关键点

样本量：太少看不出差异——通常要数千以上
置信度：通常 95%——意味着 5% 的概率结果是偶然
实验时长：覆盖完整业务周期（一个工作周 + 一个周末至少）
不要早停：实验跑到一半看到"实验组好"就停掉——选择性偏差

工程实现

1
2
3
4
5
6


public boolean isInExperimentGroup(String userId, String expName) {
 // 用 hash 保证同一用户始终落入同一组
 // ⚠️ Math.abs(Integer.MIN_VALUE) 仍然返回负数，会让 % 出负值，必须先与 0x7FFFFFFF
 int hash = (userId + expName).hashCode() & 0x7FFFFFFF;
 return hash % 100 < 50; // 50% 分流
}

不要随机分流——要确定性 hash，避免同一用户在实验间被反复切换。生产推荐用 Guava Hashing.murmur3_32() 等分布更均匀的 hash 替代 String.hashCode()。

八、典型陷阱清单

1. 指标聚合时的 Simpson 悖论

整体看：A 渠道转化率 5%，B 渠道转化率 4%——A 更好。分群看：男性 A 是 3%，B 是 6%；女性 A 是 8%，B 是 10%——其实都是 B 更好！

别只看整体均值，要分群看。

2. 数据延迟

同一指标，“实时大盘” vs “T+1 报表"可能差 10%——实时数据有未结算、未对账。给老板汇报永远用结算后的数据。

3. 异常流量

突然 PV 暴涨 → 不一定是真实增长，可能是爬虫、脚本、刷量。任何指标异常都要先看流量来源、IP 分布、设备分布。

4. 跨平台 ID 拉通

用户在 PC、H5、App、小程序留下不同 ID——要统一到同一个用户主键才能算准 UV / LTV。这是营销平台的基础工程。

5. 计算口径漂移

“上周 UV 100 万"和"这周 UV 80 万”——也许是统计口径变了，不是真的下降。每次指标讨论先确认口径。

九、技术架构：怎么算这些指标

flowchart TD
 Client[客户端 SDK] --> Collect[埋点采集]
 Collect --> Kafka
 Kafka --> Stream[Flink 实时计算]
 Kafka --> Batch[Spark T+1 计算]
 Stream --> Realtime[(实时指标 Redis)]
 Batch --> Warehouse[(数仓 Hive/ClickHouse)]
 Realtime --> Dashboard[实时大盘]
 Warehouse --> Dashboard
 Warehouse --> BI[BI 报表]

实时指标（PV、UV）：Flink + Redis HLL
离线指标（次留、LTV）：Hive / ClickHouse 批处理
去重：HyperLogLog（HLL）做近似 UV，误差 1-2% 但内存占用极小
漏斗：通常是离线计算

十、给工程的几条建议

指标定义要写文档——口径明确、覆盖所有边界
指标计算代码 + SQL 上版本管理——和业务代码一样审 PR
异常告警要有——指标突然涨/跌 30% 必须触发
跨业务的核心指标统一在一个数据服务——别每个业务方自己实现一套
永远做"指标对账”——多个口径的数字定期 cross-check

小结

把全文压一句：

营销平台的所有讨论都围绕指标——但指标的『口径、归因、时间窗口』比『定义』更关键。算错口径会让团队在错误数据上做错决策。

记住几条：

PV、UV 必须先达成口径共识
转化、留存必须明确时间窗口
CAC、LTV、ROI 决定业务能不能持续
归因模型选哪个，团队要统一
A/B 测试要先算样本量，不要早停

把指标这件事做对，营销平台的"决策质量"会瞬间提一个量级——这是数据驱动的真正价值。

转化率 on 牛哥聊技术