DEV Community: dalin zhou (钱先生)

Weekends Are Not Dead. My Data Says They're 10% Better.

dalin zhou (钱先生) — Tue, 27 Oct 2026 12:45:37 +0000

Every "when to post" article gives you a chart. Almost none of them explain why two charts of the same product can contradict each other.

I have two of those charts. They contradict each other. That turned out to be the most useful thing I learned.

This is 152 days of production data from PicKu, a URL shortener I run: 28,230 clicks from 11,472 unique IPs, May 25 to October 23, 2026. Every number below comes from my own database. Including the one where I was wrong.

The contradiction

An earlier analysis I published looked at the last ten days of traffic and concluded:

"Weekend volume collapses to 40–60% of weekday volume."

A later analysis over 152 days concluded:

"Saturday is the single biggest day of the week (4,614 clicks, 16.3%). Weekend days average about 10% more clicks than weekdays."

Both came from the same database. Both were computed correctly. Only one is useful.

Day type	Share of weekly clicks	Per-day share
Weekdays (5 days)	69.5%	13.9%
Weekend (2 days)	30.5%	15.3%

If you divide weekend clicks by weekday clicks you get 0.44, so "weekends get 44% of weekday volume" is arithmetically true. But that number is a ratio of 2 days to 5 days, not a statement about demand. Per day, weekends win by about 10%.

I published the 44% version and it was quietly wrong in the way that matters: it told readers "don't bother on weekends," and the data says the opposite.

Why the 10-day window lied

The 10-day sample was October 12–21. In it, Saturday logged 97 clicks and Sunday 169, against a weekday average of 266. Clear collapse.

Had I widened the window by one week, the conclusion would have flipped. Saturday is the strongest day in the full dataset, and it happened to be a weak Saturday in that particular ten-day slice.

The mechanism is boring and universal: weekly seasonality has a seven-day period. A window shorter than a few weeks cannot distinguish "the weekend is slow" from "that weekend was slow." Two weekends is not a sample. It is an anecdote with decimals.

The rule I now apply to any time-series claim, mine included: if the pattern has a weekly cycle, look at four or more full cycles before naming a pattern. That is 28 days minimum. Anything shorter is a preview, not a finding.

The peak is 14:00 UTC, but 02:00 UTC is why you should care

The busiest hour is 14:00 UTC, with 1,707 clicks (6.0%) — 2.7 times the quietest hour, 21:00, at 621 clicks (2.2%).

The interesting one is second place. 02:00 UTC posts 1,533 clicks (5.4%), clearly above its neighbours at 01:00 and 03:00. That is 9–10 PM US Eastern and 10 AM in Beijing.

A single peak means one audience. A secondary peak twelve hours away means two audiences that never overlap, and you have been optimising for the more visible one.

This is an inference, not a measurement — I have not segmented clicks by region inside each hour — but the arithmetic is hard to explain any other way. The takeaway costs nothing to test: if you have a global audience and you only ever post at your local morning, you are talking to one of your two audiences.

Is it all one viral link? No.

The objection to any timing claim from one product is survivorship: maybe one popular link was posted at a lucky hour and dragged the whole distribution with it.

Most-clicked single link: 3,712 clicks, 13.1% of all clicks
Top five links combined: ~30%
Remaining 801 links: ~70%

No single link dominates. Timing patterns computed across 806 links are not one person's lucky afternoon.

What I did not do

Three disclosures that most analytics posts skip:

I did not filter bots. The 28,230 clicks include automated traffic. With 11,472 unique IPs that is about 2.5 clicks per IP; link scanners mostly get 404s rather than recorded clicks. I believe bots are too few to reshape the hourly curve, but I cannot give you the exact ratio, so treat the curve as approximate.
Everything is UTC. Convert before acting. 14:00 UTC is 10 PM in Beijing, which is a strange time to be told to post.
This is my audience, not the internet. A B2B SaaS and a short-link tool have different rhythms. What travels here is the method, not the numbers.

What I actually changed

Post between 12:00–14:00 UTC if I can pick one slot: 8–10 AM US Eastern, 1–3 PM Central Europe.
Stop treating Saturday as dead time. In my data it is the largest single day. Weekend sharing costs nothing and it was the cheapest correction in this whole exercise.
Do not schedule anything from a 10-day window. Four full weeks or it is not a finding.
Look for a second peak. If your hourly curve has two humps, you have two audiences and one of them has been ignored.

