unzoi

Solutions / Media monitoring

Media monitoring

For communications and pr teams.

The problem

Coverage arrives faster than anyone can read it, and the volume is mostly repetition. The failure is rarely missing a story — it is that the channel fills with duplicates until people stop opening it, and then a real story lands in a feed nobody reads.

How does a news API support media monitoring?

Collapse coverage into stories before it reaches anyone. One event arrives once, carrying the publishers that ran it, so the volume in the channel reflects how many things happened rather than how widely one thing was syndicated.

What the workflow looks like

  1. Query on a schedule, keeping the last-seen timestamp so each poll returns only what is new, or save the query as a watch and the index runs that loop for you. When a story crosses a threshold, fetch it with get_story: its counts are over the whole story, not the poll window.
  2. Escalate on the shape of coverage: one outlet is a mention, five unrelated outlets within an hour is a story.
  3. Route by language so coverage reaches whoever reads it.
  4. Review the acted-on rate monthly — precision decays long before coverage does.

What will a news API not do for media monitoring?

This covers news publishers. It does not cover social platforms, broadcast transcripts, podcasts or forums, and for many communications teams those are half the picture. If social listening is the core requirement, this is a component rather than the system.

The mistake teams make here

The characteristic mistake is measuring the channel by what it sent rather than by what was read. Delivery volume, coverage count and reach are all available, all rise when syndication rises, and all look like success on a slide. Meanwhile the working channel fills with near-duplicates until the team stops opening it, and nothing in any dashboard records that — a muted channel reports the same delivery numbers as a read one. The second mistake follows from the first: when the channel is obviously too noisy, teams narrow the keyword list, which reduces volume by cutting recall rather than by cutting repetition. The repetition was the problem, and collapsing coverage into events addresses it without giving up anything you wanted to see.

How would you know media monitoring is working?

The metric that matters is the acted-on rate: of the items that reached a human, how many produced a response, a briefing note or a decision not to respond. Volume delivered is not a measure of anything. Sample a week of output quarterly and read it as a stranger would — a channel that has quietly become unreadable looks healthy in every dashboard, because the dashboards count what was sent rather than what was opened.

What to build in the first week

Run it manually before automating anything. Pick the five names you would genuinely want to hear about, query them once a day by hand for a week, and keep a note of every item you would have escalated and every item you would have deleted unread. At the end you will know two things that no amount of design discussion produces: roughly how many items a day this actually generates, and what the escalation rule should be. Both are usually different from what people expect, and building the pipeline first means discovering them after the routing, the alerting and the reporting have already been shaped around the wrong assumptions.

What are the alternatives for media monitoring?

Full-service monitoring suites bundle social, broadcast and print clippings with an analyst layer, and if you need a named human to call about a crisis at 2am, buy one of those. This is the component underneath: cheaper, faster to integrate, and yours to shape. Teams routinely run both — the suite for reporting to the board, an API feed for the working channel that has to stay clean.

The queries that implement it

Each recipe makes the case for its parameters. Response fields, failure modes and scheduling cost are in the technical documentation.