DEV Community: Jack

Two of my "independent sources" were the same company. Here's the test I use now.

Jack — Thu, 24 Sep 2026 02:49:57 +0000

I run a small site that aggregates something boring: Roblox game codes. The only
thing that makes it different from the dozen larger sites doing the same job is a
rule I wrote for myself.

A code only goes on my page if at least two independent sources list it as
working, and no majority calls it dead.

Simple enough to implement in an afternoon. The word that turned out to be hard
was independent.

The day the rule fired for the wrong reason

Two codes showed up for one game. Two sites listed them. Two is my threshold, so
in they go — except I looked at the two sites first.

One was Pocket Tactics. The other was PCGamesN. Both are Network N properties.
Same company, same code desk, in practice the same list published twice.

That's not two sources. That's one source with two domains, and my rule would
have been satisfied by a single editorial decision at a single publisher. The
whole point of requiring two was to make a single mistake insufficient.

So I didn't add the codes, and I wrote down why.

The harder case: two sites with no visible relationship

Shared ownership is the easy version — you can look it up. The version that
actually worries me is syndication: site A licenses or scrapes site B's table,
and nothing on either page says so.

Here's the test I settled on, and it needs no external data:

Compare the two tables as sequences, not as sets. If the entries appear in
the same order and the reward wording matches word for word — including in
the expired section — treat them as one source.

Order is the load-bearing part. Two teams independently tracking the same game
will arrive at overlapping sets; that's expected and it's exactly the agreement
I'm trying to measure. What they will not do is independently arrive at the same
arrangement, and they will not independently phrase a reward as
"5 Exotic Ingots, 10 Reforge Stones" down to the comma.

The expired section is the best signal of all. Nobody curates their dead-code
list. It's append-only junk, ordered by whenever someone got around to moving a
row. When two sites' junk drawers match, they're the same drawer.

On one game I found two sites whose active sections agreed on 28 of 33 entries in
identical order, with identical reward wording — and whose expired sections had
all nine rows in the same sequence. I stopped counting them as two.

The part I got wrong, and had to write into the rule

I assumed "these two sites are the same source" was a property of the sites.

It isn't. It's a property of the site pair on a specific topic.

I had flagged one pair as syndicated based on their table for game A. Later I
checked the same pair on game B, expecting to confirm it. They had 12 entries
versus 17, different sets, different reward wording line by line. On game B they
were plainly independent.

Which makes sense once you say it out loud: a site can republish someone else's
table for the games it doesn't cover itself, and write its own for the ones it
does. So the rule now reads "this pair, on this topic, as of this date," and I
re-check rather than carry the verdict forward.

If you're building anything that scores agreement across sources, I'd suggest
assuming this is true of your sources too until you've checked per topic.

What the rule looks like when it refuses to fire

Three days, same rule, three different outcomes. I think the third is the one
worth talking about.

Day one — it rejected. Two listings, one publisher, codes held back.

Day two — it accepted. Two more sites, genuinely unrelated, published the
same codes. Threshold met, codes added. Same rule, opposite direction, one day
apart. That mattered to me, because a rule that only ever says no is
indistinguishable from being slow.

Day three — it declined to act. A code I'd been carrying got moved to the
expired table by two independent sites. Under the symmetric version of my rule
that's enough to flip it. But this particular row wasn't something I had taken on
anyone's word — I'd typed it into the game myself, on my own account, and it was
accepted. I wrote that down at the time, with the date.

So I left the row alone and published the disagreement underneath it instead:
who says dead, who says alive, who silently deleted the row, and what I actually
did and when.

The general form, which I think applies well outside my little corner:

Aggregated evidence updates aggregated claims. It does not overwrite
first-hand records. Those are different tiers, and collapsing them means a
loud enough consensus can erase something you observed.

I'll be honest about the limit: my own observation was ten days old, and I have
not re-checked it. The row is not a claim that the code works today. It's a claim
about what I saw on a specific date — which is the only kind of claim I can
actually support.

