早上好,我是まさきん。
这个博客的周报显示,28天内的搜索点击只有“7次”。按页面重新查看,实际上是145次。原因出在汇总的方式上,所以我把它写成一篇实务笔记,免得再踩同样的坑。
※以上为文章发布时的信息。最新条件请以官方网站为准。
- 如果按“页面×查询”获取Search Console的数据再相加,匿名查询的部分会被整个漏掉
- 在我的周报里,点击只剩下实际数量的约5%(145次中的7次)
- 每周的合计不要包含query,按page或整个资源(property)获取比较安全
- API的行数上限以及汇总方式(byPage / byProperty)的不同,也会让合计出现偏差
- 把按查询划分的表格当作“观察趋势的材料”,也许会更好相处
发生了什么
这个博客有一份每周自动送达的分析报告。它会收集Search Console和GA4的数字,列出与上周的差异。
有一周,周报里的搜索点击在28天内只有“7次”。那段时间文章每周都在增加,搜索的展示次数也在增长。我觉得这实在太少了。
于是我在Search Console的界面里,按页面查看了同一时段。合计是145次。7次只有实际数量的约5%。
并不是访问量下降了,而是汇总出了问题。幸好是在看到数字、下结论说“这周搜索表现不佳”之前发现的。
原因是页面×查询的加总
周报的脚本是按page和query的组合来获取Search Console数据的。然后把所有行加起来,当作“搜索点击合计”。
乍一看,把每个页面、每个查询的明细全部相加,似乎就是合计。可在Search Console里并不是这样。
查询当中有“匿名查询”。这部分在包含query的表格里连一行都不会出现。所以在相加的时候,这部分就消失了。
什么是匿名查询
匿名查询是为了保护隐私而从表格中省略的查询。Google的Search Central博客对此做了说明。大致标准是“在2〜3个月内,搜索用户未超过几十人的查询”。
实际的搜索词不会显示。另一方面,图表的合计中也包含了这部分。不过,如果按查询筛选,它们也会被排除在合计之外。
官方博客里有一个很好懂的例子。把明细中的查询加起来是450次点击,而整体合计是550次点击。相差的100次就是匿名查询的部分。
匿名查询也不会以“其他”这样的一行返回。只是把行相加的话,根本察觉不到有数据被漏掉,这才是最大的陷阱。
网站越小,差距可能越大
匿名化的标准是“搜索的人数”。所以,越是被各种细碎搜索词一点点带来阅读的网站,匿名化的比例可能越高。
这个博客正是这种类型。每个搜索词的量都很少,读者是通过各种细致的说法找来的。结果,大部分点击可能都落在了匿名查询那一侧。
只剩5%看起来很极端。不过,对个人博客或刚上线的网站来说,这也许并不罕见。
整理合计出现偏差的原因
Search Console的数字对不上,原因不只是匿名化。我把在官方帮助和博客里能确认到的原因整理成了表格。
| 偏差原因 | 会发生什么 | 容易受影响的场景 |
|---|---|---|
| 匿名查询 | 在包含query的表格中整行消失 | 按page×query合计、按查询筛选 |
| 汇总方式不同 | 按资源和按页面的计数方式不同 | 比较图表合计与按页面的合计时 |
| 表格行数上限 | 界面上的表格最多1,000行 | 长尾流量多的网站 |
| API行数上限 | 每天、每个网站、每种搜索类型都有上限 | 大型网站通过API获取时 |
| 数据延迟与时差 | 需要2〜3天才能反映、按太平洋时间汇总 | 看最近几天的数据或与GA4比较时 |
在我的周报里起作用的,基本上就是第一条。不过,其他原因叠加上来的话,数据会更难读懂。
按资源与按页面的区别
Search Console有两种汇总方式:按资源(byProperty)和按页面(byPage)。
根据官方帮助,图表的合计是按资源汇总的。即使同一个查询中你的网站出现了多次,展示次数也只算1次。
另一方面,如果把表格按“页面”分组,就是按页面汇总。同一个搜索结果中出现2个页面的话,每个页面都会计入展示次数。所以,按页面的合计有时会比图表的合计更大。
| 汇总方式 | 计数方式 | 适合的用法 |
|---|---|---|
| byProperty | 整个网站只算1次 | 看整个网站展示和点击的变化 |
| byPage | 每个页面分别计数 | 比较每篇文章的表现 |
| auto | 由服务端自动决定 | 按page分组或筛选时的指定 |
API参考文档写着,按page分组或筛选时不能选择byProperty。这种情况下,建议指定auto。
也要注意API的行数上限
Search Analytics API的rowLimit默认是1,000行。可指定的范围是1〜25,000行,超出部分要用startRow翻页。
通过API能获取的上限是“每天、每个网站、每种搜索类型50,000行”。Search Central博客是这样说明的。据说Looker Studio的连接器也是同样的上限。
另外,API参考文档里有一条注释,大意是“不保证返回所有行”。最好以返回的是排名靠前的行为前提来使用。
另一方面,不包含query或URL的获取方式,据说会返回全部数据,例如按国家、按设备等。要取合计的话,这也是值得记住的一点。
展示次数、CTR、排名的定义
在周报里谈论数字之前,先统一一下指标的含义。官方帮助中的定义整理如下。
| 指标 | 官方帮助中的含义 |
|---|---|
| 点击次数 | 从Google搜索结果中点击你网站的次数 |
| 展示次数 | 你网站的链接在搜索结果中显示的次数 |
| CTR | 点击次数除以展示次数的值 |
| 平均排名 | 你网站排名最高的链接的排名平均值 |
平均排名在一次搜索中即使出现多次,也只取最靠前的排名。我认为不要只凭一个指标做判断,把几个指标结合起来看很重要。
周报里改了什么
找到原因后,我改了周报的结构。做了3件事。
- 把主角定为“GSC按页面的搜索表现”和“GA4的流量来源”这两项
- 前后都不到30PV的分类,定下不讨论其增减的规则
- 把新文章和已有文章分开来看
第1条是针对这次问题本身的对策。合计不含query来获取,每篇文章的表现按页面来看。按查询划分的表格,降级为观察读者用什么词找来的材料。
第2条是为了不因小数字而大惊小怪的规则。差几次就写“涨了”“跌了”,下一步的判断很容易摇摆。
第3条是为了不把新文章的增长和已有文章的变化混在一起。只看合计的话,就分不清到底是哪边起了作用。
“看不见的数字”家庭账本里也有
这次的事让我想到,从下往上累加合计,是察觉不到遗漏的。从上面看整体,再和明细对照,这样才第一次看到了差距。
家庭的固定开销也类似。就算一行一行地看明细,如果不和整体支出比较,也很难发现遗漏。像手机费这种每月自动扣款的支出,不妨找机会集中重新审视一下。
自己做汇总时容易踩的坑
下面是写给用自制周报、API或BigQuery批量导出来看GSC的人。也包括我自己踩过的坑。
- 把page×query的行相加,当作整个网站的合计
- 把按查询筛选后的数字和未筛选的数字放在同一张表里比较
- 以为按页面的合计与图表合计对不上是出了故障
- 没有指定rowLimit,只用默认的1,000行来汇总
- 用最近2〜3天尚未确定的数字和上周比较
BigQuery批量导出也有需要注意的地方。根据官方帮助,匿名查询通过is_anonymized_query这一列来区分。据说这些行的query列是空的(null)。
另外,数据表分为按资源和按URL两种。如果按query汇总并排除空行,合计应该也会同样变小。计算合计时,不按query筛选来汇总或许比较稳妥。
适合与不适合的看法
我把哪些数字用于什么目的,大致区分一下。
- 适合: 整个网站的变化,用按资源的合计来看
- 适合: 每篇文章的表现,按page来看
- 适合: 按查询划分的表格,用来看“读者用什么词找来”的趋势
- 不适合: 把按查询划分的行相加,当作整体合计
- 不适合: 把几次的差距当作增减的依据
我个人觉得,用不同的获取方式分别得出合计和明细是最放心的。在分析工作中,能说明数字从何而来也很重要。这可能和数据分析所需的“翻译能力”也有相通之处。
开始之前要确认的事
- 周报的点击合计是否用了包含 query 的获取方式
- 是否已将 Search Console 界面上的合计与周报合计对照过一次
- 是否指定了 API 的 rowLimit 和 startRow
- 是否按目的选择了 aggregationType
- 是否把最近2〜3天未确定的数据用于比较
- 是否已定好讨论小分类增减的规则
常见问题
Q. 匿名查询的部分,之后还能看到吗?
实际的搜索词不会显示。Search Central博客说明,这是为了保护隐私而省略的。看来只能把它当作包含在合计中的部分,通过差额来推测。
Q. 界面上的合计和按查询划分的表格合计,哪个是对的?
取决于用途。如果是整个网站的点击次数,图表的合计应该更接近实际。按查询划分的表格,最好当作不包含匿名部分的明细来看。
Q. 为什么按页面的合计比图表的合计更大?
因为汇总方式不同。按页面汇总时,同一次搜索中出现多个页面会分别计数。图表是按资源汇总的,所以只算1次。
Q. 如果用API做周报,该怎么获取比较好?
合计不含query来获取比较安全。每篇文章的数字只按page获取,aggregationType设为auto。按查询划分的数据用另一次调用获取,我不会把它和合计混在一起。
Q. Looker Studio也会出现同样的情况吗?
据说Looker Studio的连接器和API的行数上限相同,出处是Search Central博客。匿名化的机制也是共通的,所以包含查询的表格合计可能会偏小。
Q. 用BigQuery批量导出能获取全部数据吗?
官方博客说明,它不受行数上限的影响。不过,匿名查询的query列是空的。按查询汇总的话,这部分依然看不到。
Q. 为什么不讨论不到30PV的分类?
因为数量少的时候,很容易被偶然的增减牵着走。因为几次的差距就改变方针,判断会变得摇摆不定。在我的周报里,定好阈值后会机械地把它们排除掉。
参考的官方信息
- Performance report (Search results): Overview and basic setup(Search Console 帮助)
- Performance report (Search results): Troubleshooting data discrepancies(Search Console 帮助)
- What are impressions, position, and clicks?(Search Console 帮助)
- Table names and location(Search Console 帮助、批量数据导出)
- Search Analytics: query(Search Console API 参考文档)
- A deep dive into Search Console performance data filtering and limits(Search Central 博客)
- Bulk data export: a new and powerful way to access your Search Console data(Search Central 博客)
总结
Search Console的数据,取法不同,合计就会有很大差别。在我的周报里,page×query的加总让145次变成了7次。
合计不含query来获取;文章的表现按page来看;按查询划分的表格当作观察趋势的材料。只要把握这3点,读错数据的情况应该会少很多。
弄懂了机制,看数字的角度也会有些不同。如果你在用自制的周报,不妨拿界面上的合计对照一次。
作为类似的“记录上对得上,实际情况却有偏差”的例子,我也附上标着“已退订”的订阅却一直在扣费的经历。如果想重新审视固定开销,固定开销审视入门或许也能作为参考。
本文包含联盟营销广告。如果您通过本站链接申请相关商品或服务，我们可能会从合作企业获得报酬。此外，运营者是乐天集团的员工，也可能通过员工推荐计划获得报酬。文章内容与评价均基于运营者的真实体验与调查完成，与是否存在广告无关，但请您在阅读前了解上述关系。详情请参阅免责声明与联盟营销说明。 免责声明与联盟营销说明
本文包含机器翻译内容。正式条件请以乐天移动官方网站的多语言页面为准。
如果您对乐天移动的通信区域·信号状况有疑问，可以通过官方的 电波改善调查申请表 进行咨询。
