Thirty Seconds According to Whom?

My Medium Read rate collapsed from 14.8% to 1.2% on a single date. I audited the system, failed to prove why, and the failure turned out to be the answer.

Share
An antique stopwatch on a desk, its hand resting on the thirty-second mark

I noticed a drift in my dashboard a while ago. It wasn't a sudden crash or a glaring error message; it was a subtle shift in the shape of the data—the kind of thing that doesn't trigger an alarm but makes a systems thinker lean in and squint.

For a long time, my Read statistics on Medium had behaved with a certain historical consistency. I knew the general ratios of how many people who clicked on a story actually stayed long enough to be counted as a "Read." Then, the numbers started to move. They didn't just dip; they shifted into a different regime.

It reminded me of an article I wrote previously titled Your Dashboard Is Lying to You. In that piece, I looked at a specific result: 20 Views and 0 Reads. At the time, it was a bit of a joke—a literal example of how a metric can fail to capture the reality of a reader's experience. But when the drift started happening across my broader body of work, the joke felt less like a punchline and more like a diagnostic signal.

I didn't want to assume something was broken, and I didn't want to assume I was being "shadow-banned" or that the platform had arbitrarily decided to stop counting my audience. I wanted to know what the data was actually saying. So, I decided to audit the system.


Auditing the Black Box

To understand a system, you have to look at its inputs and outputs, not just the summary UI. If the dashboard is the "front end," I wanted to see what the "back end" was telling the dashboard.

I began by pulling my own Medium backend statistics using the same GraphQL operations that Medium's own stats interface uses to populate its UI. This was a necessary step to rule out a simple rendering problem—a glitch in the way the numbers were being displayed to me.

The results were clear: the discrepancy was not merely a dashboard rendering problem. Medium's own GraphQL stats responses returned the same underlying counts shown in the interface. The data I was seeing was the data the system was providing.

With that established, I could look at the numbers without the distraction of wondering if my browser was lying to me. I began to map out the timeline of my account's performance to find the point where the "normal" state ended.


The April 23rd Breakpoint

The data revealed a distinct shift. I looked at 81 articles and 1,132 lifetime Views. The results were lopsided, but they were also bifurcated by a specific date.

Before April 23, 2026, my account showed a Read rate of roughly 14.8% (466 Views to 69 Reads). After that date, the rate collapsed to 1.2% (666 Views to 8 Reads).

I wanted to see if this was a "member traffic" issue—the idea that my most loyal readers had simply stopped showing up. I compared the member and non-member splits. Before the breakpoint, I had 22 member Views and 8 member Reads. After the breakpoint, I had 21 member Views and 0 member Reads.

The symmetry is the important part here. The number of member Views remained almost identical (22 vs. 21), but the Reads vanished. The same happened with non-member traffic, which collapsed from 61 Reads out of 444 Views to just 8 Reads out of 645 Views.

To see how extreme this became, I looked at July. In that month, I recorded approximately 309 Views and only 1 Read. Furthermore, among my later stories that managed to get at least 10 Views, 29 out of 35 recorded zero Reads. Those zero-Read stories accumulated 538 Views.

Throughout this period, Medium continued to record other telemetry normally. Views, presentations, membership types, referrers, claps, replies, follows, and earnings all continued to flow in. The system wasn't "down." It was simply reporting a different reality for one specific metric.

An analog stopwatch reading thirty seconds beside a digital timer reading 00:28.4

I Tried to Prove Myself Wrong

When you find a discrepancy like this, the instinct is to find a reason why it's happening. My first instinct was to look for a reason why the data might be "correct" despite looking wrong. I wanted to see if I could find an explanation that didn't involve a systemic change in how Reads were being counted.

I looked for tiny sample sizes, but the numbers were large enough to be meaningful. I looked for a loss of traffic, but the View counts remained steady. I looked for a change in member composition, but as the data showed, the member View count was nearly constant.

I even looked at the traffic sources. This is where the investigation got interesting. My referrer analysis showed that the composition of my traffic did change between the periods.

Before the April 23 breakpoint, approximately 68% of my referrers were "Direct." After the breakpoint, that number jumped to about 88%. Conversely, Search traffic fell from roughly 15% to under 2%.

This is a significant shift. It means that the audience reaching my stories was coming from different places—moving away from search engines and toward direct links. This is a plausible alternative explanation. It's possible that the way people arrive at a story via a direct link versus a search result changes their behavior in a way that affects the "Read" metric.

However, I have to be precise about what this data doesn't tell us. These referrer counts are not session-level data. They don't map one-to-one to View totals, and they are lifetime referrers associated with stories grouped by publication date. They cannot tell us whether the change in acquisition was sufficient to explain a roughly twelvefold collapse in the View-to-Read conversion rate.

