运营做渠道分析，最朴素的想法就是"看看用户是从哪个网址点过来的"。这时候前端同学多半会掏出 document.referrer。这个字段确实能拿到一些信息，但如果你认真做过多渠道投放，就会知道它丢数据、粒度粗、还容易被"洗"。今天聊聊为什么渠道分析不能指望它，以及正确的做法是什么。
投放过的人都知道，现在几乎没有产品只靠自然流量活着。一个典型的投放组合可能是：
- 百度 SEM（按关键词买搜索流量）
- 微信朋友圈 / 视频号信息流广告
- 抖音、小红书的信息流或达人合作
- 公众号文章、知乎软文、KOL 推文
- 邮件营销（EDM）、短信触达
钱撒出去了，运营要回答三个问题：
- 每个渠道带来了多少访问？
- 这些访问的转化质量怎么样？——不只是点击，而是注册、下单、关注
- 钱花得值不值？下一步预算往哪儿倾斜？
这三个问题，构成了"运营渠道分析"的全部内容。注意第二个问题的关键词——转化质量。渠道分析从来不只关心"来了多少人"，更关心"来的是什么样的人"。比如：我认为我们网站的登录人数是最值得关注的指标，那么登录转化率就应该作为我们分析的关键指标了。那么哪个渠道来的用户，转化率更高呢？
最常用的就是document.referrer，而它只能勉强回答第一个问题的一半。
document.referrer 记录的是"用户上一个页面的网址"。但有一大批访问，浏览器里压根不存在"上一个页面"：
| 访问场景 | referrer | 运营看到的结果 |
|---|---|---|
| 扫二维码打开 | 空 | 归为"直接访问" |
| 微信 / QQ / 钉钉里点链接 | 基本为空（WebView 内不可靠） | 归为"直接访问" |
| 邮件、短信、PDF 里的链接 | 空 | 归为"直接访问" |
| App 内嵌浏览器打开 | 空 | 归为"直接访问" |
| 地址栏输入、收藏夹 | 空 | 归为"直接访问"（这个倒是真的直接） |
问题在于：扫码来的、聊天工具来的、邮件来的用户，恰恰是运营最想单独评估的渠道。他们全部被塞进"直接访问"这一个筐里，和真·直接访问（老用户输网址）混在一起，渠道分析直接失真。
如果你的流量里微信生态占比高（做公众号、做私域的几乎都这样），这个筐能吞掉你三成以上的访问。在 referrer 视角下，这些渠道等于不存在——你投了朋友圈广告，报表上却什么都没有。
就算用户真的是从别的网页点过来的，现代浏览器也不见得给你完整的 referrer。两个原因：
一是浏览器默认策略收紧了。 Chrome 85 之后，默认的 Referrer-Policy 是 strict-origin-when-cross-origin——跨域跳转只发送"来源域名"，不带路径、不带查询参数。什么意思？用户从百度搜索结果页点进你的网站，你拿到的 referrer 只有：
https://www.baidu.com/
用户搜的词（wd=xxx）、点的是第几条结果、结果页的完整 URL——全都没有。
二是 HTTPS 到 HTTP 的跳转直接不发送。 如果你的落地页还是 HTTP（或者链路中间有任何 HTTP 环节），从 HTTPS 站点跳过来的 referrer 会被浏览器整个吞掉。
这两个因素叠加，意味着"从搜索引擎来的用户搜了什么词"这件事，靠 referrer 在当下基本解析不出来了。而搜索词恰恰是 SEM 优化最核心的数据——没有它，你连否定词都加不了。
这是最容易被新手忽略的坑。
用户从百度点进你的落地页，落地页 URL 是 https://你的网站/landing?from=baidu_sem。在这一页上，document.referrer 是百度的网址。但只要用户在站内再点一下——进入首页、注册页、详情页——后面每一页的 referrer 都变成了"你自己的网站"。
做渠道分析，你要的是"这个用户是从哪来的"，而不是"这一页的上一步是哪一页"。如果只在每次页面加载时读 referrer 上报，就会发生：
- 落地页的访问能归到百度；
- 用户在注册页完成注册这个转化动作时，referrer 已经是站内地址，转化被归到了"站内"。
渠道分析最关键的"转化归因"，就这样断掉了。所以成熟的方案都会在用户第一次访问时就采集来源并存下来（这就是"首次来源"的由来），而不是每页都读一遍 referrer。
广告行业有个普遍现象：点广告链接，并不会直接到达你的网站，中间要经过好几层：
用户点击 → 广告平台点击监测 → 短链接服务 → 联盟跳转 → 你的落地页
这些中间环节里，只要有一步用 JS 跳转（location.href）、meta refresh，或者设置了 no-referrer 策略，你落地页上读到的 referrer 就变成了中间跳转页的网址，甚至空值。
运营看到报表上写着"来源：某短链服务商域名"，或者"来源：直接访问"，真实投放渠道被完全掩盖。花了钱投的抖音信息流，最后变成了一堆来源不明的流量。
前面四个坑都是"丢数据"，这一个是"数据本身不够用"。
假设一切顺利，referrer 完整地告诉你"来自 https://www.baidu.com/"。然后呢？运营接下来要回答的问题一个都答不了：
- 是哪个推广计划带来的？（百度后台有十几个计划在跑）
- 是哪个关键词触发的？（同一个计划下几十个词）
- 是哪个创意 / 素材吸引点击的？（AB 测试了三个落地页）
referrer 最多给到"哪个网站"这一层。而运营做预算决策，需要的是"计划—关键词—创意"级别的粒度。这一层信息，referrer 结构上就提供不了，必须靠投放链接自带的参数来区分。
既然 referrer 靠不住，渠道分析怎么做？成熟的落地组合就三件事：投放链接打标、首次来源持久化、分群漏斗对比质量。
最基础也最有效的一步：在每一条投放链接上带参数。业界通用的 UTM 体系：
https://你的网站/landing?utm_source=baidu&utm_medium=cpc&utm_campaign=2026Q3大促&utm_term=前端监控&utm_content=素材A
| 参数 | 含义 | 举例 |
|---|---|---|
| utm_source | 渠道 | baidu / wechat / douyin |
| utm_medium | 媒介 | cpc / 信息流 / 邮件 |
| utm_campaign | 推广计划 | 2026Q3大促 |
| utm_term | 关键词 | 前端监控 |
| utm_content | 素材 / 创意 | 素材A / 素材B |
二维码、邮件、短信同理——链接上带参数，扫码和点邮件的人就不再是"直接访问"，而是带着自己的渠道标识进来。
落地页的 SDK 读取 URL 上的这些参数，和 referrer 一起上报。referrer 在这里的角色降级为"兜底信号"：参数为主，referrer 为辅。有参数的用参数；没参数的（比如自然搜索、外站软文）才看 referrer 能补充什么。
前面 2.3 讲过，站内一跳 referrer 就失忆。解法是：用户第一次访问时，把来源信息固化到用户身上，之后无论再来多少次、从哪个入口进来，最初的来源都在。
实现上，第一次访问时把渠道参数、referrer、解析出的搜索词写入用户档案（cookie 或服务端），并标记"这是首次来源，之后不再覆盖"。这样一个用户"出生"在哪个渠道，就一直跟着他。
这一步的价值要在下一步才能完全体现：只有把渠道挂在用户身上，才能把"渠道"和"转化质量"连起来。
渠道分析的最后一步，也是最容易被忽略的一步：不要只看每个渠道的访问量，要按渠道把用户分开，分别跑转化漏斗。
以我们自己在用的 Webfunny 埋点系统为例，SDK 会自动记录几个预置用户属性：
- 首次流量来源（用户第一次是从哪来的）
- 首次广告关键词（第一次是搜什么广告词进来的）
- 首次搜索关键词（第一次搜索用的词）
注意，全是"首次"——对应 3.2 的持久化逻辑。有了这些属性，就能建渠道分群：
[属性满足] 首次流量来源 = 百度-短语匹配
[属性满足] 首次流量来源 = 百度-智能匹配
然后把"浏览 → 体验 → 关注 / 注册"的漏斗分别套到两个分群上跑。结果往往是：两个渠道带来的访问量差不了多少，转化率却能差出几倍。
我们自己的真实经历：百度智能匹配带来的流量更多，但漏斗一跑，转化率比短语匹配低了一大截——这就是后来砍掉智能匹配词、转化率反而从 1% 出头涨到 3.4%～5.98% 的依据（完整过程写在《百度推广关键词优化：流量降了，转化率涨了》里）。
这一步为什么必须依赖"首次来源"而不是 referrer？因为转化（注册、下单、关注）往往发生在落地页之后的第 N 个页面，那一刻的 referrer 早就是站内地址了。只有把渠道固化在用户身上，转化数据才能和渠道对上号。
【截图位置 1：Webfunny 埋点系统里按"首次流量来源"维度拆分的渠道分布图】
【截图位置 2：渠道分群 + 漏斗卡片的组合使用效果，展示不同渠道的转化率对比】
假设某产品 9 月同时在跑四个渠道，用"纯 referrer"和"参数 + 首次来源"两种口径看同一批数据：
| 渠道 | referrer 口径看到的 | 参数 + 首次来源口径看到的 | 转化率（分群漏斗） |
|---|---|---|---|
| 百度 SEM | 一部分（只有 baidu.com，分不清计划和词） | 完整，可下钻到计划 / 关键词 | 可按词对比 |
| 微信朋友圈 | 几乎为 0（全在"直接访问"里） | 完整 | 可单独评估 |
| 邮件 EDM | 0 | 完整 | 可单独评估 |
| 自然搜索 | 有（但解析不出搜索词） | 有 + 搜索词 | 可看搜索词质量 |
| “直接访问” | 巨大（混入所有无 referrer 的渠道） | 只剩真实的直接访问 | — |
【待补充：从埋点系统拉真实数据填充上表，重点展示"直接访问"口径的差异——referrer 口径下直接访问占比虚高，参数口径下各渠道归位】
两种口径的差别不是数字精度问题，是渠道存在与不存在的问题。用 referrer 口径，你很可能得出"微信投放无效"的结论——不是无效，是数据根本没进来。
回到标题的问题：为什么不推荐用 document.referrer 做渠道分析？
- 它天生丢数据：扫码、App 内、聊天工具、邮件来的流量全没有 referrer，而这些恰恰是运营最想评估的渠道；
- 它给的粒度太粗：最好的情况下也只到"哪个网站"，运营需要的"计划—关键词—创意"级别，它结构上提供不了；
- 它不可持续：站内一跳来源就失忆，转化归因直接断链。
但也不要走极端——referrer 并非一无是处。在"参数为主"的体系里，它仍然是识别自然搜索、外站软文等"没打标流量"来源的辅助信号。值得采集，不值得依赖。
真正能撑起运营渠道分析的组合是：
投放链接打标（让渠道自报家门） + 首次来源持久化（把出身记在用户身上） + 分群漏斗对比（回答钱花得值不值）
渠道分析的终点从来不是"来了多少人"，而是"哪笔钱花对了"。
文中的"首次流量来源、首次广告关键词、首次搜索关键词"来自 Webfunny 埋点系统的预置用户属性，渠道分群 + 漏斗对比可以直接体验：https://www.webfunny.cn/wf_event/dataView.html
相关阅读：
- 《百度推广关键词优化：流量降了，转化率涨了》
- 《用户分群怎么做？用 3 个真实场景，讲清楚它的用法和价值》
- 待补充数据：
- 第四章的渠道对比表，建议从埋点系统拉真实的"首次流量来源"维度数据填充，重点展示 referrer 口径下"直接访问"占比虚高 vs 参数口径下各渠道归位；
- 截图 1：按首次流量来源拆分的渠道分布图；
- 截图 2：渠道分群 + 漏斗对比的效果图。
- 标题备选：
- 网站来源渠道分析：为什么不推荐用 document.referrer？（当前）
- 运营渠道分析的第一课：别指望 document.referrer
- document.referrer 丢掉的流量，比你想象的还多
- 技术表述校准（已按以下口径撰写）：
- "HTTPS → HTTP 跳转不发送 referrer"为浏览器安全默认行为；
- "Chrome 85+ 默认 strict-origin-when-cross-origin"指跨域跳转仅发送来源域名；
- 2.4 中间跳转污染主要发生在 JS / meta refresh 跳转与 no-referrer 中间页，302 服务端跳转通常保留原始 referrer，表述已做区分；
- 微信等 WebView 内 referrer 不可靠，表述为"基本为空"。
- 系列呼应：文中引用了《百度推广关键词优化》《用户分群》两篇已发布文章，发布时请加上站内链接。
- 若产品后续有独立的"来源分析 / 渠道分析"报表页，可在第三章补一节产品功能截图。