Data Discrepancies: GSC vs SPA

Google Search Console data representation has its own limitations; some of the highlights are as follows:

• To protect user privacy, GSC doesn't show all data. For example, we might not track some queries that are made a very small number of times or those that contain personal or sensitive information.
• Some processing of our source data might cause these stats to differ from stats listed in other sources (for example, to eliminate duplicates and visits from robots). However, these changes should not be significant.
• Technical differences between tools. We are using the Search Console API which processes data differently from the Search Console UI.

In the following examples, the “View” column represents the available data splits in the GSC UI. The “Overall” view, presented in the GSC screenshot below, is different from other views.  In both examples, we can see that the “Pages” view shows more clicks and impressions in comparison to other breakdowns (overall, queries, countries, devices). This is one example that highlights the extent of data discrepancies.

The data presented in SPA will reflect, more closely, the metrics related to “Pages” rather than the “Overview”. 

Example # 1: Bushnell, May 2020

Schema Performance Analytics (SPA):

Example # 2: Bushnell, June 2020

Schema Performance Analytics

From the above samples, we can clearly see that GSC matrices reflect maximum clicks and impressions for page view even though the number of pages are limited to 1000 in UI. These data discrepancies are known by Google Search Console and are explained here for different reasons: https://support.google.com/webmasters/answer/6155685?hl=en#groupingdata

Whereas, SPA uses the GSC API to collect data on a daily basis. API gives the advantage to retrieve more than 1000 rows, however, when metrics such as clicks or impressions are pulled using API and broken down by different dimensions (page, search appearance and query), metrics are not the same as if the breakdown had not been applied. For example, the results of the brand query could not be equivalent to the overall/unfiltered results. As overall results provide an aggregate of all queries while brand queries (branded and non-branded) reflect the aggregate of tracked queries and omit the performance (clicks, impressions, CTR, position) of untracked queries. Therefore, anonymized queries are omitted, and data is truncated due to serving limitations by Google. This same reason is applicable to data inconsistencies for search appearances, scopes and other measures in SPA.

Therefore, in order to pull data for different data dimensions in SPA, first, we pull one row per URL, with the total of clicks, impressions, and CTR. After that, a separate stream pulls the breakdown by query and search appearances. The following scheme is used while pulling the information from API and also presenting different visualizations in the SPA dashboard. 

• Overall Results 

  • All Features + All Queries

• Specific Feature 

  • Feature +All Queries

• Specific Feature Brand Query (Branded/NonBranded) 

  • Feature + set of tracked queries

• Overall Brand Query (Branded/NonBranded)

  • AllFeatures + set of tracked queries

The users of the dashboard don’t need to memorize or handle the above information while extracting and filtering the information. The above information is provided to clarify the gap between different data segments.

Why do I see gaps in reporting for “No rich results”?

You may come across graphs in reporting that appear to show missing data. This is expected behaviour for tracking “No Rich Results”. Google doesn't report on this category, so Schema App computes these metrics with the formula:

All clicks - Sum of Search Appearance Clicks = No Rich Result Clicks

Ideally, the "No Rich Results" category should be a positive number, however, Google sometimes reports sum(search appearance clicks) more than overall clicks, therefore the formula results in a negative value which shows up as missing data in the visualization.