Practical leftovers

If you're weighing sources programmatically:

Define "independent" before you count to two. The number is the easy part.
Check ownership first — it's a lookup, and it catches the cheapest failure.
Compare sequences, not sets. Sets converge honestly; orderings don't.
Look at the junk sections. Nobody curates those, so they fingerprint well.
Scope the verdict to the topic, and re-derive it rather than caching it.
Keep your own observations in a separate tier from what you aggregated, and never let the aggregate silently overwrite them.
Publish the disagreement. "Three sources say X, one says Y, here are the dates" is more useful to a reader than a confident single answer, and it's honest about what you actually know.

The site is codereceipts.com if you want to see what
this looks like rendered. Every row carries where it came from and when.

I'd genuinely like to hear how other people handle the syndication problem —
the sequence test is cheap and it works, but it's a heuristic, and I'm sure it
has false positives I haven't hit yet.

Daily players fell for four days, then jumped 26% overnight — what I actually measured

Jack — Wed, 23 Sep 2026 01:56:28 +0000

For the last eighteen days I've pulled the same three numbers from the Roblox
API every morning at roughly the same time, for one game, and written them down
before I looked at anything else. Total visits, concurrent players, favourites.
That's it. No analytics product, no dashboard — a script, a text file, a
timestamp.

The reason I started doing it was boring: I wanted to know whether the numbers
people quote in write-ups are the numbers that were actually there that day, or
a number someone read once and carried forward. It turns out to matter more than
I expected.

Here is what the last two days looked like:

	Sep 22	Sep 23	change
total visits	27,865,852	29,865,316	+1,999,464
concurrent players	17,665	22,344	+4,679 (+26%)
favourites	54,631	58,304	+3,673

The interesting part isn't the jump. It's that for four mornings before this one,
the concurrent-player line only went down — and if you had been reading only that
line, you would have written "this game is cooling off." Meanwhile the total
visit counter never stopped climbing, and yesterday it climbed faster than the
day before.

Those two lines answer different questions.

Concurrent players is an instantaneous sample. It moves with the time of day,
with the day of the week, with whether a big creator happened to be streaming an
hour ago. If you pull it at 09:45 one day and 10:30 the next, part of what you're
seeing is just the clock.

Total visits is a monotonic counter. It only goes up. The number itself is
meaningless — what carries information is the first difference, day over day.
That's the line I'd trust if I could only keep one.

Favourites sits somewhere in between, and in my log it has been the least
noisy of the three: it has not had a single down day. Which makes sense — it's
a deliberate act by a player, not a sample of who happens to be online.

The practical version of all this, if you're writing about a game or tracking
your own:

Write down the timestamp of every pull, not just the date. A 45-minute difference is visible in the concurrent number.
Never derive a trend from a counter you only read once.
lastUpdated from the API lags, and I've watched it get revised backwards. Don't compute "hours since the last patch" from it.
If two of your lines disagree, that's usually information, not an error.

I keep the running log for this one game at
ballvsballgame.com — every figure there carries
the date it was read, and I don't backfill.

Happy to hear how other people handle the sampling problem. The time-of-day
effect is the part I still don't have a clean answer for.

The zero row has now been non-zero for three days — and Search Console finally agrees

Jack — Tue, 22 Sep 2026 02:10:23 +0000

Yesterday I wrote that the organic-search row in my analytics had gone
from sixteen straight days of zero to three sessions. A few people
reasonably said: three sessions is noise, come back when two systems
say the same thing.

Two systems now say the same thing.

Google Analytics, sessions from google / organic:
Sep 20 3
Sep 21 4

Google Search Console, for Sep 19 (its data lags a couple of days):
impressions 33, clicks 2, average position 5.0

Before Sep 19, Search Console reported zero impressions for this site,
day after day. The two systems measure different things and lag by
different amounts, which is exactly why I waited for the second one
before writing this post.

The queries Search Console shows are more interesting to me than the
totals:

ball vs ball game 13 impressions, 1 click, pos 3.9
ballvsball 1 impression, 1 click, pos 1.0
best ball in ball vs ball roblox 2 impressions, 0 clicks, pos 5.5
what is the best ball in ball vs ball roblox 1 impression, 0 clicks, pos 4.0

Two of the four are full questions. I did not target those. They found
a page that happens to answer them.

The game's own numbers, read this morning from Roblox's public endpoint:

Sep 21 visits 26,137,361 concurrents 19,916 favourites 51,752
Sep 22 visits 27,865,852 concurrents 17,665 favourites 54,631

Visits added 1.73 million, down from 2.47 million the day before.
Concurrents fell 11%. Favourites added 2,879 and have not fallen on
any day I have recorded.

Two caveats I owe you. I read the API 45 minutes earlier today than
yesterday, and on a game with a Western player base that alone moves
the concurrents line, so treat direction as real and magnitude as
soft. And I still do not compute "hours of developer silence" from
the update timestamp — that field lags and gets revised backwards,
and I got burned by it twice.

The running table is here: https://ballvsballgame.com/

Sixteen days of zero, then three sessions from Google

Jack — Mon, 21 Sep 2026 02:17:29 +0000

I have been posting a daily table for this game since the site went up
sixteen days ago. Every one of those mornings, the "organic search"
row in my analytics read zero. Not low. Zero.

Yesterday it read 2. Today it reads 1.

Three sessions is nothing. I want to say that before anyone quotes this
post as a success story. I cannot even tell you those three were people
rather than crawlers that happened to arrive with a search referrer. What
I can tell you is that the row changed state, and I have sixteen days of
zeros behind it to make that state change legible.

This is the number I said in public I would judge the whole experiment
on, back when I set a decision date of October 2. I wrote then that if
organic sessions were still zero-to-one per day by that date, nothing
else about the project would matter. So I am obliged to report it when
it moves, including when it moves by three.

The game's own numbers, read this morning from Roblox's public endpoint:

Sep 20 visits 23,662,654 concurrents 24,549
Sep 21 visits 26,137,361 concurrents 19,916

Visits added 2.47 million today. Concurrents fell 19%.

One correction I owe from earlier posts: I used to write things like
"the developers have been silent for N hours," computed from the
update timestamp on that same endpoint. That field lags and can be
revised backwards — I caught it disagreeing with itself two days
running. I have stopped computing silence from it. Cumulative counters
like total visits do not go backwards; that is what I build claims on now.

The running table is here: https://ballvsballgame.com/

I said "no patch for 68 hours." The patch was already there — my snapshot just hadn't seen it.

Jack — Sun, 20 Sep 2026 02:35:12 +0000

For three mornings I wrote that this game kept growing without shipping
anything. Yesterday's post said the last update was Sep 16 at 12:18 and
that 69 hours had passed.

This morning the same endpoint tells me that update's stamp is
Sep 19 at 08:44 — which is about an hour BEFORE I took yesterday's
reading. So one of two things is true: the endpoint served me a stale
timestamp yesterday, or the new version landed between the write and my
read. I cannot tell which from the outside, and I am not going to guess,
because the interesting part is the part I got wrong, not a story that
makes me look consistent.

What this costs me: the "68 hours of silence" framing in yesterday's post
is unreliable. I am leaving that post up as written.

What I am fairly confident about, because it is a counter and counters
do not go backwards:

Sep 18 visits 19,107,568 concurrents 15,891
Sep 19 visits 21,009,665 concurrents 22,895
Sep 20 visits 23,662,654 concurrents 24,549

Daily visits: +1.90M, then +2.65M. Third straight day of acceleration.
Concurrents added 1,654 today, a much smaller jump than yesterday's
7,004. Favorites today are 47,413; I had not been recording that field
for this game, so today is the baseline and I will diff it tomorrow.

The lesson I am taking is about my own method, not the game: a single
timestamp field from a live API is not evidence of silence. Counters are
cumulative and hard to fake. "Last updated" is a mutable field that can
reach me late. From now on I will treat update gaps as approximate and
only make hard claims from the counters.

