DEV Community: Zenovay

Our Ahrefs Domain Rating Fell From 23 to 6

Zenovay — Fri, 14 Aug 2026 17:25:01 +0000

Our Ahrefs Domain Rating fell from 23 to 6. The number was hard to ignore. It was also not an explanation.

That distinction shaped the investigation. A third party score can tell you that something changed in its model. It cannot tell you which technical decision caused the change, or whether the same movement appears in search performance. So we treated the drop as a prompt to inspect the site, not as a verdict.

The inspection found a real problem at the root URL. For visitors without an existing language preference, the same URL could return a temporary redirect to different locale paths depending on the request location. That behavior was inconsistent with the permanent locale structure we wanted search engines to understand.

We fixed it. We still cannot honestly say that this redirect caused the Domain Rating drop.

What the score actually tells us

Ahrefs defines Domain Rating as a relative measure of a website's backlink profile on a 0 to 100 scale. The calculation depends on the sites linking to a domain and on the wider Ahrefs index. A score can therefore move even when a site has not lost the same proportion of backlinks.

Ahrefs also states that Domain Rating is not a Google ranking factor. It is useful for comparing backlink profiles and noticing changes, but it is not a direct measurement of how Google ranks a page.

That left us with two separate facts:

We observed the score fall from 23 to 6.
Our root redirect behavior needed to be corrected.

The facts existed at the same time. Their timing did not prove that one caused the other.

What the root URL was doing

The old middleware selected a locale from the request country when no locale preference was already present. It then redirected a nonlocalized path such as the root URL to that locale with a 302 response.

In simplified form, the relevant behavior looked like this:

const country = request.cf?.country
  || request.headers.get('CF-IPCountry')
  || 'US'

const targetLocale = LOCALE_MAP[country] || 'en'

return new Response(null, {
  status: 302,
  headers: { Location: `/${targetLocale}/` },
})

The code was trying to be helpful. A visitor in Germany could be sent to the German locale, while a visitor in the United States could be sent to English.

The problem was the crawler facing contract. One source URL did not have one stable destination. Its response depended on location, and the redirect said the move was temporary.

This matters because Google treats permanent and temporary redirects differently. Its redirect guidance says that permanent redirects such as 301 and 308 are strong signals that the target should become canonical. With temporary redirects such as 302 and 307, the source generally remains the canonical URL in search results.

Temporary redirects are valid when a change really is temporary. They are the wrong default when the site has a permanent locale hierarchy and needs a deterministic canonical entry point.

Why location dependent routing was risky

Imagine two crawlers requesting the same root URL from different locations. One receives a redirect to /en/. The other receives a redirect to /de/. Both responses are temporary.

Nothing in either response tells a stable story about the site's preferred root destination. The behavior can also make external tools record different chains depending on where and when they crawl.

This does not automatically destroy authority, and a 302 is not a penalty. Search engines can interpret redirects using more than the status code alone. The issue was that our implementation mixed three concerns in one response:

The permanent structure of the site
The visitor's likely language
The visitor's saved preference

Those concerns deserve different handling. The canonical route should be stable. Personalization should happen only when there is an explicit preference or after the stable page has loaded.

The deterministic fix

The corrected middleware separates a new request from a returning visitor with a saved locale choice.

For a cookieless request to a nonlocalized path, the server now returns a permanent 301 redirect to the English path. The destination is the same regardless of country:

https://zenovay.com/  ->  https://zenovay.com/en/

For a visitor who already has a locale preference cookie, the middleware can still honor that personal choice with a temporary redirect. That is a genuinely user specific response, not a claim about the site's canonical structure.

This is a small code change with a useful property: a crawler and a clean browser now see one predictable first hop. We verified the live root response with ordinary requests, Googlebot requests, and different language headers. Each returned a 301 to the same English URL.

The fix does not require us to remove localized pages. Every locale still has its own URL. Language selectors and saved preferences still serve visitors. The change only makes the default entry path deterministic.

What we can conclude, and what we cannot

We can conclude that the old root redirect was a technical flaw. It used a temporary status for a permanent site structure and allowed the destination to vary by request location. The current behavior is easier for crawlers, external auditing tools, and humans to reason about.

