数据归因的链路系统

对接过发行系统的开发会频繁看到 数据归因 这个名词, 简单来说就是投放数据需要溯源分析从而知道获客来源多

以现实例子在抖音推广来说:

  1. (广告曝光)需要投入资金购买抖音广告位

  2. (广告展示)需要分析展示效果和频率(这部分可有可无, 有的主要只计算点击率)

  3. (广告点击)用户看到广告之后点击推广触发下载跳转落地页等行为, 这种就是获得点击量

  4. (安装激活)用户下载到设备安装完成, 首次启动代表整体链路激活, 这种就是设备激活量

  5. (用户转化)用户启动之后注册/登录账号的时候, 就代表正式转化为我们的用户, 这就是用户转化量

  6. (付费用户)如果用户正式在应用触发付费行为, 那么这就代表该用户为核心付费用户, 也就是购买广告位获得的正向收益

数据归因 所要做的就是跟踪整体链条保证让投入产出比持续健康, 保证收益 就是归因的最终目的

广告位这部分是真金白银投入的, 如果投放的渠道收益差(投入资金但收益低)就要赶快停止或者切换渠道

数据核心指标

CAC = 获取客户的成本 = Customer Acquisition Cost

计算公式: CAC = 总投放费用 ÷ 有效新增付费用户

注: 需剔除刷量、退款、7天内流失用户

例子:

  • 投入¥50,000，展示2,000,000次，点击60,000次

  • 下载15,000次，激活8,000人，付费400人

  • 7日流失80人，退款20人

计算:

  1. 原始CAC = 50,000 ÷ 400 = ¥125/人

  2. 无效用户 = 80 + 20 = 100人

  3. 有效用户 = 400 - 100 = 300人

  4. 真实CAC = 50,000 ÷ 300 = ¥166.67/人

CPM = 千次曝光成本 = Cost Per Mille

计算公式: CPM = (总投放费用 ÷ 广告展示次数) × 1000

例子:

  • 投入¥50,000，曝光2,000,000次

  • CPM = (50,000 ÷ 2,000,000) × 1000 = ¥25/千次

平台对比:

  • 抖音: ¥25 | 广点通: ¥30

注: CPM仅作参考，最终决策看ROI

CTR = 点击率 = Click-Through Rate

计算公式: CTR = (用户点击次数 ÷ 广告展示次数) × 100%

注: 用于评估广告素材吸引力，CTR偏低需优化素材或定向

例子:

  • 展示2,000,000次，点击60,000次

  • CTR = (60,000 ÷ 2,000,000) × 100% = 3%

  • 即每100次曝光获得3次点击

LTV = 用户生命周期价值 = Life Time Value

计算公式: LTV = 累计付费金额 ÷ 新增用户数(去重设备/账号)

细分指标:

  • 首日LTV、3日LTV、7日LTV、30日LTV、长期LTV

例子(1000人cohort):

  • 首日: ¥5,000 → LTV=¥5

  • 3日: ¥12,000 → LTV=¥12

  • 7日: ¥20,000 → LTV=¥20

30日LTV预估:

  • 7日LTV × 经验系数K

  • K=1.5(超休闲)、2.0(休闲)、2.5(中重度)、3.5+(重度)

留存衰减参考:

  • 公式: 留存率 = 首日留存率 × (天数)^(-b)

  • b值: 0.3(极慢)、0.6(较慢)、0.8(中等)、1.0(线性)、1.2(很快)

  • 示例: 首日留存50%，b=0.8 → 30日留存≈5%

ROI = 投资回报率 = Return on Investment

计算公式: ROI = (回收金额 - 投入成本) ÷ 投入成本 × 100%

细分指标:

  • 首日ROI = 首日付费 ÷ 当日消耗

  • 7日ROI = 7日累计付费 ÷ 消耗

  • 30日ROI = 30日累计付费 ÷ 消耗

  • 长期ROI = LTV ÷ CAC

例子(投入¥10,000):

  • 首日¥3,000 → 30%

  • 7日¥8,000 → 80%

  • 30日¥15,000 → 150%

决策:

  • ROI<100%: 未回本，考虑停投

  • ROI>100%: 正向回报，可加量

  • 游戏行业特别关注首日/7日ROI

这里主要从游戏行业方面说明, 其他行业的数据归因其实大差不差也是这部分逻辑

游戏行业常说的 买量 其实就是购买这部分付费转化的用户, 核心就只有 付费用户 才能正向收益

很多游戏会投放首次充值奖励礼包(5~10元左右), 用游戏优惠礼包让利给玩家从而保证长期 ROI 回收成本

链路系统

下面就是整体流程链路流转

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  广告曝光    │───→│   广告点击    │───→│  落地页/下载  │
│  (View)     │    │  (Click)    │    │  (Landing)  │
└─────────────┘    └──────┬──────┘    └─────────────┘
                          │
                    ┌─────┴─────┐
                    │ 点击ID生成  │←── 设备指纹/IDFA/GAID
                    │ Click ID  │    时间戳、渠道标识
                    └─────┬─────┘
                          ▼
