DEV Community: 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.

Stripe revenue attribution in a cookieless world. The webhook patterns that hold up

Zenovay — Tue, 26 May 2026 21:30:29 +0000

Tying a stripe payment back to the marketing channel that produced it is a classic problem. The classic solutions all rely on third party cookies or shared identifiers across tools. Neither survives 2026.

I built revenue attribution into Zenovay (cookieless web analytics) and the implementation had more gotchas than expected. Sharing the patterns that ended up holding.

The minimal viable attribution flow

browser     analytics worker     stripe checkout     stripe webhook
  |              |                    |                    |
  | sessionId    |                    |                    |
  |------------->|                    |                    |
  |                                                        |
  | redirect to checkout with sessionId in metadata        |
  |------------------------------>                         |
  |                                   payment              |
  |                                   --->                 |
  |                                          fires event   |
  |                                          ----------->  |
  |                                              read sessionId
  |                                              attribute revenue

Step 1, injecting sessionId into stripe metadata

// in the customer's checkout creation code
const sessionId = window.zenovay?.sessionId();

const checkout = await stripe.checkout.sessions.create({
  line_items: [...],
  mode: 'payment',
  metadata: {
    zenovay_session_id: sessionId,
    zenovay_utm_source: window.zenovay?.attribution()?.utmSource,
    zenovay_first_seen: window.zenovay?.attribution()?.firstSeen,
  },
  success_url: 'https://example.com/success',
  cancel_url: 'https://example.com/cancel',
});

This is a one line integration for the customer. The js sdk exposes sessionId and attribution helpers. Everything else flows from these few fields landing in stripe metadata.

Step 2, the webhook handler

export async function handleStripeWebhook(req: Request, env: Env): Promise<Response> {
  const sig = req.headers.get('stripe-signature') ?? '';
  const body = await req.text();

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(body, sig, env.STRIPE_WEBHOOK_SECRET);
  } catch {
    return new Response('invalid signature', { status: 400 });
  }

  if (event.type === 'checkout.session.completed') {
    const session = event.data.object as Stripe.Checkout.Session;
    await attributeRevenue(env, {
      sessionId: session.metadata?.zenovay_session_id,
      amount: session.amount_total,
      currency: session.currency,
      stripeEventId: event.id,
      utmSource: session.metadata?.zenovay_utm_source,
    });
  }

  if (event.type === 'charge.refunded') {
    await reverseAttribution(env, event.data.object.payment_intent as string);
  }

  return new Response('ok');
}

Step 3, idempotency

Stripe retries webhooks. You will receive the same event multiple times. Always idempotent by event.id:

async function attributeRevenue(env: Env, data: AttributionInput) {
  const seen = await env.KV.get(`stripe:event:${data.stripeEventId}`);
  if (seen) return;

  await env.DB.prepare(
    `INSERT INTO revenue_attribution
     (session_id, amount, currency, utm_source, stripe_event_id, created_at)
     VALUES (?, ?, ?, ?, ?, ?)`
  )
  .bind(data.sessionId, data.amount, data.currency, data.utmSource, data.stripeEventId, Date.now())
  .run();

  await env.KV.put(`stripe:event:${data.stripeEventId}`, '1', { expirationTtl: 86400 * 30 });
}

The five non obvious gotchas

checkout.session.completed does not fire for direct charge api usage. If your customers do not all use stripe checkout, you also need to listen to payment_intent.succeeded and look up metadata from there.
Subscriptions. checkout.session.completed fires once. invoice.paid fires every cycle. Decide which is your 'attribution event'. We attribute the first, separately track recurring as ltv.
metadata is string only. Numbers and booleans become strings. Convert when reading.
Stripe metadata has a 500 character limit per value, 50 keys max. You will hit this if you try to dump the entire attribution object. Pick the few fields you really need.
Webhook signature validation must use the raw body, not the parsed json. Most frameworks have to be told this explicitly.

Reversals on refunds

Charge refunded fires charge.refunded. Use the payment_intent field to find the original attribution row and either soft delete it or write a negative attribution event. We chose soft delete with an revoked_at field. Easier to audit.

