My Search Console Clicks Showed Only 5% of the Real Number: Anonymized Queries Dropped Out When I Aggregated by Page × Query

Good morning, まさきん here.

This blog’s weekly report showed “7” search clicks over 28 days. When I looked again by page, the real number was 145. The cause was how the aggregation was set up, so I am leaving this practical note so others do not fall into the same trap.

*This information is current as of publication. Please check the official websites for the latest terms.

What happened

This blog has an analytics report that arrives automatically every week. It collects numbers from Search Console and GA4 and lays out the changes from the previous week.

One week, that report showed search clicks over 28 days as “7.” New posts were going up every week, and search impressions were growing at the time. It seemed far too low.

So I looked at the same period by page in the Search Console interface. The total was 145. The 7 was only about 5% of the real number.

Traffic had not dropped; it was an aggregation bug. I am glad I caught it before concluding “search is weak this week” from the numbers.

The cause: adding up page × query

The weekly report script was pulling Search Console data as combinations of page and query. It then added up all those rows and called that “total search clicks.”

At first glance, it seems like adding up every per-page, per-query breakdown should give you the total. But in Search Console, it does not.

Some queries are “anonymized queries.” Not a single row for them appears in any table that includes query. So they vanished at the point of adding things up.

What are anonymized queries?

Anonymized queries are queries left out of tables to protect privacy. Google’s Search Central blog explains them. The rule of thumb is that they are “queries not searched by more than a few dozen users over a two-to-three-month period.”

The actual search terms are not shown. However, the chart totals do include them. But if you filter by query, they are excluded from the total as well.

The official blog had an easy-to-follow example. Adding up the breakdown by query gave 450 clicks. Meanwhile, the overall total was 550 clicks. The difference of 100 was from anonymized queries.

The gap may be bigger for smaller sites

The anonymization threshold is based on “the number of people who searched.” So sites that get read a little at a time through very specific search terms are likely to have a higher share of anonymized queries.

This blog is exactly that type. Each search term brings only a few visitors, and people find it through very specific phrasing. As a result, I think most of the clicks were on the anonymized side.

Keeping only 5% looks extreme. But for personal blogs or newly launched sites, it may not be unusual.

Sorting out why totals do not match

Anonymization is not the only reason Search Console numbers do not add up. I put the ones I could confirm in the official help and blog into a table.

What hit my weekly report was almost entirely the first one. Still, when other reasons overlap, the numbers become even harder to read.

Property-level vs. page-level

Search Console has two ways of aggregating: by property (byProperty) and by page (byPage).

According to the official help, chart totals are aggregated by property. Even if your site appears multiple times for the same query, the impression is counted once.

On the other hand, grouping the table by “Page” gives you page-level aggregation. If two of your pages appear in the same search result, each gets an impression. So the per-page total can be larger than the chart total.

The API reference says that when you group or filter by page, you cannot choose byProperty. In that case, it advises specifying auto.

Watch out for API row limits too

The Search Analytics API’s rowLimit defaults to 1,000 rows. You can specify 1 to 25,000 rows, and beyond that you page through with startRow.

The maximum you can pull through the API is “50,000 rows per day, per site, per search type.” That is how the Search Central blog explains it. Apparently the Looker Studio connector has the same limit.

The API reference also has a note to the effect that “it is not guaranteed to return all rows.” It seems best to use it on the assumption that you get the top rows back.

On the other hand, pulls that do not include query or URL are said to return all the data. Country or device breakdowns are examples. If you are pulling totals, this is another point worth remembering.

Definitions of impressions, CTR, and position

Before talking numbers in a weekly report, let’s align on what the metrics mean. Here is a summary of the official help definitions.

Average position uses only the topmost position, even if your site shows up several times in one search. I think it is important to read metrics in combination rather than judging by any single one.

What I fixed in the weekly report

Now that I knew the cause, I changed how the weekly report is put together. I did three things.

1. Made “GSC page-level search performance” and “GA4 traffic sources” the two main features
2. Adopted a rule not to comment on changes in categories with fewer than 30 PV before or after
3. Started looking at new posts and existing posts separately

The first is the direct fix for this bug. Totals are pulled without query, and per-post performance is viewed at the page level. I demoted the per-query table to material for browsing what words people use to find posts.

The second is a rule to avoid making a fuss over small numbers. Writing “up” or “down” over a difference of a few makes the next decision more likely to wobble.

The third is so I do not mix growth from new posts with changes in existing ones. If you only look at the total, you cannot tell which one made the difference.

Household budgets have “invisible numbers” too

What this taught me is that if you build a total from the bottom up, you cannot notice what is missing. Look at the whole from the top, then check it against the breakdown. Only then did the gap become visible.

Household fixed costs are similar. Even if you go through your statement line by line, gaps are hard to spot unless you compare against your total spending. For expenses that are automatically charged every month, like your phone bill, it may be worth reviewing them all together once.

