← Blog · 2 November 2026 · Lire en français

Listening statistics inside WordPress: which articles actually get heard

A walk through the Statistics screen of the WeDispatch WordPress plugin: what counts as a listen, how the 'to the end' rate is worked out, why some figures stay hidden, and why a total that looks wrong usually is not.

Adding audio to a WordPress site is the easy part. The harder question comes a month later, usually from an editor or a manager who never touched the plugin settings: is anyone listening? If answering it means logging into another tool, matching article IDs and exporting a spreadsheet, the question tends to go unanswered. That is why the WeDispatch plugin ships its own Statistics screen, inside the plugin menu in your WordPress admin.

This post explains what that screen shows, how each number is produced, and what it deliberately leaves out. Everything below can be checked against the plugin's code and the service code that counts listens.

Why a WordPress screen at all

The WeDispatch dashboard already counts listens. Copying it into WordPress would add nothing. What the service cannot do is name your content the way you name it: it knows an article ID and the title it had when the audio was produced. It does not know your post, its post type, or its Edit link.

So the screen does one extra job, and it is the whole point: it matches the service's counters to the posts on this site. Each row shows the title as it currently reads in WordPress, the post type (post, page or a custom type) and a direct link to the editor. You read "your post, 214 listens, Edit", not an opaque string.

If the plugin is not installed yet, the WordPress page lists exactly what it adds to your site and what it leaves alone. It downloads without an account, and the Statistics screen simply says "No figures without a connection" until a key is entered.

What counts as a listen

A listen is counted when a visitor presses play. Not when the page loads, not when the player scrolls into view. An article read by a thousand people and played by twenty shows twenty.

Counting is anonymous by design. The service stores no IP address, no browser string, no cookie and no listener ID: it increments a counter on the article and nothing else. The trade-off is explicit. You can say how many listens happened, never how many people listened. To keep loops and scripts from inflating the figures, one article accepts at most five events of the same type from the same network address per half hour. A newsroom behind a single office connection gets through; a page reloaded in a loop does not.

"To the end" is stricter than it looks

The To the end column is the share of listens that reached the end of the audio. The player reports milestones at 25, 50, 75 and 100 percent of the duration, each one once per page load. The rate shown is the number of listens that reached 100 percent divided by the number started, rounded and capped at 100.

One rule matters more than the rest: dragging the progress bar does not trigger the milestones you skip over. Someone who presses play, then jumps to the last second to check the length, is not counted as a full listen. Expect this figure to sit below what tools counting "reached the final second" report. That is intended, because it is the only version of the number that tells you whether the audio is really being consumed.

For benchmarks on what a healthy completion rate looks like for short and long pieces, see our guide to the listening metrics that matter.

How the screen is laid out

From top to bottom:

  • The last 30 days: listens over the period, compared with the 30 days before. When the earlier period is empty, the screen says "first period counted" rather than "+100%", since growth from zero means nothing.
  • Since the beginning: total listens and the share heard to the end.
  • Your most listened content: up to 25 rows sorted by audience, each with its listens and completion rate.
  • By byline: the same breakdown per author, shown only when there are at least two bylines to compare.

Two blocks appear only on sites that use the matching feature. The click rate on the subscribe prompt is shown only if you reserve audio for subscribers with the registration wall, and previews (the part of a reserved audio a visitor without access can hear) are counted separately, never blended into full listens. On a site that does not use either, an accurate "0%" would read like a fault.

Three cases where a total looks wrong but is not

Rows you do not recognise

A second table is titled Counted on this key, published elsewhere. It lists audio produced with the same API key from another site, or posts since deleted here. They are shown because they count towards the totals above; hiding them would leave sums that never add up. If you run several sites, give each one its own key: a key tied to a site only sees that site. Our post on WordPress multisite networks covers the setup.

The "Unsigned" row

In the byline table, the last row gathers posts sent without an author: those produced before the plugin started sending bylines, and those whose author was later deleted. It stays visible because the rows must add back up to the total. Each author's rate is computed on that author's own listens and never averaged across posts, since an average of averages gives a post heard three times the same weight as one heard three thousand times.

A number that lags

Figures are cached in WordPress for fifteen minutes. One extra listen changes no decision, whereas re-reading every event on each page view would slow down the admin of a busy site. The Refresh the figures button clears the cache when you want the count right now, and the screen states how long ago the figures were read.

What the screen does not do

It does not compare voices or sections against each other; that view lives in the WeDispatch dashboard, described on the listening analytics page. If you want the numbers in an internal dashboard, the statistics API the plugin itself calls is open to your key and returns the same anonymous counters. The WordPress screen answers one question, in the place where articles get written: which pieces are heard, and how far. For the metrics we refuse to produce, and why, read what to actually measure for blog audio.

Give your articles a voice with WeDispatch

This blog is itself voiced by WeDispatch. Curious how it sounds on your content?

Book a demo

Read next