The data model

Keep it simple. One row per attributed revenue event. Index by session_id and by created_at for the common queries. Roll up nightly into the channel reports.

I build Zenovay. Cookieless web analytics with stripe revenue attribution as the default view, not an addon.

Real time event streams with Cloudflare Durable Objects, the missing tutorial

Zenovay — Mon, 25 May 2026 10:29:50 +0000

Most tutorials for real time on Cloudflare jump straight to Pages + Pusher or to a third party broker. Durable Objects do the job natively, are stateful, and the cost is great if you keep the connection pattern simple. The catch is that the official docs are correct but not opinionated enough for someone shipping their first one.

I learned this building Zenovay (cookieless web analytics) where we needed events tail to stream live visitor events into a browser dashboard and into our cli. Same source of truth, two consumers, low latency.

Here is the pattern that ended up working, end to end.

The architecture

[ browser sdk ]                                  [ dashboard ws client ]
      |                                                  ^
      v                                                  |
[ ingest worker ] -> [ durable object per site ] -> [ ws / sse fanout ]
                                  |
                                  v
                          [ d1 / r2 for storage ]

One durable object per site. The DO holds the active websocket connections for that site's dashboards and forwards every ingested event to them. Storage is separate.

The Durable Object

export class SiteEventStream {
  state: DurableObjectState;
  sockets: Set<WebSocket> = new Set();

  constructor(state: DurableObjectState) {
    this.state = state;
  }

  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);

    if (url.pathname === '/subscribe') {
      return this.handleSubscribe(request);
    }
    if (url.pathname === '/publish') {
      return this.handlePublish(request);
    }
    return new Response('not found', { status: 404 });
  }

  handleSubscribe(request: Request): Response {
    const pair = new WebSocketPair();
    const [client, server] = Object.values(pair);
    server.accept();
    this.sockets.add(server);

    server.addEventListener('close', () => this.sockets.delete(server));
    server.addEventListener('error', () => this.sockets.delete(server));

    return new Response(null, { status: 101, webSocket: client });
  }

  async handlePublish(request: Request): Promise<Response> {
    const event = await request.json();
    const payload = JSON.stringify(event);
    for (const ws of this.sockets) {
      try {
        ws.send(payload);
      } catch {
        this.sockets.delete(ws);
      }
    }
    return new Response('ok');
  }
}

The ingest worker

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const event = await request.json();
    const siteId = event.siteId;

    const id = env.SITE_EVENTS.idFromName(siteId);
    const stub = env.SITE_EVENTS.get(id);

    await stub.fetch('https://do/publish', {
      method: 'POST',
      body: JSON.stringify(event),
    });

    return new Response('ok');
  }
};

Why one DO per site, not one global DO

Durable Objects are single threaded. A global DO would be a single bottleneck for every site's events. With one DO per site, sites scale horizontally and a noisy site does not starve a quiet one. The idFromName pattern means the same siteId always routes to the same DO instance.

The mistakes i made first

Trying to use the DO for both events and metric aggregation.
The DO became a complex state machine, hard to reason about, and any bug killed both real time and aggregation. Now: DO does fanout only. Aggregation is a separate worker.

Not cleaning up dead sockets.
If a dashboard closes its tab the websocket goes away but the DO does not know until it tries to send and fails. Always handle close and error events and remove from the set.

Holding too much state in the DO.
Durable Objects can hold state but they are not a database. We tried caching the last 1000 events. Memory pressure killed it. Now the DO is stateless except for the active sockets.

Latency

End to end (browser ingest to dashboard receive) is consistently under 100ms in our measurements. The DO adds maybe 5 to 10ms on top of the raw worker. Acceptable for the simplicity.

Where this approach breaks

It does not handle reconnection well. If a dashboard drops and reconnects, it misses events in the gap. For analytics this is fine (the data is still in d1). For something like chat you need a different design with a small replay buffer.

I'm Valerio, building Zenovay, a privacy first web analytics tool. If you want to see this pattern in action you can install the script and watch events tail light up in real time.

