DEV Community: Zenovay

I Published 31 DEV Posts. The One With 300 Views Got Zero Reactions.

Zenovay — Sat, 25 Jul 2026 12:42:48 +0000

I published 31 posts on DEV and collected 1,222 views.

My most-viewed post reached 300 views.

It got zero reactions and zero comments.

Another post reached only 47 views. It got 3 reactions and 5 comments.

That changed how I think about “a successful post.”

One post was a search engine

The 300-view article was an 11-minute Cloudflare architecture deep-dive.

It earned 112 views from Google and 20 from DuckDuckGo. Months later, people still find it because the title matches a specific technical problem.

But its average read time was 123 seconds.

It created discovery, not discussion.

The other post was a conversation

The 47-view article was about a problem I felt while using coding agents:

AI can write code faster than I can responsibly review it.

It had no tutorial and no giant code block. It had one tension, concrete examples, and a question readers could answer from their own experience.

Its average read time was 79 seconds. More importantly, people added ideas that improved the original argument.

I was optimizing one number to do two jobs

Search posts and discussion posts are different products.

A search post needs a precise problem, concrete implementation details, and enough depth to deserve the query.

A discussion post needs a sharp claim, a human consequence, and room for the reader to disagree.

The mistake is expecting one article to maximize both.

Now I want to alternate deliberately:

Discovery posts that answer one narrow technical question.
Discussion posts that expose one real decision or failure.

If you had to choose, which result would you rather publish: 300 views with no visible response, or 47 views that start a real conversation?

Disclosure: I used AI to help analyze my DEV dashboard, structure this post, and produce the visuals. I reviewed the source data, claims, and final draft.

AI Can Write Code Faster Than I Can Responsibly Review It

Zenovay — Wed, 22 Jul 2026 17:30:30 +0000

I use Claude Code almost every day while building Zenovay.

It can scaffold a feature, trace a bug across several files, write tests, refactor an old module, and explain an unfamiliar part of the codebase before I have finished my coffee.

That sounds like pure leverage.

But it created a problem I did not expect:

AI can produce code much faster than I can build a reliable mental model of it.

The bottleneck is no longer writing code.

It is human attention.

A large diff still feels like progress

There is something satisfying about watching an agent work through a task.

Files change. Tests appear. Type errors disappear. The terminal keeps moving.

Twenty minutes later, there is a 700-line diff and everything is green.

It feels like a productive session.

Then I open the diff and realize I cannot confidently explain every decision it made.

Why was this abstraction added?

Does this retry create duplicate events?

Is the permission check happening at the API boundary, or only in the interface?

What happens when the webhook arrives twice?

Did the code preserve the privacy rule I described three prompts ago?

The dangerous output is rarely code that obviously fails.

It is code that compiles, passes the happy-path test, and quietly implements the wrong assumption.

Generation got cheap. Review did not.

Before coding agents, the effort required to write a feature naturally limited its size.

You had time to think while typing. You noticed awkward interfaces because you had to use them repeatedly. You remembered why a branch existed because you wrote it ten minutes earlier.

AI removes much of that friction.

That is useful, but the friction was also doing hidden work.

It slowed the amount of new code entering the system.

Now a solo developer can generate changes at something close to team velocity. The review capacity is still one person.

That creates a kind of review debt.

Every accepted line that I do not fully understand becomes a small future obligation. Maybe it is harmless. Maybe it becomes the function nobody wants to touch six months later because nobody remembers why it works.

The code was generated quickly.

The understanding was deferred.

Some decisions should stay slow

While building an analytics product, small technical decisions can carry real consequences.

A mistake in attribution can show a customer the wrong acquisition channel.

A mistake in session replay can capture something that should have been masked.

A mistake in billing logic can affect real money.

A mistake in authorization can expose one customer's data to another.

I still use AI around all of these areas, but I do not let it silently decide the important boundaries.

There are a few things I now treat differently:

Data and privacy boundaries

The agent can help implement the rule.

The rule itself has to come from me.

I want to know exactly what enters the system, where it is transformed, how long it stays, and what must never be stored.

Authorization and billing

A plausible-looking permission check is not enough.

For auth, subscriptions, invoices, refunds, and webhooks, I review the full path instead of only the changed function.

Database migrations

AI is very good at generating a migration that looks correct.

It is less aware of the strange data already living in production, the old client still sending a deprecated field, or the rollback you will need at 2 AM.

Product assumptions

An agent will happily turn an unclear requirement into working code.

That does not make the requirement correct.

When the model fills in a missing product decision, it often chooses the most conventional answer. Conventional is not always what your product needs.

My workflow changed

I used to prompt for an implementation and review the result.

Now I separate thinking from writing.

First, I ask for the proposed approach, affected files, assumptions, failure cases, and the parts of the task that are still ambiguous.

Only then do I let it edit.

I also try to keep each change small enough that I can review it without scrolling through an entire afternoon of generated code.

For critical paths, I ask the agent to attack its own solution:

Where can this fail silently?
Which input breaks the current assumption?
What happens during retries?
What happens when two requests arrive at the same time?
Which authorization check is missing?
What data could be stored accidentally?

This catches useful issues, but it does not transfer responsibility to the model.

Tests do not do that either.

A test suite proves that the cases we thought about behave as expected. It says nothing about the cases nobody considered.

At the end, I ask myself one simple question:

Could I explain this change to another developer without mentioning the AI?

If the answer is no, I am not ready to merge it.

AI did not remove the need for engineering judgment

Coding agents are probably the biggest productivity improvement in my workflow.

I am not going back.

But I no longer measure a good AI session by the number of files changed or how quickly the task reached a green checkmark.

The useful metric is how much verified progress entered the codebase.

That is usually less impressive than the generated diff.

It is also much more valuable.

AI can help write the code.

