DEV Community: Zenovay

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.

Why I Ditched GA4 for a Custom Next.js + Supabase Analytics Stack

Zenovay — Tue, 14 Apr 2026 19:38:04 +0000

Why I Ditched GA4 for a Custom Next.js + Supabase Analytics Stack

Let's be honest: GA4 is a nightmare for developers.

It's built for enterprise marketing teams. For those of us building micro-SaaS or lean startups, it feels like flying a Boeing 747 just to go to the grocery store. I spent more time debugging my tracking than building my product. So, I simplified everything.

The Problem: "Tracking Debt"

Most projects end up with a mess of scripts:

GA4 for traffic.
Clarity for heatmaps.
Stripe for the actual money.

Each script adds weight to your LCP and complicates your privacy policy. Worst of all: these tools don't talk to each other. You see a spike in traffic but have no idea if those users actually paid.

The Technical Stack

I wanted something fast, serverless-first, and scalable:

Frontend: Next.js (App Router)
Database: Supabase (PostgreSQL)
Backend: TypeScript
Infrastructure: Cloudflare

The Solution: Contextual Analytics

I built a custom dashboard to answer three questions in one place:

1. Technical Health vs. Revenue

One thing GA4 misses is the link between Core Web Vitals and Revenue. By measuring LCP and CLS directly within user sessions, I can see if a slow deployment actually cost me money in real-time.

2. The Stripe Link

Client-side event tracking often fails. By connecting directly to the Stripe API, I see the Real Lifetime Value (LTV) of a traffic source. If a Reddit post brings in 1,000 visitors but $0, and a niche newsletter brings in 10 visitors and 5 customers, I need to know that instantly.

3. The "Single Script" Philosophy

I replaced the bloat with one lightweight script. No manual event configuration for every button. It captures the interaction layer automatically for heatmaps and replays.

// Simple implementation
import { Analytics } from 'your-custom-tracker';

const Track = () => (
  <Analytics 
    projectId="your_id" 
    trackRevenue={true} 
    captureHeatmaps={true} 
  />
);

Conclusion

We've reached a point where analytics tools are more complex than the products we build. If you're feeling overwhelmed by GA4, you're not alone.

The real question isn't which tool has the most features — it's which tool actually answers your questions. For micro-SaaS, that usually means: who visited, did they pay, and did my latest deploy break anything? A custom stack built on Next.js and Supabase can answer all three in one place, without the overhead of stitching together five different dashboards.

What's your biggest pain point with modern analytics? Do you prefer specialized tools or a consolidated view?

More about this implementation: Zenovay Introduction

94% of my traffic shows as direct. Here's what I found

Zenovay — Mon, 06 Apr 2026 21:21:10 +0000

I have been tracking my own website zenovay.com for about 30 days now. Here is what the channel breakdown looks like:

Direct: 402
Organic Search: 24
Referral: 2
Organic Social: 1
Paid Search: 1
Paid Social: 1

94% Direct. on a site I was actively promoting on Reddit, X, Indie Hackers, and a bunch of Slack and Discord communities during that same period. that felt way too high so I started poking around.

First thing I realized is dark social is eating my attribution alive. Every link I dropped in slack channels, Discord servers, DMs, private newsletters, none of that carries a referrer header. It all gets dumped into direct. I estimate at least half of that direct bucket is actually community traffic that just can't be attributed properly. Which means I have no idea which community is actually driving results and which ones I am wasting time in.

Second thing that jumped out was singapore showing up as one of my top countries with 50 visits. I have zero audience there. Never promoted there. Never even thought about that market.

Pulled up the session data and it was obvious. Single pageview visits, all under 5 seconds, same Chrome Windows combo. Bots or crawlers running from Singapore based infrastructure. Probably inflating my numbers by 12%. I would have never noticed if I hadnt looked at the geo data and sessions together.

Third thing was kind of an accident. While I was digging through all this I noticed my performance had spiked on a couple of days. Out of curiosity I cross referenced those dates with my cohort retention data.

The Mar 9 cohort that signed up during that performance spike had a 2.2% week 1 retention. The Mar 2 cohort when everything was normal had 26.3%. Same product, same onboarding, same everything. The only difference was that half the Mar 9 users were probably staring at a blank screen and bouncing before the page even rendered.

I would have spent weeks trying to figure out why that cohort churned. Blaming the onboarding, the copy, the pricing. Turns out it was just a slow page.

The thing that bugs me most is that in most setups these metrics live on completely different screens. Your traffic data is in one tool, your performance data is somewhere else, your retention is in a third place. You would have to manually line up the dates to even notice the correlation. Most people never would.

Anyway three things I am taking away from this:

Direct over 30% is not a channel report, it is a data quality problem. If you are not investigating what is hiding in there you are making decisions on incomplete data.

Bot traffic from cloud regions like Singapore will quietly inflate everything if you dont filter it. Especially on smaller sites where a few dozen fake sessions actually move the percentages.

Performance and retention need to be visible together. If your performance drops and your retention drops the same week and you can't see both on one screen, you will blame the wrong thing every time.

Curious what your Direct percentage looks like. Anyone else tried to actually break down what is actually hiding in there?

Stop asking users for "steps to reproduce". just watch their session break in real time

Zenovay — Sat, 04 Apr 2026 15:47:58 +0000

The absolute worst message you can get from a user is "the checkout is broken" with zero additional context. no browser info, no console logs, nothing.

You end up staring at ga4 trying to figure out where the drop off happened but aggregate data is completely useless for debugging a frontend issue. you cant see if it was an api timeout, a hidden element or just a user doing something weird.

We were dealing with this exact headache a few weeks ago. we had users bouncing at the pricing page and no idea why.

Instead of guessing we started using session recordings combined with error tracking. we literally watched the playbacks of users getting stuck and saw exactly what was triggered. it turned out to be a clunky layout bug on specific mobile viewports that we missed. fixed it in 10 minutes and conversions went up.