Building an MCP server so Claude can query my SaaS analytics directly

Zenovay — Sat, 23 May 2026 13:26:52 +0000

Last week I shipped a Model Context Protocol (MCP) server for my analytics SaaS. Now Claude Desktop, Cursor, and any MCP compatible client can query traffic, revenue, and funnel data directly.

This is a walkthrough of how I built it, what worked, and a couple of patterns that surprised me.

What MCP is, briefly

MCP is a protocol that lets AI clients invoke tools and read resources from external servers. Think of it as REST for LLM tool calling, with a stable schema and discovery.

Server skeleton

import { Server } from '@modelcontextprotocol/sdk/server/index.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'

const server = new Server({
  name: 'zenovay',
  version: '1.0.0',
}, {
  capabilities: {
    tools: {},
    resources: {}
  }
})

Defining tools

server.setRequestHandler('tools/list', async () => ({
  tools: [
    {
      name: 'get_traffic',
      description: 'Get pageview and visitor counts for a site over a date range',
      inputSchema: {
        type: 'object',
        properties: {
          site: { type: 'string' },
          from: { type: 'string' },
          to: { type: 'string' }
        },
        required: ['site', 'from', 'to']
      }
    }
  ]
}))

The pattern that surprised me: structured returns

Way better than raw JSON: return a short natural language summary plus the data. Claude uses the summary for its response and the JSON for follow up questions.

What I did not expect

Users started asking Claude to do things I had not built dashboards for:

"Compare my paid traffic conversion rate this week vs last week"
"Which 5 pages had the biggest week over week drop in pageviews"
"Summarize what changed in my funnel completion rate over the last 30 days"

Claude does this by chaining multiple tool calls. I did not need to build any of those views. The tools are atomic, Claude composes.

This is the part I think is genuinely new about MCP. The interface is the LLM, the backend is just well shaped tools.

Install

npm install -g @zenovay/mcp then add to your Claude Desktop config.

Site: zenovay.com

Open source MCP server work happening here too? Curious what patterns others have found.

Valerio

Cookieless web analytics: how it actually works under the hood

Zenovay — Fri, 22 May 2026 14:34:15 +0000

'Cookieless analytics' gets thrown around as a marketing term. What does it actually mean technically? How do you identify unique visitors without a cookie?

This post is a complete technical breakdown of how it works in Zenovay, in case you are building something similar or evaluating tools.

What a traditional analytics cookie does

In GA4 and most legacy tools:

Set-Cookie: _ga=GA1.2.1234567890.1697123456; Max-Age=63072000; Path=/

Two roles: unique identifier for the visitor + persistence across sessions.

The cookieless approach: ephemeral fingerprinting

Instead of storing an ID, generate one server-side per visit using non-identifying signals:

function generateVisitorId(request) {
  const signals = [
    request.headers.get('User-Agent'),
    request.headers.get('Accept-Language'),
    request.cf?.country,
    salt(getCurrentDay())
  ].join('|')

  return crypto.subtle.digest('SHA-256', new TextEncoder().encode(signals))
}

Key property: this ID cannot be reversed to identify the person, rotates daily, and is consistent within a single day for the same browser.

Sessions without cookies

A session in cookieless analytics is defined as: events from the same visitor ID within a 30-minute inactivity window. Handled server-side via Cloudflare KV with TTL.

The tracking script

Has to be tiny. Zenovay's is 1.4kb gzipped.

;(function() {
  const send = (type, data) => {
    fetch('https://e.zenovay.com/c', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        type,
        site: 'your-site-id',
        url: location.href,
        ref: document.referrer,
        ts: Date.now(),
        ...data
      }),
      keepalive: true
    })
  }

  send('pageview', {})
})()

Notice: no cookies set, no localStorage written, no fingerprinting library loaded.

What you give up

Cannot track returning visitors across days as the same visitor
Cannot do persistent A/B test assignment client-side
Cannot do detailed multi-session funnel analysis for anonymous users

What you keep: accurate per-session funnels, pageviews, events, bounce rate, per-day unique counts, path analysis, revenue attribution via auth bridge.

