Does the audio player set cookies? What it actually adds to your site
Before adding an audio player to their articles, most site owners want to know whether they are inheriting another cookie, a tracker, or a heavier consent banner. Here is what the player really stores, and what it does not.
The question always lands at the same moment. You are ready to add audio to your articles, you like the player, and someone on the team asks what it means for data. An audio player is a piece of code that runs on your visitors' machines, so the worry is fair: plenty of free widgets pay for themselves by dropping a tracker, and the site that installs one inherits a third-party cookie, a longer consent banner, and another entry in its records. This article sets out exactly what the WeDispatch player puts on a visitor's page, with no rounding up, because this is precisely the kind of claim that is worthless unless you can check it.
What the player adds to your page
The player mounts inside an isolated frame served from our own domain, placed where you asked for it in the article. In practice, the snippet you add drops a player into the page and fetches the right audio; it sets no cookie on your domain, and it calls no advertising tracker and no third-party analytics script. There is no ad banner behind it to fund, so nothing is reported back to an ad network. The player does one thing, play audio, and its code says so: it fetches the audio that matches the page, and that is all.
Measuring listens without identifying the listener
This is the part that surprises people most, because most measurement tools work the other way around. To know how many listens an article received, WeDispatch does not place an identifier on the listener. Measurement is done by milestones: the player reports that a listen started, that it reached a quarter, half, the end, and it is these threshold crossings that are counted, not people. There is no visitor cookie, no browser fingerprint, and no listener profile to build for the statistics to exist. It is a design choice, and it has a trade-off we own: you will know how many articles are listened to and how far, you will not know who listened. To defend audio at budget time, that is more than enough; to reconstruct a named reader's journey, it was never built for that, and that is deliberate.
What the player remembers on the listener's side
The player remembers two things from one listen to the next: the position reached in the article, and the chosen playback speed. Both settings serve the listener's comfort, who picks up where they left off when they reopen the page, and who does not have to reset their preferred speed on every article. These settings live on the visitor's device, in their browser's local storage, not in an account and not on our servers. Nothing ties them to a person, nothing carries them from one site to another, and nothing feeds an advertising profile. It is a listening convenience, no different from the volume your browser remembers for a video, not a tracking device.
Sharing a passage follows the same logic. When a listener shares an article from a precise moment, the timestamp travels in the link's address, not in a cookie: the shared position is written into the URL, and it is the URL that puts the cursor back when the page opens.
Do you need a consent banner?
This is the real question behind all the others, and the honest answer starts with a caveat: we are not your legal counsel, and the final decision belongs to you and your data protection officer. What we can state is what the player does technically. It sets no advertising cookie, installs no cross-site identifier, and adds no third-party tracker to your page. The only thing it keeps is the local comfort memory described above, strictly functional and confined to the listener's browser. In most frameworks, that kind of functional storage does not trigger the obligation of a prior consent banner, but how you mention it in your own policy is a matter for your site. When you install the module on your site, that is the right moment to check this once, calmly, rather than discovering it after the fact. For reference, our own cookie policy draws the same line between what is functional and what is not.
A deliberate choice, not a missing feature
Measuring by milestones rather than by people, keeping settings on the device rather than in a profile, carrying a position in a URL rather than in a cookie: these are three decisions pulling in the same direction, and they hold together. They cost something, since they deny you the named tracking other tools advertise. But they spare you exactly what you feared when you opened this article: one more cookie to declare, a tracker to watch, and a banner that grows heavier. The player adds a voice to your articles, not a line to your records.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo