We build static websites because they’re fast, cheap to host, and hard to break. The trade-off people assume you make is measurement: that a hand-built static site can’t tell you much beyond a raw visitor count.
That assumption is wrong. This site — the one you’re reading — runs full product analytics, a conversion funnel, and session replay. Here’s exactly how, and why we did it before selling it to anyone.
Why a visitor count isn’t enough
Most local-business sites have Google Analytics bolted on and nothing else. It answers one question well: how many people showed up? It’s weak at the question that actually pays your bills: what did they do once they were here, and why didn’t more of them call?
“900 visits last month” is a vanity number. The useful version is:
- 900 people landed
- 280 reached the page where they could request something
- 118 actually submitted
Now you know your problem isn’t traffic. It’s the gap between landing and acting. That’s a fixable problem. A visitor count hides it.
What we picked, and why
We use PostHog. Three reasons it fits how we work:
- It does behavior, not just traffic. Funnels, individual session replays, and event tracking in one tool, instead of stitching together five dashboards nobody opens.
- It’s privacy-conscious and open-source. We can self-host it if a client needs to, and it respects Do-Not-Track and ad-blocker signals out of the box.
- It drops onto a static site with one script. No backend, no server to babysit. That matters when the whole point of the site is that it’s static.
The build, in plain English
Four decisions did most of the work.
1. The analytics only load when they’re supposed to
The tracking snippet is gated behind an environment variable. If the key isn’t set — on a developer’s laptop, in a preview build — it renders nothing at all. Tracking turns on only in the real, deployed site. No accidental data from us testing our own pages, no surprise scripts in places they shouldn’t run.
2. We track the actions that matter, by name
Pageviews are automatic. The things that make money are not, so we name them on purpose: the “Run a Free Audit” button and phone-number taps each fire a clearly labeled event. When we look at the data later, we’re reading “118 people requested an audit,” not guessing which anonymous click was the important one.
3. The conversion event survives the form’s own code
This is the one genuinely fiddly part. Our audit form does its own thing when you submit it — it sends the request, then swaps the page to a confirmation message, and in doing so it stops the browser’s default submit behavior.
A naive analytics listener would miss that submit entirely. We attach our “submitted” event one level up, in the phase of the click that fires before the form cancels the default. The result: the form behaves exactly as designed for the visitor, and we still record the conversion cleanly. We verified it end to end — submit the form, the email arrives, the event shows up.
4. The funnel ties it together
With pageviews and named events in place, the funnel almost builds itself: first visit → reached the audit page → submitted the request. That’s the whole customer journey in three steps, and it shows us the exact stair where people fall off. We fix that stair instead of guessing.
The honest part: what we capture, and what we don’t
A measurement page that isn’t honest about privacy isn’t worth running. So, plainly:
- We capture behavior — pages, clicks, the named actions above — not identity.
- We do not capture what anyone types into a form field.
- We don’t sell data, and we honor Do-Not-Track and ad-blocker signals.
- Session replay, where we use it, records anonymized sessions to find friction — not to identify people.
You can learn everything you need to improve a site without hoarding personal details. We’d rather build trust than a creepy data pile.
One thing that didn’t work
We tried to route the analytics through our own domain to dodge ad-blockers. On the shared hosting this site runs on, the proxy approach the docs suggest simply isn’t available — the server refused it. So we left it off. For a local-business audience the blocker rate is low enough that it doesn’t move the numbers, and we’d rather ship the honest, working version than a fragile workaround. If a client’s audience is more technical, there’s a clean fix using a Cloudflare worker we’ll reach for then.
We’re writing that down here for the same reason we write everything down: the dead ends are part of the work, and pretending they don’t happen is how you end up repeating them.
Why we built it on ourselves first
We don’t sell tools we don’t run. Every part of this — the install, the named events, the funnel, the replay — is live on our own site before we offer it to a single client. When we tell a business owner “here’s what your visitors actually do,” we’ve already lived the exact setup we’re handing them.
If you want this kind of measurement on your site — the funnel, not just the visitor count — it’s part of our Know Your Website work.
To see where you’re starting from, run a free audit. We’ll score your site, and we’ll tell you whether you can even measure what it’s doing today.