Why this matters

In typical European traffic, GA4 reports roughly 40–60% of actual sessions due to consent rejection. Cookieless reports close to 100% because there is nothing to consent to.

If you want to see this in action on a real product: zenovay.com

— Valerio

Building a terminal interface for my analytics SaaS with Cloudflare Durable Objects

Zenovay — Thu, 21 May 2026 12:44:08 +0000

Every analytics dashboard lives in a browser tab. My terminal is always open. So I built @zenovay/cli, a terminal interface for my analytics SaaS.

The killer command is zenovay events tail: a live stream of pageviews and events, filterable, pipeable, scriptable. Think stripe listen but for your web traffic.

This post covers how the live tail actually works.

The product surface

$ zenovay events tail --site mysite.com --path /pricing
[14:32:18] mysite.com  pageview  /pricing               US  Chrome
[14:32:21] mysite.com  pageview  /pricing               DE  Firefox
[14:32:24] mysite.com  click     /pricing#cta-pro       US  Chrome
[14:32:28] mysite.com  pageview  /pricing               GB  Safari

You can pipe it:

$ zenovay events tail --site mysite.com | jq .country | sort | uniq -c

The architecture

Three components:

CLI binary (TypeScript, distributed via npm)
WebSocket gateway (Cloudflare Worker with Durable Objects)
Event broadcast (Workers pushing to subscribed Durable Objects)

The Durable Object as fanout point

Each tracked site gets a Durable Object that holds the list of active WebSocket subscribers.

export class SiteStream {
  constructor(private state: DurableObjectState) {
    this.sockets = new Set<WebSocket>()
  }

  async fetch(request: Request) {
    if (request.headers.get('Upgrade') === 'websocket') {
      const pair = new WebSocketPair()
      this.handleSocket(pair[1])
      return new Response(null, { 
        status: 101, 
        webSocket: pair[0] 
      })
    }

    if (request.method === 'POST') {
      const event = await request.json()
      this.broadcast(event)
      return new Response('ok')
    }
  }

  broadcast(event: unknown) {
    const data = JSON.stringify(event)
    for (const ws of this.sockets) {
      try { ws.send(data) }
      catch { this.sockets.delete(ws) }
    }
  }
}

The CLI side

Built with Commander for argument parsing and just plain WebSocket for the stream. Catppuccin Mocha palette via chalk hex codes.

Install

npm install -g @zenovay/cli
zenovay auth login
zenovay events tail --site yoursite.com

Free tier of Zenovay includes the CLI. Site is zenovay.com.

Anyone else building TUIs for SaaS products? Curious what patterns you have found.

Valerio

Building a live 3D globe of real time web traffic with Three.js and Server Sent Events

Zenovay — Wed, 20 May 2026 12:05:41 +0000

For the new Zenovay landing page I built a 3D globe that shows actual live visits from customer sites in close to real time. Dots glow and fade where visits happen.

This post is a complete walkthrough of how it's built, in case you want to do something similar.

What you see vs what it actually is

What the visitor sees: a smooth spinning Earth with bright dots appearing in different countries every few seconds.

What it actually is:

A THREE.SphereGeometry with an Earth texture
A THREE.Points instance updated in place as events arrive
A custom GLSL fragment shader for the glow effect
Server Sent Events streaming batched data from Cloudflare Workers
Lazy initialization to keep LCP fast

The data flow

Visitor on customer site
  -> Tracking script POSTs event to Cloudflare Worker (sub 100ms)
  -> Worker pushes to Queue
  -> Consumer aggregates per region every 2s
  -> SSE stream pushes to landing page
  -> Three.js animates new dot

The points system (the tricky part)

Points need to appear, glow, and fade. Re creating geometry every event is too expensive. Instead, allocate a fixed buffer and reuse slots.

buildPointsSystem() {
  this.maxPoints = 1000
  this.points = new Float32Array(this.maxPoints * 3)
  this.lifetimes = new Float32Array(this.maxPoints)
  this.cursor = 0

  this.pointsGeometry = new THREE.BufferGeometry()
  this.pointsGeometry.setAttribute('position', 
    new THREE.BufferAttribute(this.points, 3))
  this.pointsGeometry.setAttribute('lifetime', 
    new THREE.BufferAttribute(this.lifetimes, 1))
}

