流量来源对不上：两个后台各说各话时，怎么算出一个数

这一篇不是教你看 GA4 里的流量来源报表。它要解决的是后面那件事：两个后台对不上的时候，怎么算出一个能拿去汇报、半年后自己还认的数。Search Console 知道搜索词和页面，但没有会话、没有钱；分析工具知道会话和钱，但不知道搜索词。两边没有共同的主键，所以这一章不去对账 —— 而是把每一步都关在一个系统里，再把两边的差额当成一个常数记下来。

读这篇之前

两个系统里得各有同一批页面、至少 28 天的数据，还得有一个你已经信得过的转化事件。事件是新埋的就先等一个月 —— 拿一个还在调试的指标去搭归因链，算出来的数以后没人敢替它辩护。

这一章教的是手工算法。QueryWin 不替你算这笔账，也不是朝这个方向建的：算术很容易，难的是那几处判断，而这一章的全部内容就是那几处判断。

两个后台的流量来源为什么拼不起来

Search Console 的一次点击和分析工具的一次会话，是两件不同的事，由两套代码在两个时刻记录，过滤规则也不一样。前者记的是结果被点了，后者记的是页面加载完、脚本跑起来了。这两个时刻之间，隔着同意弹窗、脚本拦截、预取、重定向，以及一批没等页面加载完就走的人。

Search Console 内部本身还有一处聚合差异，而且是写在文档里的。效果报告帮助页原文，2026-08-20 访问：「Data grouped by Queries, Countries, Devices, or Dates is aggregated by property. Data grouped by Pages or Search appearance is aggregated by page.」同一页还写着：「The chart totals can sometimes differ from the table totals.」

也就是说，同一天、同一份报告里拉出来的两个自家数字，允许对不上，而且原因是写明了的。所以目标从一开始就不该是对账。

别让两个系统对上账。每一步只在一个系统里量，两边的差额记成一个你要盯的常数。

那张工作表

六行。每一行都注明数据来自哪个系统，除了第四行 —— 它存在的意义正是量那道跨越。

那个数 = 点击 × 承接率 × 转化率 × 单次转化价值，报的时候必须连窗口和四个输入一起报。永远不要只报乘积。一个不带常数的孤零零的数字，正是半年后被人拿回来问你的那种东西 —— 那时四个输入早就全变了。

第四行是关键的一行

承接率是「Search Console 说到了多少人」和「分析工具说到了多少人」之间的比值。它的绝对值不太有意思，取决于你的同意弹窗怎么配、你的读者装没装拦截插件、你有几道重定向。要紧的是它在两个周期之间应该大体稳定。

承接率在两个窗口之间猛地一动，说明变的是测量，不是世界：上了同意弹窗、迁了代码、加了重定向。遇到大幅波动就停下来找那处改动，别把它当成一个需要解释的业绩结果。

第六行是决定，不是测量

有单次转化收入就用真的。没有 —— 注册、预约演示、留资这类大多没有 —— 那就自己定一个数，把怎么定的写下来，并且跨周期不改。一个自定但恒定的常数，照样能让两个周期可比；一个被你悄悄改过的常数，会让所有比较作废，而且改的方向往往正好是你希望的那个方向。

AI 那条线放在哪

单独一行，用它自己的分母，不加进上面那个数里。

两条具体理由。Search Console 对 AI 面的报告是页面级的、字段也不一样，说明在AI 流量在 Search Console 里能看到什么。另一条是从 AI 答案过来的访问里有很大一部分不带来源信息、直接落进直接流量那个桶，说明在把 AI 带来的访问从直接流量里捞出来。

所以诚实的呈现方式是两行加一句话：归因过的那个数、只部分归因的 AI 那一行，再明确写出有多少流量你两边都归不上。最后那句话，才是让前两行可信的东西。

