Five Ways Publisher Audio Projects Fail

Adding audio does not guarantee that anyone will listen. I have supported deployments across more than 30 media companies and seen both sides: projects that found a repeat audience and projects that quietly stopped. The failures usually began before the text-to-speech system was chosen.

1. Converting every story

Short alerts, market tables, and visual explainers are often easier to scan than hear. Converting everything increases production volume while diluting the playback rate.

Start with reporting that can stand without the screen: analysis, interviews, essays, and narrative features. A decade of audio products suggests the same rule—begin with a use case, not a technical capability.

2. Publishing without a quality process

Current TTS systems can sound convincing, but names, acronyms, and long sentences still fail. Listening to every file manually does not scale either. A sustainable process samples ordinary stories and gives extra attention to articles dense with people, companies, or specialist terms.

I learned this while building a voice chat application. Pronunciation dictionaries and pauses took more operational time than expected. PUBVOICE, our product at MediaLeap Inc., prepares an ear-friendly script before generation partly because of that experience.

A publisher building in-house should decide who owns pronunciation rules and sampling before launch. Otherwise quality work becomes an emergency task with no budget.

3. Hiding the player

A small button beneath the article is functionally invisible. Place playback near the headline, label it in words as well as with an icon, and include the duration. On mobile, the control needs a comfortable tap target.

The strongest voice apps shorten the path to sound. Three traits behind well-rated AI voice apps applies that lesson to article players.

4. Loading short audio with ads

My earlier career was in publisher monetization and programmatic advertising. I repeatedly saw the same trade-off: another ad unit can raise immediate revenue while making the product less pleasant and reducing later visits.

Audio is no exception. A fixed rule such as “one ad per session” is still too crude. A short story may need no ad. A long program may support one, depending on placement and audience expectations. Test completion rate and revenue together.

5. Deciding how to measure after launch

Without a pre-launch baseline, a publisher cannot tell whether audio changed behavior. At minimum, track:

• starts as a share of article views
• completion among listeners
• engaged time for sessions with and without playback

Segment results by story type and device. A single site-wide average can hide a useful format inside a large volume of unsuitable stories.

A small pre-launch check

Before shipping, the team should be able to answer five questions:

• Which stories are worth hearing?
• How will pronunciation and pacing be sampled?
• Can a mobile reader find and start playback immediately?
• How will ad load vary with duration?
• What result would justify continuing the test?

What successful audio apps reveal about demand can help define the listening situation. International audio app lessons offers examples of low-friction design.

Some publishers should decide not to add audio. A newsroom built around rapid alerts or interactive graphics may get little value from it. That is a sound product decision, not a failure.

The safest path is smaller: select a few suitable stories, listen on real phones and mobile connections, collect the agreed metrics, then keep only what earns another round.