The uncomfortable part is not the numbers. It is that the wrong conclusion was also mine, published, and looked completely reasonable at the time. Anyone analysing their own traffic will produce that same error, because ten days of data is enough to feel confident.

It is not enough to be right.

Period: 2026-05-25 to 2026-10-23. 28,230 clicks, 806 short links, 11,472 unique IPs, all times UTC. Tool: PicKu, a free URL shortener with click analytics. The full write-up, including the numbers behind every claim here, is at picku.org/blog/when-people-actually-click.

Part 2 of a series on short-link data. Part 1 asked what the numbers cannot tell you — half the clicks had no referrer, and 45% came from my own domains: 27,013 Short-Link Clicks, and 45% Came From Me.

27,013 Short-Link Clicks, and 45% Came From Me

dalin zhou (钱先生) — Tue, 27 Oct 2026 12:42:09 +0000

Most articles about short-link analytics are invented. They show you a clean pie chart, tell you "78% of users are on mobile," you redesign your landing page around it, and nothing changes.

This one is different. It is the raw output of five months of production traffic from PicKu, a URL shortener I run: 27,013 clicks across 806 short links, from 120 countries, May 25 to October 21, 2026. Every number below comes from real records, including the parts that make me look bad.

Start with the number nobody puts in a blog post

Of those 27,013 clicks, 13,745 (50.9%) arrived with no referrer at all. Another 12,220 (45.2%) came from three domains I own.

Strip my own traffic out, and the genuinely external organic traffic is 714 clicks — 2.6% of the total.

I could have left that out. Most write-ups would. But here is why it matters:

If you read your own referrer report as "where my users come from," your promotion channels will systematically mislead you. You will conclude your users come from your other site, then spend double on that site, closing a self-congratulatory loop. I nearly did exactly that.

The actionable rule: before you optimise acquisition, subtract self-referred traffic. What remains is your real acquisition surface. Mine was 2.6%. Yours might be 40%. You cannot know until you subtract.

"Direct" is over half. That is not a bug.

Every short-link system shows a fat "direct" slice. This is not broken tracking — it is the fate of the format.

A short link's whole job is to fit a long URL into a chat window. When someone taps it from WeChat, QQ, Slack, or email, the browser gets either no referrer or the referrer of the app's in-app container. Modern apps use their own WebViews and many strip the Referer header outright as a privacy measure. You cannot intercept that.

So: if a tool claims 100% source attribution, it is either lying or normalising only the tracked subset into something that looks clean and isn't usable.

The 23% "Unknown OS" is WebViews and crawlers

OS	Clicks	Share
Windows 10	9,360	34.7%
Unknown OS	6,320	23.4%
Android	5,109	18.9%
Mac OS X	2,800	10.4%
iPhone	2,424	9.0%
Linux	645	2.4%
iPad	125	0.5%
Windows 7	91	0.3%

My first reaction to "Unknown OS" at second place was that my parser was broken. It isn't. Three things land in that bucket:

App WebViews that omit key fields or disguise themselves
In-app browsers (27.8% of all traffic, see next section)
Search engine prefetching — Baidu, 360, and Bing crawlers hit short links constantly

That third one deserves emphasis: short-link pages are among the most heavily crawled page types on the web. Any public short link shared into a group chat gets crawled within hours. Counting those as analytics is measuring bot traffic.

At least half of that 23% is WebView plus crawlers. That is why "mobile share" is such a soft number across most short-link tools.

One conclusion does survive the noise: Windows 10 at 34.7% plus Windows 7 at 91 clicks makes desktop Windows the absolute majority. If your short links point at landing pages with images, popups, or splash screens, design for 1366×768 through 1920×1080 first, mobile second. That runs against instinct. The data decides it, not instinct.

"Handheld Browser" at 27.8% is not a browser

Browser	Clicks	Share
Chrome	12,632	46.8%
Handheld Browser	7,520	27.8%
Unknown Browser	5,359	19.8%
Firefox	790	2.9%
Safari	695	2.6%
Internet Explorer	5	0.02%
Opera	1	—

"Handheld Browser" is the fallback label a server-side UA parser assigns when it cannot identify the engine at all. Everything in that bucket is, in substance, a mobile WebView. The frequency check confirms it: Opera, a genuinely obscure desktop browser, managed exactly 1 click.

