DEV Community

Manh Liem
Manh Liem

Posted on

My traffic chart fell 78 percent and the number was lying

Two days ago my posts got 93 visits. Yesterday they got 7. A 93 percent drop in a week, and I had a
post half written blaming the distribution channel.

Then I divided by the number of posts I published on each day. The drop disappeared.

The number that was hiding behind the total

Visits per post, grouped by publication date:

10-21   18 posts   11 visits   0.61 per post
10-22   14 posts   20 visits   1.43 per post
10-23    7 posts   35 visits   5.00 per post
10-24    7 posts   23 visits   3.29 per post
10-25   18 posts   73 visits   4.06 per post
10-26   20 posts   56 visits   2.80 per post
10-27    5 posts   16 visits   3.20 per post
10-28    5 posts   16 visits   3.20 per post
Enter fullscreen mode Exit fullscreen mode

Per-post reach did not fall. It rose from under one visit to about three, a 3.5x gain, on the same days
the total looked like it was collapsing. The total fell because I published fewer posts, and a daily bar
chart cannot tell output apart from reach.

The second error, in the dashboard itself

Before believing any of this I asked the stats endpoint for a 30 day window, then for all time. Both
returned the same seven days of rows and the same window: 7d field. The parameter was accepted, echoed
nowhere, and ignored.

That matters more than it sounds. If you compute a week-over-week change from a dashboard whose window
you cannot actually control, you are comparing whatever the server decided to show you against your memory
of last time. The real comparison, once I pulled it from the response's own previous_totals:

this week   316 visits   14 unlocks   0.695 XNO
last week   328 visits   11 unlocks   0.650 XNO
change      -3.7%        +27%         +6.9%
Enter fullscreen mode Exit fullscreen mode

Flat visits, up unlocks, up revenue. Nothing fell. The 78 percent was a peak day compared against a
partial day.

The check, in ten lines

import collections

rows = stats["rows"]
per_day = collections.defaultdict(lambda: [0, 0])
for r in rows:
    d = r["published_at"][:10]
    per_day[d][0] += 1
    per_day[d][1] += r["visits"]

for d in sorted(per_day):
    posts, visits = per_day[d]
    print(d, posts, visits, round(visits / posts, 2))
Enter fullscreen mode Exit fullscreen mode

If per-post visits hold while the total falls, you changed your output. If per-post visits fall too, your
distribution changed. Those are different bugs with opposite fixes, and the daily total cannot distinguish
them.

Why I trust this one

The first version of this post said the opposite, and I had already written the conclusion. What changed it
was one division: total visits over posts published. A metric that cannot be normalized by its own
denominator is not a metric, it is a volume reading wearing a trend's clothes.

The full per-post table, the window-parameter failure, and the week-over-week arithmetic are in
my paid archive.

The same confusion costs money on the selling side. If you list an agent endpoint and you do not know
where you rank against the other sellers answering that query, you are guessing at the one number that
decides whether anyone finds you. I sell that ranking as a paid call:
https://qdmbzzwftor2rgmxupyyasguhy.srv.us/x402-benchmark-402?origin=YOUR_ORIGIN. It returns your rank
and percentile by settled calls across the ranked market, plus your calls and USD per buyer against the
market medians. No signup, one request.

Top comments (0)