那句话要写成会话占比，不要写成脚注。「本窗口的会话里，这一部分没有来源信息也没有活动参数，我们没有尝试归因」，财务看得懂、也能拿去用。而「归因存在误差」这种脚注没人读，也拦不住那个复合数被当成完整的数。

这里要忍住的诱惑，是去给那部分建模 —— 假设一个比例、折算进去。那等于把一个诚实的缺口换成了一个带小数点的数字，而小数点正是让人不再追问的东西。

七步，按顺序

七步，顺序本身在干活：每一步都固定住一个选择，否则下个月它就会被换一种做法。先定窗口再定页面，先定页面再拉数，先算承接率再看转化率 —— 因为知道了答案，人对输入的宽容度就变了。

1. 定死窗口。28 天，截止到至少三天前，让两个系统都处理完。
2. 定死页面集。一份存在表里的地址清单，不是一个下个季度可能被重新解释的目录规则。
3. 第一、二行从 Search Console 拉，用页面筛选而不是搜索词筛选，让聚合口径全程保持在页面级。
4. 第三行从分析工具拉，同一份地址清单，只取自然搜索这一个渠道。
5. 先算承接率，先写下来，再去看别的任何东西。
6. 拉正好这批会话的转化率，再套上你固定下来的那个价值。
7. 把四个输入、窗口和结果写成表里的一行，过去的行永远不改。

第七步是全部纪律所在。这套动作的价值出现在第四、五次重复的时候 —— 那时你有了一条序列，而序列成立的前提是没人回头去「改进」早先那几行。

三种把这个数算坏的方式

三种都不会报错。每一种都给出一个看起来合理、里面带着缺陷的数，而缺陷要等到有人问「上季度怎么不一样」时才露出来。

1. 窗口没对齐。 一边 28 天一边 30 天，承接率会无缘无故地漂。两个窗口必须是同样那几天，不是同样的天数。
2. 直接用默认渠道分组。 不看清楚有多少落进了直接流量就取「自然搜索」，AI 带来的那部分已经被排除在外了，而你不知道被排除了多少。
3. 单次转化价值跟着心情走。 季度不好看就往上调，那不是分析。定一次，写下来，连理由一起。

这一章说不了什么

它说不了因果。这套做法给的是一个口径一致、可核的数，而一致不等于真实 —— 每个输入都带着它所在系统的偏差，四个连乘是把偏差乘起来，不是让它们互相抵消。

我们也没法拿服务器日志来验证，跑这套流程的人大多也没有。没有日志就没有第三方仲裁，Search Console 和分析工具吵起来的时候没人能判，所以承接率始终是一个你盯着看、而不是真的懂的黑盒。

量级太小的时候这一章整个不适用。如果这批页面一个月只有几百次曝光，第五行的转化率不过是几个事件，四个带噪音的比值相乘，摆动会大到看着像业绩。窗口内不足约一千次点击，就只报原始的点击数和转化数，复合数别算。

这个数的用处是跟你自己以前那几行比 —— 和十四天复盘是同一条纪律，只是周期更长、而且带上了钱。把这种比较变成不用手工拼的东西，是 QueryWin 正在做的事。

常见问题

Search Console 的点击和分析工具的会话为什么永远对不上？

两者在不同时刻记录不同的事件，过滤规则也不同；Google 自己还写明了 Search Console 内部两个视图都可能因聚合方式而不一致。别再想让它们相等，改成盯住那个比值。

该拿哪个数去汇报？

拿复合数，旁边印上窗口和四个输入，再加上单列的 AI 那一行和归不上的占比。一个不带输入的数字，会招来你最不想听的那个问题：这数哪儿来的。

用末次点击归因不行吗？

行，单渠道的站上差别很小。这一章不点名任何归因模型，是因为问题出在模型之前 —— 两个系统在任何归因模型开始工作之前就已经对不上了。

多久算一次？

每月一次，按固定日程，窗口截止日距离你算的那天始终隔同样的天数。看着有意思才去算一次，算出来的序列长得像你的好奇心。