It can suggest tests, point out risks, and challenge an implementation.

But once that code reaches production, the model is not maintaining the promise behind it.

I am.

How are you handling this in your own workflow?

Do you review every line of AI-generated code, or are there areas where you deliberately trust it more?

Disclosure: I use AI heavily while building Zenovay and used it to help structure and edit this post. The opinions, examples, and final decisions are my own.

7 Sources Hiding Inside Your Direct Traffic

Zenovay — Mon, 20 Jul 2026 10:57:18 +0000

Open almost any web analytics dashboard and you will find a channel called Direct.

The usual explanation is simple:

Direct traffic comes from people who typed your URL into the browser.

That explanation is technically possible.

It is also incomplete.

A visitor is normally classified as Direct whenever the analytics system cannot identify a better source.

That means Direct is not really one acquisition channel.

It is a container for missing information.

Inside that container, you may find:

Copied links
Private messages
Desktop applications
Mobile applications
AI assistants
Documents
Bookmarks
Redirects
Privacy-protected referrals
Genuinely typed URLs

When Direct traffic becomes unusually large, the correct conclusion is not:

Our brand recognition must be amazing.

The better conclusion is:

We are losing acquisition context somewhere in the journey.

What Direct traffic actually means

A browser may send referral information when someone follows a link from one website to another.

For example:

example-newsletter.com
        ↓
your-saas.com

Your analytics system can then classify the visit as a referral from the newsletter website.

But when the browser sends no usable referral information and the URL contains no campaign parameters, the analytics system has little evidence to work with.

The visit often becomes:

Source: Direct
Medium: None

This does not prove that the visitor manually entered the address.

It only proves that the source could not be determined.

That distinction matters.

A growing Direct channel could indicate stronger brand awareness.

It could also mean that your most effective newsletter, community, AI assistant, document, or mobile application is not being measured correctly.

1. Links copied from private messages

Consider this common journey:

Person A discovers your product on X
        ↓
Person A copies the link
        ↓
Person A sends it through WhatsApp
        ↓
Person B opens the link

The second visitor did not arrive directly from X.

They arrived through WhatsApp.

However, the browser may provide no useful referral information from that private conversation.

The visit can therefore appear as Direct.

This is commonly called dark social.

It can include traffic from:

WhatsApp
Telegram
Signal
Slack
Discord
Microsoft Teams
Direct messages
SMS
Desktop email clients

The term "dark" does not mean malicious or secret.

It means the referral path is not visible to the analytics system.

This is especially common for content that people naturally share with colleagues:

Technical tutorials
Pricing pages
Comparison pages
Free tools
Templates
Research
Product launches

A page with unusually high Direct traffic may simply be highly shareable in private conversations.

2. AI assistants

A visitor might ask an AI assistant:

What is a privacy-friendly alternative to Google Analytics for a small SaaS?

The assistant may recommend several products and include links.

Depending on the assistant, browser, and method used to open the link, the visit could arrive with:

A recognizable AI referrer
A normal referral
Campaign parameters
No referral information at all

The last case becomes Direct.

There is another complication.

The visitor may not click the link immediately.

They might instead:

Read the recommendation
Remember the product name
Search for it later
Open the website through Google

The final visit becomes Organic Search, even though the original discovery happened inside an AI assistant.

This is why AI influence and AI referral traffic are not identical.

Referral traffic measures identifiable clicks.

Influence can happen earlier in the journey without leaving a clean technical signal.

You should therefore avoid silently classifying every suspicious Direct visit as AI traffic.

A more honest report separates:

Measured AI referrals
Likely AI-influenced visits
Unclassified Direct visits

The second category is an estimate, not a fact.

3. Desktop and mobile applications

Links opened from native applications do not always include normal web referral information.

Examples include:

Desktop email clients
Notes applications
Password managers
PDF readers
Project-management tools
Mobile messaging applications
Native social media applications

Imagine someone clicks your link from a task inside a desktop project-management application.

The browser opens.

Your website loads.

No recognizable referrer arrives.

The session becomes Direct.

This is one reason the same campaign can appear differently across devices.

The desktop application may produce Direct traffic, while its browser-based version produces a recognizable referral.

From the visitor's perspective, both clicks came from the same product.

From the analytics system's perspective, they may look like two unrelated channels.

4. Documents and presentations

Links inside documents are another hidden source of Direct traffic.

Someone might open your website from:

A PDF
A Word document
A Google Docs export
A slide deck
A spreadsheet
An internal knowledge base
A downloaded report

Some document viewers pass referral information.

Many do not.

This is particularly relevant for B2B products.

A potential customer might discover your product in a comparison document shared internally by their team.

Several colleagues then click the same link.

Your dashboard shows a group of Direct visitors.

In reality, the traffic came from one highly influential internal document.

Without campaign parameters, that source is almost impossible to recover.

When you control the document, add a clear campaign identifier to its links.

For example:

https://example.com/pricing
?utm_source=partner_report
&utm_medium=document
&utm_campaign=analytics_comparison

Do not put names, email addresses, or other personal information into campaign parameters.

URLs may appear in screenshots, logs, browser history, analytics systems, and shared documents.

5. Redirects and tracking links

Redirects can remove or obscure acquisition context.

A typical journey might look like this:

Social post
    ↓
Shortened link
    ↓
Tracking domain
    ↓
Marketing redirect
    ↓
Final landing page

Every additional step creates another opportunity to lose:

UTM parameters
Click identifiers
Referral information
Path information
Fragment values

This happens frequently when several tools are involved:

Social scheduling software
Affiliate platforms
Link shorteners
Newsletter providers
Redirect services
Custom campaign domains

One redirect may preserve the complete destination URL correctly.

A later redirect may accidentally drop everything after the question mark.

The visitor still reaches the correct page, but the attribution information disappears.

