Podcast media monitoring: how to track brand and client mentions in episodes

When a journalist writes about your client, a media monitoring service tells you within hours. When a podcast host spends ten minutes discussing your client, praising a product or repeating a damaging rumor, you may never find out. Podcasts are a blind spot in many monitoring programs, even though they reach large, attentive audiences and their episodes stay online for years.

Podcast monitoring is now practical. Full-text search across episode titles, show notes and, increasingly, transcripts can surface mentions shortly after episodes publish. This guide explains how to set up podcast monitoring for brands, clients, executives, competitors and issues: what to track, how to write queries that are precise, how often to check, how to triage, and how to report. Examples use podsearch.org, which indexes episodes from around 3.2 million active feeds in the open Podcast Index catalog and re-polls feeds within seconds to minutes when their hosts send Podping notifications.

What podcast monitoring can and cannot see

Set expectations with clients from the start.

What is searchable:

• Episode titles. Highly reliable signals: if your client is in the title, the episode is about them or features them.
• Show notes and descriptions. Often include guest names, companies discussed, links and sponsors.
• Transcripts and episode content, where publishers provide them, for example through the <podcast:transcript> tag. These capture spoken mentions that never appear in show notes.

What is not:

• Spoken mentions in episodes without transcripts. If the host mentions your client in passing and the show publishes no transcript, text search will not find it. Closing this gap requires transcribing audio yourself.
• Podcasts that are not distributed via RSS, such as some platform exclusives.

A fair summary for clients: podcast monitoring reliably catches episodes about or featuring a subject, and catches spoken mentions where transcripts exist. Coverage of passing spoken mentions is partial.

Step 1: decide what to track

A monitoring program usually covers five kinds of subjects. Define each one explicitly.

Step 2: write precise queries

Monitoring lives or dies on query precision. A query that returns 300 irrelevant episodes a day will be ignored within a week.

Quote names and phrases

"Acme Robotics"
"Jane Doe"

Disambiguate common words and names

If a brand name is a common word, require context:

"Notion" AND (desc:productivity OR desc:app OR desc:workspace OR desc:software)
"Apple" NOT (desc:recipe OR desc:orchard OR desc:cider)

Use field prefixes to tune precision and recall

On podsearch.org, episode: matches episode titles, desc: descriptions and show notes, title: the show title and content: (or transcript:) episode content and transcripts where available. Running separate alerts per field lets you prioritize:

• Title mentions (episode:"Acme Robotics"): highest priority; the episode is about the client.
• Description mentions (desc:"Acme Robotics"): medium; the client is a topic, guest or sponsor.
• Content mentions (content:"Acme Robotics"): lower priority, larger volume; read in a daily digest.

Exclude your own ads

If your client sponsors podcasts, description searches will return their own ad reads. Exclude promo-code language or the specific shows you sponsor, or route those results to a separate "ads aired" report.

desc:"Acme Robotics" NOT (desc:"promo code" OR desc:"use code" OR desc:"brought to you by")

Step 3: schedule checks with the API

