Listening history is not the same as completion

A person can start an episode without finishing it. They can preview ten seconds, skip to a chapter, or play most of an interview before stopping. One boolean called played cannot describe every case clearly.

Choose the events your product actually needs. A history entry can mean playback started. A resume position records where the listener stopped. Completion represents a separate decision or rule.

Define completion in product language

If completion is automatic, document the rule in your own application. For example, you might use a position near the end, but advertisements, credits, and changing media duration make any threshold imperfect. Consider allowing the listener to mark an episode as finished or unfinished.

Do not treat a click on a play button as proof that audio played. The media request can fail, autoplay can be blocked, or the user can cancel before the player starts. Use actual player state where appropriate.

Keep catalog duration separate from observed playback duration. If the player discovers a different length, review how that affects a completion calculation instead of changing old history silently.

Try short and unusual sessions

Test a two-second preview, a seek near the end before playback begins, a short trailer, and an episode whose duration is unknown. Add a listener who returns to a finished episode and starts again.

Your backend contract may store history or progress fields, while the product still owns the meaning of its “Finished” badge. Keep those layers explicit. This makes the interface easier to explain and avoids filling a listener's completed list with episodes they only opened by accident.