询盘归因怎么算才对:First Touch、Last Touch 与 12 种 Click ID
一、第一性问题:很多站的归因数据从源头就是脏的
先看四个真实常见的错误,它们都出现在”选模型”之前:
| 错误 | 表现 | 后果 |
|---|---|---|
| 同域跳转未剔除 | 客户从文章页跳到产品页,被记成”新来源” | 自然流量被虚高,重复计算 |
| 直接访问占首触位 | 客户第一次来是通过 Google,但首触被记成”直接访问” | 首触渠道全部失真 |
| Click ID 过期丢失 | 广告点击后 30 天再转化,gclid 已丢 | 广告效果被低估 |
| 把访问环境当渠道 | 微信内置浏览器被当成”渠道 = 微信” | 付费渠道与微信混在一起,无法判断谁在起作用 |
这四类问题合起来,会让一份归因报告”看起来完整、实际不可用”。所以正确的顺序是:先修数据源,再选模型。下面按三层展开。
二、第一层:把”来源”识别准
2.1 来源判定的优先级
一次访问的来源,应该按下面的顺序判定,顺序不能颠倒:
| 优先级 | 判定依据 | 说明 |
|---|---|---|
| ① | Click ID 参数 | 最可靠(gclid / fbclid 等),有则直接归属 |
| ② | UTM 参数 | 人工标记,可靠度次之 |
| ③ | Referrer | 需要剔除规则,见下 |
| ④ | 直接访问 | 兜底 |
为什么 Click ID 优先于 UTM?因为 UTM 是人工加的,容易加错、漏加、或被人为修改;而 Click ID 是广告平台自动附加的,唯一且不可伪造。
2.2 Referrer 的三条剔除规则
referrer 是最容易出错的一环。三条必须执行的剔除规则:
| 规则 | 做法 | 为什么 |
|---|---|---|
| 同域剔除 | referrer 域名 == 本站域名时,视为站内跳转,不覆盖来源 | 否则站内点击会不断”洗掉”真实来源 |
| 搜索引擎归一化 | 不同国家的 Google 域名归为一个来源 | google.de / google.co.uk / google.com 应统一为 Google |
| 无效 referrer 归入直接访问 | 空 referrer、来自本站 App、来自邮件客户端 | 邮件客户端的 referrer 通常为空,容易误判 |
同域剔除是三条里最重要的。一个客户从你的博客文章点进产品页,如果被记成”新来源 = 博客文章”,那么他的原始来源(比如 Google 搜索)就丢了。长此以往,报告里会看到”博客是最大来源”这种假象。
2.3 首触位的写入规则
First Touch(首触)只在真的带回来来源时写入。这条规则看起来很细节,但它决定了整个归因体系的准确性。
| 情形 | 是否写入首触 | 理由 |
|---|---|---|
| 首次访问来自 Google 搜索 | ✅ 写入 | 有明确来源 |
| 首次访问来自广告点击(带 gclid) | ✅ 写入 | 有明确来源 |
| 首次访问是直接访问(输入网址 / 书签) | ❌ 不写入 | 没有来源信息,不能占首触位 |
| 首次访问来自站内跳转 | ❌ 不写入 | 不是真实来源 |
为什么”直接访问不占首触位”?因为如果允许它占位,那么一个品牌词搜索进来的客户(很可能先被记成直接访问)会永久丢掉他的真实首触。而实际上,”直接访问”往往是前面某次营销的效果——只是那一次的来源没被记录。
正确处理是:首触位保持空着,等待第一次带回真实来源的访问来填充。
三、12 种 Click ID 与 90 天保留期
Click ID 是广告平台附加在落地页 URL 上的唯一标识。它们是跨平台归因的唯一可靠手段,因为只有它们能告诉你”这次访问来自哪个平台、哪次点击、哪个广告”。
| # | 参数名 | 平台 | 典型有效期 | 用途 |
|---|---|---|---|---|
| 1 | gclid |
Google Ads | 30–90 天 | 搜索广告归因 |
| 2 | wbraid |
Google Ads(iOS) | 30–90 天 | iOS 隐私限制下的替代 |
| 3 | gbraid |
Google Ads(iOS App) | 30–90 天 | App 内 WebView 场景 |
| 4 | fbclid |
Meta | 90 天 | Facebook / Instagram 广告 |
| 5 | ttclid |
TikTok | 90 天 | TikTok 广告 |
| 6 | li_fat_id |
30 天 | LinkedIn 广告 | |
| 7 | msclkid |
Microsoft Ads | 90 天 | Bing 广告 |
| 8 | twclid |
X (Twitter) | 30 天 | X 广告 |
| 9 | yclid |
Yandex | 90 天 | Yandex 广告 |
| 10 | epik |
30 天 | Pinterest 广告 | |
| 11 | s_kwcid |
Adobe / 部分平台 | 30–90 天 | 企业级投放追踪 |
| 12 | irclickid |
联盟营销 | 30–90 天 | 联盟渠道归因 |
三个关键设计决定:
| 决定 | 做法 | 原因 |
|---|---|---|
| 独立存储 | 12 种 ID 各自单独存字段,不合并成一个”click_id” | 同一个用户可能同时带多个 ID,需要分别归因 |
| 保留 90 天 | 首次捕获后保存 90 天 | 覆盖 B2B 长决策周期(30–60 天很常见) |
| 首次捕获优先 | 同一个 ID 类型只记第一次,后续不覆盖 | 保证归因稳定,避免”最后一次点击偏向” |
“保留 90 天”这个决定对 B2B 尤其重要。一个工业装备的采购,从第一次点击广告到最终提交询盘,中间隔 45–70 天是常态。如果 Click ID 只保留 30 天,那么超过一半的转化会归因失败,广告效果被严重低估。
四、第二层:四种归因模型与选择
数据源修好之后,才轮到模型。
| 模型 | 逻辑 | 适用场景 | 局限 |
|---|---|---|---|
| First Touch | 100% 归给第一次接触 | 评估”谁带来了新客户” | 低估临门一脚的渠道 |
| Last Touch | 100% 归给最后一次接触 | 评估”谁促成了转化” | 会让直接访问/品牌词占尽便宜 |
| Last Non-Direct | 归给最后一次非直接访问 | 默认推荐(同 GA4 默认) | 需要正确处理直接访问 |
| 线性 / 位置归因 | 按比例分配给多个接触点 | 多触点成熟后的精细化 | 需要更长的数据积累 |
为什么默认推荐 Last Non-Direct?
因为纯粹的 Last Touch 有一个严重缺陷:大量转化前的最后一步是”直接访问”(客户已经决定要联系你,直接打开你的网站填表)。如果按 Last Touch 算,这些转化会全部归给”直接访问”,于是所有渠道看起来都没用。
正确的口径是:回溯到最后一个”带回来源”的接触。也就是 GA4 和多数现代分析工具采用的 last_non_direct 口径。
一个实用建议:同时看两个口径。
| 看哪个 | 回答什么问题 |
|---|---|
| First Touch | 哪个渠道在拉新?(B2B 里通常指向内容与自然搜索) |
| Last Non-Direct | 哪个渠道在促成转化?(通常指向品牌词与再营销) |
只看一个一定会误判。典型的误判是:只看 Last Touch,得出”SEO 没用、广告最有效”的结论——因为广告往往是转化前的最后一次点击;而实际上,是 SEO 内容先带来了认知,广告只是搭了便车。
五、第三层:微信是”访问环境”,不是”渠道”
这一点在中文出海场景里经常被搞混,值得单独说明。
微信(含企业微信)内置浏览器是一种”访问环境”,它与”渠道”是两个正交的维度。
| 维度 | 取值示例 | 回答的问题 |
|---|---|---|
| 渠道 | 自然搜索 / 付费广告 / 社媒 / 直接访问 / 邮件 | 他从哪来? |
| 访问环境 | 微信 / 企业微信 / 普通浏览器 / App 内 WebView | 他在什么环境里访问? |
为什么要分开?看一个具体例子:
| 场景 | 渠道 | 访问环境 | 正确解读 |
|---|---|---|---|
| 客户在微信里点开朋友分享的链接 | 社媒(分享) | 微信 | 微信是传播载体,渠道是社媒 |
| 客户在微信里点开你投的广告 | 付费广告 | 微信 | 付费优先级最高,不能被微信覆盖 |
| 客户在微信里直接输入网址 | 直接访问 | 微信 | 环境是微信,渠道是直接 |
| 客户在企业微信里打开你发的资料 | 邮件/IM 发送 | 企业微信 | 环境是企微 |
如果混在一起,会出现两种错误:
| 错误做法 | 后果 |
|---|---|
| 把”微信”作为渠道值 | 付费广告的效果被归到”微信”名下,无法评估广告投放 |
| 忽略访问环境维度 | 不知道客户的访问环境,无法优化分享体验与落地页适配 |
正确做法:渠道与访问环境各存一个字段,付费渠道优先级最高(不被环境覆盖),微信作为独立字段并存。这样你既能算”广告带来了多少询盘”,也能算”其中多少是在微信里访问的”。
六、访客归属:国家与城市怎么判断
归因不只要知道”从哪来”,还要知道”从哪国来”——这对出海业务是基础数据。这里有两种模式,各有取舍:
| 模式 | 判断依据 | 精度 | 外部请求 | 适用 |
|---|---|---|---|---|
| 轻量模式(默认) | CDN 提供的国家头 + 浏览器时区推断 | 国家(时区可辅助判断) | 零 | 多数出海站 |
| 精确模式 | 站长配置的 IP 查询接口 | 国家 + 城市 | 需配置接口 | 需要城市级数据时 |
为什么默认用轻量模式?因为一次访客访问会触发多次资源请求,如果每个请求都去查一次 IP 库,会带来三个问题:响应变慢、外部依赖(接口挂了就全挂)、以及隐私合规风险(把访客 IP 发给第三方)。轻量模式用 CDN 已经在响应头里提供的国家信息,零额外开销。
什么时候需要精确模式?当你需要回答”哪个城市的询盘最多,要不要在当地做地推或参展”这类问题时。此时再配置接口是值得的。
七、常见错误与验收清单
七个常见错误
| # | 错误 | 后果 | 修正 |
|---|---|---|---|
| 1 | 同域 referrer 未剔除 | 站内跳转覆盖真实来源 | 加同域剔除规则 |
| 2 | 直接访问占首触位 | 首触渠道失真 | 首触只写带来源的访问 |
| 3 | Click ID 只存 30 天 | B2B 长周期转化丢失归因 | 延长至 90 天 |
| 4 | Click ID 合并成一个字段 | 多渠道并存时归因错误 | 12 种独立存储 |
| 5 | 只看 Last Touch | 低估内容与 SEO 的作用 | 同时看 First 与 Last Non-Direct |
| 6 | 把微信当渠道 | 付费效果被掩盖 | 渠道与环境正交存储 |
| 7 | 用客户端脚本记录归因 | 隐私设置 / 广告拦截导致数据缺失 | 服务端记录关键数据 |
上线验收清单
| 检查项 | 验证方法 | 通过标准 |
|---|---|---|
| 同域跳转不覆盖来源 | 从内页 A 跳到内页 B,看来源是否变化 | 来源保持不变 |
| 首触只在带来源时写入 | 直接访问新访客,看首触字段 | 首触为空,第二次带来源访问后写入 |
| Click ID 正确捕获 | 用带 ?gclid=test123 的链接访问 |
数据库里能看到 test123 |
| Click ID 保留期 | 模拟 60 天后再次访问 | 归因仍能匹配上 |
| 渠道与环境字段分离 | 微信内访问带 ?gclid= 的链接 |
渠道=付费,环境=微信 |
| 首次访问与转化关联 | 提交一条测试询盘 | 询盘记录里有完整来源链路 |
| 数据可导出 | 导出最近 30 天询盘数据 | 含来源、Click ID、国家、环境字段 |
FAQ 常见问题
| 问题 | 看哪个 |
|---|---|
| 新客户从哪来? | First Touch |
| 哪个渠道促成转化? | Last Non-Direct |
| 哪些渠道同时出现在两端? | 对比两者,重合度高的渠道价值最稳 |
| 渠道类型 | 建议归因窗口 |
|---|---|
| 付费搜索(品牌词) | 30 天 |
| 付费搜索(通用词) | 60–90 天 |
| 社媒广告 | 30–90 天 |
| 自然搜索 / 内容 | 90 天以上(建议不做硬窗口,保留长期) |
| 展会 / 线下 | 手动补录,无窗口限制 |
写在最后
归因这件事的价值,不在于”算得多精确”,而在于它决定了你下一笔预算投在哪里。
如果数据是脏的,那么结论就是错的;结论错了,预算就流向了”看起来很有效但实际只搭了便车”的渠道。而真正在拉新的那条路径(往往是内容与自然搜索)会因为没有即时回报而被削减——这是出海企业最常见的资源错配。
所以做归因的正确顺序是:先把数据源修干净(同域剔除、首触规则、Click ID 保留期、渠道与环境分离),再谈模型选择。前者是工程问题,一次做对可以长期受益;后者是分析问题,可以随认知演进不断调整。