This is exactly why we built zenovay. if you look at our sidebar we specifically put "Errors" and "Sessions" right next to each other. the goal was to stop switching between an analytics tool, a heatmap tool and an error monitoring tool.

We just wanted a simple dashboard where you see an error spike, click it and watch the exact session of the user who triggered it.

Right now we are a tiny bootstrapped team of developers trying to build an alternative to the massive google monopoly. it is really tough. we have fewer than 200 users and we are trying to get honest feedback from other devs.

We have a free tier that gives you the core tracking. if any of you are willing to drop our script into a side project and test out the error tracking and session replays, let me know. ill happily upgrade your account to the pro plan for a few months in exchange for some honest, constructive roasting of our ui and workflow.

This isnt about self promotion. its about taking on monopoly power and building a tool that actually saves developers time. we are grateful for any feedback.

Zenovay vs PostHog: marketing analytics vs product analytics (and why it matters)

Zenovay — Thu, 02 Apr 2026 06:55:28 +0000

PostHog and Zenovay get compared a lot, but they are solving fundamentally different problems.

PostHog answers: "Which features retain users? Where do people drop off in the onboarding flow? Does variant B of the signup page convert better?"

Zenovay answers: "Which marketing channels bring paying customers? How do visitors from Twitter behave differently from organic visitors? Which blog post generated the most revenue?"

Product analytics vs marketing analytics. Engineering teams vs founders and marketers. If you pick the wrong one, you will be frustrated.

Where PostHog is genuinely better

PostHog has a generous free tier: 1 million events per month. For early-stage startups with engineering resources, that is real value.

Feature flags and A/B testing are built in. You can roll out features gradually, test variants, and measure impact without a separate tool. Zenovay does not offer these because they are product tools, not marketing tools.

PostHog is open source under MIT license. You can self-host, audit the code, and contribute. Their developer community is one of the most engaged in the analytics space.

If your primary questions are about product engagement, user retention, and feature adoption, PostHog is purpose-built for that.

Where Zenovay fills a different gap

Zenovay is built for the question most founders actually ask every morning: "Where are my customers coming from and which channels are worth my time?"

Connect Stripe and see revenue attribution automatically. No event instrumentation required. No engineering time to set up custom properties. Add one script tag and you have answers in 2 minutes.

Zenovay also includes heatmaps and session replay. PostHog has these too (via their toolbar), but Zenovay is EU-hosted in Germany by default with cookieless tracking. PostHog Cloud defaults to US hosting, with EU as an option on specific plans.

The setup gap

This is where the difference hits hardest in practice.

PostHog is powerful but requires engineering investment. You need to plan your event taxonomy, instrument events in your codebase, configure properties, and build dashboards. For a team with dedicated engineers, that is fine. For a solo founder or small marketing team, it is a barrier.

Zenovay is designed for non-engineers. One script tag. Connect Stripe. See revenue data. The tradeoff is less customization, but for most marketing questions, the defaults are enough.

Feature comparison

Feature	Zenovay Pro ($20/mo)	PostHog (free to usage-based)
Focus	Marketing analytics	Product analytics
Revenue attribution	Built in (Stripe)	Not built in
Heatmaps	Included	Included (toolbar)
Session replay	Included	Included
Feature flags	No	Yes
A/B testing	No	Yes
Setup time	2 minutes	Hours to days
EU hosting	Default	US default, EU option
Open source	No	Yes (MIT)
Pricing	Flat tiers	Usage-based

Can you use both?

Yes, and many teams do. PostHog for product analytics, feature flags, and experiments. Zenovay for marketing analytics, revenue attribution, and heatmaps. They complement each other because they answer different questions.

My recommendation

Choose PostHog if you need product analytics (funnels, retention, cohorts), feature flags and A/B testing are essential, you have engineering resources for setup, or open source and self-hosting matter.

Choose Zenovay if you need marketing analytics and revenue attribution, you want actionable data in 2 minutes without engineering, EU hosting and privacy compliance are priorities, or you prefer predictable pricing over usage-based billing.

Disclosure: I built Zenovay. PostHog is a great tool for product teams. If product analytics is your primary need, use PostHog. If marketing analytics and revenue attribution are what you need, try Zenovay.

Launched my project a few weeks ago, traffic was okay but my retention was a disaster

Zenovay — Thu, 12 Mar 2026 15:20:12 +0000

The first few days actually looked promising. got some decent initial traction from X and Reddit (first slide). was hyped to see people actually clicking through and exploring.

But then I checked the cohort retention and it was a bloodbath. Most of my Feb cohorts had a week 1 retention of about 2-4%. I spent a few nights just staring at the screen, thinking the product was useless or that I’d built something nobody wanted. Honestly was already preparing to sunset the project or do a massive pivot.

Before giving up I looked into the performance metrics. Realized my LCP was spiking like crazy (check the graph below). Basically half of those users were staring at a blank loading screen for nearly 10 seconds and bounced before even seeing the UI.

Spent the last few days optimizing DB queries and fixing some caching issues. Difference is night and day now. Stupid mistake to make during a launch, but I guess that’s part of the learning curve.
Lesson learned: Don’t just track who is coming to your site, track if the site is actually loading for them lol.
Anyone else had a launch "fail" for purely technical reasons?

Zenovay vs Plausible: both privacy-first, but different depth

Zenovay — Thu, 12 Mar 2026 07:18:33 +0000

Plausible is one of the tools I respect most in the analytics space. They have been championing privacy-first analytics since before it was trendy, their dashboard is genuinely beautiful, and their tracking script is the smallest in the industry at roughly 1KB.

Both Zenovay and Plausible are EU-hosted, cookieless, and GDPR compliant without consent banners. So the privacy question is settled. They are essentially equal on that front.