┌─────────────┐    ┌──────────────┐    ┌─────────────┐
│  应用激活     │←── │  归因匹配     │←───│  服务端上报   │
│ (Activate)  │    │ (Attribution)│    │  (Postback) │
└──────┬──────┘    └──────────────┘    └─────────────┘
       │
       ▼
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  注册/登录    │──→│   首次付费    │───→│   LTV计算    │
│  (Register) │    │  (First Pay)│    │  (ROI分析)   │
└─────────────┘    └─────────────┘    └─────────────┘

落实到技术层面, 就需要给投放的广告点击跳转到我们下载服务器或者落地页面设置 链路ID(trace_id) 标识

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
用户点击广告
    │
    ▼
┌─────────────────────────────────────────
│  广告平台 (巨量/腾讯/快手/Google/Facebook)  
│  ───────────────────────────────────────  
│  1. 生成 click_id (平台侧唯一标识)         
│  2. 拼接监测链接 + 宏替换                  
│                                         
│  [广告平台如果提供唯一标识(如点击ID/曝光ID)可直接合并成UUID作为 trace_id]          
│                                         
│  平调回调示例:                            
│  https://your-tracker.com/click?        
│    click_id=__CLICK_ID__&                
│    ad_id=__AID__&                       
│    cid=__CID__&                         
│    idfa=__IDFA__&                       
│    ip=__IP__&                           
│    ts=__TS__                            
└─────────────────────────────────────────
    │
    ▼
┌─────────────────────────────────────────
│  归因监测服务端 (自己的服务器)                
│  ───────────────────────────────────────
│  1. 接收点击请求, 确认 trace_id            
│  2. 存储点击日志 (Redis + ClickHouse)     
│  3. 302 跳转到应用商店/落地页               
│
│  [广告平台如果提供唯一标识(如点击ID/曝光ID)可直接合并成UUID作为 trace_id]
│                                         
│  响应头设置:                              
│  Set-Cookie: trace_id=tr_abc123;        
│         Domain=.your-domain.com;        
│         Max-Age=2592000;                
│         HttpOnly; Secure                
└─────────────────────────────────────────
    │
    ▼
┌─────────────────────────────────────────
│  应用商店 / 落地页                         
│  ───────────────────────────────────────  
│  落地页需保留 trace_id 到 localStorage     
│  供后续下载/激活时回传                      
└─────────────────────────────────────────

对于 Google/iOS 商店和非官方商店采用以下方式获取安装之后捕获 trace_id:

Google 和 iOS 商店这部分不用太多说明, 主要需要针对的是 安卓的其他分发方式:

  1. 在抖音购买广告推广计划

  2. 我们自己服务器需要为这个广告生成固定的 trace_id, 比如 douyin_20260318_312

  3. 需要将后台提交的应用母包反编译注入该参数 TRACE_ID 动态分出专门广告包开放下载

  4. 外部提供连接为 https://{自己服务器}?trace_id=douyin_20260318_312 分包地址

  5. 玩家点击下载完成在 APP 首次启动时提交 TRACE_ID 和 IDFA/GAID/OAID/IMEI 设备标识

注意: Google 和 iOS 这种官方商店上架分发和其他方式不太一样, 官方有专门的回调处理方法

这就是整体的链接跟踪实现方式, 主要大头还是在客户端的反编译注入处理方式

误区说明

需要注意: 发行SDK系统不要和广告链路系统集成在一起对外提供服务

这部分我见过将发行平台和链路跟踪归到相同的系统共同维护, 后续做代码维护更新的时候耦合在一起很不好处理

发行SDK和链路SDK都是由客户端自行去提交推送不同地址, 也就是客户端开发内部是带有两个请求服务地址:

  • https://sdk.{自己服务器}.com: 发行平台的请求对接系统

  • https://trace.{自己服务器}.com: 广告平台的链路上报系统

这样解耦的好处就是能够将不同服务分布在不同服务器管理, 保持服务之间的独立性

trace 系统只负责 广告曝光 → 点击 → 安装 → 激活 → 转化 → 留存 的链路跟踪

trace_id 由客户端保证本地数据安全性并对上报提交参数做签名保证不可变动, 还有设备ID(OAID/IDFA/GAID)与 trace_id 做绑定

一定要保证严格监控广告引流转化的流程, 因为这部分都是自身出资购买而来的用户量, 如果不及时监控会出现买量却毫无转化的情况

买量的计算方式是从点击的下载量就开始开始计算的, 所以要严格确认点击之后的转化而来的付费用户量(用户点了广告触发下载就扣钱)

去除部分误差之外, 也有些第三方买量公司会偷偷搞刷量的小动作, 导致出现付费之后安装和激活量很高但是基本上都是直接单次流失的用户