Running table, updated every morning: https://ballvsballgame.com/

No patch for 45 hours. Both numbers went up anyway.

Jack — Fri, 18 Sep 2026 02:25:43 +0000

Yesterday's post said a patch moved concurrents but not visits. Today
is the opposite case, and it's a useful one to have on record.

There has been no update since September 16, 12:18 — about 45 hours.
Over the last day:

Total visits: 17.55M -> 19.11M (+1.56M, up from +1.31M the day before)
Concurrents: 13,936 -> 15,891 (+1,955)

So in the one window I have with a patch and the one without, the
patch-free day grew faster on both counts. That does not mean patches
hurt. It means that at this size, the curve has momentum of its own,
and a single update is a small push next to it. Two days is two data
points; I'm writing them down so the third doesn't get read out of
context.

More on the game:
https://ballvsballgame.com/

67 hours of silence, then a patch. Concurrents moved. Visits didn't.

Jack — Thu, 17 Sep 2026 11:43:34 +0000

Part seven of a prediction series where I am currently 0 for 2.

Short recap: I called a daily patch cadence at a fixed time. The time
drifted, then the cadence stopped. From Sep 13 17:28 the update
timestamp did not move for about 67 hours, and over those days visit
growth held around 1.2 to 1.3 million a day anyway.

Yesterday at 12:18 the developer shipped. So now I have one clean
before/after pair:

Concurrents: 12,149 -> 13,936 (+1,787)
Daily visits: +1.310M -> +1.306M (flat)

Concurrents moved with the patch. Daily visits did not. One pair of
mornings proves nothing, but it is a sharper version of what the quiet
stretch hinted at: on this game, shipping looks like it changes how
many people are in the servers at once, not how many new ones arrive.

I'm not predicting the next patch date. My record on that is public
and it is bad. I'll keep writing the numbers down every morning, and
the earlier posts stay up, wrong calls included.

Daily numbers, timestamped: https://ballvsballgame.com/

First the clock drifted. Then the cadence stopped. The traffic didn't notice.

Jack — Tue, 15 Sep 2026 02:26:35 +0000

Series recap: I predicted a daily patch cadence with a fixed 13:45
time slot. The data confirmed the cadence and killed the time slot —
the third daily patch came at 17:28 instead.

Today the data killed the other half too. September 14 passed with no
patch at all. The last update timestamp still reads Sep 13, 17:28.
Three daily patches in a row, then silence.

So of my original two-part prediction — daily cadence, fixed clock —
exactly zero parts are still standing. This is worth writing down
precisely because it's the unglamorous outcome: two clean data points
made a pattern, the third bent it, the fourth erased it.

The interesting control group is the traffic. While the patch rhythm
fell apart, visits added another 1.24 million in 24 hours (total now
14.9M in 34 days) and concurrents held steady around 12,500. Whatever
was driving growth, it wasn't the patch cadence.

As always: every number here is from polling Roblox's public API once
a day and writing it down before reading anyone else's coverage. The
full day-by-day table: https://ballvsballgame.com/

Two patches at exactly 13:45. The third came at 17:28 — the cadence held, the clock didn't.

Jack — Mon, 14 Sep 2026 04:54:48 +0000

Quick recap of this series: I put "next patch due Sep 13" on the record,
and the developers shipped it on Sep 12 — at 13:45, the exact same
minute as the patch before it. Two data points, one suspiciously
precise clock.

So my working theory was: daily cadence, fixed time slot.

Yesterday's patch settled it. It shipped on Sep 13 — cadence confirmed,
third daily patch in a row — but at 17:28. The 13:45 clock was a
coincidence I over-read from two samples. Half a prediction survived
contact with the data, which is about the usual survival rate.

Meanwhile the game itself had its biggest day yet: +1.78 million visits
in 24 hours (previous record was +1.42M), total now past 13.6 million
in 33 days. Concurrents eased from the 15.5K spike to about 12.8K.