The real question is: do you need more than traffic counts?

What Plausible does perfectly

Plausible is intentionally simple. One page. All the stats you need. Visitors, sources, top pages, locations, devices. No learning curve, no feature bloat.

It is also fully open source under AGPL. You can audit the code, self-host the community edition, and contribute. That transparency matters, and it is something closed-source tools like Zenovay cannot offer.

At $9/month for 10K pageviews, it is the most affordable serious analytics tool available. For bloggers, personal sites, and small projects that just need "how many people visited and where did they come from?", Plausible is genuinely hard to beat.

Where the paths diverge

Plausible shows you that 500 visitors came from Twitter yesterday. Zenovay shows you that those 500 Twitter visitors generated $1,200 in revenue through Stripe, while the 300 visitors from your blog post generated $2,800.

That is the core difference: traffic data vs revenue data.

Zenovay also includes heatmaps and session replay. You can see where visitors click, how far they scroll, and watch full session recordings. Plausible intentionally does not include any behavior analytics because it conflicts with their minimalist philosophy.

Both approaches are valid. It depends on what you need.

The feature gap

Feature	Zenovay Pro ($20/mo)	Plausible ($9-69/mo)
Privacy/EU hosting	Yes	Yes
Cookieless	Yes	Yes
Revenue attribution	Yes (Stripe)	No
Heatmaps	Yes	No
Session replay	Yes	No
Open source	No	Yes (AGPL)
Self-hosting	No	Community edition
Script size	~5KB	~1KB
White-label	Scale plan	No
Agency features	Multi-client dashboards	Limited

The pricing math

Plausible starts at $9/month. Zenovay Pro is $20/month. On the surface, Plausible is cheaper.

But if you outgrow simple traffic stats and need heatmaps, you add Hotjar ($80+/month). If you need revenue attribution, you add custom GA4 configuration or another tool. Suddenly your "simple" stack costs $100+/month.

Zenovay Pro at $20/month includes everything. The question is whether you will need those features eventually.

My honest recommendation

Stay with Plausible if simple traffic stats are genuinely all you need, open source and self-hosting matter to your team, you want the absolute smallest tracking script, or budget is tight and basic analytics are enough.

Consider Zenovay if you need to know which channels bring paying customers (not just visitors), heatmaps and session replay would help you improve your site, you manage multiple client websites and need agency features, or you want a platform that grows with you instead of switching tools later.

If you are happy with Plausible, stay with it. It is an excellent tool. Only switch if you find yourself wishing it could tell you more.

Disclosure: I built Zenovay. Plausible is a tool I genuinely respect. If simple, open-source analytics is what you need, use Plausible. If you need more depth while keeping privacy, try Zenovay.

Why I stopped paying $80/mo for Hotjar (and what I use instead)

Zenovay — Wed, 11 Mar 2026 12:52:35 +0000

For years, my analytics stack looked like this: Google Analytics for traffic data, Hotjar for heatmaps and session recordings. Two tools. Two scripts on every page. Two bills. Two dashboards to check every morning.

Then I realized something obvious: there is no reason these should be separate products.

Hotjar is excellent at what it does. Their heatmaps are mature, their session recordings work well, and their surveys are genuinely useful for UX research. But Hotjar cannot tell you where your traffic comes from, which pages convert, or which marketing channels bring revenue. For that, you still need a separate analytics tool.

Zenovay combines both. Analytics, heatmaps, session replay, and revenue attribution in one platform for $20/month. Here is how they actually compare.

What Hotjar does well

Hotjar pioneered the heatmap category and it shows. Their click, scroll, and movement maps are polished. Session recordings are reliable. Rage click detection automatically surfaces frustrated users.

But the real differentiator is surveys and feedback widgets. If your primary job is UX research, collecting qualitative user feedback directly on your site, Hotjar has built specific tools for that. Inline feedback widgets, on-page surveys, and interview recruitment are features Zenovay does not have.

If qualitative UX research is your main workflow, Hotjar is purpose-built for it.

The cost problem

Here is where the math breaks down.

Hotjar Business starts at $80/month for 500 daily sessions. Scale is $171+/month. These prices are just for heatmaps, recordings, and surveys. You still need Google Analytics (free but complex) or another analytics tool alongside it.

So your real stack cost looks like:

Tool	Purpose	Cost
GA4	Traffic analytics	Free (but hours of setup)
Hotjar Business	Heatmaps + recordings	$80+/mo
Consent banner tool	GDPR compliance	$10-50/mo
Total		$90-130/mo + setup time

Zenovay Pro includes analytics, heatmaps, session replay, and revenue attribution for $20/month. No separate analytics tool needed. No consent banner needed because it is cookieless.

Feature comparison

Feature	Zenovay Pro ($20/mo)	Hotjar Business ($80/mo)
Web analytics	Full dashboard	Not available (need GA4)
Revenue attribution	Built in (Stripe)	Not available
Heatmaps	Click, scroll, movement	Click, scroll, movement
Session replay	Included	Included
Rage click detection	Yes	Yes
Surveys	Not available	Built in
Feedback widgets	Not available	Built in
GDPR compliance	EU-hosted, cookieless	US-owned (Contentsquare)
White-label	Scale plan	Not available

The revenue attribution gap

This is the feature that made me switch.

Hotjar can show you that users are rage-clicking on your pricing page. That is useful. But it cannot tell you whether the people who came from your latest LinkedIn campaign spent more time on that page than organic visitors, or whether they converted to paying customers at a higher rate.

Zenovay connects to Stripe and maps revenue back to channels, campaigns, and individual pages. You do not just see behavior. You see which behavior leads to money.

When to choose Hotjar, when to choose Zenovay

Choose Hotjar if UX research is your primary job, you need built-in surveys and feedback widgets, your team only needs heatmaps and already has analytics covered, or qualitative user research is your main workflow.