The podsearch.org API (ListenNotes-compatible, at https://podsearch.org/api/v2) accepts the same boolean syntax with syntax=dql. Sort by date and filter by published_after (epoch milliseconds) to get only new episodes since your last run:

import json, os, time, requests

API = "https://podsearch.org/api/v2"
HEAD = {"X-ListenAPI-Key": os.environ["PODSEARCH_API_KEY"]}
STATE = "monitor_state.json"

ALERTS = {
    "acme_title":   'episode:"Acme Robotics"',
    "acme_desc":    'desc:"Acme Robotics" NOT (desc:"promo code" OR desc:"use code")',
    "ceo":          'episode:"Jane Doe" OR desc:"Jane Doe"',
    "competitor":   'episode:"Rival Robotics" OR desc:"Rival Robotics"',
}

def run():
    state = json.load(open(STATE)) if os.path.exists(STATE) else {}
    now_ms = int(time.time() * 1000)
    for name, q in ALERTS.items():
        since = state.get(name, now_ms - 7 * 86_400_000)
        r = requests.get(f"{API}/search", headers=HEAD, timeout=20, params={
            "q": q, "syntax": "dql", "type": "episode", "sort_by_date": 1,
            "published_after": since})
        r.raise_for_status()
        for ep in r.json()["results"]:
            print(f"[{name}] {ep['podcast']['title_original']} | {ep['title_original']} | {ep['link'] or ep['audio']}")
        state[name] = now_ms - 3_600_000   # one-hour overlap to tolerate late indexing
    json.dump(state, open(STATE, "w"))

if __name__ == "__main__":
    run()

Run it on a schedule (cron, a serverless scheduler, or your workflow tool) and send results to email, Slack or your monitoring dashboard. De-duplicate by episode id so the overlap window does not create repeat alerts.

How often to check

• Crisis or launch mode: every 15 to 30 minutes for title and description alerts.
• Normal operations: a few times a day for title alerts, daily for description and content alerts.
• Competitor and issue tracking: daily or weekly digests.

Freshness depends on the show. Feeds whose hosts send Podping notifications are re-polled within seconds to minutes of publish. Others are polled on an adaptive schedule: active shows often, dormant ones rarely. A one-hour overlap in your published_after window, as in the script, catches episodes that were indexed a little after they were published.

Step 4: triage what you find

Not every mention needs action. A simple triage scheme:

For each important item, someone should listen to the relevant section. Show notes can be misleading, and tone matters. Where a timed transcript exists, find the timestamp of the mention to save listening time.

Size and context signals

To judge how much a mention matters without proprietary data:

• Chart presence: podsearch.org tracks Apple Podcasts charts per country and category on its browse pages.
• Longevity and cadence: hundreds of episodes over years usually indicates a durable audience.
• Show type: an industry show with a small audience may matter more to a B2B client than a large general show.

Modeled audience estimates are available from some vendors; treat them as estimates. podsearch.org does not estimate audience size.

Watch for machine-generated shows

Some feeds publish large volumes of automatically generated episodes on trending names and topics. They can inflate mention counts and occasionally repeat inaccurate claims. podsearch.org labels shows "likely AI-generated" only when its LLM classifier is at least 0.9 confident; coverage is partial and on demand, so absent labels mean "not yet judged". Note suspicious high-volume shows in your reports and weigh them accordingly; exclude_ai=true on the API filters labelled shows out.

Step 5: measure share of voice

For competitive reporting, count episodes mentioning each brand per period, using the same query structure and fields for every brand. Count both episodes and distinct shows; a competitor mentioned on 40 different shows has broader awareness than one mentioned 40 times on a single daily show.

def mentions(q, since_ms, until_ms, pages=10):
    eps, offset = {}, 0
    for _ in range(pages):
        r = requests.get(f"{API}/search", headers=HEAD, timeout=20, params={
            "q": q, "syntax": "dql", "type": "episode", "sort_by_date": 1,
            "published_after": since_ms, "published_before": until_ms, "offset": offset}).json()
        for e in r["results"]:
            eps[e["id"]] = e["podcast"]["id"]
        if r["next_offset"] in (-1, None):
            break
        offset = r["next_offset"]
    return len(eps), len(set(eps.values()))   # episodes, distinct shows

Each plan has a results-per-query limit (30 on Free, 300 on Pro), so for high-volume brands count week by week rather than month by month.

Step 6: report to clients

A useful monthly podcast monitoring report includes:

• Headline numbers: episodes and distinct shows mentioning the client, by field (title, description, transcript), against last month.
• Top appearances: featured episodes with show, date, a one-line summary and a link.
• Sentiment notes: for important items, a short assessment based on listening, not just text.
• Share of voice: client against two to four competitors.
• Issues watch: new coverage of tracked issues.
• Method and caveats: the queries used, fields searched, and the transcript coverage limitation.

Link to the publisher's episode page or audio rather than embedding audio, and quote briefly with attribution.

Monitoring for ad verification

If your client sponsors podcasts, monitoring doubles as ad verification. Many shows list sponsors in show notes, often with promo codes. Search descriptions for the client's brand or codes after each scheduled air date:

desc:"ACME20" OR (desc:"Acme Robotics" AND desc:"brought to you by")

Not every show lists sponsors in notes, so combine this with confirmations and hosting statistics from the shows.

Four monitoring scenarios

The same tools serve different purposes. Here is how the setup changes by scenario.

Product launch. For the two weeks around a launch, track the product name and launch campaign phrases in titles and descriptions, checked every 30 minutes. Add the names of the journalists, creators and analysts you briefed, because their podcast appearances often follow their articles. After launch week, step down to daily checks and fold results into the launch report.

Crisis. When something goes wrong, speed and completeness matter more than precision. Widen queries to include misspellings, nicknames and the issue's own vocabulary (for example a recall, a lawsuit or an outage), check frequently, and have one person listening to every relevant episode from sizeable shows. Record what was claimed, by whom and when, so legal and communications teams work from the same facts.

Executive visibility. For a CEO or expert building a public profile, track their name in episode titles to log every appearance, and in descriptions to catch shows that discuss them. Over a year, the log becomes evidence of reach, and a source of clips and quotes for marketing, with the show's permission.

Regulatory and policy issues. For clients affected by legislation or regulation, track the bill names, agency names and key phrases across news, politics and industry shows. Weekly digests are usually enough; spikes in coverage are often an early sign that an issue is moving from specialist to mainstream audiences.

Extending coverage with your own transcription

If a client needs spoken mentions on shows that publish no transcripts, you can transcribe selected shows yourself.

1. Choose a small watch list. Transcribing everything is impractical; pick the 20 to 100 shows that matter most to the client.
2. Fetch new episodes from each show's RSS feed, whose URL the API returns as rss, or from GET /podcasts/{id}, which lists recent episodes with their audio URLs.
3. Transcribe with a speech recognition model, hosted or open source, and store the text with timestamps.
4. Search your transcripts with the same queries you use for show notes.

Keep this internal: audio and transcripts are the publishers' copyrighted work, so use them for monitoring and analysis, quote briefly, and link to the original episode rather than republishing. Budget for the compute and storage, and check accuracy on names, which speech recognition often misspells; add common misspellings of the client's name to your transcript queries.

For most programs, a blend works best: full-text search across millions of episodes for breadth, and your own transcription on a short watch list for depth.

Building it into your workflow

Monitoring works when it is boring and reliable. A few practices help:

• One owner per client who reviews alerts and maintains queries.
• Quarterly query reviews to add new products, executives and competitors, and to remove noisy terms.
• A shared log of every important mention, keyed by episode ID and show feed URL, so you can report trends over time.
• Clear escalation rules agreed with the client in advance.

Setting expectations in the contract

Podcast monitoring is newer than print and broadcast monitoring, so write its scope into the client agreement. Specify the subjects tracked, the fields searched (titles, show notes, transcripts where available), the check frequency, the escalation rules and the reporting cadence. Name the coverage limitation for spoken mentions without transcripts explicitly. Clients rarely object to an honest limit stated up front; they do object to discovering it after a missed mention.

Keeping noise under control

Every monitoring program drifts toward noise as subjects are added. Review alert volumes monthly: any alert producing more than a few irrelevant results per week needs a tighter query, and any alert that has produced nothing relevant in three months may not be needed at all.

Frequently asked questions

Can I monitor what is said in podcasts, not just show notes?

Where publishers provide transcripts, yes: use content: or deep_search=1. Many shows do not publish transcripts, so spoken-only mentions on those shows are not searchable as text.

How quickly will a new mention appear?

For feeds that send Podping notifications, typically within seconds to minutes of publish. Others are polled adaptively, so active shows are checked often and dormant ones rarely.

How do I reduce false positives?

Quote names, add context terms for ambiguous words, use field prefixes, exclude your own ad language, and review a sample of results whenever you change a query.

Can I get alerts by email?

Run a scheduled script against the API, like the one above, and send results through your email or chat tool.

How do I measure share of voice in podcasts?

Count episodes and distinct shows mentioning each brand per period, with identical queries and fields for every brand, and report both numbers.

Summary

Podcast monitoring closes a real gap in earned-media tracking. Define subjects, write precise queries with phrases, context and field prefixes, schedule date-filtered API checks, triage by importance and listen to what matters, measure share of voice in both episodes and shows, and report with clear caveats about transcript coverage. With fresh full-text search, podcasts stop being a blind spot.