We cannot conclude that the flaw caused the entire Ahrefs score change. We do not have a controlled experiment that isolates the redirect from changes in Ahrefs' index, the backlink graph, referring domains, or other site factors.

We also cannot claim a recovery before the data shows one. Shipping the fix is the start of observation, not the end of the story.

The responsible approach is to record the change date and watch several signals separately:

Domain Rating and the referring domains behind it
Newly discovered and lost backlinks
Search impressions and clicks from first party search data
Indexing and canonical selection for the root and locale pages
The redirect response seen from clean requests over time

If those signals improve together after the fix, the evidence becomes more interesting. It still needs cautious interpretation.

A practical redirect audit

You do not need a large SEO platform to catch this class of problem. Start with the HTTP response itself.

Request the root URL without cookies and record the status and Location header.
Repeat the request with different language headers and, if possible, from different regions.
Confirm that permanent public routes have one deterministic destination.
Follow the chain and check that it ends without extra hops or loops.
Inspect the final page's canonical and alternate language links.
Test a returning visitor with an explicit locale preference separately.
Save the result and the deployment date so later metric changes have context.

A useful command line check is deliberately boring:

curl -I https://example.com/

Then vary only one input at a time. Add an Accept-Language header. Use a clean cookie jar. Run the request from another region. If the public URL is supposed to have a single canonical destination, the first hop should not become a geography lottery.

The broader lesson

Metric drops create pressure for a quick story. A quick story is often where a technical observation becomes an unsupported causal claim.

The better sequence is slower and more useful:

Confirm what the metric measures.
Inspect the system for concrete defects.
Fix defects because they are defects.
Separate verified behavior from hypotheses about impact.
Watch primary and third party signals after the change.

Our Domain Rating drop led us to a real redirect problem. Correcting that problem gave the site a stable canonical entry path. Whether it explains the score movement remains an open question, and we would rather leave that question open than manufacture certainty.

That is the kind of debugging record we trust: exact about the code, careful about causation, and clear about what to measure next.

Sources

Traffic increased 18 percent is not an insight

Zenovay — Thu, 06 Aug 2026 20:13:43 +0000

Traffic increased 18 percent. Compared with what? Driven by whom? Did those visitors do anything useful? Is the change large enough to matter, and what should someone inspect next?

Until those questions have answers, 18 percent is a measurement. It is not an insight.

This distinction matters because analytics products are getting better at turning charts into sentences. A sentence feels more complete than a chart label, but grammar does not create judgment. If a tool only restates the visible movement, it has saved you a glance and left the actual analysis untouched.

The 18 percent in this article is an illustrative example. It is not a Zenovay traffic result.

An observation is not a decision

Suppose a dashboard compares the last seven days with the seven days before them and reports:

Traffic increased 18 percent.

That statement answers one narrow question: how did the total change between two windows?

It does not tell you whether the earlier week was unusually quiet, whether one campaign created the increase, whether bot traffic distorted the count, whether the lift came from a useful market, or whether any of the new visitors engaged or converted.

The number can be correct and still be unhelpful.

The minimum useful unit is not a percentage. It is a chain:

Observation: What changed, and by how much?
Context: Compared with which baseline, over which period, and with what normal variation?
Explanation: Which segments changed enough to plausibly account for the movement?
Impact: Did the change affect a business outcome or only a surface metric?
Next check: What should a person inspect or test now?

That chain does not need to be long. It needs to be honest.

Start with a baseline that deserves trust

The previous period is convenient, but it is not always representative. A product launch, holiday, outage, paid campaign, or unusually strong post can make one week a poor baseline for the next.

A better comparison uses recent history and keeps the time windows equivalent. For example, compare Tuesday through Monday with several previous Tuesday through Monday windows. If the business has a strong weekday pattern, comparing a Monday with a Sunday produces noise that looks like news.

In Zenovay's current insight service, expected values are calculated from up to four recent nonempty weekly periods, with more weight given to the most recent weeks. The same service keeps the latest week available as a separate comparison. That design does not make the baseline perfect, but it makes a single unusual week less powerful.

The practical question is simple: would the statement still look interesting if you changed the baseline?

If an 18 percent rise becomes 2 percent against the recent average, the story changes. If it remains 18 percent across several sensible comparisons, it deserves attention.