Choose Zenovay if you want to replace both Hotjar and GA4 with one tool, revenue attribution matters to your business, you need EU hosting for GDPR compliance, or you would rather pay $20/month instead of $80+/month for heatmaps that also include full analytics.

You can install Zenovay in 2 minutes alongside Hotjar, compare the heatmap data, and then decide whether to drop Hotjar and GA4.

Disclosure: I built Zenovay. This comparison is honest. Hotjar surveys and feedback widgets are features we do not have. If those matter to you, Hotjar is the right tool. If you want analytics + heatmaps + attribution in one place, try Zenovay.

Zenovay vs Google Analytics: I switched after 8 years. Here's my honest take.

Zenovay — Tue, 10 Mar 2026 12:39:30 +0000

I ran Google Analytics on every project since 2018. When GA4 replaced Universal Analytics, I stuck with it. Learned the new UI. Rebuilt my reports. Figured out the event model.

Then last year I installed Zenovay on one of my production sites as an experiment. Two months later, GA4 was gone from that project. Three months later, it was gone from all of them.

This is not a hit piece on GA4. It is a genuinely good tool for certain use cases. But for the way I work, the tradeoff stopped making sense.

The setup gap

GA4 setup is a project. Create a property. Configure a data stream. Install gtag.js or set up Google Tag Manager. Define custom events for the things you actually care about. Configure conversions. Set data retention. If you have EU users, add a consent management platform and configure Consent Mode v2. If you want raw data access, connect BigQuery.

For someone who has done it before, that is a day of work. For a founder doing it for the first time, it can take a week of Googling.

Zenovay is one script tag in your HTML head. I timed it once: 1 minute and 40 seconds from signup to seeing live data. No tag manager. No event configuration for the basics. No consent banner needed because it is cookieless by default.

That gap matters more than people think. Every hour you spend configuring analytics is an hour you are not building product.

The daily experience

This is where I felt the difference most.

With GA4, answering "how many people visited my pricing page yesterday" requires clicking into Explore, creating a free-form report, adding dimensions and metrics, and filtering. There is a reason "GA4 tutorial" has tens of thousands of monthly searches.

Zenovay gives you one dashboard. When you log in, the answer is right there: visitors, top pages, referral sources, devices, locations on a real-time 3D globe. No report builder. No configuration. Just the data.

For teams that need custom funnels, cohort analysis, or complex multi-touch attribution across Google Ads campaigns, GA4 has more raw power. But for the daily question of "what is working on my website right now?", Zenovay answers it faster.

The privacy problem GA4 cannot solve

GA4 uses cookies. In the EU, that means a consent banner. When visitors reject cookies, and research suggests 30-60% do, those visitors disappear from your data completely.

Your analytics dashboard shows 1,000 visitors. The real number might be 2,000. You are making business decisions on half the picture.

Multiple EU data protection authorities in Austria and France have ruled against standard GA4 implementations. You can make it compliant with Consent Mode v2, server-side tagging, IP anonymization, and a data processing agreement. But that is significant work, and you still lose the visitors who reject cookies.

Zenovay is cookieless by default. No consent banner needed. EU-hosted in Germany. You see 100% of your visitors.

For any business with European traffic, this is not a minor difference. It is a data quality difference that affects every decision you make.

Where GA4 still wins

I want to be honest about what you give up by switching.

Google Ads integration. If you run significant Google Ads spend and rely on the analytics-to-ads pipeline for audience building and remarketing, GA4 is essentially irreplaceable. The native integration is deep, and Zenovay cannot match it.

BigQuery access. The ability to run SQL queries on your raw analytics data is powerful. If your team does custom analysis beyond what any dashboard provides, this matters.

It is free. For most use cases, GA4 costs nothing. If your budget is literally zero, GA4 is hard to beat.

The ecosystem. Millions of users. Thousands of tutorials. Every marketing hire already knows it. Switching has a real training cost.

Where Zenovay wins

Revenue attribution. Connect Stripe and see which channels, campaigns, and pages bring paying customers. Not just "traffic went up 20%" but "Twitter brought 40 visitors who generated $2,300 in revenue." GA4 can do something similar, but it requires custom dimensions, conversion events, and significant configuration. Zenovay does it out of the box.

Heatmaps and session replay included. Most GA4 users also pay for Hotjar ($80+/month) to see where people click and watch session recordings. Zenovay includes both. One tool instead of two. One bill instead of two.

GDPR compliance without the headache. EU-hosted. Cookieless. No consent banners. No DPA rulings to worry about.

2-minute setup. One script tag. Connect Stripe. See revenue attribution immediately. Your marketing team will actually use it because they do not need a data analyst to find the answer.

The pricing math

GA4 is free but most teams also pay for Hotjar ($80+/month) for heatmaps, and spend hours configuring attribution. Zenovay Pro is $20/month and includes analytics, heatmaps, session replay, and revenue attribution.

	Zenovay Pro	GA4 + Hotjar
Analytics	Included	Free (GA4)
Heatmaps	Included	$80+/mo (Hotjar)
Session replay	Included	$80+/mo (Hotjar)
Revenue attribution	Included	Hours of config
EU hosting	Default	Not available
Total	$20/mo	$80+/mo + time

My recommendation

Stay with GA4 if Google Ads is your primary channel, you have a data team that does custom analysis in BigQuery, or your entire organization is trained on GA4 and switching cost is high.

Try Zenovay if you want to know which channels bring paying customers (not just traffic), you are tired of maintaining GA4 + Hotjar + consent banners, or you need GDPR compliance that actually works without cutting your data in half.

You can run both in parallel. Install Zenovay in 2 minutes alongside GA4, compare the data for a month, then decide.

