国内广告归因系统搭建指南：从零到一实现精准投放 | AttriTouch - 广告归因与数据洞察，开启广告投放的精准优化时代

做广告投放的人都有个共同的痛点：钱花出去了，但转化到底从哪来的？是微信、抖音，还是小红书带来的用户更优质？哪个创意、哪个关键词真正起了作用？用户是看到广告就立刻转化，还是被「种草」后隔了几天才下单？

这些问题搞不清楚，广告投放基本就是在「撞大运」。更要命的是，国内各大平台广告数据割裂严重，腾讯的广告平台看不到字节的广告数据，小红书的广告数据也无法和其他渠道打通。

但是在国内有着独特的技术环境：各大广告平台普遍支持点击回调，OAID（开放匿名设备标识符）相对稳定可获取，自建一套更稳定、更精准的归因系统变得触手可及。

广告归因说白了，就是给用户的每一个「关键行动」找到真正的「幕后功臣」。比如有人下载了你的 App、注册成了会员，或者下单买了东西，归因系统要做的就是弄明白：到底是哪条广告、哪次推广，最终促成了这个行动？就像咱们平时说「这次成交多亏了上周那条广告」，归因系统干的就是把这种「多亏了」用数据精确算出来。

详细了解归因请参考之前文章：广告归因的底层逻辑：为什么说它比投放策略更重要？

那么，既然自建归因如此重要，具体应该如何从零到一的搭建呢？下面，我们将这个过程分解为四个核心步骤来给大家讲解一下。

国内安卓平台自建归因搭建步骤

搭建自建归因系统主要分四步：收集广告点击数据、采集用户行为、计算归因结果、上报并记录数据。

第一步：收集广告点击数据

首先要准备一个「监测链接」，这个链接看着普通，其实里面藏了不少「隐藏的信息收集点」—— 也就是各个广告平台支持的「宏参数」。在用户点击广告时，广告平台会在回调你的监测链接之前，将宏参数自动替换为具体的点击信息（比如这次点击的 ID、用户设备 OAID、点击时间等）。然后通过这个链接，广告平台把这些信息回传到你的系统。

点击数据的存储也需要重点关注，如果投放量大，点击数据每天可能达到千万甚至亿级别，因此需要考虑系统的高并发和海量数据存储计算能力。

第二步：采集用户行为

当用户在 App 里完成核心行为（比如激活、注册、付费等），App 要立刻把这些行为信息收集起来。收集的信息得包含：用户的设备标识（如 OAID）、行为类型（是注册还是付费）、行为发生时间等关键信息。

第三步：计算归因结果

我们得到了用户的行为信息，那么到底是哪个广告促成了这次转化？

我们要拿着行为事件里的用户设备标识（比如 OAID）和 appId，先去归因结果库中找，如果说这个用户最近已经被归到广告了，那么我们可以根据归因策略选择是否采纳之前的归因结果（例如你的策略里有重归因窗口期是 60 天，那么 60 天之后可以不再采纳这个广告结果）。

如果之前没有归因记录，那么我们就去收集到的广告点击数据库里找 —— 看看这个用户之前点过哪些广告。如果只找到一次点击，那功劳就归它；如果找到好几次（比如用户 3 天前点过 A 广告，今天又点了 B 广告，之后完成转化），就得按事先定好的归因模型分功劳，例如：

末次点击归因：就是最后点的那个广告算最大功；
线性归因：就是所有点击的广告平均分功劳；
首次点击归因：就是最先点的那个广告算最大功；
U 型归因：就是用户第一次点击和最后一次点击的广告功劳最大，中间的点击平分剩余功劳。

实际业务中，我们更倾向于选用末次点击归因，用户从点击到转化的链路短，最后一次点击的广告往往是直接促成决策的关键，用它能快速锁定效果最好的「临门一脚」广告，方便及时调整投放策略。

第四步：上报平台并记录归因结果

归因完成后，先把转化数据上报给广告平台，平台拿到后，就能知道哪些用户更容易被转化，下次就会把你的广告推给这类人，让投放更准。

另外，如果用了事件分析工具或者 BI 工具，还能把归到的广告信息标记到用户的属性里。这样一来，后续看用户在 App 里的行为（比如谁下单了、谁看了哪篇文章）时，就能按「来自哪个广告」、「哪个投放渠道」这些维度分开统计，清楚知道不同广告带来的用户在 App 里表现有啥不一样，方便针对性优化。

最后，把归因结果数据存到对应数据库，重点存入系统内部用户和广告之间的关联关系，有了这层关系在计算归因结果时可以使用 OAID 匹配。

