When to run podcast SEO benchmark research on your own numbers

What to take away

Apple's iOS 26 changes to Apple Podcasts mean benchmark figures quoted from before that release may no longer describe how listeners find shows.
A benchmark is only usable if you record the source, the date and the population it covers. Undated numbers are decoration.
Listener data counts as personal information under the UK GDPR where it can identify a person, so benchmark collection has a compliance boundary.
Run the exercise before you commit budget, then repeat it against your own prior period rather than a rival's published figures.

What a benchmark actually is

A benchmark is a reference point you can compare your own performance against. In podcast SEO that usually means discovery metrics: impressions in search, click-through to a show page, follows, and episode plays attributed to organic entry.

Define each metric before collecting

Impressions in search
Click-through to show page
Follows
Episode plays from organic entry
One-line definition per metric

The trap is treating a published industry average as a target. Averages blend different show sizes, genres and distribution setups, so a daily news show and a monthly interview show share no useful baseline.

So the useful benchmark is your own previous period, plus a small number of external reference points you can date.

Write the definition of each metric before you collect it. Platforms do not count a play or an impression identically, so a one-line definition per metric stops two people reporting the same phrase with different arithmetic.

Why the ground shifted recently

Apple has continued to change how Apple Podcasts surfaces shows, with new features arriving in iOS 26 as set out in iOS 26: What's new for Apple Podcasts. A benchmark assembled before those changes describes a different discovery surface.

Carrying a 2024 figure into a 2027 report without a note compares two different products. Set your metric list first, and use the structure in our podcast SEO measurement and reporting guide to decide how discovery, on-site behaviour and reporting fit together.

Record the source for every number

Every figure needs a source, a publication date and a population. If any of the three is missing, leave the figure out.

Source record for every figure

Source named
Publication date recorded
Population described
Missing any of the three? Leave it out
Notes in one dated file per cycle

For example, a team tracking 40,000 monthly impressions might record the platform, the date range and the filter applied. That is a benchmark. A slide claiming the industry average click-through is strong is not.

Where you cannot cite a dated source, label the figure as an illustrative example and say so in the table. Keep the notes in one file per reporting cycle, named by date, so the next person can trace a number back without asking around.

The compliance boundary

Audience data is not automatically anonymous. The ICO's guidance on personal information under the UK GDPR explains that information relating to an identifiable individual falls within scope, including device and behaviour data once combined.

GOV.UK's summary of UK data protection legislation sets out the obligations that follow: lawful basis, retention limits and handling rules.

Practical effect for benchmark work: aggregate before you store, keep raw listener-level exports out of shared drives, and set a retention period you enforce. Say in your privacy notice what you collect and why, and name the lawful basis you rely on.

Before and after the exercise

Before

Metric list: Platform dashboard defaults
Source record: Screenshot in a slide
Comparison: Rival show's published average
Data storage: Raw exports in shared folders
Reporting cadence: Ad hoc when asked

After

Metric list: Named metrics tied to discovery stages
Source record: Source, date and population noted per figure
Comparison: Own prior period, same filters
Data storage: Aggregated, with a retention period set
Reporting cadence: Fixed monthly and quarterly reviews

Choosing the comparison period

Match the period to the change you are testing. A feed title rewrite needs a short window, perhaps 28 days either side. A site restructure needs a quarter.

Seasonality will distort short windows. December and August behave differently for most shows, so note the calendar position in the table. If a metric moves outside its normal range, shorten the next window rather than redefining the metric midway.

The methods in our piece on podcast SEO attribution methods explain how to connect a discovery change to a specific entry point without overclaiming.

Common questions

How often should benchmark research be repeated?

Quarterly is usually enough for discovery metrics, with a fresh baseline after any platform release that changes how shows are surfaced. Repeat sooner if a single metric moves sharply.

Can I use a competitor's published figures?

Only as context, never as your target. Their audience, genre and release schedule differ, and you cannot verify how they counted.

Does listener data count as personal information?

It can. Where data relates to an identifiable individual it falls within UK GDPR scope, so aggregate early and set a retention period.

What if no dated source exists for a metric?

Label it as an illustrative example in the table, or drop it. An undated figure weakens every other number in the report.