Full disclosure: I built Zenovay. But I wrote this comparison the way I would want to read it, with honest acknowledgment of where GA4 is better. If GA4 fits your needs, use it. If it does not, give Zenovay a try.

I tested 8 analytics tools. Here's what they all get wrong.

Zenovay — Sat, 21 Feb 2026 15:03:30 +0000

I spent the last 6 months deep in web analytics while building my own platform. Along the way I tested GA4, Hotjar, Mixpanel, Amplitude, Plausible, Fathom, PostHog, and Matomo.

Every single one forces you into a tradeoff that shouldn't exist. Here's the short version.

GA4 — Free, but requires a certification to find basic data. Filtering for a single page takes 6 clicks. Reports are sampled above 10M events with error rates up to 30%. Cookie consent banners make 40-60% of your EU traffic invisible. The "free" tool effectively requires BigQuery for anything useful.

Hotjar — Great heatmaps, but the script adds ~830ms to your page load and ~0.5MB to page weight. The free plan records 35 sessions per day. Full Business tier across all products costs $922/mo. Session recordings break on Next.js and React apps when CSS filenames change between deploys.

Mixpanel — Powerful product analytics, but 10M events/month costs ~$2,500/mo. One HN user reported getting downgraded from 20M free events to 10K when switching to a paid plan. Client-side tracking loses 30-50% of users to ad blockers per their own docs.

Amplitude — Similar power, similar problems. Growth plan starts at ~$30K/year. The UI has so many options that teams spend more time navigating the tool than getting insights. Requires 25K+ monthly users minimum for accurate advanced analytics.

Plausible — Beautiful and simple. But resets visitor identity daily, so one person visiting 5 days counts as 5 uniques. No heatmaps, no session replay, no funnels on the self-hosted version. Self-hosted also lacks the bot detection the cloud version uses — one dev saw their stats jump from 200 to 5,000 visitors/day after switching.

Fathom — Clean and privacy-first. But custom events can't send metadata. No goal attribution with UTM parameters. No funnels, no entry/exit pages, no scroll depth. Completely closed-source with no self-hosting option. Shows you what happened, never why.

PostHog — Tries to do everything. The JS SDK is 52KB+. Self-hosting requires ClickHouse, Kafka, Redis, PostgreSQL, Zookeeper, and MinIO running simultaneously. One dev ran up a $10K bill in half a day. Another needed 64GB RAM and still couldn't get it working.

Matomo — The oldest open-source option. MySQL-based architecture means reports can take hours to generate. UI barely evolved in 10+ years. Heatmaps, session replay, funnels, and A/B testing are all premium plugins at €1,200+/year even for self-hosted.

The pattern nobody talks about:

Every tool falls into one of two camps. Simple counters (Plausible, Fathom) that show what happened but not why. Or enterprise platforms (GA4, Amplitude, PostHog) that can answer deep questions but require weeks of learning and dedicated engineering.

Nothing sits in the middle: simple to start, powerful when you need it, privacy-first without sacrificing conversion tracking.

That gap is exactly why I built Zenovay. One dashboard with analytics, heatmaps, session replay, AI insights, and revenue attribution. No cookies. EU-hosted. $20/mo.

Not saying it's perfect yet. But the tradeoff between simple and powerful shouldn't be a tradeoff at all.

What analytics tool are you currently using, and what's the one thing that frustrates you most about it?

I tested 8 analytics tools. Here's what they all get wrong.

Zenovay — Thu, 19 Feb 2026 20:10:55 +0000

I spent the last 6 months deep in web analytics while building my own platform. Along the way I tested GA4, Hotjar, Mixpanel, Amplitude, Plausible, Fathom, PostHog, and Matomo.

Every single one forces you into a tradeoff that shouldn't exist. Here's the short version.

Plausible — Beautiful and simple. But resets visitor identity daily, so one person visiting 5 days counts as 5 uniques. No heatmaps, no session replay, no funnels on the self-hosted version. Self-hosted also lacks the bot detection the cloud version uses, one dev saw their stats jump from 200 to 5,000 visitors/day after switching.

The pattern nobody talks about:

Nothing sits in the middle: simple to start, powerful when you need it, privacy-first without sacrificing conversion tracking.

That gap is exactly why I built Zenovay. One dashboard with analytics, heatmaps, session replay, AI insights, and revenue attribution. No cookies. EU-hosted. $20/mo.

Not saying it's perfect yet. But the tradeoff between simple and powerful shouldn't be a tradeoff at all.

What analytics tool are you currently using, and what's the one thing that frustrates you most about it?

zenovay.com if you want to see what we're building.

How We Built a Real-Time Analytics Platform on Cloudflare Workers (Architecture Deep-Dive)

Zenovay — Tue, 17 Feb 2026 20:41:05 +0000

Most analytics platforms follow a familiar pattern: events land on a centralized server, get queued, and eventually show up in a dashboard minutes later. When we built zenovay.com, we wanted something fundamentally different. Sub-100ms event ingestion globally, real-time dashboards with live visitor counts, and zero cookies. This article walks through the architecture that makes that work.

This is not a product walkthrough. It is a technical deep-dive into the design decisions, tradeoffs, and production lessons of running an analytics platform on Cloudflare Workers.

1. Why Edge-First?