Always test the final browser URL rather than checking only the link configured inside the campaign tool.

A simple test process is:

Open the real published campaign link
Follow every redirect
Inspect the final URL
Confirm that the expected parameters remain
Verify the visit inside your analytics tool

Do this before launching an important campaign.

6. Privacy and referrer restrictions

Modern browsers deliberately limit the referral information websites receive.

This is good for privacy.

It also means analytics systems cannot always reconstruct the complete previous page.

Referral information can be affected by:

Browser privacy settings
Referrer policies
Private browsing
Security software
Browser extensions
Cross-origin navigation rules
Transitions between secure and insecure pages

A website can also define its own referrer policy.

A strict policy may prevent external websites from seeing which exact page a visitor came from.

This can reduce unnecessary data sharing.

It can also make referral reporting less detailed.

There is always a tradeoff:

More referral detail
        ↕
Less information shared across websites

An analytics system cannot recover information that the browser intentionally did not provide.

This is why attribution should be presented with confidence levels and limitations rather than as perfect truth.

7. Returning visitors and forgotten first touches

The largest attribution problem often happens after the first visit.

Consider this journey:

Monday:
Visitor discovers your SaaS through a newsletter.

Wednesday:
Visitor returns through Google.

Friday:
Visitor opens the pricing page from a bookmark.

Sunday:
Visitor signs up during a Direct session.

If your analytics tool looks only at the signup session, the conversion may be attributed to Direct.

But Direct did not create the original discovery.

The newsletter did.

This is the difference between a session source and the complete customer journey.

A useful system preserves at least:

The first known source
The most recent known source
The source immediately before conversion
The ordered sequence of meaningful touchpoints

These can produce very different reports.

First-touch attribution

The first identifiable source receives the credit.

Newsletter: 100%

This helps answer:

Which channels introduce new customers?

Last-touch attribution

The final eligible source before conversion receives the credit.

Direct: 100%

This helps answer:

Which channels appear closest to conversion?

Multi-touch attribution

Credit is distributed across several interactions.

Newsletter: 40%
Google: 20%
Direct: 40%

This helps answer:

Which channels participated in the journey?

There is no universally correct attribution model.

The mistake is not choosing the "wrong" model.

The mistake is showing a revenue number without stating which model produced it.

How to reduce unexplained Direct traffic

You will never eliminate Direct traffic completely.

That should not be the goal.

The goal is to reduce avoidable attribution loss.

Use consistent UTM parameters

Whenever you control a link, add campaign information.

A simple convention is enough:

utm_source
utm_medium
utm_campaign
utm_content

Example:

https://example.com/pricing
?utm_source=devto
&utm_medium=content
&utm_campaign=direct_traffic_article
&utm_content=article_cta

Keep the values:

Lowercase
Predictable
Documented
Free of personal information

Avoid using several names for the same source.

These values should not all coexist:

devto
dev.to
DEV
dev-community

Choose one convention and apply it consistently.

Preserve campaign parameters through redirects

When a campaign link redirects to another page, forward its original parameters.

Bad:

/start?utm_source=newsletter
        ↓
/pricing

Better:

/start?utm_source=newsletter
        ↓
/pricing?utm_source=newsletter

This becomes especially important when authentication, regional routing, link shortening, or checkout pages sit between the landing page and conversion.

Track meaningful conversion events

Pageviews tell you that someone visited.

They do not tell you whether the visit mattered.

Track meaningful events such as:

signup_started
signup_completed
project_created
integration_connected
trial_activated
checkout_started
subscription_created

The exact event names matter less than using them consistently.

A useful acquisition report should connect sources not only to visits, but also to:

Signups
Activation
Purchases
Recurring revenue
Retention

Otherwise, the channel with the most visitors may look like the best channel even when it produces no customers.

Preserve the original source

Do not replace the original source every time the visitor returns.

Store first-touch information separately from current-session information.

Conceptually:

First source: dev.to
Current source: Direct
Conversion source: Email

All three can be true.

This gives you the flexibility to compare different attribution models later.

Use self-reported attribution carefully

During signup, you can ask:

How did you first hear about us?

This can reveal sources that technical attribution misses:

A podcast
A private community
A recommendation from a colleague
An AI assistant
A conference
Word of mouth

But self-reported attribution is also imperfect.

People forget.

They may remember the most recent interaction instead of the first one.

They may select the easiest available option.

Use it as an additional signal, not as the only source of truth.

One useful comparison is:

Measured source: Google
Self-reported source: ChatGPT

That difference tells you something important about the discovery journey.

Do not fix Direct traffic by inventing certainty

It is tempting to build rules such as:

No referrer + deep page = AI
No referrer + returning user = Bookmark
No referrer + mobile = Messaging app

These rules may produce useful estimates.

They do not produce facts.

A responsible analytics system should label results accordingly:

Measured
Inferred
Unknown

Unknown is not a failure.

Unknown is often the most accurate answer the available evidence supports.

A practical Direct-traffic audit

When Direct traffic looks suspiciously high, inspect it in this order.

1. Check the landing pages

A Direct visit to your homepage may plausibly come from a typed URL or bookmark.

A Direct visit to a deeply nested page such as:

/blog/how-to-connect-stripe-webhooks-to-revenue-attribution

is more likely to have been copied, shared, or opened from somewhere that removed the referrer.

It is still not proof of one particular source.

2. Compare new and returning visitors

Large amounts of returning Direct traffic can come from:

Bookmarks
Browser history
Saved applications
Repeated internal usage

Large amounts of first-time Direct traffic to deep pages may suggest missing referral information.

3. Test every active campaign

Open the real links from:

Newsletters
Scheduled social posts
Advertisements
Partner websites
Documents
QR codes
Shortened links

Confirm that the campaign parameters survive until the final page.

4. Review cross-domain journeys

Check whether visitors move between:

The marketing website
The application
Authentication pages
Checkout
Documentation
Regional domains
Subdomains

A broken cross-domain journey can make later sessions appear as Direct or as self-referrals.

5. Compare Direct traffic with campaign dates

Look for Direct traffic increases immediately after:

A newsletter
A Product Hunt launch
A community mention
An AI citation
A podcast appearance
A partner announcement

The campaign may be contributing more than the dashboard shows.

Treat this as supporting evidence rather than exact attribution.

Direct traffic is not useless

Direct traffic is often described as a dirty bucket.

That description is too negative.

Direct still tells you something:

The visitor reached the website without providing enough acquisition information for a more specific classification.

That can represent genuine brand strength.

People may:

Remember your domain
Return from browser history
Use a bookmark
Open your application daily
Share your product privately

The problem begins only when Direct is interpreted as one precise acquisition channel.

It is not.

It is a mixture of different behaviours that happen to produce the same technical result.

Final thought

Web attribution is not a recording of objective reality.

It is a reconstruction based on incomplete signals.

Browsers protect information.

Applications hide referral paths.

People switch devices.

Links move through private conversations.

Discovery and conversion can happen days apart.

A useful analytics system should therefore help you distinguish:

What was measured
What was inferred
What remains unknown

The purpose of attribution is not to make every journey look perfectly explainable.

It is to preserve enough trustworthy context to make better decisions.

The next time Direct traffic rises, do not immediately celebrate your brand awareness.

Open the landing pages.

Check the campaigns.

Inspect the redirects.

Look at the complete customer journey.

Your missing acquisition channel may already be hiding in plain sight.

Disclosure: I work on Zenovay, a privacy-first web analytics product. This article discusses a general analytics problem and does not depend on Zenovay-specific implementation details. AI was used to help edit and structure the article.

What is the strangest source you have ever discovered hiding inside your Direct traffic?

The tracking script that never blocks page load: a stub and queue pattern

Zenovay — Sat, 27 Jun 2026 10:54:00 +0000

How we built an analytics client that captures everything without ever blocking paint.

The Constraint

An analytics script that slows down the page is sabotage, especially on a marketing site where the conversion you are measuring is the thing you just hurt. So our hard rule: the client must never block page load, and it must never lose an event that happened before it finished loading. Those two goals fight each other, and the resolution is a stub and queue.

The Stub

A tiny synchronous stub defines the global immediately and queues every call into an array. This is all that runs before the real script arrives.

window.zv = window.zv || function () {
  (zv.q = zv.q || []).push(arguments);
};

Now the page can call zv('event', {...}) from the very first line, and nothing is lost even though the real implementation is not loaded yet. Every call lands in zv.q.

Loading the Real Script Without Blocking

The real script loads async, so it never blocks parsing or paint.

<script>
  window.zv = window.zv || function(){ (zv.q = zv.q || []).push(arguments) };
</script>
<script async src="https://cdn.example.com/zv.js"></script>

When zv.js arrives, it drains the queue in order before handling anything new:

const queued = (window.zv && window.zv.q) || [];
window.zv = realImplementation;
for (const args of queued) {
  realImplementation.apply(null, args);
}

The stub and the real implementation share one entry point, so the page never knows or cares which one it is talking to.

Push the Work to the Edge

The browser stays thin on purpose. The heavy work runs on Cloudflare Workers:

per site config (which features are on) is cached in Workers KV and read at the edge, so the script does not round trip to an origin to configure itself
events batch in the browser and flush with sendBeacon, which survives the page being closed

let buffer = [];

function enqueue(event) {
  buffer.push(event);
  if (buffer.length >= 10) flush();
}

function flush() {
  if (!buffer.length) return;
  navigator.sendBeacon('/ingest', JSON.stringify(buffer));
  buffer = [];
}

addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') flush();
});

The Byte Budget

The whole client sits around 3.1kb gzipped, treated as a hard ceiling. Every feature either fits or loads on demand. Session replay, for instance, is a separate module loaded only when enabled, so customers who never use it never download it.

What We Learned

The stub and queue is the entire trick for never blocking and never losing events. It is a few lines and it solves both goals at once.
sendBeacon on visibilitychange is what makes the last events survive navigation. A normal fetch on unload gets cancelled.
A hard byte budget forces good decisions. Without it, every feature quietly adds weight to the page you are paid to protect.

Honest Limit

Stub and queue slightly delays the first few events until the real script drains the queue. For analytics that is invisible. For anything user facing, it would not be acceptable.

If you ship a third party script, how do you keep it from becoming the slowest thing on your customers' pages?

I build Zenovay with my co-founder, cookieless website analytics on Cloudflare Workers. This is how our client script stays out of the way.

Running A/B tests on top of edge feature flags

Zenovay — Thu, 11 Jun 2026 18:20:33 +0000

Once you have feature flags, an A/B test is a small step further: a flag with more than one variant, plus honest measurement. Here is how we do it at the edge, and the two bugs that quietly invalidate experiments.

I build this for Zenovay (web analytics). This assumes you already read flag config at the edge with no extra latency.

A flag is on/off. An experiment is a bucket.

The only new pieces are: assigning each user to a variant consistently, and logging exposure so you can measure.

