DEV Community: Zenovay

Running A/B tests on top of edge feature flags

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

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

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

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

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

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

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

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

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

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

Log exposure, not just conversion (bug #2)

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

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

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

Measuring the result

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

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

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

When not to roll your own

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

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

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

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

Filtering bot and spam traffic out of your analytics

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

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

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

With bots (inflated):

Bots filtered out (honest):

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

Layer 1: it never ran JavaScript

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

Layer 2: obvious user agent signatures

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

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

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

Layer 3: datacenter and known ranges

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

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

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

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

Layer 4: behavior that is not human

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

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

Putting it together

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

The decision that matters: drop or flag

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

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

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

Retention cohort analysis with plain SQL

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

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

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

The idea

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

The two inputs

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

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

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

Turning counts into retention percent

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

The mistake that breaks it

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

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

Making it fast

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

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

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

Lightweight client side error tracking without a 90kb SDK

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

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

Capture the two events that matter

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

const queue: CapturedError[] = [];

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

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

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

Batch, debounce, and survive unload

let timer: number | undefined;

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

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

addEventListener("pagehide", flush);

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

Do not drown in noise

Two cheap filters save you from a flood:

const seen = new Set<string>();

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

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

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

The one thing you actually need a server for

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

Takeaway

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

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

Building session replay that masks input data by default

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

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

What session replay actually is

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

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

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

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

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

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

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

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

Step 3: record mutations, not frames

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

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

Step 4: batch and send, do not flood

let buffer: ReplayEvent[] = [];

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

setInterval(flush, 5000);

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

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

Things that bit us

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

Takeaway

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

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

Scoring anonymous web visitors without storing personal data

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

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

The goal

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

The signals that actually correlate

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

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

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

The scoring function

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

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

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

Running it at the edge on the event stream

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

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

When we switch to a learned model

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

The honest limitations

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

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

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

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

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

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

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

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

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

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

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

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

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

The redesign

New version:

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

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

Why this took 4 years across the industry to figure out

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

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

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

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

The pattern I'm trying to follow now

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

Counter argument I can hear

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

Real question for the thread

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

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

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

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

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

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

What i underestimated

The time required to actually do distribution well.

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

The cost of context switching.

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

How much hand drafting matters.

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

The slow accumulation of cred.

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

What i overestimated

The importance of the perfect post.

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

The reach of any single platform.

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

The persuasive power of features.

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

What i changed mid stream

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

The hardest part

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

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

What i'd tell my earlier self

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

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

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