Search Console performance segmentation

The trap of a single average

The performance report opens with the whole property as one row: total clicks, impressions, CTR and position. That single view hides the story. A page that ranks at position 4 on mobile but position 12 on desktop, or a query that converts at position 2 in the UK but position 9 elsewhere, both average into one number that describes neither.

Segmentation is the act of splitting by a dimension (page, query, device, country, date, search type) so each row is a coherent population instead of a mishmash. The same data is documented in detail by the performance report article; this page is the "split it correctly" half.

The dimension that matters depends on the question

The click matrix of product-category vs brand-discounted is where query segmentation earns its keep: brand queries hide the real category keywords, and the query coverage article explains why.

Slicing by device, correctly

1. Open the performance report, set your date range.
2. Add the device dimension using the "Dimensions" toggle (the report offers Desktop, Mobile and Tablet).
3. Compare mobile CTR and position against desktop for the same pages.

The trap: Google reports device as the value at click time, so a page that shifts layouts under one device shows a mobile CTR that is the "at-the-time" value, not a stable mobile-design statement. Read the mobile row as trend, then corroborate with the CLS/LCP analyses when the mobile number is the one that matters.

Filtering by query and by country

To find the query behind a click change:

1. Apply the query dimension and sort by clicks descending.
2. Filter a specific page to see which queries drive it.
3. Apply country and compare XX vs previous period.

The average position flag: when the row is wide, "average" position is across servers and queries. A 50-city site can show position X on mobile and Y on desktop because the denominator changes, not the ranking. The honest move is to hold device+query constant, then compare periods.

Date slicing that does not lie

The most over-used segmentation is the one that misleads: comparing two windows of different lengths or different weekdays. The report's "compare" control forces the same window, but only if you set it: compare this 28 days to the *previous* 28 days (or the same 28 days last year). A seven-day window that includes a holiday or a weekend will jump around in a way a 28-day view will not.

Building the honest workflow

1. Pick a baseline filter set once: web search type, the date range, and the dimensions you will repeat (device, query, country).
2. Save the same filter every time; a changed date range silently re-pivots the story.
3. Decide the hypothesis before writing the query; segment to answer "did mobile drop?" not "is the whole site down?"
4. Cross-check dramatic single-dimension lines with the crawl health picture and the indexing analysis workflow, because a segmentation artifact and a real Google change look identical in one column.

Prevention

Keep the segmentation habit connected to a real decision: every time you add a dimension, you must be able to say what you will do differently if the row splits one way versus the other. The three slices that carry 90% of the value on a normal site are device, query, and country compared within the same fixed window. Everything else is a finer net to hunt with once those three point somewhere specific, which is exactly the disciplined use of the performance report this family teaches.