Deterministic assignment (bug #1 if you get it wrong)

Never use Math.random to pick a variant. The same user would flicker between variants on every request, which destroys the experiment and the user experience. Hash a stable id instead, so a given user always lands in the same bucket.

async function bucket(userId: string, experiment: string, variants: string[]) {
  const data = new TextEncoder().encode(`${experiment}:${userId}`);
  const digest = await crypto.subtle.digest("SHA-256", data);
  // take 4 bytes of the hash as an unsigned int
  const n = new DataView(digest).getUint32(0);
  const bucketFraction = n / 0xffffffff;          // 0..1, stable for this user
  const index = Math.floor(bucketFraction * variants.length);
  return variants[index];
}

// usage at the edge
const variant = await bucket(userId, "checkout_copy_v1", ["control", "treatment"]);

Including the experiment name in the hash matters: it means a user is not correlated across different experiments. Without it, anyone in "treatment" for experiment A tends to be in "treatment" for B too, which confounds everything.

Log exposure, not just conversion (bug #2)

You must record that a user was actually exposed to a variant, at the moment they were exposed. If you only look at who converted, you cannot compute a rate, because you do not know the denominator per variant.

// fire once, when the variant is actually shown
function logExposure(userId: string, experiment: string, variant: string) {
  sendBeacon("/exposure", { userId, experiment, variant, ts: Date.now() });
}

The classic mistake is assigning a variant but only logging conversions. Then "treatment converted 40, control converted 30" tells you nothing without exposure counts.

Measuring the result

With exposure and conversion events, the rate per variant is straightforward.

select
  e.variant,
  count(distinct e.user_id) as exposed,
  count(distinct c.user_id) as converted,
  round(100.0 * count(distinct c.user_id) / count(distinct e.user_id), 2) as rate
from exposures e
left join conversions c
  on c.user_id = e.user_id
 and c.event_at >= e.event_at        -- only conversions after exposure
group by e.variant;

Note the join condition: only count a conversion if it happened after the user was exposed. A conversion before exposure is not caused by the variant.

When not to roll your own

Do this yourself for simple, low-stakes tests. Reach for a real experimentation platform when you need sequential testing, guardrail metrics, automatic significance, or non-engineers launching tests.

The hard part of A/B testing is not assignment — it is the statistics and not fooling yourself. The code above gives you rates, not confidence.

Disclosure: I build Zenovay, which ties experiment exposure to downstream revenue so you can see which variant made money, not just which got clicks.

Do you stop tests on significance or on a fixed sample size? Stopping the moment it looks significant is the most common way to ship a false winner.

Filtering bot and spam traffic out of your analytics

Zenovay — Tue, 09 Jun 2026 18:22:16 +0000

If your analytics counts bots, every number you make decisions on is inflated. Conversion looks worse than it is, traffic looks better than it is. Here is the layered filter we run at ingestion, cheapest checks first.

Same traffic, with bots counted and with them filtered out:

With bots (inflated):

Bots filtered out (honest):

I build this for Zenovay (web analytics). None of these checks is perfect alone, which is why they are layered.

Layer 1: it never ran JavaScript

The single most effective filter. Most crawlers fetch HTML and leave. If your analytics fires from a script, a large class of bots is already excluded because they never execute it. This is free and catches a lot, but not headless browsers, which do run JS.

Layer 2: obvious user agent signatures

const BOT_UA = /(bot|crawl|spider|slurp|headless|phantom|puppeteer|playwright|curl|wget|python-requests|axios)/i;

function looksLikeBotUA(ua = "") {
  if (!ua) return true;             // no UA at all is suspicious
  return BOT_UA.test(ua);
}

A regex on the UA is trivial to spoof, so treat it as a hint, not proof. It mostly clears out honest bots that identify themselves.

Layer 3: datacenter and known ranges

Real users come from residential and mobile networks. A burst from a cloud provider ASN is usually automation. At the edge you often get the ASN for free.

const DATACENTER_ASNS = new Set([
  // a maintained list of cloud/hosting ASNs
  16509, // aws
  15169, // gcp
  8075,  // azure
  14061, // digitalocean
]);

function fromDatacenter(request) {
  const asn = request.cf?.asn;        // cloudflare provides this
  return asn ? DATACENTER_ASNS.has(asn) : false;
}

Careful: some legitimate corporate traffic and VPNs also exit through datacenter ranges, so do not hard drop on this alone. We flag, then combine with behavior.

Layer 4: behavior that is not human

The strongest signal after "did it run JS". Humans are slow and irregular. Bots are fast and uniform.

function behaviorIsBotty(session) {
  // many pageviews in an impossibly short time
  if (session.pageviews >= 10 && session.durationMs < 2000) return true;
  // zero mouse, scroll, or key events across a long visit
  if (session.durationMs > 5000 && session.interactions === 0) return true;
  // perfectly regular timing between events (scripted)
  if (session.events.length > 5 && variance(session.interEventMs) < 1) return true;
  return false;
}

Putting it together

function classify(request, ua, session) {
  let score = 0;
  if (looksLikeBotUA(ua)) score += 2;
  if (fromDatacenter(request)) score += 1;
  if (behaviorIsBotty(session)) score += 3;
  // 0 to 1 = human, 2 = suspicious (flag), 3+ = bot (exclude from metrics)
  return score >= 3 ? "bot" : score >= 2 ? "suspicious" : "human";
}

The decision that matters: drop or flag

Do not delete suspicious traffic. We keep everything but tag it, and exclude bots from the default metrics. That way if our filter is wrong, the data is recoverable, and you can audit how much you are filtering. A silent filter you cannot inspect is its own bug.

Disclosure: I build Zenovay, which does this filtering by default so your numbers are not inflated. The layered approach above is what runs under the hood.

What is your highest signal bot tell? For us it is a long visit with literally zero interaction events.

Retention cohort analysis with plain SQL

Zenovay — Mon, 08 Jun 2026 18:09:38 +0000

Everyone wants a retention chart and most reach for a tool. You can get the core cohort triangle from raw events with one SQL query. Here is the pattern we use, and the mistake that quietly makes it wrong.

I build this for Zenovay (web analytics) where we show retention by signup cohort. The shape below is database agnostic, written for Postgres.

The idea

A cohort is a group of users bucketed by when they first appeared (usually signup week). For each cohort you measure what fraction are still active N weeks later. Plot it as a triangle and you can see whether newer cohorts retain better than older ones.

The two inputs

You need two things per user: their cohort (first activity week) and every week they were active.

-- 1) each user's cohort week
with first_seen as (
  select
    user_id,
    date_trunc('week', min(event_at)) as cohort_week
  from events
  group by user_id
),
-- 2) the distinct weeks each user was active
activity as (
  select distinct
    user_id,
    date_trunc('week', event_at) as active_week
  from events
)
select
  f.cohort_week,
  -- how many weeks after signup this activity is
  (extract(epoch from (a.active_week - f.cohort_week)) / 604800)::int as week_number,
  count(distinct a.user_id) as active_users