For anyone shipping a landing page, this matters far more than "Chrome is 46.8%":

WeChat's in-app browser doesn't support all modern CSS — backdrop-filter, :has(), and some position: sticky behaviour
WeChat intercepts pages with outbound links, so an outbound button may render as an interstitial
WebP support depends on the WeChat version — older WebViews show a blank block where your carefully optimised image should be

If you run short links in China, open your splash page inside WeChat itself, not in Chrome's device emulator. I have seen too many pages that "looked fine in the emulator" and showed no image in WeChat.

Moldova is not your 12th biggest market

Country	Clicks
China	10,127
United States	6,174
France	1,722
(blank)	1,417
Japan	1,268
United Kingdom	875
Germany	609
Hong Kong, China	441
Canada	420
Taiwan, China	399
South Africa	388
Republic of Moldova	385

That blank 1,417 (5.2%) is not "unknown country" — it means the request carried no resolvable IP. Causes: server-side internal redirects, proxy requests, CDN origin fetches, crawlers.

The easy misreading: see "China 10,127, US 6,174" and conclude your users split evenly between China and the US. But with 13,745 direct clicks in the referrer column, there is no way to tell how many were Chinese users clicking Chinese links versus overseas users clicking Chinese links.

The telling outlier is Republic of Moldova at 385 clicks, rank 12. Moldova has about 2.5 million people. A country of 2.5 million contributing 1.4% of all clicks — ahead of Japan, the UK, and Germany per-capita by an absurd margin — is not a normal number. My read: those are overseas VPS or proxy egress IPs that geolocate to Moldova, or imprecise IP database data for the region. Moldova is a known proxy-relay hub in Europe.

The lesson is not "localise for Moldova." It is: always distrust the outliers in the long tail. When a country suddenly enters your top five, check IP attribution before you build a campaign for it.

A 207-a-day average hides a weekly rhythm

October 12–21 totals 2,068 clicks, a daily average of 206.8.

Day	Clicks
Weekdays (avg)	266
Sat, Oct 12	97
Sun, Oct 13	169

Weekend volume collapses to 40–60% of weekday volume, and the pattern is very stable.

That is directly usable for scheduling: weekday daytime is the main arena — that is when load time and reliability matter most.

One caution I nearly got wrong myself: Oct 13's 169 looks like a drop, but it is a Sunday. Never judge a trend from a single day.

What this data is actually for

If you read those five tables and thought "so what," here are the three things I actually do with them.

1. Decide landing page dimensions instead of guessing.
Desktop Windows at 34.7% means design for 1440px wide, then fold down for mobile. Not the reverse. Most people get this order backwards.

2. Decide what your stack must support.
Handheld Browser at 27.8% means old WebView compatibility is mandatory: no :has(), do not lean on backdrop-filter, ship both WebP and JPG.

3. Strip self-owned traffic before deciding where to spend.
Remove my own domains and external natural traffic is 2.6%. That number is small, but it tells me something more important than any acquisition report: I currently have almost no external acquisition.

The uncomfortable summary

50.9% of clicks had no referrer. Normal, not broken.
45.2% came from my own domains. That is the number that should worry you about your own data.
2.6% was genuinely external. That is the number that should drive your budget.
"Unknown OS" and "Handheld Browser" are not user segments. They are measurement failure.
A country ranking can be a proxy artefact.

If your analytics show a clean picture, you are probably looking at a filtered report.

Raw dataset: 27,013 clicks, 806 links, 27,002 detail rows (an 11-row gap, 0.04%, is crawler traffic that redirects but carries no referrer or complete UA). 120 countries. Period: 2026-05-25 to 2026-10-21. Tool: PicKu — free URL shortener with click analytics. The full breakdown, including the numbers I left in this post, is at picku.org/blog/short-link-analytics-blind-spots.

Part 1 of a series. Part 2 takes the part the data does have — timing — and finds something I got wrong the first time: weekends are not dead, Saturday is the biggest day of the week. Weekends Are Not Dead. My Data Says They're 10% Better.

How I Built a URL Shortener with Click Analytics (Architecture Deep Dive)

dalin zhou (钱先生) — Fri, 09 Oct 2026 12:35:47 +0000

