Reporting Segments That Mean Something

A sitewide total is the average of unrelated things: brand queries, a help centre, a blog, product pages and a careers section that ranks well and converts nothing. Reporting the total lets a help centre surge hide a commercial decline for two quarters. Ad hoc filters per report do not solve it either, because the definitions drift between reports and no two quarters end up comparable.

The skill file

---
name: organic-reporting-segments
description: Use when sitewide organic keeps rising while the part of the site the business cares about is falling.
---

# Reporting Segments That Mean Something

A sitewide total is the average of unrelated things: brand queries, a help centre, a blog, product pages and a careers section that ranks well and converts nothing. Reporting the total lets a help centre surge hide a commercial decline for two quarters. Ad hoc filters per report do not solve it either, because the definitions drift between reports and no two quarters end up comparable.

## What you need first

- a full URL inventory with a template or content type label
- Search Console query and page data for 12 months
- a branded query list including misspellings, product names and staff names
- agreement from the business on which segments are commercially meaningful

## Method

1. Segment by URL pattern first, because it is the only cut that is unambiguous and stable over time. Keep the patterns as regular expressions in one file that every report and dashboard reads.
2. Split branded from non-branded with an explicit published list rather than a rule nobody has seen. An undocumented brand regex makes every non-branded number in the report unauditable.
3. Add an intent cut across the non-branded set but hold it to two or three buckets. Fine-grained intent taxonomies get argued about at length and then stop being maintained.
4. Check each segment carries enough volume to show a signal. A segment averaging 30 clicks a day cannot show a 10 percent change reliably, so either merge it or report it annually and say why.
5. Test the segmentation against an event you remember: a migration, a template fix, a launch. If it smears across every segment rather than landing in one, the cut is wrong and will not explain anything later.
6. Freeze the definitions with a version and a date. When one has to change, run the old definition alongside for a quarter so a single report contains both and the trend line does not silently end.
7. Report segments alongside the total, never instead of it. A set of segments with no total invites the reasonable suspicion that you chose the flattering ones.

## What this produces

A versioned segment definition file of URL patterns and branded terms, plus a report layout showing each segment and the site total together.

## Where this goes wrong

- Redefining a segment mid-year without keeping the old definition running, which quietly ends every trend built on it
- Segmenting by folder on a site where folders do not match content type, producing numbers that look precise and mean nothing
- Letting the branded list go stale after a product launch, so new product name queries are counted as non-branded growth
- Building segments in one tool only, so the dashboard and the board report disagree and both get distrusted

---

From the QuQi skill library - https://www.quqi.io/skills/organic-reporting-segments

What you need first

• a full URL inventory with a template or content type label
• Search Console query and page data for 12 months
• a branded query list including misspellings, product names and staff names
• agreement from the business on which segments are commercially meaningful

Method

1. 01 Segment by URL pattern first, because it is the only cut that is unambiguous and stable over time. Keep the patterns as regular expressions in one file that every report and dashboard reads.
2. 02 Split branded from non-branded with an explicit published list rather than a rule nobody has seen. An undocumented brand regex makes every non-branded number in the report unauditable.
3. 03 Add an intent cut across the non-branded set but hold it to two or three buckets. Fine-grained intent taxonomies get argued about at length and then stop being maintained.
4. 04 Check each segment carries enough volume to show a signal. A segment averaging 30 clicks a day cannot show a 10 percent change reliably, so either merge it or report it annually and say why.
5. 05 Test the segmentation against an event you remember: a migration, a template fix, a launch. If it smears across every segment rather than landing in one, the cut is wrong and will not explain anything later.
6. 06 Freeze the definitions with a version and a date. When one has to change, run the old definition alongside for a quarter so a single report contains both and the trend line does not silently end.
7. 07 Report segments alongside the total, never instead of it. A set of segments with no total invites the reasonable suspicion that you chose the flattering ones.

What this produces

A versioned segment definition file of URL patterns and branded terms, plus a report layout showing each segment and the site total together.

Where this goes wrong

• Redefining a segment mid-year without keeping the old definition running, which quietly ends every trend built on it
• Segmenting by folder on a site where folders do not match content type, producing numbers that look precise and mean nothing
• Letting the branded list go stale after a product launch, so new product name queries are counted as non-branded growth
• Building segments in one tool only, so the dashboard and the board report disagree and both get distrusted

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Questions about this skill

More in Analytics & reporting