先讲一个隐蔽的坑
回传链路一切正常,后台也能看到转化数据,但优化效果就是差。深入排查发现:转化没归到正确的那条计划上——加粉明明是 A 计划带来的,却记到了 B 计划头上。B 计划被”误奖”,A 计划被”误杀”,模型按错误的归因去学,越优化越偏。
回传的价值,一半在”传没传”,一半在”归对没归对”。这篇文章讲归因窗口怎么配,让每一笔转化都落到它该去的计划上。
归因窗口是什么
归因窗口决定了”一次转化,算到多久之前、哪一次点击头上”。腾讯广告里,窗口设太短,真实转化没被算进去;设太长,又可能把 A 计划带来的加粉记给了更早的 B 计划。
关键要匹配你的决策周期:
- 企微加粉这种”点完很快就加”的行为,归因窗口可以设短(比如 1 天以内)。
- 决策周期长、先留资后转化的业务,窗口要拉长。
设错方向,直接污染模型。
归因窗口配错的两个典型后果
- 窗口太短:很多真实转化落在窗口外,模型”看不到”这些转化,误以为计划没效果,压量或让计划提前死掉。
- 窗口太长 + 多计划重叠:同一用户点了多条计划的广告,加粉被归给了最早那条,导致新计划永远”背锅”,跑不起来。
怎么配对归因窗口
- 先看你的加粉决策周期:从点击到加粉,用户平均花多久。大部分企微加粉在几分钟到几小时内完成,窗口不必拉太长。
- 用叮咚外链带上准确的转化时间戳,让平台按真实发生时间归因,而不是按回传时间。
- 多计划投放时,开启归因去重:同一用户一次转化只归一条计划,避免重复计。
配完要验证:挑几个已知来源的加粉,看后台归因对不对。归因错了,比没回传更难发现,也更要命。
落地清单
- [ ] 归因窗口已按加粉决策周期设置,不过长不过短
- [ ] 回传带准确转化时间戳,按发生时间归因
- [ ] 多计划重叠时,归因去重已开启
- [ ] 抽样验证归因结果,确认落到正确计划
回传是把数据交给模型,归因是告诉模型”这笔账算谁的”。账算错了,数据再准,模型也学不对。