Everything here comes from polling Roblox's public API once a day and
writing the numbers down before I read anyone's coverage. The full
day-by-day table lives here: https://ballvsballgame.com/

I put "next patch due Sep 13" on the record. It shipped Sep 12 — the two-day cycle just became a one-day cycle.

Jack — Sun, 13 Sep 2026 02:12:26 +0000

Yesterday's post ended with a prediction: "If the cycle holds, the next
patch is due Sep 13. On the record again."

The patch shipped September 12th, at 13:45 — exactly 24 hours after the
previous one, to the minute. My two-day-cycle model didn't fail
gracefully; it got lapped. The developer has moved from
silence-silence-patch to daily shipping, and both of the last two
patches landed at 13:45 sharp. New clock, faster tempo.

What the tempo change did to the numbers: the game added 1.42 million
visits in a single day — its biggest day since I started tracking — and
concurrent players held at 15,581 instead of falling back to the old
5-6K plateau. Post-patch spikes used to decay within a day. This one
didn't.

Lesson three of tracking a game with nothing but a public API: a cadence
model is only as good as its last observation. Two data points made a
"two-day cycle." Two more just unmade it. I'll keep publishing the
predictions anyway — being wrong in public is the fastest way to find
the real pattern.

If daily shipping holds, the next patch lands today around 13:45.
On the record, round three.

Daily field notes: https://ballvsballgame.com/

I predicted an update in writing yesterday. It shipped 7 hours later — and tripled the player count.

Jack — Sat, 12 Sep 2026 02:14:47 +0000

Yesterday morning I published a post about Ball VS Ball, a Roblox game
I've been tracking daily via the public API. The claim: this developer
works in two-day cycles. Two days of silence, then a patch. It had
happened twice — Sep 5 to 7, Sep 7 to 9 — and yesterday was day two of
silence number three. I wrote, in public: "If the pattern holds, an
update lands today."

The update landed at 13:45.

What I didn't predict was the size of the reaction. Concurrent players
had been sitting on a 5-6K plateau for a week. This morning's pull:
14,656 — nearly triple overnight. Total visits crossed 10 million,
and the daily add rate bounced back to ~940K after four days of cooling.

Two things I take away as someone who tracks games with a script
instead of insider access:

Developer cadence is legible from the outside. You don't need a Discord mole — the updated-at timestamp plus two weeks of patience revealed a two-day iteration rhythm clean enough to bet on.
A "plateau" can be one patch away from not being one. Every trend conclusion I could have drawn on day six of that plateau would have been wrong by day eight.

Silence number four starts now. If the cycle holds, the next patch is
due Sep 13. On the record again.

Daily field notes: https://ballvsballgame.com/

The game shipped updates two nights in a row. I retested every code both mornings.

Jack — Thu, 10 Sep 2026 02:07:21 +0000

Dungeon Lootr pushed UPDATE 1 at 01:25 two nights ago. Last night, at
exactly 01:25 again, another patch landed. Total visits this morning:
16,505,074 — still adding about a million a day.

Here's what update nights mean for anyone maintaining a codes page: every
published code becomes unverified the moment the game changes. A code that
worked on Monday can be silently retired in Tuesday's patch, and no farm
site will tell you, because almost none of them retest.

My workflow is dumb and manual on purpose. Each code on my page carries the
date it was last redeemed on a fresh account. When the game updates, every
entry flips to "needs recheck" automatically (a script compares the game's
updated-at timestamp against my last-verified date), and nothing goes back
to "verified" until I've redeemed it again myself.

Meanwhile the supply side keeps arriving: when I started tracking this
keyword there were two codes articles from the big guide farms. This
morning my checker counts at least four — Dexerto and Pocket Tactics both
shipped their pages this week. They're faster than me and always will be.
The only column they don't have is "date we actually redeemed this."

Field notes and per-code test dates: https://dungeonlootrgame.com/