Traditional analytics architectures have a structural problem: the event producer (the visitor's browser) and the event consumer (the analytics server) are physically far apart.

Consider a visitor in Tokyo hitting a site tracked by an analytics service hosted in us-east-1. The tracking pixel request has to cross the Pacific Ocean, hit a load balancer, wait for an available process (or suffer a cold start), write to a database, and return a response. Round-trip latency: 300-800ms. During that time, the browser is potentially blocking on the request, degrading the user experience of the site being tracked.

The edge-first approach eliminates this entirely. With Cloudflare Workers, your event ingestion code runs in 300+ data centers worldwide. That visitor in Tokyo hits a Worker in Tokyo. The response comes back in single-digit milliseconds. No cold starts (Workers use V8 isolates, not containers), no cross-ocean roundtrips, no load balancer hop.

The numbers matter because analytics tracking scripts run on every page load of every tracked site. If your tracking script adds 500ms of latency to page loads, you are degrading the Core Web Vitals of every site that uses your product. At the edge, the overhead drops to effectively zero.

But edge-first introduces its own set of problems. You cannot just INSERT INTO postgres from 300 data centers simultaneously, you need session identification without centralized state, and you need to get real-time data back to dashboards despite your event source being globally distributed. The rest of this article covers how we solved each of these.

2. The Architecture

Here is the high-level data flow:

Browser (tracking script)
    |
    v
Cloudflare Worker (Hono.js)  <-- Edge: event validation, bot detection, geo lookup
    |
    ├──> Cloudflare KV          <-- Hot data: deduplication, rate limits, live counts
    ├──> Workers Analytics Engine <-- High-cardinality event stream (dual-write)
    └──> Supabase (PostgreSQL)   <-- Persistent storage: visitors, page_views, analytics
            |
            v
        Supabase Realtime (WebSocket)
            |
            v
        Dashboard (Next.js)      <-- Live updates via subscription

The API is a single Cloudflare Worker running Hono.js, an ultra-fast web framework designed for edge runtimes. Hono gives us express-style route handlers with middleware chaining, but with zero Node.js dependencies and sub-millisecond router overhead.

The Worker handles everything: tracking event ingestion, authentication (JWT validation via Supabase), analytics queries, billing (Stripe), and cron jobs (daily aggregation, retention cleanup). It is a monolith at the edge, and that is intentional. V8 isolates are cheap, and co-locating concerns eliminates inter-service latency.

Here is a simplified version of the tracking route handler:

import { Hono } from 'hono';
import { createSupabaseClient } from '../services/supabase';

const app = new Hono<{ Bindings: Env }>();

app.post('/:trackingCode', async (c) => {
  const trackingCode = c.req.param('trackingCode');
  const data = await c.req.json();

  // 1. Bot detection (User-Agent + Cloudflare Bot Management signals)
  const cfData = (c.req.raw as any).cf;
  if (cfData?.botManagement?.verifiedBot || isBot(data.user_agent)) {
    return c.json({ error: 'Bot traffic blocked' }, 403);
  }

  // 2. Rate limiting via KV (60 req/10s burst, 5000 req/hr sustained)
  const clientIP = c.req.header('CF-Connecting-IP') || 'unknown';
  const rateLimitKey = `tracking_ratelimit:${clientIP}`;
  // ... KV-based sliding window check ...

  // 3. Geolocation from Cloudflare's edge network (free, no API call)
  const geoData = {
    country_code: cfData?.country,
    city: cfData?.city,
    latitude: cfData?.latitude,
    longitude: cfData?.longitude,
  };

  // 4. Deduplication via KV (5-second window per session+URL)
  const dedupeKey = `dedupe:${websiteId}:${data.session_id}:${data.url}`;
  const recent = await c.env.CACHE.get(dedupeKey);
  if (recent) return c.json(JSON.parse(recent));

  // 5. Write to Supabase + dual-write to Analytics Engine
  const supabase = createSupabaseClient(c.env.SUPABASE_URL, c.env.SUPABASE_SERVICE_KEY);
  await supabase.from('visitors').upsert(visitorRecord);

  // 6. Cache the response for deduplication
  await c.env.CACHE.put(dedupeKey, JSON.stringify(response), {
    expirationTtl: 5
  });

  return c.json(response);
});

A few things to note:

Custom Supabase client. We do not use the official @supabase/supabase-js SDK at runtime. It pulls in too many Node.js dependencies that do not work in the Workers runtime. Instead, we wrote a lightweight PostgrestBuilder class that wraps fetch() calls to Supabase's PostgREST API directly. Same chainable .from().select().eq() syntax, but ~50KB smaller and fully edge-compatible.

Geolocation for free. Cloudflare attaches geolocation data to every request via the cf object, including country, city, latitude, longitude, timezone, and ASN. No external API call needed. This is one of the biggest advantages of running on Workers: you get production-grade geolocation at zero cost and zero latency.

Three KV namespaces. We separate concerns across dedicated KV namespaces: CACHE for real-time data and deduplication, RATE_LIMIT for rate limiting state, and SECURITY for IP reputation scoring. This prevents hot keys in one concern from affecting read latency in another.

3. Session Identification Without Cookies

Privacy-focused analytics means no cookies and no fingerprinting. But you still need to know whether two page views came from the same visitor. Here is how we handle it.

The tracking script generates two IDs on the client side:

session_id: A crypto.randomUUID() stored in sessionStorage. Dies when the tab closes. Represents a single browsing session.
visitor_id: A crypto.randomUUID() stored in localStorage. Persists for 365 days. Represents a returning visitor across sessions.

// Client-side tracking script (simplified)
const sessionId = sessionStorage.getItem('zv_sid')
  || (() => {
    const id = crypto.randomUUID();
    sessionStorage.setItem('zv_sid', id);
    return id;
  })();

const visitorId = localStorage.getItem('zv_vid')
  || (() => {
    const id = crypto.randomUUID();
    localStorage.setItem('zv_vid', id);
    return id;
  })();

This approach has important tradeoffs:

No cross-device tracking. A visitor on their phone and their laptop shows as two different visitors. This is by design. Cross-device tracking requires either login-based identity or invasive fingerprinting, and we chose to avoid both.

No cross-browser tracking. Different browsers on the same device get different visitor_id values because localStorage is browser-scoped. Again, by design.

Private browsing breaks session continuity. Incognito mode clears localStorage on close, so every incognito session is a "new" visitor. This slightly inflates unique visitor counts but maintains privacy.

The accuracy tradeoff is acceptable. In practice, the slight overcounting of unique visitors (estimated 5-15% depending on the audience) is a worthwhile trade for not setting any cookies and not doing any fingerprinting. Site owners get accurate trend data, they can see whether traffic is going up or down, which pages perform best, which countries their visitors come from, without compromising visitor privacy.

For session linking on the server side, when a tracking event arrives, the Worker looks for an existing visitor record matching either the session_id or the visitor_id:

// Server-side session resolution (simplified)
const { data: existingVisitors } = await supabase
  .from('visitors')
  .select('id, visited_at, visitor_id, session_id')
  .eq('website_id', websiteId)
  .gte('visited_at', twentyFourHoursAgo)
  .or(`session_id.eq.${data.session_id},visitor_id.eq.${data.visitor_id}`)
  .order('visited_at', { ascending: false })
  .limit(2);

// Prefer session_id match; fall back to visitor_id for cross-subdomain continuity
const match = existingVisitors?.find(v => v.session_id === data.session_id)
  || existingVisitors?.find(v => v.visitor_id === data.visitor_id);

The OR query eliminates a common N+1 pattern where you would first query by session_id, then separately by visitor_id if no match was found. One query, two potential match paths.

4. Batching Writes and Managing Database Load

A naive implementation would write every tracking event directly to PostgreSQL. At scale, this falls apart quickly. Here is what happens:

Connection exhaustion. Cloudflare Workers can spawn thousands of isolates simultaneously. Each one opening a direct Postgres connection would overwhelm connection limits.
Write amplification. A single visitor session generates many events: initial pageview, heartbeats every 30 seconds, scroll depth updates, page navigation, exit event. Writing each one as a separate INSERT is wasteful.
Hot rows. Updating a visitor record on every heartbeat creates lock contention on the same row.

Our approach combines several strategies:

Upsert instead of insert. Instead of creating a new record for every event, we upsert on session_id. The first event for a session creates the visitor record, subsequent events (heartbeats, page navigations) update it in place:

// Session continuation: UPDATE existing record
await supabase
  .from('visitors')
  .update({
    visited_at: new Date().toISOString(),
    page_url: trackingData.url,
    time_on_page: Math.max(trackingData.time_on_page, existing.time_on_page),
    scroll_depth_percentage: Math.max(trackingData.scroll_depth, existing.scroll_depth),
    had_interaction: trackingData.had_interaction || existing.had_interaction,
  })
  .eq('id', existingVisitor.id);

Note the Math.max calls. This prevents race conditions where a late-arriving heartbeat with older data could overwrite newer values.

KV-based deduplication. Before writing to Supabase, we check Cloudflare KV for a recent write with the same session_id + URL combination. The dedup window is 5 seconds with a TTL, so KV entries clean themselves up:

const dedupeKey = `dedupe:${websiteId}:${sessionId}:${url}`;
const cached = await c.env.CACHE.get(dedupeKey);
if (cached) return c.json(JSON.parse(cached)); // Return cached response

// ... process and write ...

await c.env.CACHE.put(dedupeKey, JSON.stringify(response), {
  expirationTtl: 5
});

Conditional ML recalculation. Each visitor gets a real-time value score (a weighted prediction based on country, device, browser, session behavior). Recalculating this on every heartbeat is expensive. We only recalculate when there is a meaningful signal change:

const shouldRecalculate =
  event !== 'heartbeat' ||           // Always recalc on pageviews
  heartbeatCount % 5 === 0 ||        // Every 5th heartbeat
  scrollDelta >= 20 ||               // Significant scroll change
  (hasInteraction && !hadPrior);     // First interaction detected

This reduces ML computation by roughly 80% on active sessions while keeping scores fresh.

Dual-write to Workers Analytics Engine. For high-cardinality queries (unique visitors by country over 90 days, for example), Supabase can be slow. We dual-write every event to Cloudflare's Workers Analytics Engine (WAE), which is designed for exactly this workload:

export function writeTrackingEvent(
  analytics: AnalyticsEngineDataset,
  event: Partial<WAETrackingEvent> & { trackingCode: string }
): void {
  analytics.writeDataPoint({
    indexes: [event.trackingCode],
    blobs: [
      event.eventType, event.url, event.referrer,
      event.country, event.city, event.browser,
      event.os, event.deviceType, event.sessionId,
      event.visitorId, event.isBot ? 'bot' : 'human',
    ],
    doubles: [
      event.loadTimeMs, event.scrollDepth,
      event.viewportWidth, event.viewportHeight,
      event.pagesViewed, event.valueScore,
    ],
  });
}

WAE writes are fire-and-forget with no backpressure. Cloudflare handles the buffering internally. Queries use SQL via their API, and they are fast even over billions of events because WAE uses columnar storage under the hood.

5. Real-Time Dashboard

The dashboard needs to show live data: visitors currently on the site, a 3D globe with real-time markers, and analytics that update without page refresh. We use a two-layer approach.

Layer 1: KV for instant counts. When a visitor arrives or leaves, the Worker updates a KV counter. The dashboard reads this counter for the live visitor badge:

// In the tracking handler - update live count
const visitorKey = `visitor:${websiteId}:${sessionId}`;
await c.env.CACHE.put(visitorKey, JSON.stringify({
  country: geoData.country_code,
  page: trackingData.url,
  value_score: valueScore,
  last_seen: Date.now()
}), { expirationTtl: 300 }); // Auto-expires after 5 minutes of inactivity

KV reads are globally fast (sub-5ms) because they are served from Cloudflare's edge cache. The 5-minute TTL means inactive visitors automatically disappear without any cleanup logic.

Layer 2: Supabase Realtime for detailed updates. For the full visitor list, the globe visualization, and the activity stream, the dashboard subscribes to Supabase Realtime channels:

// Dashboard component (simplified)
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

// Subscribe to new visitors for this website
const channel = supabase
  .channel(`visitors:${websiteId}`)
  .on(
    'postgres_changes',
    {
      event: 'INSERT',
      schema: 'public',
      table: 'visitors',
      filter: `website_id=eq.${websiteId}`,
    },
    (payload) => {
      // New visitor arrived - add marker to globe, update sidebar
      addGlobeMarker({
        lat: payload.new.latitude,
        lng: payload.new.longitude,
        country: payload.new.country_name,
        value_score: payload.new.value_score,
      });
    }
  )
  .subscribe();

Supabase Realtime uses WebSockets under the hood, backed by PostgreSQL's LISTEN/NOTIFY. When the Worker inserts a new visitor record, PostgreSQL fires a notification, Supabase picks it up and pushes it through the WebSocket to all subscribed dashboard clients. Latency from write to dashboard update is typically under 500ms.

The 3D globe itself uses Mapbox GL JS with custom markers. Each new visitor gets a marker at their geographic coordinates, color-coded by value score (green for premium visitors, blue for medium, gray for low). Markers animate in and fade out based on session activity.

6. Performance Results

After running this architecture in production, here are the numbers:

Event ingestion P95: 47ms globally. This includes JSON parsing, bot detection, geolocation lookup (from the cf object, so free), KV dedup check, Supabase write, and response serialization. The Supabase write is the long pole at ~30-40ms, but it happens asynchronously relative to the response in most cases.

Event ingestion P99: 89ms. The tail latency comes from cold KV reads (first read after a key expires) and occasional Supabase connection resets.

Dashboard real-time latency: ~400ms. From the moment a visitor lands on a tracked site to the moment their marker appears on the dashboard globe. This includes Worker processing (~50ms), Supabase write (~40ms), PostgreSQL NOTIFY propagation (~100ms), WebSocket delivery (~100ms), and client-side rendering (~100ms).

Zero cold starts. V8 isolates spin up in under 5ms compared to 200-2000ms for container-based serverless. In practice, Workers are almost always warm because analytics tracking generates continuous traffic across all data centers.

Rate limiting accuracy: 99.7%. KV-based rate limiting has eventual consistency, so there is a small window where a burst can exceed limits. We accept this tradeoff because the alternative (centralized rate limiting) would add 50-100ms of latency to every request.

For comparison, a traditional setup with a Node.js server in us-east-1, writing to RDS PostgreSQL, would see P95 latencies of 200-600ms for visitors outside North America, with cold starts adding 500ms+ after periods of low traffic.

7. Lessons Learned

What worked well:

Hono.js is excellent for Workers. Express-style ergonomics with zero Node.js runtime overhead. The middleware chain pattern (CORS, IP blocklist, rate limit, bot protection, handler) is clean and composable.
Cloudflare's cf object for geolocation. Eliminating the external GeoIP API call removed ~100ms and an external dependency from every request. The data quality is comparable to MaxMind.
KV for deduplication and rate limiting. The global consistency model (write at one edge, readable everywhere within 60s) is perfect for these use cases. We do not need strict consistency. If a dedup check misses in a 60-second window, the worst case is one duplicate write.
Supabase as the persistence layer. PostgreSQL is boring in the best way. RLS policies, real-time subscriptions, and a REST API that works from edge runtimes without an SDK.

What was harder than expected:

Custom Supabase client. The official SDK does not work in Workers due to Node.js dependencies (node:crypto, node:events). Writing a compatible PostgREST client from scratch took a week and introduced subtle bugs around .maybeSingle() behavior and error code parsing.
KV write limits. Cloudflare KV has a 1,000 writes/second limit per namespace. Our rate limiter was writing on every request, quickly hitting this limit. We fixed it by only writing to KV when the request count is within 90% of the limit or when there are active violations, reducing writes by ~95%.
Connection resets to Supabase. Workers do not keep persistent HTTP connections between invocations. Every Supabase call opens a new TCP+TLS connection. At high traffic, this creates connection churn. Supabase handles it well, but P99 latency spikes during connection storms.
Time zone handling at the edge. JavaScript Date in Workers always uses UTC. Converting to the visitor's local timezone for "business hours" detection requires the timezone string from the cf object, and it is not always present.

What we would change:

Workers Analytics Engine from day one. We added WAE as a dual-write later, but it should have been the primary analytics store from the start. SQL queries over WAE are faster than aggregating raw visitor rows in PostgreSQL for any non-trivial time range.
Durable Objects for live counts. We started with KV for live visitor counting, but KV's eventual consistency means the count can be stale by up to 60 seconds. Durable Objects provide strong consistency for counters, we are migrating to this now.
Fewer Supabase queries per tracking request. The current flow makes 3-5 Supabase calls per event (website lookup, existing visitor check, upsert, page view insert, goal detection). Batching these into a single RPC call or using Supabase Edge Functions co-located with the database would cut latency significantly.

Wrapping Up

Building analytics at the edge is not just about speed, it changes what is architecturally possible. When your ingestion latency is under 50ms, you can show visitors on a live 3D globe as they arrive. When there are no cold starts, your tracking script never degrades the sites it monitors. When you run in 300+ locations, geolocation comes free.

The stack (Cloudflare Workers + Hono.js + Supabase + KV) is production-ready for this workload. The rough edges are real (custom SDK clients, KV write limits, connection churn), but they are solvable problems, not architectural dead ends.

If you are building something that needs global sub-100ms response times with real-time downstream updates, this pattern works. The event source runs at the edge, hot state lives in KV, cold state lives in PostgreSQL, and WebSockets bridge the gap to the client.

This architecture powers zenovay.com, the real-time analytics platform we built for privacy-focused website analytics with 3D globe visualization.