Decompose the total before you explain it

Aggregate traffic is where analysis starts, not where it ends. The next step is to find where the change lives.

Useful cuts often include:

Referrer or campaign
Landing page
Country or region
Device type
New and returning visitors
Engagement or value segment

Imagine the total grew 18 percent, but almost all of the additional visits came from one referral source and landed on one article. That is a much more useful observation. It narrows the search and gives the team something concrete to inspect.

Now compare that source with the rest of the traffic. Did its visitors interact? Did they reach important pages? Did they complete a goal? A volume increase with weaker visitor quality can be less valuable than a smaller increase from a source that reaches the intended audience.

Zenovay's current insight path assembles total visitors, engagement rate, average value score, the share of high value visitors, and leading countries, devices, referrers, and landing pages before it asks for an interpretation. Those fields reflect what the code actually provides today. They are context for analysis, not proof of causation.

Treat causes as hypotheses

This is where many automated summaries become overconfident.

If traffic rose after a campaign launched, the campaign may have contributed. The timing alone does not prove that it caused the full increase. Organic search, a referral, a returning audience, a tracking change, or simple variation may also be involved.

A responsible insight separates evidence from inference:

Evidence: Visits from the campaign source rose during the period and account for most of the total increase.

Hypothesis: The campaign is the leading explanation for the lift.

Check: Compare tagged campaign visits, landing pages, engagement, and goal completions with the prior baseline.

That wording is slightly less dramatic. It is also far more useful because it tells the reader how to prove or reject the explanation.

Connect traffic to an outcome

More visits are not automatically good. They can be useful, irrelevant, expensive, accidental, or fraudulent. The meaning depends on what the site is meant to achieve.

For a content site, the next signal might be meaningful interaction or a return visit. For a product site, it might be a signup, an activated account, or a qualified lead. For commerce, it might be revenue, order value, or a completed checkout.

This is why the phrase “traffic increased 18 percent” feels unfinished. It describes movement at the top of a system while ignoring what happened next.

A better statement might read:

Traffic was 18 percent above the recent weekly baseline. Most of the lift came from one referral source and one landing page. Those visitors engaged at a lower rate than the site average, so check the source message and landing page fit before increasing spend.

That example contains a baseline, a segment, an outcome, and a next action. It still avoids claiming a cause that the data has not established.

Give every insight a next check

An insight should reduce the distance between noticing and deciding. If the reader still has to ask “so what do I do now?”, the summary stopped too early.

The next step should be specific enough to perform and modest enough to trust. Good examples include:

Compare the leading source with the recent weekly baseline
Open the landing page that received the new traffic
Check engagement and goal completion for that segment
Verify whether a campaign, release, or tracking change happened in the same window
Watch the pattern for another equivalent period before changing budget

Zenovay's current AI insight format includes a metric name, current value, expected value, percentage change, description, severity, and recommendation. Its chart narrative path also combines trend, peak, low, recent data points, and a requested action. If the AI service is unavailable, the product can fall back to rule-based summaries. These implementation details matter because a useful product needs a defined output contract, relevant evidence, and a graceful failure mode. A clever sentence alone is not enough.

A five question test for any AI insight

Before acting on an automated insight, ask:

What exactly changed? The metric, window, and amount should be explicit.
What is the baseline? Previous period, recent average, forecast, or benchmark should not be hidden.
Where did the change happen? Look for the source, page, device, geography, or visitor segment that explains the aggregate.
What evidence supports the explanation? Timing is useful evidence, but it is not causation.
What is the next check? The recommendation should be concrete and reversible when confidence is limited.

If a statement fails these questions, treat it as a notification. Notifications can still be valuable. They tell you where to look. They should not pretend the looking has already been done.

The standard is useful uncertainty

Good analytics does not eliminate uncertainty. It makes uncertainty visible and gives you a better next move.

“Traffic increased 18 percent” sounds certain because the number is precise. The important parts remain uncertain: why it changed, whether it matters, and whether it will persist.

A useful insight keeps the exact observation, adds the strongest available context, labels any explanation as a hypothesis, connects the change to an outcome, and proposes the next check.

That is the difference between a chart rewritten as a sentence and analysis that helps someone decide.

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