Most URL shorteners solve the "make it short" problem and stop there. When I set out
to build PicKu, I wanted to answer a different question: what actually happens
after someone clicks your short link?

This is a write-up of the architecture decisions behind PicKu — including the ones
that turned out to be harder than expected.

The obvious requirements

A URL shortener needs three things to work at all:

Fast alias lookup — resolve picku.org/aBcD to a destination URL in single-digit milliseconds
Safe redirects — open redirect is the #1 abuse vector for any shortener
Click counting — the reason most people actually use one

That's the easy part. The interesting parts were everything else.

1. Why Redis for alias resolution

The lookup path is read-heavy and latency-sensitive: every click is a read, and
short links are hit in bursts. A link gets shared, a Slack channel reacts, traffic
spikes for ten minutes, then it dies.

A relational database handles this fine — until it doesn't. Sibling rows land on the
same physical page, and a viral link turns into a hot-page contention problem.

Redis key-value lookups are O(1) with no page contention, which is exactly the shape
of this workload. The tradeoff is durability: Redis alone loses data on restart.

The pattern I settled on: Redis as the read path, with write-through to the
primary store on every create. Reads are fast and cheap; the source of truth is still
durable. If Redis comes back empty after a restart, it rebuilds from the durable store.

2. Link expiry without a cron army

Expiring links sounds like it needs a scheduled job scanning every link every minute.
That approach falls over quickly — a million links means a million-row scan every
minute, and most of those links are nowhere near expiry.

Instead: lazy expiry. Store expires_at with each link. On every lookup, check it:


python
if link.expires_at and link.expires_at < now:
    mark_expired(link)
    return 410, "Gone"
return redirect(link.destination)
Zero background cost. Expired links cost one timestamp comparison, and you only pay
it on links actually being clicked — which, for most expired links, is never.
If you're building this yourself: decide your abuse policy before you write the
redirect handler. Retrofitting it means rewriting the hot path.
3. The abuse problem is the real hard part
Any URL shortener becomes an open redirect service the moment someone posts a
malicious link to a forum. Two things handle it:
Domain allowlisting for custom aliases. Custom aliases are opt-in, and the set of
destinations that may use them is controlled. This is the single biggest abuse
reduction lever.
Reputation scoring, not keyword blocking. Every destination domain accumulates a
score based on reports, age, and traffic patterns. Below a threshold, links are held
for review instead of served immediately.
The reason not to go keyword-filter-first: attackers trivially evade keyword filters,
and legitimate short links get caught constantly. Score the destination, not the string.
4. Analytics: what people actually want to see
The raw click count is the least interesting number. What people pay for is where the
click came from:
- Referrer — the referring URL, not just "direct"
- Country — resolved at click time, not at redirect time
- Device / browser — parsed from the user agent
- Timestamp — with a sane retention window, not forever
Two design notes that mattered:
Resolve geo at click time, not at creation time. A link created in one country
often gets clicked in another. Resolving at redirect is both cheaper and correct.
Retention beats resolution here. Analytics that keep three years of per-click rows
are expensive and nobody reads them that far back. A tight window (90 days on the free
tier, longer for paid) is the better trade.
5. Custom splash and overlay pages
Sometimes you don't want an instant redirect — you want a page with your branding, a
countdown, or a click-through. This is what the Direct Frame vs Splash options in the
UI control:
- Direct frame → straight redirect, zero friction
- Splash → branded intermediate page, optional countdown
- Custom domain → your own domain stays in the address bar, which matters for
brand trust and for link-preview screenshots in social apps
Custom domains are also what make a short link survive being shared in a room full of
people who don't trust bit.ly.
What I'd do differently
If I rebuilt this, I'd spend two more weeks on rate limiting and bot detection
before launch rather than after. Every shortener attracts scrapers within days of
launching — they're scanning for open redirects. Building it in from the start is
cheaper than retrofitting it under load.
The other thing I'd do earlier: make the API first-class from day one. A lot of
the long-term value came from integrations, not from the web UI.
If you're interested in comparing implementations or have questions about any of the
above, I'm happy to go deeper in the comments.
For reference, the tool this post is based on is here: https://picku.org — free tier
covers 10 links, and the paid tier removes ads and unlocks unlimited links, custom
domains, and API access.
Questions about any part of this? Happy to go deeper.