前面讲清了国内自建归因搭建步骤，这些该如何落地？下面就以小红书聚光广告平台为例，看看归因接入的实际操作。

小红书广告归因接入案例

第一步：获取监测链接

监测链接是用来记录「用户点了哪个广告」的关键工具，不用非得写代码生成，手动拼接也行。监测链接不仅包含广告平台自动填充的宏参数（如 __CLICK_ID__、__OAID__ 等），它们记录了每次点击的动态信息，还可以手动配置我们自己的固定参数。例如，链接中的 channel 就用来标识该点击来自小红书平台，这方便我们在接收到数据时进行归类和统计。

例如这里我们拿到了三次广告点击记录：

 # 第一次点击
https://attritouch.com/click-monitor?channel=小红书聚光&clickId=1&appId=1&unitId=2&oaid=12345&oaidMD5=__OAID_MD5__&event_time=2025-07-26 12:00:00

 # 第二次点击
https://attritouch.com/click-monitor?channel=小红书聚光&clickId=2&appId=1&unitId=1&oaid=34567&oaidMD5=__OAID_MD5__&event_time=2025-07-26 12:00:00
 
 # 第三次点击
https://attritouch.com/click-monitor?channel=小红书聚光&clickId=2&appId=1&unitId=3&oaid=34567&oaidMD5=__OAID_MD5__&event_time=2025-07-26 11:00:00

第二步：采集转化数据

用户在 App 里完成激活、注册等操作时，得把这些行为数据记下来。以激活为例，数据可以是这样：

{
    "event_type": "active", // 事件类型
    "uid": "用户 ID",
    "androidid": "xxxxx", // 安卓 ID 
    "oaid": "12345", 
    "imei": "xxxx",
    "packageName": "com.xxx.xxx", // 包名
    "event_time": xxxx // 事件发生时间
}

采集行为的时候可以多采集一些信息，有的平台可能要的信息多。

第三步：计算归因结果

此时拿我们从用户转化行为那采集到的 OAID 和监测链接拿到的点击数据进行匹配（监测链接拿到的 OAID 一般是经过 MD5 加密的）。

以上面的数据为例，采集到用户的 OAID 是 12345，MD5 加密之后是 34567（举个例子，不是真实加密值），然后和采集到的监测链接进行匹配，我们拿 oaidMD5 和 appId 作为查询键，查询监测链接数据库，取最 event_time 最新的一条记录，查询到的结果是上述第二次点击。

此时我们合并用户的转化行为和归因到的广告信息：

{
    "event_type": "active",
    "uid": "用户 ID", 
    "androidid": "xxxxx", // 安卓 ID
    "oaid": "12345",
    "imei": "xxxx",
    "packageName": "com.xxx.xxx", // 包名
    "event_time": 2025-07-26 12:00:00,
    "clickId"： 2,
    "unitId": 1
}

第四步：上报平台

使用 POST 请求将转化数据上报给小红书广告平台（示例）：

curl -X "POST" "https://adapi.xiaohongshu.com/api/open/conversion" \
     -H 'Content-Type: application/njson' \
     -d '{
  "platform": "com.xxx.xxx", // 必传。来源，可以写死为投放的 App 的名称
  "timestamp": 1704805800000, // 必传。事件发生时间
  "scene": "701", // 必传。
  "advertiser_id": "13667", //必传。投放账号 ID
  "os":0, // 必传。操作系统
  "caid1_md5":"8425DG6D7B37SGFDC4GD5D1234D0828F4",
  "click_id": "Mdo9fK5B62TSkrqg3fE082PYcu24bE-PkDGS6PNDKeMaMRM", // 必传。监测链接中的点击 ID
  "event_type": 411, // 必传。411 代表 App 激活
}'

第五步：联调测试

接入完成之后还建议测试一下接入的效果，可以使用小红书提供的联调工具。模拟从用户点击广告到完成转化事件，观察这个过程中广告平台的点击数据回传以及 App 侧转换数据回传链路是否通畅、正确。

至此，你已经把「归因」从玄学变成了工程：

点击数据像水一样流进来，被宏参数精准标记；
用户行为像脚印一样被实时采集，OAID 把两端牢牢串起；
归因模型像法官一样按规则分功行赏；
回传接口像快递员一样把结果第一时间送到平台，让算法越跑越准。

剩下的，就是把它当成日常基建去迭代：监控延迟、校准窗口期、A/B 不同归因模型、甚至尝试做一些混合归因。

当某天老板再问「这波预算到底花得值不值」时，你只需打开报表，指着一个清晰的 click_id 说：

「值，就值在这里。」