from first_seen f
join activity a using (user_id)
group by f.cohort_week, week_number
order by f.cohort_week, week_number;

That gives you a long table of (cohort_week, week_number, active_users). To turn it into a percentage you divide by the cohort size (week_number 0).

Turning counts into retention percent

with counts as (
  -- the query above, as a CTE
  ...
),
cohort_size as (
  select cohort_week, active_users as size
  from counts
  where week_number = 0
)
select
  c.cohort_week,
  c.week_number,
  c.active_users,
  round(100.0 * c.active_users / s.size, 1) as retention_pct
from counts c
join cohort_size s using (cohort_week)
order by c.cohort_week, c.week_number;

The mistake that breaks it

The subtle bug: defining "active" inconsistently between the cohort and the activity step. If your cohort is based on signup but your activity is based on, say, only paid events, week 0 retention will not be 100 percent and every number downstream is wrong. The fix is to make sure the week_number 0 cohort count equals the number of users who signed up that week. If it does not, your two definitions disagree.

The other one: time zones. date_trunc on a raw UTC timestamp buckets by UTC weeks. If your business thinks in a local week, convert before truncating, or your Monday is someone's Sunday and cohorts blur at the edges.

Making it fast

Over raw events this gets slow quickly. We run it over a daily rollup table (one row per user per active day) instead of millions of raw events, so the cohort query touches thousands of rows. Same result, far cheaper. The rollup is a separate scheduled job.

Disclosure: I build Zenovay, a web analytics tool that does this so you do not have to write the SQL. But the query above is the whole idea, and you should understand it before trusting any tool's version.

How do you define "active" for retention, any event or a meaningful one? That choice changes the whole chart.

Lightweight client side error tracking without a 90kb SDK

Zenovay — Sat, 06 Jun 2026 17:38:03 +0000

The popular error tracking SDKs are great and also large. For our analytics tool we wanted error capture that adds a couple of kb, not ninety. Here is the whole thing. It is smaller than you think.

Capture the two events that matter

type CapturedError = {
  message: string; stack?: string; url: string;
  line?: number; col?: number;
  kind: "error" | "unhandledrejection"; ts: number;
};

const queue: CapturedError[] = [];

window.addEventListener("error", (e) => {
  queue.push({ message: e.message, stack: e.error?.stack, url: location.href,
    line: e.lineno, col: e.colno, kind: "error", ts: Date.now() });
  schedule();
});

window.addEventListener("unhandledrejection", (e) => {
  const r = e.reason;
  queue.push({ message: typeof r === "string" ? r : r?.message ?? "unhandled rejection",
    stack: r?.stack, url: location.href, kind: "unhandledrejection", ts: Date.now() });
  schedule();
});

That is most of the value right there. error catches thrown exceptions, unhandledrejection catches the async ones everyone forgets.

Batch, debounce, and survive unload

let timer: number | undefined;

function schedule() {
  clearTimeout(timer);
  timer = setTimeout(flush, 2000) as unknown as number;
  if (queue.length >= 20) flush();
}

function flush() {
  if (!queue.length) return;
  const batch = queue.splice(0, queue.length);
  navigator.sendBeacon("/errors", JSON.stringify(batch));
}

addEventListener("pagehide", flush);

sendBeacon is the trick. A normal fetch on unload gets cancelled. Beacon does not.

Do not drown in noise

Two cheap filters save you from a flood:

const seen = new Set<string>();

function dedupe(err: CapturedError): boolean {
  const sig = err.message + ":" + err.line + ":" + err.col;
  if (seen.has(sig)) return false;   // already reported this page load
  seen.add(sig);
  return true;
}

const IGNORE = [/ResizeObserver loop/, /Script error\.?$/, /extension/i];
const ignored = (err: CapturedError) => IGNORE.some((re) => re.test(err.message));

Script error. with no detail is almost always a cross origin script with no CORS headers. ResizeObserver loop limit exceeded is benign browser noise. Filter both.

The one thing you actually need a server for

Minified stacks are useless without source maps. Upload your source maps at build time and resolve the stack server side. That, not the capture, is the part worth real effort.

Takeaway

Two event listeners, a batched beacon, dedupe, and an ignore list gets you most of the value of a heavy SDK in a couple of kb. Spend your effort on source map resolution, not on the capture.

Disclosure: this is the error tracking we ship in Zenovay.

Building session replay that masks input data by default

Zenovay — Wed, 03 Jun 2026 14:04:59 +0000

Session replay sounds scary because the naive version records everything a user types, including passwords and personal data. We built ours to mask sensitive input by default, so the safe path is the default path. Here is the approach.

What session replay actually is

It is not a video. Recording video would be huge and would capture everything. Instead you record the DOM and its mutations, then replay them in an iframe later. Much smaller, and crucially, you control what gets captured.

Step 1: serialize the initial DOM, masking as you go

function serializeNode(node: Node): SerializedNode {
  if (node.nodeType === Node.TEXT_NODE) {
    return { type: "text", value: node.textContent ?? "" };
  }
  const el = node as Element;
  const tag = el.tagName.toLowerCase();
  const attrs: Record<string, string> = {};
  for (const a of Array.from(el.attributes)) attrs[a.name] = a.value;
  if (tag === "input" || tag === "textarea") {
    attrs["value"] = maskValue((el as HTMLInputElement).value);
  }
  return { type: "element", tag, attrs, children: Array.from(el.childNodes).map(serializeNode) };
}