I also looked at what other writers were saying. There were contemporaneous reports from some Medium writers describing unusual View/Read behavior or "stuck" stats around that same period. Others, however, continued to report healthy Read ratios. This tells me that while there was discussion of unusual behavior, there was no evidence of a universal, platform-wide Read collapse.

So, where did that leave me? I had ruled out a UI glitch. I had ruled out a simple loss of traffic or a disappearance of my members. I had found a plausible alternative (the traffic mix change), but I couldn't prove it was the primary driver.


What Does the Machine Recognize as Thirty Seconds?

This brings us to the core of the issue, which is the definition of the metric itself.

Medium publicly defines a View as a visitor remaining on a story for at least 5 seconds and a Read as remaining for at least 30 seconds. They also discuss "active reading time," noting that their system attempts to distinguish between a natural pause (like someone thinking about a sentence) and idle behavior (like someone walking away from their screen).

What is not publicly documented is a reproducible implementation. Medium's publicly available definition does not provide enough information to independently reproduce or audit how a session becomes a qualifying Read.

This creates a central engineering question: What does the machine recognize as thirty seconds of reading?

A pocket watch with its case removed, exposing the gear train, beside a gear schematic

Because the implementation is opaque, we are left with a series of questions that we cannot answer independently:

  • Is elapsed time the only factor?
  • What role does page visibility play?
  • What specific activity signals matter?
  • How is "idle" behavior mathematically determined?
  • How does the system distinguish someone who walked away from someone who simply stopped scrolling because they were deeply engaged with a paragraph?
  • What other telemetry participates in the qualification?

We don't have the data to know. And that is the point.

A metric can be legitimate and still be insufficiently auditable to the person depending on it. If a platform tells you that your audience is "reading" your work, but you cannot independently verify the logic the platform uses to reach that conclusion, you are making decisions based on a black box.


The Architecture of Dependency

This investigation changed my internal question. I started by asking, "Why aren't my Reads being counted the way I expect?"

But as I dug into the data and hit the wall of unobservability, the question shifted. It became: "Why am I building my publishing practice around a system I cannot independently understand?"

I realized that I was already doing much of the heavy lifting. I was the one writing the articles. I was the one promoting them through social media. I was the one surfacing them on my own website. Much of the referral traffic was traffic I had generated myself.

Medium provided the hosting, the publishing environment, the analytics, and the monetization. It was a set of tools I was renting. But by using those tools, I was also accepting a set of dependencies. One of those dependencies was the authority I gave to an opaque metric to define the success of my work.

When the measurement question exposed that dependency, it forced me to look at the larger architecture of my publishing system. I had to ask: What am I actually renting here, and what am I giving up in exchange?

The move to Bluedobie Dialogues and our home on Ghost wasn't a reaction to a "broken" platform. It wasn't a "Why I Left Medium" manifesto. It was an architectural response to the realization that I wanted more control over the variables that mattered.

Moving to our own home means ownership of the publication and the reader relationship. It means greater data portability and a greater ability to choose and inspect the measurement tools I depend on. It means that when I look at my stats, I am looking at a system where I can better understand the rules of the game, rather than a system where I have to guess what the machine thinks I mean.

A stopwatch sealed inside a locked glass display case with a keyhole

Thirty Seconds Wasn't Really the Question

The investigation eventually reached the boundary of what the available evidence could establish.

I did not prove that Medium cheated me. I did not prove they deliberately undercounted Reads or changed their code on a specific day in April. I did not prove that they incorrectly classified any particular visitor.

What I did discover was that I could not determine, from the information available, why the relationship between Views and Reads had changed so dramatically.

In systems thinking, the inability to answer a question is often as useful as the answer itself. It identifies a dependency boundary in my own architecture: an important measurement was being produced by a system whose implementation I could not independently inspect.

Instead of endlessly trying to solve an unobservable question inside someone else's system, I chose to reconsider the architecture that gave that question so much authority in the first place.

Eventually, the inability to answer the question became part of the answer. I did not need to prove Medium was wrong. I needed to decide whether I wanted an unanswered and independently unauditable question to retain that much authority inside my publishing system. I was tired of guessing.


About the Author

Melanie Brown is a web developer, systems thinker, and the founder of Bluedobie Developing, LLC. She writes about governed AI, capacity-aware systems, practical web development, and the places where technology collides with actual human life.

She is the creator of Bluedobie Dialogues, where she writes from both sides of that work: the technical decisions behind the systems she builds and the lived experience that shapes why she builds them that way.

The technical writing is what I decided. The years behind it are why.