Before tracking every click, decide what the answer would change

I wanted one place to see whether people were finding my portfolio, which Field Notes held their attention, and whether an article led them toward a project, a résumé, or a conversation. That sounded like an analytics-dashboard problem, but the first proposal exposed a more important issue: I could name almost everything worth counting before I could name the decision each count would change.

The portfolio is a static Next.js site deployed through Codex Sites. It has no visitor database, no accounts, no contact form, and no analytics beacon. Adding a hosted script would be small; building a custom collector and dashboard would not. The latter would introduce a public write path, storage, bot filtering, retention rules, authentication, and a new interface to maintain—all before the site had established a useful measurement baseline.

So the question changed from “How do I track everything?” to “Which uncertainty deserves more data first?”

A metric needs a job before it needs a chart

For this portfolio, the real business outcome is a qualified conversation with someone who may want to hire or work with me. Browser analytics cannot establish that outcome on its own. A recruiter may read three Notes and contact me a week later through LinkedIn; another visitor may download the résumé and never return. The dashboard can observe parts of that path, but it cannot honestly claim the conversation.

That does not make web analytics useless; it makes them leading evidence rather than the verdict.

Pageviews can show which Notes attract attention. Landing pages and referrers can show whether people arrive from search, LinkedIn, GitHub, or another source. Search impressions can reveal which ideas are becoming discoverable. Outbound clicks can eventually show whether a visitor continued toward a dossier, demo, résumé, or contact path.

Each number becomes useful only when it has a possible consequence. If a Note receives traffic but nobody continues to its related project, the connection may be weak or hard to find. If search impressions rise while clicks do not, the title or description may be failing. If almost nobody reaches the site, optimizing an internal conversion funnel is premature.

The right side is tempting because it sounds closer to business value. However, collecting those answers first would not guarantee that I knew what to do with them.

The free plan became useful because of its blind spots

The initial assessment favored a paid, event-capable service rather than a custom dashboard. It was the sensible complete answer: use a mature collector, keep the public site static, and avoid rebuilding commodity analytics infrastructure.

I redirected the discussion before accepting that recommendation. We already had Cloudflare in the delivery path, so I wanted to understand the free option first and what we would actually lose by choosing it.

The proposed baseline paired Cloudflare Web Analytics with Google Search Console. It could cover visits, popular pages, broad referrers, search discovery, devices, and real-user performance. At the time of the assessment, Cloudflare's product did not support custom events or retain the query-string labels commonly called UTM parameters. That meant it could identify LinkedIn as a broad source, but not reliably distinguish one LinkedIn post from another or record a custom event such as a résumé download.

UTM parameters are simply labels appended to a link—utm_source=linkedin, for example—so an analytics tool can attribute otherwise identical visits to a channel, campaign, or individual post. They do not create a new article or change its canonical address, but they are only useful when the measurement system preserves and reports them.

Losing that attribution sounded like an immediate defect, though it forced a healthier question: had the missing information already prevented a decision? Not yet. Before comparing individual campaigns, the site first needs enough real traffic to establish which content is being discovered and whether visitors explore beyond the page where they arrived.

The blind spots are therefore not being presented as features, but as accepted constraints in the first experiment. A useful baseline does not need to answer every future question; it needs to reveal which future question is worth paying to answer.

A custom dashboard is another product

“We can build it ourselves” is especially attractive when the first version looks like a script, a table, and a few charts: the collector receives an event, the database stores it, and the dashboard groups it. That is the visible path, though the responsibility begins around it.

An internet-facing collector must reject malformed or abusive requests, while its schema must distinguish pageviews from actions without becoming a dumping ground for arbitrary properties. Bots and repeated events distort counts, retention and deletion need rules, and the private dashboard needs authentication; besides, migrations, backups, monitoring, and failure handling remain after the interesting charts are finished.

None of those concerns is impossible, but together they change the decision from “add analytics” to “operate an analytics product.” Owning that system could become justified if hosted reports repeatedly fail to connect content, search, publication dates, and manually recorded recruiter outcomes. Until then, it is infrastructure in search of a proven advantage.

1. 01Name the business decision
2. 02Collect the smallest useful baseline
3. 03Observe one meaningful period
4. 04Identify a decision blocked by missing data
5. 05Add one narrow event or attribution layer
6. 06Review whether the new evidence changed anything

This sequence also gives privacy a concrete role. The site should not collect persistent identities, raw interaction streams, precise location, recruiter details, or session recordings merely because a tool makes them available. Every additional field needs a decision it improves and a retention responsibility someone is prepared to own.

As of this Note's publication date, the analytics plan remains unimplemented, so there is no traffic baseline and no evidence that the free proposal is sufficient. There is only a bounded first experiment: observe traffic, content, search, and performance before adding event-level attribution. A later decision may still justify paid analytics or a custom presentation layer, but it should arrive with a named question the current evidence cannot answer.

More data can make a dashboard look mature while leaving the product decision exactly where it started. Measurement becomes useful when it reduces a real uncertainty, so the first analytics plan should not maximize what can be collected; it should make the next decision easier to defend.