Step 2: the masking rule is opt out, not opt in

function maskValue(value: string): string {
  // default: never record raw input. replace with a same length placeholder
  return "x".repeat(value.length);
}

const NEVER_RECORD = ["password", "email", "tel", "credit", "card", "ssn", "cvc"];

function shouldDrop(el: HTMLInputElement): boolean {
  const hay = (el.type + " " + el.name + " " + el.id + " " + el.autocomplete).toLowerCase();
  return NEVER_RECORD.some((k) => hay.includes(k));
}

The point: a developer using our snippet does not have to remember to mask. Masking is what happens unless they explicitly mark a field as safe to record.

Step 3: record mutations, not frames

const observer = new MutationObserver((mutations) => {
  for (const m of mutations) {
    if (m.type === "attributes" && m.attributeName === "value") {
      const el = m.target as HTMLInputElement;
      record({ kind: "attr", id: nodeId(el), name: "value", value: maskValue(el.value) });
    }
    if (m.type === "childList") {
      m.addedNodes.forEach((n) => record({ kind: "add", parent: nodeId(m.target), node: serializeNode(n) }));
      m.removedNodes.forEach((n) => record({ kind: "remove", id: nodeId(n) }));
    }
  }
});

observer.observe(document.documentElement, {
  childList: true, subtree: true, attributes: true,
  attributeFilter: ["value", "class", "style"],
});

Step 4: batch and send, do not flood

let buffer: ReplayEvent[] = [];

function record(e: ReplayEvent) {
  buffer.push(e);
  if (buffer.length >= 50) flush();
}

setInterval(flush, 5000);

function flush() {
  if (!buffer.length) return;
  navigator.sendBeacon("/replay", JSON.stringify(buffer));
  buffer = [];
}

sendBeacon survives page unload, which a normal fetch does not.

Things that bit us

canvas and video cannot be serialized as DOM. We snapshot a placeholder.
Shadow DOM needs explicit traversal, it is not in the normal tree.
Cross origin iframes cannot be read at all. We mark them as opaque.

Takeaway

Session replay is a DOM recorder, not a screen recorder, which is exactly what lets you mask sensitive input by default. Make the safe behavior the default and developers do not have to think about it.

Disclosure: this is from building the replay feature in our analytics tool, Zenovay.

Scoring anonymous web visitors without storing personal data

Zenovay — Mon, 01 Jun 2026 19:20:38 +0000

Most lead scoring assumes you know who the visitor is. We wanted to score how likely an anonymous session is to convert without storing anything that identifies a person. No third party cookie, no enrichment vendor, no PII. Here is how we did it for our analytics tool, including the parts that did not work.

The goal

Given a live, anonymous session, output a number from 0 to 100 that says "pay attention to this one". The constraint: we never store who the person is. We score the behavior of a session id that rotates, not a profile.

The signals that actually correlate

We tested a lot of inputs against real conversion data. The ones that held up:

type SessionFeatures = {
  returnSessions: number;       // distinct prior sessions. strongest signal by far
  viewedPricing: boolean;
  pricingThenReturned: boolean; // viewed pricing, left, came back
  docsDepth: number;            // scroll + pages on docs/integrations
  pathShape: "browse" | "direct" | "compare";
};

The ones we dropped because they were noise: raw time on page (a backgrounded tab destroys it), single session scroll depth on its own, and device type (much weaker than people claim).

The scoring function

For low volume sites we do not use a model. Weighted rules beat a model until you have enough data to train on:

function scoreSession(f: SessionFeatures): number {
  let score = 0;
  score += Math.min(f.returnSessions, 5) * 12;   // return visits dominate
  if (f.viewedPricing) score += 10;
  if (f.pricingThenReturned) score += 20;         // intent
  score += Math.min(f.docsDepth, 100) * 0.2;
  if (f.pathShape === "compare") score += 8;
  return Math.min(Math.round(score), 100);
}

It is deliberately boring. A heuristic you can explain beats a black box you cannot, especially when a customer asks "why is this session a 78".

Running it at the edge on the event stream

Scoring runs on each event as it arrives, so the score updates in near real time instead of in a nightly batch:

export default {
  async fetch(req: Request, env: Env) {
    const event = await req.json<AnalyticsEvent>();
    const features = await loadSessionFeatures(env, event.sessionId);
    const updated = applyEvent(features, event);
    const score = scoreSession(updated);
    await env.SESSIONS.put(event.sessionId, JSON.stringify({ ...updated, score }), {
      expirationTtl: 60 * 30, // sessions expire, nothing persists about a person
    });
    return new Response(JSON.stringify({ score }));
  },
};

When we switch to a learned model

Only once a site has enough conversions to train on. Below that, a model overfits to a handful of events and is worse than the rules. We gate it on volume, not on whether it sounds impressive.

The honest limitations

You are scoring a session, not a person. A high score might be a competitor doing research.
No identity means no true cross device. We do not pretend otherwise.
Low volume sites get scores barely better than a coin flip, and the product says so rather than faking confidence. ## Takeaway

You can get genuinely useful visitor scoring without cookies or PII, but start with explainable weighted rules, not a model. The model is the last step, not the first.

Disclosure: my co founder and I build a web analytics tool called Zenovay that does this. The approach above is what we actually shipped. See zenovay.com

Why do most SaaS dashboards still feel like enterprise software from 1998

Zenovay — Sun, 31 May 2026 14:31:15 +0000

Question for the frontend and UX folks here. Why do most SaaS dashboards in 2026 still feel like enterprise software from 1998 in everything but the CSS?

