Most analytics tools are fine for the basics. Pageviews, sessions, referrers. You add the script tag, the numbers appear in a dashboard, and that's usually enough.
Then you want to know something slightly more specific. Which landing page actually converts? Where do users drop off in the signup flow? Does the variant with the shorter form outperform the one with the social proof section? And suddenly you are looking at the pricing page for Mixpanel or Amplitude, where funnel analysis lives behind a tier that costs more than your server.
I already had BugBarn running for error tracking, and the experience of building it taught me something useful: most of what these SaaS tools charge for is the hosting, not the hard part. The hard part for analytics is the query layer: aggregating time-series data, computing funnel conversion rates, joining events into sessions. That is not trivial, but it is also not magic. So I built FunnelBarn.
Sessions without cookies
The first design decision is the one that shapes everything else. FunnelBarn does not use cookies. It does not set anything in the browser and does not ask for consent. Sessions are tracked server-side using an anonymous fingerprint derived from IP address and User-Agent. The user ID is hashed before storage and never exposed through the API. From the browser's perspective, it is just an HTTP request.
This is not perfect. Two people on the same NAT with the same browser might hash to the same session. But it is good enough for the kinds of questions funnel analysis is actually trying to answer. And it means you can deploy it without a cookie banner, without a consent management platform, and without sending your users' behavior to a third party.
What gets tracked
Each event has a name, a URL, a referrer, and optional custom properties. UTM parameters are captured automatically. You can attach anything else you want to an event as a key-value property: plan tier, experiment variant, form step, whatever makes sense for your app.
The dashboard shows time-series charts for events and sessions over 24 hours, 7 days, and 30 days. Top pages and referrers. UTM attribution broken down by source, medium, and campaign. Device and browser breakdown. There is also a live event feed that shows events as they come in, which is useful when you are testing instrumentation and want to verify something actually fired.
Funnel analysis
This is the main reason I built it. You define a funnel as an ordered list of steps. Each step is an event name plus optional property filters. FunnelBarn computes the conversion rate between each step, the drop-off count, and lets you segment the results by browser, device type, UTM source, or any custom property you attached to the events.
If you want to know how many people who landed on the homepage from a Google ad made it through to account creation and then to their first project, that is a four-step funnel with a UTM source filter on the first step. It takes about thirty seconds to set up.
A/B test analysis
FunnelBarn has a lightweight A/B analysis view. You pick a conversion event, define the control and variant using property filters, and it computes conversion rates and sample sizes for each group. It does not run your experiments for you. You still need to assign variants and attach the property to your events. But once you have that data flowing in, reading the results is straightforward.
How the ingest works
Same pattern as BugBarn. The ingest endpoint writes incoming events to a spool on disk and returns immediately. A background worker picks them up, processes them, and writes to SQLite. Ingest stays fast regardless of what the database is doing, and nothing is lost if the process restarts mid-batch. For the event volumes a self-hosted analytics tool will realistically see, SQLite handles the query side without complaint.
SDKs
There are SDKs for JavaScript, Node.js, Python, and Go. The browser SDK tracks page views automatically, supports custom events, and flushes asynchronously so it does not block anything. The Node.js, Python, and Go SDKs cover server-side tracking, useful if you want to record events that happen outside the browser, like a background job completing or a payment being processed.
All three follow the same interface: initialize with your project API key and endpoint, then call track with an event name and optional properties. The identify call lets you associate events with a hashed user ID if you want per-user funnel analysis.
Installing it
On Linux, APT is the cleanest option. Add the WebWiebe repository and install the package. It ships with a systemd unit and reads configuration from environment variables with a FUNNELBARN_ prefix.
curl -fsSL https://webwiebe.nl/apt/install.sh | sudo bash
sudo apt install funnelbarn
On macOS, there is a Homebrew tap. Docker is also available if you prefer containers.
brew tap webwiebe/funnelbarn
brew install funnelbarn
Multi-project support is built in. Each project gets its own API key, and the dashboard lets you view data per project or across all of them. If you already run BugBarn on the same server, FunnelBarn is another binary on the same machine. No additional infrastructure required.
The source is on GitHub. Installation details are on the APT and Homebrew pages.