addPoint(lat, lng) {
  const [x, y, z] = latLngToVec3(lat, lng, 5.05)
  const i = this.cursor * 3
  this.points[i] = x
  this.points[i + 1] = y
  this.points[i + 2] = z
  this.lifetimes[this.cursor] = 1.0
  this.cursor = (this.cursor + 1) % this.maxPoints
  this.pointsGeometry.attributes.position.needsUpdate = true
}

The glow shader

// Vertex shader
attribute float lifetime;
varying float vLifetime;

void main() {
  vLifetime = lifetime;
  vec4 mvPosition = modelViewMatrix * vec4(position, 1.0);
  gl_PointSize = 8.0 * lifetime;
  gl_Position = projectionMatrix * mvPosition;
}

// Fragment shader
varying float vLifetime;

void main() {
  vec2 center = gl_PointCoord - vec2(0.5);
  float dist = length(center);
  if (dist > 0.5) discard;

  float intensity = 1.0 - smoothstep(0.0, 0.5, dist);
  vec3 color = mix(vec3(0.3, 1.0, 0.7), vec3(0.5, 1.0, 0.9), vLifetime);
  gl_FragColor = vec4(color, intensity * vLifetime);
}

Coordinates: lat/lng to 3D

function latLngToVec3(lat, lng, radius) {
  const phi = (90 - lat) * (Math.PI / 180)
  const theta = (lng + 180) * (Math.PI / 180)
  return [
    -radius * Math.sin(phi) * Math.cos(theta),
    radius * Math.cos(phi),
    radius * Math.sin(phi) * Math.sin(theta)
  ]
}

Performance notes

THREE.Points with BufferGeometry keeps GPU memory stable
Fixed size buffer avoids GC pressure
Pixel ratio capped at 2 (no point rendering 3x on retina)
Lazy initialization: globe loads after main content paint
60fps on iPhone 12, ~45fps on a 5 year old budget Android

See the final result on the landing page: zenovay.com

If you want the full source as a template, drop a comment and I'll open source it.

Valerio

Achieving sub 100ms response times at the edge with Cloudflare Workers: lessons from analytics in production

Zenovay — Tue, 19 May 2026 18:29:41 +0000

Running web analytics ingestion at the edge sounds simple. POST event, write to database, return 200. The reality has more nuance.

This is a technical writeup of how Zenovay (my analytics SaaS) handles 50M+ monthly events with sub 100ms p99 response times globally on Cloudflare Workers.

The naive version

export default {
  async fetch(request, env) {
    const event = await request.json()
    await env.DB.prepare(
      'INSERT INTO events (...) VALUES (...)'
    ).bind(...).run()
    return new Response('ok')
  }
}

This works. It also blocks the response on a database write. P99 latency was 280ms.

Step 1: Decouple the write

Workers have ctx.waitUntil() which lets you do work after returning the response.

export default {
  async fetch(request, env, ctx) {
    const event = await request.json()
    ctx.waitUntil(persistEvent(event, env))
    return new Response('ok', { status: 202 })
  }
}

Response time dropped to ~40ms. But now you have a reliability question: what if the worker dies before the write completes?

Step 2: Queue the write

Cloudflare Queues turned out to be the right abstraction. Workers push events to a queue, a consumer worker handles writes in batches.

P99 now 38ms. Throughput went up because batched inserts are way more efficient than single row inserts.

Step 3: Edge caching for reads

The dashboard side has different constraints. Most dashboard queries can tolerate 5 to 10 seconds of staleness.

Workers KV is too slow for this (read latency ~50ms). Cache API on the response is way faster.

const cache = caches.default
const cacheKey = new Request(url, request)

let response = await cache.match(cacheKey)
if (!response) {
  response = await fetchFromOrigin(request, env)
  response.headers.set('Cache-Control', 's-maxage=10')
  ctx.waitUntil(cache.put(cacheKey, response.clone()))
}
return response