Common pitfalls in homemade aggregation

From here on is for people who look at GSC through a homemade weekly report, the API, or the BigQuery bulk export. I am listing them, including the ones I stepped on myself.

• Adding up page × query rows to get a site-wide total
• Comparing numbers filtered by query with unfiltered numbers in the same table
• Thinking it is a bug that the per-page total does not match the chart total
• Aggregating with only the default 1,000 rows because you did not specify rowLimit
• Comparing against last week using the last 2-3 days of numbers that have not settled yet

There is a caveat for the BigQuery bulk export too. According to the official help, anonymized queries are marked by a column called is_anonymized_query. The query column in those rows is apparently empty (null).

The tables are also split into two: one by property and one by URL. If you aggregate by query and drop the empty rows, the total should shrink in the same way. When calculating totals, it may be safest not to filter by query.

Ways of reading that work and ways that do not

Here is a rough breakdown of which numbers to use for which purpose.

• Works: view site-wide trends using property-level totals
• Works: view per-post performance at the page level
• Works: use the per-query table for trends in “what words people use to find you”
• Does not work: adding up per-query rows to get the overall total
• Does not work: treating a difference of a few as evidence of growth or decline

Personally, I feel most reassured pulling totals and breakdowns in separate ways. In analytics work too, I think being able to explain where a number comes from is what matters. It may be close to what I wrote about the “interpreting skill” data analysis needs.

What to check before you start

• Whether the total clicks in your weekly report are pulled in a way that includes query
• Whether you have checked the Search Console interface total against your report total at least once
• Whether you specify rowLimit and startRow in the API
• Whether you choose aggregationType to fit your purpose
• Whether you are using unsettled data from the last 2-3 days in comparisons
• Whether you have a rule for when to comment on changes in small categories

FAQ

Q. Can I see the anonymized queries later?

The actual search terms are not shown. The Search Central blog explains that they are left out to protect privacy. It seems all you can do is infer them from the gap, as the portion included in the total.

Q. Which is right, the interface total or the total of the per-query table?

It depends on what you use it for. For site-wide clicks, the chart total should be closer to reality. I think the per-query table is best viewed as a breakdown that does not include the anonymized portion.

Q. Why is the per-page total larger than the chart total?

Because the aggregation method differs. At the page level, if multiple pages appear in the same search, each is counted. The chart is property-level, so it counts once.

Q. If I build a weekly report with the API, how should I pull the data?

It is safest to pull totals without query. For per-post numbers, pull by page only and set aggregationType to auto. I pull per-query data in a separate call and keep it from mixing with the totals.

Q. Does the same thing happen in Looker Studio?

The Looker Studio connector is said to have the same row limits as the API. The source is the Search Central blog. The anonymization mechanism is also the same, so totals in tables that include query may come out small.

Q. Can I get everything with the BigQuery bulk export?

The official blog explains that it is not affected by row limits. However, the query column is empty for anonymized queries. If you aggregate by query, that portion still becomes invisible.

Q. Why not comment on categories with fewer than 30 PV?

With small numbers, it is easy to get thrown around by chance ups and downs. Changing course over a difference of a few makes your judgment wobble. In my weekly report, I set a threshold and exclude them mechanically.

Official sources I referred to

• Performance report (Search results): Overview and basic setup (Search Console Help)
• Performance report (Search results): Troubleshooting data discrepancies (Search Console Help)
• What are impressions, position, and clicks? (Search Console Help)
• Table names and location (Search Console Help, bulk data export)
• Search Analytics: query (Search Console API reference)
• A deep dive into Search Console performance data filtering and limits (Search Central Blog)
• Bulk data export: a new and powerful way to access your Search Console data (Search Central Blog)

Wrapping up

With Search Console data, the total can change dramatically depending on how you pull it. In my weekly report, adding up page × query turned 145 into 7.

Pull totals without query. View post performance at the page level. Use the per-query table as material for spotting trends. I think just keeping these three in mind will cut down on misreadings quite a bit.

Once you understand the mechanism, the numbers look a little different. If you use a homemade weekly report, try checking it against the interface total just once.

As a similar story of “the records looked right but reality was off,” here is the subscription I marked as “canceled” that kept charging me. If you are reviewing fixed costs, how to get started reviewing fixed costs may also help.

This article contains affiliate advertising. If you sign up for a product or service through a link on this site, we may receive compensation from the partner company. The site operator is also an employee of Rakuten Group and may receive compensation through an employee referral program. The content and opinions here are based on the operator’s own experience and research regardless of any advertising relationship, but please read with the above in mind. See the Disclaimer & Affiliate Disclosure for details. Disclaimer & Affiliate Disclosure

This article includes machine-translated content. Please check the official Rakuten Mobile multilingual page for exact terms.

If you have concerns about Rakuten Mobile coverage or signal quality, you can consult through the official signal improvement request form .