I noticed this hard when redesigning my own product (Zenovay, cookieless web analytics). The first version of our dashboard had:

a left sidebar with 14 menu items
a top bar with 6 controls
8 chart widgets visible at first paint
a "configure dashboard" modal with 23 options

It looked exactly like every other analytics tool. I could not tell my dashboard apart from PostHog or Amplitude in a screenshot.

Then I looked at how my actual users used it. The pattern was:

arrive at dashboard
look at 2 numbers
click one drill down
leave

Total time spent in the dashboard: 47 seconds median. Almost nobody touched the sidebar after onboarding.

So the 14 menu items, 6 controls, 8 widgets, and 23 configuration options were all competing for attention with the 2 numbers people actually came for.

The redesign

New version:

2 numbers at the top, big, no chart, just numbers
1 trend chart underneath
3 drill in cards (top pages, top sources, top conversions)
everything else moved to a "more" menu

Median time on dashboard went up to 1m 50s. Pages per session went up. The "I can't find X" support emails dropped.

Why this took 4 years across the industry to figure out

Hypothesis 1: founders look at their own tools through builder eyes, not user eyes. We see all 14 menu items because we built them. A new user sees noise.

Hypothesis 2: dashboard density correlates with perceived "powerful". We're rewarded by the prospect's "wow this is comprehensive" reaction in the sales call. The customer then ignores 90% of it.

Hypothesis 3: the B2B buying loop selects for tools that look like they have lots of features. Procurement teams want checklists. Engineers want simplicity. The buyer is rarely the user.

Hypothesis 4: it's just hard. Saying no to a chart widget that someone, somewhere, wants is a daily resistance pattern. The default is to add.

The pattern I'm trying to follow now

First paint is sacred. Whatever is on first paint is what the user thinks the product is. Choose ruthlessly.
Power users get a different surface. Don't try to make one UI that pleases the casual visitor and the power user. Casual visitor gets a minimal dashboard. Power user gets a separate "explorer" route.
Sidebar items are debt. Every item is one more thing the user has to mentally ignore. Items must earn their place by being clicked.
Configuration is for users who asked for it. Default to opinionated defaults. Configuration is a power user feature. The setting hidden in a submenu is rarely the same one that's exposed at first paint.

Counter argument I can hear

"You're describing a consumer UI pattern. Enterprise customers want density." Maybe. But I think the gap between consumer and enterprise UI standards is closing fast, and the new buyer who is a millennial PM or technical founder is closer to consumer expectations than to circa 2010 enterprise.

Real question for the thread

What's a SaaS dashboard you actually enjoy using? Specifically: not respect, not "admire from a distance", but actually open with mild satisfaction. Curious where the bar actually is.

I'm Valerio. Built Zenovay, spent an embarrassing amount of time learning this lesson on my own product.

Six weeks of dedicated distribution as a solo founder. What i underestimated, what i overestimated

Zenovay — Sat, 30 May 2026 10:43:35 +0000

I'm Valerio, solo founder of Zenovay (cookieless web analytics). I spent the last 6 weeks doing dedicated distribution work. Not feature shipping. Just writing, posting, and engaging.

Posting this on a saturday because the audience for this thread is other founders, and saturday morning is when we read things we should have read earlier in the week.

What i underestimated

The time required to actually do distribution well.

I budgeted 10 hours per week. The honest number was 25. Writing a post that is worth reading takes time. Responding to comments takes time. Researching the platform's tone takes time. The act of clicking 'submit' is 5%. The rest is preparation.

The cost of context switching.

I tried doing 2 hours of distribution and 6 hours of product in the same day. The distribution work was bad, the product work was worse. Both kinds of work need a different brain mode. I now schedule whole days for each.

How much hand drafting matters.

Both reddit and hacker news react badly to anything that smells like ai generated text right now. I had to retrain myself to write the way i actually talk, including the awkward pauses and sentence fragments. it actually performs better.

The slow accumulation of cred.

First few posts on a new community got buried. The third or fourth one started landing. There's a 'this person actually shows up here' signal that builds over weeks. No shortcut for it.

What i overestimated

The importance of the perfect post.

I rewrote my first reddit post 6 times before posting. The one that actually got the most traffic that week was a 4 line comment on someone else's thread. Time spent perfecting the post was time not spent participating.

The reach of any single platform.

I thought hacker news would be the big lever. It was modest. The slow accumulation across 5 platforms outperformed any single home run. Diversification matters more than i thought.

The persuasive power of features.

I kept writing posts about cool features (3d globe, terminal cli, mcp server). They were interesting. They did not move signups much. The posts that moved signups were about outcomes (post launch numbers, what did and did not work, here's what i learned).

What i changed mid stream

Around week 4 i shifted from 'tell people what we built' to 'tell people what i learned'. Same factual content underneath, different framing. Signups per post roughly doubled. The post is not 'this is our cli', it is 'here's what i discovered while building a cli for analytics that no one writes about'.

The hardest part

Honesty in public. Sharing real numbers when the numbers are small. Admitting that a feature didn't work. Writing a post that contradicts a post you wrote 2 weeks ago because you learned something new.

Every time i was tempted to round a number up or hide a failure, the post performed worse. Every time i shared the awkward truth, the post performed better. There is something deeply correct about the platforms' bullshit detectors.

What i'd tell my earlier self

Pick 3 platforms, not 5. Five is too many for one person to do well.
Write 70% of the week's content on monday. Improvising mid week burns out faster than you'd think.
Spend an hour reading other founders' posts before writing your own. Pattern match the tone.
Track utm params from day one, not from when you remember.
Reply to every comment in the first hour. Algorithms reward velocity, not lifetime engagement.

Zenovay at zenovay.com. Web analytics with revenue attribution. Built by one person, distributed by the same person, both functions equally underbudgeted.