Dashboard query P99 went from 180ms to 22ms cached, 95% cache hit rate.

Step 4: Geographic routing

One thing that surprised me: even with edge workers, your D1 or origin database location matters. A worker in Singapore writing to a D1 instance in Frankfurt adds ~180ms latency.

For Zenovay I run regional write workers that funnel to the closest D1 replica, then async sync to the primary. This is more complex but cut p99 in APAC from 240ms to 75ms.

Numbers in production

P50 response: 18ms
P95 response: 62ms
P99 response: 89ms
Cache hit rate (dashboard): 95.4%
Cost per million events: ~$0.42

If you want to see this in action: zenovay.com. The 3D globe on the homepage is showing live events flowing through this exact pipeline.

Valerio

How I rebuilt my SaaS landing page in 6 weeks: Essential lessons for developer founders

Zenovay — Thu, 14 May 2026 16:01:32 +0000

I'm a developer founder.

I love writing code. I hate writing copy. For 8 months I shipped features and ignored my landing page.

My conversion rate was 0.5%. I was confused why "such a powerful product" was not selling.

Then I spent 6 weeks rebuilding the landing page from scratch. Conversion is now roughly 3x. Same product. Different page.

This is what I learned, focused on the technical and decision making side, since most "landing page tips" articles are written by marketers and miss the developer perspective.

The shift in mental model

The first thing I had to accept: a landing page is a piece of software with one job. Get the right visitors to take one action. It should be debugged, profiled, and iterated like any other code.

Once I treated it like code, the whole rewrite became tractable.

Stack choices that matter

For Zenovay's new landing page I went with:
Next.js 15 (App Router)
Tailwind 4
Three.js (raw, not R3F)
Cloudflare Pages for hosting
Cloudflare Workers for the live data stream

Three things drove these choices:

Edge first. The page needs to load fast in every geography. Cloudflare Pages plus Workers means sub 100ms TTFB worldwide.
No framework lock in on the hero animation. Raw Three.js gave me 60fps with ~5000 dots. React Three Fiber added overhead I did not need.
Tailwind 4's new engine cut my CSS bundle by ~40% over what I had with Tailwind 3.

The hero is the entire pitch

For an analytics product, the natural hero is a screenshot of the dashboard. That is what I had for months.

I replaced it with a live 3D globe showing actual incoming visits from real customer sites. Same data the dashboard shows, but in motion, in 3D, instantly.

Here's the simplified Three.js setup for the globe:

import * as THREE from 'three'

const scene = new THREE.Scene()
const camera = new THREE.PerspectiveCamera(45, aspect, 0.1, 1000)
const renderer = new THREE.WebGLRenderer({ 
  antialias: true, 
  alpha: true 
})

// Globe sphere
const globe = new THREE.Mesh(
  new THREE.SphereGeometry(5, 64, 64),
  new THREE.MeshBasicMaterial({ 
    map: earthTexture,
    transparent: true,
    opacity: 0.9
  })
)
scene.add(globe)

// Points for visits, custom shader for glow
const pointsGeometry = new THREE.BufferGeometry()
const pointsMaterial = new THREE.ShaderMaterial({
  vertexShader: glowVertexShader,
  fragmentShader: glowFragmentShader,
  transparent: true
})

The events come in via Server Sent Events from Cloudflare Workers, batched every 2 seconds.

Performance budget

I gave myself a hard performance budget for the new page:

LCP under 1.5s on a midrange phone
CLS under 0.05
JS bundle under 180kb gzipped
Three.js scene under 60fps target

Final numbers: LCP 1.2s, CLS 0.02, JS 167kb, Three.js scene 58 to 60fps on iPhone 12.

What I would do differently

Start with the hero animation. I built the hero last, which meant the rest of the design had to bend around it. Building the visual first would have saved me 2 rewrites.
Write copy before opening Figma. I designed 3 versions with placeholder text. All 3 broke when I wrote real copy.
Test on slow networks earlier. My LP felt fast on fiber. On 4G with throttled CPU, the Three.js initial paint was a problem. Lazy loading the globe below initial paint fixed it.

If you want to see the result: zenovay.com (there is an interactive demo)

Questions about any of the technical pieces, drop them below. Happy to share more detail on the SSE batching, the binary event format, or the shader work.

The "Privacy-First" Mirage: Why Your Analytics Hash is Still Fingerprinting

Zenovay — Thu, 16 Apr 2026 19:12:02 +0000

"Privacy-first" has become the favorite marketing buzzword for every new analytics tool. But as developers, we shouldn't trust the landing page we should trust the implementation.

I've been building Zenovay, a lean alternative to the GA4 nightmare, and I spent a lot of time auditing how "privacy-friendly" tools actually handle visitor identity. What I found was a lot of "Fingerprinting Lite" masquerading as privacy.

The Trap: User Agent Persistence

Most indie analytics tools use a hash to identify unique visitors without storing an IP. You'll often see logic similar to this in their backends (let's call this the "GhostlyX" approach):

// The problematic approach
$visitorHash = hash_hmac('sha256', $ip . $ua . $site->id . $today, config('app.key'));

The issue is the $ua (User Agent). By including the User Agent in the hash, you are effectively fingerprinting the user's device.

If a user moves from their home Wi-Fi to a 5G network, their IP changes but their User Agent stays identical. The tool can still link those sessions. This creates a persistent identifier that survives network changes, which is exactly what "privacy-first" is supposed to prevent.

A Cleaner Approach: Daily Rotating Salts

When we built the tracking engine for Zenovay, we decided: if the data is supposed to be anonymous, it should be actually anonymous. No fingerprints. No persistence beyond 24 hours.

We use the Web Crypto API (available natively in edge environments like Cloudflare Workers) to process the IP the millisecond it hits our server.

The Implementation

async function hashIPForVisitor(ip: string, websiteId: string): Promise<string> {
    // Daily salt ensures no long-term tracking
    const today = new Date().toISOString().slice(0, 10); // YYYY-MM-DD

    const encoder = new TextEncoder();
    // We combine IP, Website ID, and the daily salt.
    // NOTICE: No User Agent. No device fingerprinting.
    const data = encoder.encode(`${ip}|${websiteId}|${today}`);

    const hashBuffer = await crypto.subtle.digest('SHA-256', data);
    const hashArray = Array.from(new Uint8Array(hashBuffer));

    return hashArray
        .map(b => b.toString(16).padStart(2, '0'))
        .join('');
}

Why this is technically superior:

Zero Persistence Because we include ${today}, the hash for the same visitor changes at midnight. We have no way of "following" a user across multiple days.

No Fingerprinting By omitting the User Agent, we ensure we're only measuring "a connection at a specific time," not "a specific device."

Database Integrity In our Supabase schema, ip_address is hard-coded to null. The raw IP never touches the disk.

const visitorHash = await hashIPForVisitor(clientIP, website.id);

await supabase.from('hits').insert({
    website_id: website.id,
    ip_hash: visitorHash,
    ip_address: null, // Raw IP is never stored
    pathname: request.url.pathname,
    // ...
});

The Architecture: Cloudflare + Supabase + Next.js

Building on a modern edge stack allowed us to keep the entire tracking script under 1KB.

Cloudflare Workers Handle incoming requests and hash at the edge, before any data leaves the user's network hop.
Supabase (PostgreSQL) Stores hashed events. No bloated tracking data means queries stay fast even at millions of rows.
Next.js (App Router) Powers the dashboard, connecting hits to real-time Stripe revenue attribution.

Privacy Marketing vs. Privacy Engineering

The difference comes down to transparency. If a tool doesn't tell you exactly how they generate visitor IDs, they're probably fingerprinting you.

Real privacy isn't about obfuscating data it's about making sure sensitive data is gone before it ever hits your database.

I'm bootstrapping Zenovay to prove that you can get world-class business insights and revenue attribution without turning your users into a product.

How are you handling PII in your tracking stacks? Are you using the Web Crypto API or sticking to traditional server-side hashing? Drop it in the comments.