Feasible

We wanted analytics, not a ransom note

Sat, 05 Sep 2026 00:00:00 +0000

I paid for a year of analytics in March. By summer, the dashboards I’d already bought were behind a bigger number.

That’s a strange way to thank a paying customer.

It’s also how we accidentally started an analytics company. Which, I want to be clear, was nowhere on my list.

Twenty years of not finding it

At Cloudmanic Labs we’d been shopping for analytics we actually liked for most of two decades. It went about how you’d expect.

What we used	How it ended
Google Analytics	Checking three numbers took a scavenger hunt
Clicky	Genuinely good for years. We drifted apart
Self-hosted Matomo	Congratulations, you now maintain a database

That last one deserves a note. Self-hosting didn’t save us money so much as convert money into chores. We already had plenty of chores.

Then we found Plausible.

One page. The numbers we wanted. No cookies. A product you could open, understand, and close. Somebody had built a small useful thing and resisted the urge to turn it into a cockpit, and I respected that enormously. I liked it immediately. I liked paying for it more.

I want that on the record before anything else, because everything after this is going to sound like a complaint.

The ladder

Here’s the part where a story about analytics becomes a story about arithmetic.

When	What we paid	Why
Year one	~$100/year	The plan we signed up for
Later	~$200/year	Features we wanted moved up a tier
Then	~$400/year	A free plugin got popular

The jump to $200 stung a little. I paid it anyway, partly because the features were useful and partly because I wanted the company to exist. Voting with your wallet, and all that.

Then we released herdr plus, an open-source plugin. We put it out into the world and went back to work.

People liked it. The site got traffic.

Nice problem to have.

Our pageview count doubled. Our revenue from those pageviews stayed exactly zero.

Between the plugin’s site and our other small ones, we sailed past the allowance. The next rung on the ladder was about $400 a year.

That was my limit. I’d already stretched what I thought this was worth at $200. I wasn’t going to double it again because we gave something away for free and it worked.

I understand the argument for charging more as customers grow. More traffic often means more business. It’s a reasonable model and I’m not going to pretend otherwise.

It just didn’t describe us. Our traffic doubled. Our bank account did not get the memo.

Plenty of customers look at that bill and find it perfectly fair. Good for them, sincerely. It wasn’t fair for us.

The part that actually made me leave

The price alone would have moved us eventually. The way I found out moved us immediately.

To be completely fair: Plausible publishes the policy. It’s right there. Its current documentation, checked September 5, 2026, says one month over the limit is fine. Two consecutive months over triggers an upgrade notice. A week after that notice, dashboards can be locked if you haven’t upgraded. Collection keeps running, settings stay accessible, and usage coming back under the limit can restore dashboards at the next billing cycle.

So there’s a grace period. A generous one, honestly.

I just didn’t know I was standing in it.

I hadn’t gotten an early warning email. I hadn’t seen a banner telling me we were over while there was still time to do something. The first message I received was the one telling me the upgrade was now required.

Which is a bit like being handed a speeding ticket by a cop who’s been following you silently for two months.

We run a bunch of sites. I log in, look at one number, answer the question I came in with, and leave. I do not sit there mentally adding up pageviews and custom events across every property like a man doing his taxes for fun. The combined usage total exists in account settings. It was not part of my Tuesday.

An email after month one would have solved this entire post out of existence:

You’ve gone over. Here’s what’s driving it. Here’s how long you have.

That’s it. That’s the whole fix. I could have untracked the plugin’s website in about ninety seconds. I didn’t care about its analytics. I cared about the four sites I’d been happily paying for since forever.

By the time I knew there was a problem, dialing traffic back down wouldn’t undo the upgrade requirement in front of me. The choice on the table was: pay more, or lose the dashboards.

The word for that

I’d already paid for the year. In March. Up front.

Canceling wouldn’t hand back the months of dashboard access I thought I’d bought. Paying more would let me keep using the thing I’d already paid for. I was also told I could downgrade later once usage dropped, and the difference would be credited as extra time.

I didn’t want extra time. I wanted the time I’d already bought.

There is a word for “pay us more or you don’t get your stuff back,” and it’s the title of this post.

I wrote to support and laid it all out. I said we were probably an edge case. I offered to pull the extra site off tracking. Our actual business hadn’t changed, and one free side project had briefly made us look like a bigger customer than we are.

The replies were slow, in my experience, and the answer left me facing the same upgrade.

That landed harder than it would have from a company I didn’t care about. I’d liked supporting a business funded by customers instead of investors. I’d assumed that meant there was a human on the other end with room to say “yeah, that’s silly, let’s sort it out.”

A published policy can still treat a customer badly. Being able to point at the rule doesn’t make the outcome feel fair.

And look, I know the size of this. A couple hundred dollars. A dashboard. Nobody’s house burned down. I’m aware of exactly how this sounds.

But small problems are cheap opportunities to make a customer glad they picked you. This one got resolved by the rulebook instead, and the rulebook lost you a customer who was writing you checks and telling his friends.

Everything I tried instead of building this

I want to be honest about how badly I did not want to be here.

Self-host the open-source edition. Plausible ships one, so I read through the backend and priced out what I’d need to rent to run it properly. The savings weren’t there. For our setup I was getting uncomfortably close to just paying for hosted analytics again, except now I’d also be the on-call engineer.

I’d already lived the self-hosted analytics chapter. I did not want a sequel with a bigger cast.

Switch to Fathom. Pricing felt more reasonable to me. It was missing a few things I wanted, and I didn’t love how the dashboard looked.

So I wrote a Chrome extension to restyle it.

Read that again. I built and shipped a browser extension so that I could be comfortable giving somebody else money. That is how much I wanted this to be anyone’s problem but mine.

Eventually a friend had to point out that I’d spent more effort avoiding the obvious next step than the obvious next step would take.

So we built it

We’ve been building software at Cloudmanic Labs for twenty years. We’ve run big systems. Keeping an analytics service online is not exotic work for us, and building software that runs on a modest amount of hardware is a thing we’re genuinely good at.

The more I stared at the pricing, the less I could talk myself into it. Plausible Business at a million monthly pageviews is $1,390 a year, checked September 5, 2026, and includes up to ten sites. We weren’t anywhere near that volume. I was looking at where the ladder went.

I don’t know anybody’s profit margin, and a server bill isn’t the whole cost of running a company. Support costs money. Development costs money. Backups, uptime, and answering emails at 11pm all cost money. We pay those bills too, so I’m not going to stand here and pretend the number should be zero.

But we also know exactly what it costs to store and count this much traffic, because we wrote it all down. We ran the math on charging a fraction of that price and still having a business at the end of it.

The math worked. So here we are.

Feasible is $99 a year. Unlimited sites. Unlimited teammates. A million pageviews and custom events a month, combined. A dashboard that fits on one page and doesn’t require an afternoon.

The part I care about most

*:first-child]:mt-0 [&>*+*]:mt-4">

Because I know precisely what it feels like to discover a grace period after it’s over, we send usage emails at 70%, 85%, and 100%. If you stay over, we ask you to reply. Replying stops the lock timer so an actual person can talk it through with you.

We have limits too. We’d just like you to hear about ours while you can still do something about them.

Yes, “Feasible” is a poke at “Plausible.” The .lol is us not being subtle about it.

I wanted analytics at a price I felt good about paying, from a company I felt good about paying. I couldn’t find both in the same place anymore.

Now that’s our job.

Why we don't charge per site

Wed, 02 Sep 2026 00:00:00 +0000

You launch a second site. It gets four hundred visitors a month. You go to add it to your analytics, and the answer is a bigger plan.

That’s the moment this post is about. Not the price - the shape of it.

What per-site pricing costs

Published list prices, annual billing, checked September 3, 2026.

Vendor and plan	Per year at 1M pv/mo	Sites	Seats
Plausible Starter	$690	1	Owner only
Plausible Growth	$1,040	3	3
Plausible Business	$1,390	10	10
Fathom	$600	75	Not published
Simple Analytics	$600	10	1
Matomo Cloud	$2,040	30	30
Pirsch Standard	$540	50	Unlimited
Umami Pro	$240	20	10
Feasible	$99	Unlimited	Unlimited

Some of those are generous, and worth saying so. Pirsch gives you fifty sites and unlimited teammates on the cheap plan. Fathom sells extra sites in packs of fifty for $100 a year, which is a fair price for a real thing. Umami’s twenty sites for $240 is good value by any reading.

But look at the first three rows as a ladder rather than three products. One site. Three sites. Ten sites. The site count is the thing that moves you up it, and at Simple Analytics the same is true of people - one user is included and each additional seat is $240 a year.

Here’s our objection, and it’s structural, not personal. A per-site price puts a toll booth at the exact moment a customer is about to make you more useful to them. The second site is when a tool stops being a thing you check and starts being the thing you check. The fifth colleague you add is the one who makes it hard to leave. Metering both is metering the habit you spent all that money acquiring.

A second site costs us almost nothing. A million pageviews a month is about 3.5 GB a year and 0.4 writes a second, and splitting that across nine sites instead of one doesn’t change the arithmetic. Neither does a sixth login. So we don’t charge for either, and if that ever stops being true we’ll tell you what changed instead of quietly adding a tier.

Compare the billing unit

This matters more than the site count, and almost nobody puts it on a comparison table.

Those vendors don’t all count the same thing. Sourced from each vendor’s own pages and FAQs, checked September 3, 2026:

Vendor	What counts against the limit
Plausible	pageviews + custom events
Fathom	pageviews + custom events - their FAQ says those requests are “counted as if they were pageviews”
Simple Analytics	datapoints - pageviews, events, and each stored event property
Umami	events - pageviews, custom events, and each stored property
Pirsch	pageviews + custom events + 10% of session-extension events; deleted domains keep counting until the limit resets
Matomo	hits - “a tracked page view, an event tracking, a download, an outlink, an onsite search or a content tracking request”
Feasible	pageviews + custom events

Now put that next to a normal Tuesday afternoon decision: let’s start tracking outbound clicks.

On Matomo’s definition, every outbound click is a hit. So are downloads. So are site searches. A site with all three turned on can generate two or three hits per pageview, which means a million-pageview site can need Matomo’s 2M or 5M tier - $399 or $975 a month rather than $204 (matomo.org/pricing, checked September 3, 2026). Your traffic didn’t change. Your instrumentation did.

On the datapoint model it’s finer-grained still. A pageview carrying five properties can bill as six datapoints. Add a property to an event you fire on every page and you’ve just multiplied your bill by a number you’d have to sit down to work out.

None of that is hidden - every one of those definitions is on the vendor’s own site, which is why we can link it. It’s just that it’s on a FAQ page and the price is on a pricing page, and you make the decision looking at the second one.

The practical effect is a slow tax on describing your business. Every extra field on an event is a line item somewhere, so the tool asks you to think about the bill every time you consider measuring something properly.

So here’s ours, plainly. We count pageviews and custom events. That’s the same unit Plausible and Fathom use, and it includes the outbound clicks, file downloads and form submissions our script fires on its own. Turn on outbound-click tracking and our number moves too. We’re not going to run a page that pretends otherwise.

What we don’t count is the describing. Properties are free, however many you hang on an event. So are the engagement and scroll pings behind time-on-page and scroll depth, because you can’t switch those off. So are sites, seats, goals and funnels. A sixth field on your purchase event costs nothing here and a tier somewhere else.

Two units, both of which you can count yourself before you buy. That’s as simple as we could make it and still be telling the truth.

What the limit is

A million pageviews and custom events a month, between them. Per account, per calendar month, UTC. Unlimited sites, unlimited teammates, unlimited properties, five years of retention. $9.99 a month or $99 a year.

A limit has to exist somewhere. Storage is real, CPU is real, and a plan with no number on it is a plan that gets repriced the first time someone points a firehose at it - usually by adding a tier and moving everyone up one. We’d rather publish the number now.

What we care more about is what happens when you cross it, because that’s where a pricing page stops being marketing.

Emails at 70%, 85% and 100%. One full month over costs you nothing at all. Two consecutive complete months over and we email asking you to reply, with fourteen days on the clock. Only if nobody replies does the dashboard lock - and even then collection never stops, nothing is deleted, and export keeps working. Come back in range, or reply to the email, and it unlocks straight away. There’s no overage charge in the product because we didn’t write one.

Compare that to a policy on the other side, and this is a real published one: Pirsch states that “If you reach the usage limit before the end of your billing period, your access will be limited to the day you reached the limit,” with five days to upgrade or wait for the reset (pirsch.io/pricing, checked September 3, 2026).

And credit where it’s due, because Fathom’s policy here is better than most and we’re not going to pretend otherwise. Theirs: “We’ll never turn your analytics off for occasional traffic spikes… if you go over for two months in a row, we’ll let you know we’re upgrading you” (usefathom.com/pricing, checked September 3, 2026). That’s the right instinct. The difference is what the upgrade costs.

One last thing that belongs in a pricing post more than a features post. Raw event export is a button here, in every plan and every copy of the software, hosted or self-hosted - one ZIP with the roll-up CSVs and the raw rows. At Plausible, scheduled raw event export is an Enterprise line item (plausible.io, checked September 3, 2026), which means there’s no published price at which you can get your own raw events out on a self-serve plan.

Getting your data out shouldn’t require the expensive plan. You should be able to leave without a project.

Above a million pageviews a month, email sales@feasible.lol and we’ll work it out. Everything else is on the pricing page, and the comparisons have the rest of the ladders with their sources.

One page, no menus, on purpose

Mon, 31 Aug 2026 00:00:00 +0000

The Feasible dashboard is one screen. Six numbers across the top, one graph, four report cards, one wide card underneath. No menu. No report list. No place to go.

You’ve either got what you came for by then or the product has failed, and we’d rather find that out than hide it behind navigation.

Fifteen metrics

There are fifteen metrics in the entire product: visitors, visits, pageviews, events, bounce rate, visit duration, views per visit, time on page, scroll depth, exit rate, conversion rate, group conversion rate, total revenue, average revenue, revenue per visitor.

That’s it. There’s no sixteenth waiting behind a menu.

Six of them are on screen the moment the page loads - unique visitors, total visits, total pageviews, views per visit, bounce rate, visit duration - and each tile is a button that redraws the graph with that metric. The other nine live where they mean something: time on page and scroll depth on pages, conversion rate on goals, revenue on revenue goals.

A metric list is a product decision disguised as a feature list. Every number you add is a number somebody has to rule out before they trust the one they wanted. Fifteen is already more than most people use.

The graph under the tiles is hand-drawn SVG. The whole dashboard has two runtime dependencies - React and React DOM. No chart library, no map library, no router, no state library. The map is generated country outlines and the flags are Unicode characters, so opening your stats page makes no request to anyone but us.

Filters stay on the page

The other way products get big is by growing a second screen for narrowing things down. A segment builder. A saved-view list. A modal with three dropdowns.

We put filters on the page as a row of pills, and you build them by clicking things.

Click a country on the map and you’re filtered to that country. Click a page row and you’re filtered to that page. Click a browser and a channel and now you’re looking at Firefox users from organic search on one URL, still on the same screen, still with the same six tiles at the top comparing against the previous period.

Six operators, no more: is, is not, contains, does not contain, matches regex, does not match regex. Repeated filters combine with AND, multiple values inside one filter combine with OR. Escape clears the lot.

And the filters live in the URL as readable parameters, which is the part that turns out to matter most in practice. ?f=is,country,DE&f=is,device,Mobile is a link. You can paste it into Slack and the person who opens it sees what you saw. That’s the feature that replaced saved segments, and we think it’s the better one - but you should know we don’t have saved segments, because some people want them.

There are thirteen date-range presets and every one has a single-key shortcut. W is last 7 days. F is last 28. L is last 12 months. X toggles comparison. ? lists them all. A keyboard shortcut is the cheapest speed you can give somebody, and nobody has to discover it for the product to work.

Scope changes the conversion rate

Here’s the specific, unglamorous thing we care most about getting right.

Custom properties in Feasible are declared as event-scoped or session-scoped, and you pick when you create them. Event scope means the property describes one hit - the plan name on a checkout event, the file name on a download. Session scope means it describes the whole visit - the logged-in plan tier, the A/B variant, the country of the account.

That choice sets the denominator on every conversion rate you’ll ever read off that property.

Say you fire signup with a property source=email, and you want the conversion rate for email traffic. If the property is event-scoped, the only events carrying source=email are the signups themselves - so your denominator is signups, and your conversion rate is 100%. It’s a true number and it’s useless, and worse, it looks fine. If the property is session-scoped, it’s attached to the visit, so the denominator is everyone who arrived from email and the rate is the one you wanted.

Same data. Same query. Two very different numbers, and only one of them is the question you asked.

Most tools let you attach a property and figure this out later, usually in a meeting, usually loudly. We make you say which one it is at creation time and we show the scope next to the property name in the report, because a conversion rate with an unexamined denominator isn’t a metric, it’s a rumor.

The same instinct shows up elsewhere. Ask for bounce rate broken down by page and Feasible refuses the query rather than answering it - bounce is a property of a visit, not of a page, and a number that quietly redefines itself to fit your breakdown is worse than an error message. And events that didn’t carry a property land in a labeled (none) row instead of silently vanishing from the total, so the column adds up to what you think it adds up to.

What you give up

Plainly, because you’ll find out anyway. Every argument for simple web analytics has a bill attached, and this is ours.

You can’t build an arbitrary custom report. There’s no report builder, no drag-and-drop dimension canvas, no saving a view and naming it. If your job is to answer a question nobody has asked before, in a shape nobody has used before, this is the wrong screen.

There’s no saved segment list, no session replay, no heatmaps, no cohort or retention report, and no A/B testing. Referrer is a filter, not its own report card. There’s no search-terms report either - you can connect a Search Console account, but nothing pulls the data across and nothing would read it back if it did.

Some of those are missing because we haven’t built them. Some are missing because we don’t think they belong in a tool this size, and session replay is the clearest case: a recording of one person’s session is a different product with a different privacy story, and the UK’s own analytics exemption draws the line in that place.

The escape hatch is that we didn’t lock the door. The Stats API is in every plan and every build - there’s no plan check in that code at all - and raw event export is a button that produces a ZIP with the roll-up CSVs and the raw rows. So when you do need the arbitrary report, you take your data and build it somewhere designed for arbitrary reports. That’s a better answer than us growing a worse version of that product inside this one.

Who shouldn’t use this

If you’re an analyst who lives in explorations, you’ll be bored in an hour. If you need session recordings or heatmaps to do your job, we don’t have them and won’t pretend otherwise. If you have a genuine attribution modeling problem across paid channels, that’s a different category of tool and you should buy it.

If you run a site, and once a week you want to know which pages people read, where they came from, and whether the thing you changed worked - that’s the whole design brief, and it fits on one screen.

The trade was never “fewer features, cheaper price.” It was that every feature we add is a feature somebody has to walk past on the way to their answer. We just decided to count that as a cost.

See what’s in it, or what it costs.

So do you need a cookie banner?

Fri, 28 Aug 2026 00:00:00 +0000

Article 5(3) of the ePrivacy Directive doesn’t contain the word “cookie.”

That’s not a technicality. It’s why most of what you’ve read about consent banners is aimed slightly to the left of the actual rule, and why “we’re cookieless, so you don’t need a banner” is a weaker sentence than the people saying it think.

We sell an analytics tool, so everything below is either a quote from the rule or a link to the regulator - and we’ll say plainly where our own product doesn’t clear a bar.

What the rule says

Directive 2002/58/EC, Article 5(3), as amended in 2009. This is the sentence everything hangs on:

“Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent… This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication…, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.”

(legislation.gov.uk, checked September 3, 2026.)

Three things to take from that.

The trigger is “information,” not “personal data.” The rule bites even when nothing you store is personal. A random number counts.

It’s technology-neutral. Cookies, localStorage, sessionStorage, IndexedDB, cache tricks - none of them are named, because it’s about the act of storing, not the mechanism.

There are two exemptions: storage needed to carry the communication, and storage strictly necessary for a service the user explicitly asked for.

Why “strictly necessary” doesn’t cover analytics

Analytics fails the second exemption on the same word every time: explicitly requested.

Your visitor asked for the article. They didn’t ask to be counted. So under the classic EU reading, measurement has never fitted exemption two, no matter how privacy-respecting the tool is. A vendor telling you otherwise is arguing a position, not reporting a rule.

Cookieless doesn’t settle the question

“Cookieless means no banner” rests on a claim that Article 5(3) is never engaged at all, because nothing is written to and nothing is read from the device.

The European Data Protection Board tightened that in Guidelines 2/2023 on the Technical Scope of Article 5(3), version 2.0 adopted October 7, 2024. Their reading is broad:

Storage and access “do not need to be both present” - either one engages the rule (§30).
JavaScript that “instructs the browser of the user to send asynchronous requests with the targeted information” is access, and “clearly falls within the scope” (§33).
A hashed unique identifier doesn’t escape it, because the browser was instructed to send it (§63).
The storage medium is irrelevant - hard disk, SSD, RAM, even CPU cache (§38).

But the EDPB also says the thing every summary leaves out. From §56: “the applicability of this article does not systematically mean that consent needs to be collected… in each case it would have to be assessed if a consent is needed or whether an exemption under Article 5(3) ePD could apply.”

So the question isn’t does this tool touch the device. It’s what is it for, and can anyone be identified with it. Which is how the UK now writes it down.

The UK analytics exemption

The Data (Use and Access) Act 2025, section 112 and Schedule 12, inserted a new Schedule A1 into PECR, in force February 5, 2026 (the statute, the commencement regulations). Biggest change in this area in years, and barely reported.

Paragraph 5 exempts storage or access where the sole purpose is to “collect information for statistical purposes about how the service is used with a view to making improvements,” the information isn’t shared, the user gets “clear and comprehensive information” about the purpose, and the user has “a simple means of objecting, free of charge,” and doesn’t object.

The ICO calls it the analytics exception and draws the boundary in one sentence: “It is about how your service is used, not about who uses it.” Their published examples (ICO guidance on storage and access technologies, last updated April 29, 2026):

Covered	Not covered
Visits page by page, traffic, user journeys	Logs or recordings of individual visitors
Scroll depth and on-page interactions	Whether someone viewed or clicked an advert
Device type, browser and OS versions	Linking a visitor ID to conversions shared with ad partners
Referrer, search, campaign source	Tracking or profiling individuals
Coarse geolocation at city or region level	Anything for online advertising

Two conditions vendors skate past, and we won’t. The exemption requires you to explain the analytics in your privacy notice, and it requires a simple free way to object - a toggle that’s on by default is fine, browser settings alone are not. A site running “exempt” analytics with no disclosure and no opt-out isn’t covered by the exemption it’s claiming.

Third-party tools are explicitly allowed - but your provider “must be a processor, not a joint controller,” must use the data only to improve your service, and must not pool it with anything else.

France uses self-assessment

CNIL’s audience-measurement exemption under Article 82 of the loi Informatique et Libertés is narrower. A tracker’s purpose must be strictly limited to measuring that one site, for the publisher alone, producing anonymous statistics only - and it must not cross-reference with other processing, pass non-anonymous data to third parties, or let a person be followed across sites or apps (CNIL, July 4, 2025).

Their self-assessment tool is unusually specific: referrer limited to host or domain; no CRM or campaign IDs imported from URLs; browser and OS reduced to major version; and if a fingerprint is used at all, the hash must carry a site-specific component and a time component, so it can’t follow anyone anywhere or for long.

Nobody can say “CNIL-approved” any more. CNIL retired its published list of evaluated tools in July 2025 and replaced it with self-assessment, and it forbids the phrasing outright - you may not present a solution as « certifiée » or « validée par la CNIL ». A vendor claiming it is describing a program that no longer exists.

Two rulebooks. Clearing ePrivacy doesn’t clear GDPR, and what GDPR-friendly analytics means is written out on its own page.

If a tool processes an IP address, even for a moment, that can be personal data - Breyer (C-582/14, October 19, 2016) held a dynamic IP is personal data for a site operator if that operator has legal means to identify the visitor using information held by the access provider. Conditional, not blanket. Where it applies you need an Article 6 basis, and legitimate interest under 6(1)(f) is the normal answer, which brings a balancing test and a right to object.

Privacy-friendly analytics doesn’t make GDPR stop applying. It makes it apply to a much smaller, shorter-lived pile of data with an easier case to make.

What Feasible stores

No cookies. None, ever, for visitors on a tracked site.

We do use localStorage, for two things. Every event is written to a small retry queue before the request goes out, so a dropped connection doesn’t become a missing pageview; a successful response deletes it. And if you set feasible_ignore yourself, we skip you. That’s storage on the device, and under Article 5(3) storage is storage. We’re not going to pretend it isn’t there to get a cleaner sentence.

No visitor identifier is stored on the device at all. The visitor hash lives on our side: a daily-rotating SipHash of user agent, IP and domain. The salt changes every UTC day and the old one is unrecoverable, so nobody - us included - can connect Tuesday’s visitor to Wednesday’s. It’s site-scoped, so it can’t follow anyone between sites.

It’s pseudonymous, not anonymous. We won’t use the second word. Pseudonymous data is still personal data, and a vendor who upgrades that adjective is telling you something about the rest of their claims.

The raw IP never reaches disk. Geolocation and hashing happen in the ingest tier and the address is discarded before anything is written. Geolocation is a local lookup against DB-IP Lite - country, region, city, no network call per pageview, nothing finer.

Where we don’t clear a bar: we’re a US company in Oregon with no EU region, and transfers run on standard contractual clauses through our DPA. CNIL’s own suggested alternative for anyone worried about transfers is a tool that makes none, and that isn’t us. If EU-only hosting is your requirement, buy from someone who has it.

Do you need one?

Most sites running Feasible won’t need a consent banner. The UK now has a statutory exemption written for this, and the practices it describes are the practices we implement. Elsewhere in the EU it’s a strong case rather than a settled one.

Do two things either way, because both are cheap and both are conditions of the UK exemption: put a plain sentence in your privacy policy saying you measure traffic and how, and give people a simple free way to opt out.

And if you’re somewhere strict, or regulated, or you’d just rather be certain - ask your own lawyer. We’re an analytics company, not your counsel, and nothing here is legal advice. Every rule above is linked so they can start from the source instead of from us.

More on the mechanism in the docs, and the rest of what we don’t collect is on the privacy page.

Google Analytics is free. Here's the bill

Tue, 25 Aug 2026 00:00:00 +0000

Google Analytics 4 costs nothing. That part is true, and it’s why roughly everyone uses it.

The bill arrives somewhere other than the invoice. Here are the line items we can source.

GA4 sets cookies. Cookies are storage on the visitor’s device, which puts the tag squarely inside Article 5(3) of the ePrivacy Directive, and in the EU and UK that means a consent request before the tag runs.

Every visitor who declines is a visitor missing from your numbers.

How many? We’re not going to give you a percentage, because the confident ones circulating don’t have a study behind them. The same goes for ad blocking: it varies enormously by audience - a mainstream consumer site might lose under 10%, a developer-heavy audience can lose more than half - and anybody quoting you a single number measured it on their traffic, not yours.

What’s certain is the direction. Your GA4 total is smaller than your real total, by an amount nobody can tell you.

There’s a second-order cost too. Since early March 2024, EEA advertisers have had to implement Consent Mode v2 to keep measurement working, and Google is explicit about the reach of that: “The requirements also apply if you are using Google Analytics data in Google Ads, Search Ads 360, or Display & Video 360” (support.google.com/google-ads/answer/13695607, checked September 3, 2026). Not implementing it “may lead to loss in data” - their phrasing.

Missing rows

This is the one that costs you trust with whoever you report to.

GA4 applies data thresholding: when a report includes demographic data, or search query information, or just a narrow date range with low counts, it removes rows rather than showing them. Google’s own page is blunt about your options - “Data thresholds are system defined. You can’t adjust them” (support.google.com/analytics/answer/9383630, checked September 3, 2026). The remedy Google offers is to widen your date range.

Whole rows. Not noised, not estimated. Gone, with a small icon.

Then sampling. The event-level query quota is “10 million events for standard Google Analytics properties and up to 1 billion events for Google Analytics 360 properties” (support.google.com/analytics/answer/13331292, checked September 3, 2026). You’ll read in a lot of places that standard reports are never sampled. Google’s own comparison of reporting surfaces groups Reports, Insights and Explorations together and marks sampling as possible for all three. Only the BigQuery export is marked as never sampled.

And cardinality. A dimension with more than 500 unique values in a day is high-cardinality, and GA4 has a cardinality limit of 50,000 values (support.google.com/analytics/answer/12226705, checked September 3, 2026). Past that, values collapse into a row called (other). If you have a lot of URLs, some of your URLs are now (other).

Three separate mechanisms, all on by default, none of which you can switch off, and the escape hatch for all three is an export into a data warehouse.

Fourteen months

You can set GA4’s retention for user-level data to 2 months or 14 months. That’s the whole list (support.google.com/analytics/answer/7667196, checked September 3, 2026). 26, 38 and 50 months exist only on 360.

Get the scope right, because a lot of posts don’t: the setting “does not affect standard aggregated reports.” Your headline pageview chart survives. What hits the wall at 14 months is Explorations and funnel reports - the analysis you’d sit down to do. And Google notes that when a standard property becomes Large, the event-level retention setting is “automatically reduced to 2 months” and older data is “permanently deleted.”

For comparison, since we’re a vendor and you should hear it from us plainly: Feasible keeps five years on the $99 plan, and Plausible’s Business plan keeps five (plausible.io, checked September 3, 2026).

The history that’s already gone

This is Google’s sentence, not ours.

From the Universal Analytics sunset page, last updated July 16, 2025: “Starting the week of July 1, 2024: You will not have access to any current or historical Universal Analytics data.” The same page says the data would be “permanently deleted by Google and won’t be recoverable” (support.google.com/analytics/answer/11583528, checked September 3, 2026).

Standard UA properties had already stopped processing hits on July 1, 2023. Nothing migrated into GA4 - not goals, not configuration, not history. Anyone who didn’t export in that window lost a decade of numbers. Migrating off Google Analytics to anything has the same shape: export first, switch second.

You can’t price that line. You can only notice that it happened, and ask what your current tool would do to you.

A 148 KB script

Measured on September 3, 2026, with curl -H 'Accept-Encoding: identity' <url> | gzip -9 | wc -c:

Script	Raw	gzip -9
Google `gtag.js`	427,563 B	148,451 B
Feasible	7,099 B	3,377 B

Over the wire on the day we measured, gtag.js came in at 147,179 bytes against our roughly 3.4 KB. About 43 times. And gtag.js is only the first request - it pulls more payloads once it loads, so the real figure is worse than the table.

Reproduce it yourself. Scripts change; that’s why we date ours.

While we’re being straight about measurements: our script isn’t the smallest in the category. Plausible’s is 1,291 bytes gzipped, comfortably under half of ours. The 43× is against Google, and that’s the only script comparison we’ll make.

Your visitors’ behavior funds advertising

Google’s revenue is advertising. GA4 data flows into Google Ads, Search Ads 360 and Display & Video 360 - that’s not an accusation, it’s the reason the Consent Mode v2 requirement above is written the way it is.

Now the part where we correct a claim that would help us.

Google Analytics isn’t illegal in the EU. Between 2021 and 2023, data protection authorities in Austria, France, Italy, Denmark, Finland, Norway and Sweden all found against GA in specific cases - most with reprimands and no fine, though Sweden’s IMY fined Tele2 SEK 12 million in June 2023, upheld on appeal in October 2025 (imy.se, checked September 3, 2026). Every one of those decisions turned on EU-to-US transfers after Schrems II.

That ground moved on July 10, 2023, when the European Commission adopted the EU-US Data Privacy Framework adequacy decision. Google is certified under it, which removes the transfer basis every one of those decisions rested on. The General Court dismissed a challenge to the framework in September 2025, and an appeal is pending at the CJEU as Case C-703/25 P with no ruling yet.

So the version: those rulings happened, they’re worth knowing about, and they aren’t a live prohibition today. Anyone still telling you GA4 is banned in Europe is running a page they haven’t updated since 2023.

The durable objection isn’t legal. It’s that the analysis you can do is capped, the rows you can see are edited, the history has a shelf life, and the counterparty’s business is advertising.

The time cost

The last line item is the one nobody puts on a slide. From r/GoogleAnalytics, March 12, 2026:

“Google Analytics 4 boggles my mind. It’s overly complicated and some of the most useful data points are harder to find or missing altogether.”

u/NowExciting, thread

You can find a thousand of those. What they have in common isn’t privacy - it’s that a small business owner wanting to know how many people read a page has to know which of several similar-looking metrics answers that question, and where the report lives.

That’s what a one-page dashboard is for, and why we built ours the way we did.

What $99 buys instead

No banner for most sites. No thresholding, ever - if a row exists we show it. Five years of retention. A 3,377-byte script. Raw event export as a button, not a plan tier. Unlimited sites and unlimited teammates. A health panel that names every dropped event and why, because failing silently is the actual sin here.

And a company whose revenue is your subscription, which is a shorter sentence than any privacy policy.

If you’re weighing it up, the head-to-head is here and the price is here. If you’re staying on GA4 - plenty of people should, and the BigQuery export is good - export your data on a schedule anyway. July 2024 is the argument for that, and Google made it.

What it costs to count a million pageviews

Fri, 21 Aug 2026 00:00:00 +0000

A pageview, stored the way we store it, is 210 bytes. A million of them a month, kept for a full year, is about 3.5 GB.

That’s most of the post. But nobody’s analytics invoice looks like a 3.5 GB file, so it’s worth walking the rest of the way slowly.

What one million pageviews need

A million pageviews isn’t a million rows. Scroll and engagement pings ride along so you can have time-on-page and scroll depth, so the event count for a million-pageview month is about 1.39 million. Our benchmark stored 1,394,408 of them and the account database came to 293.8 MB, plus 4.2 MB for the system database that holds accounts, sites and sessions. Twelve of those months is about 3.5 GB.

The write rate is the part people get wrong. A million pageviews a month sounds like load. Spread over a month it’s about 0.4 writes a second.

One Feasible process accepts around 6,000 events a second through the whole path - parse, geolocate, hash, drop the IP, commit. Median time to accept one is 13 microseconds, and it stays there regardless of what else is writing. So the machine is doing roughly one fifteen-thousandth of what it could.

Reads are the same story, for a boring reason: the reports are built when the events arrive, not when you open the page. Twenty-eight days of top pages comes back in 81 to 111 milliseconds. Twelve months takes 0.4 to 0.7 seconds.

The floor we publish is one CPU core, 512 MB of RAM and a gigabyte of disk. What we’d put a busy site on is two cores and 2 GB, because headroom is cheap and pager duty isn’t.

Those figures are from internal/bench/RESULTS.md in our repo, measured on a laptop. The repo’s public and so is the benchmark. Run it and tell us if we’re wrong.

Server cost

This part is just shopping. Prices below are list, checked September 3, 2026.

Host	Plan	RAM	Transfer	Per month	Per year
DigitalOcean	Basic, 1 vCPU	512 MiB	500 GiB	$4.00	$48
DigitalOcean	Basic, 1 vCPU	1 GiB	1,000 GiB	$6.00	$72
Vultr	`vc2-1c-1gb`	1 GB	1 TB	$5.00	$60
Hetzner	CX23, 2 vCPU	4 GB	20 TB	€5.49 net	~€66 net

One note on that last row, because stale numbers circulate: Hetzner raised prices on June 15, 2026 - the CX23 went from €3.99 to €5.49, and their ARM boxes are now more expensive than the Intel ones. Any Hetzner figure from an older blog post is wrong, including the ones we used to quote at each other.

Then bandwidth. Our tracking script is 3,377 bytes gzipped, 7,099 raw. Assume a pessimistic 30% of pageviews fetch it fresh rather than from cache: 300,000 × 3,377 bytes is about 1 GB a month, against the 500 GiB that $4 droplet includes. It’s a rounding error, and it would still be a rounding error if we were ten times worse at caching.

Storage fits on the $6 box. CPU is asleep. Bandwidth doesn’t register. The box is $48 to $72 a year.

We don’t run one box, to be clear. Ingest is a separate tier from the app, and there’s more than one of each, because a single machine that reboots is an outage and we’d rather it weren’t. That’s a redundancy bill. It isn’t a large one, and it doesn’t scale with your pageviews the way an invoice does.

Other architectures cost more

This is the caveat, and it cuts against us in one place.

Plausible’s Community Edition runs three containers - their application, PostgreSQL and ClickHouse - and their README asks for “at least 2 GB of RAM” (github.com/plausible/community-edition, checked September 3, 2026). ClickHouse’s own documentation recommends 32 GB and warns that below 16 GB “you may experience various memory exceptions because default settings do not match this amount of memory” (clickhouse.com/docs/operations/tips, checked September 3, 2026).

That’s not a knock on either. ClickHouse is a column store, and column stores are extraordinary at the queries analytics asks. On ClickBench - ClickHouse’s own benchmark, built on 100 million real pageview rows - ClickHouse stores a row in 145 bytes where SQLite takes 758. If we told you SQLite was more efficient on disk, we’d be lying to you by a factor of 5.2.

What SQLite buys us isn’t bytes. It’s that there’s one file, one process, nothing to tune, no cluster to keep quorate, and a backup that’s a file copy. On a machine this small, that’s worth more than compression.

And credit where it’s due before we talk about money: the privacy-friendly analytics companies got the important thing right, and got it right first. No cookies, no cross-site identity, no selling behavior to advertisers. They made that normal while everyone else was still arguing about it. The disagreement below is about a price, not about principles.

Vendor prices

Annual list price, annual billing, at 1,000,000 pageviews a month. Checked September 3, 2026.

Vendor and plan	Per year	Sites	Seats	Retention
Matomo Cloud	$2,040	30	30	Configurable
Plausible Business	$1,390	10	10	5 years
Plausible Growth	$1,040	3	3	3 years
Plausible Starter	$690	1	Owner only	3 years
Fathom	$600	75	Not published	Forever
Simple Analytics	$600	10	1	3 years
Pirsch Standard	$540	50	Unlimited	Unlimited
Umami Pro	$240	20	10	2 years
Feasible	$99	Unlimited	Unlimited	5 years

Two things about that table that matter more than the ordering.

The plans aren’t the same plan. Plausible’s $690 Starter is one site and no teammates, and custom properties, funnels and the Stats API all start on Business at $1,390. Comparing our price to Starter’s would be the same trick we’re complaining about, so we’ve listed all three.

The units aren’t the same unit. Matomo bills in hits - their own definition counts “a tracked page view, an event tracking, a download, an outlink, an onsite search or a content tracking request.” Turn on download and outbound-link tracking and a million pageviews can be two or three million hits, which is a different row on that price list. Simple Analytics and Umami count each stored event property as a unit of its own. We wrote a separate post about billing units, because it’s the part of the bill nobody puts on the comparison page.

Where the gap comes from

Some of it is real. Not the privacy part - privacy-friendly analytics is a design decision, not a line on an invoice. But a stack with a column store, a relational database and a queue in front of it costs more to run than one binary and a file - genuinely, not as a rhetorical device. Support costs money. Salaries cost money. A company that raised outside money has a number it has to hit, and that number is set by the people who wrote the check, not by the server.

Our costs are different because our company is different. One plan. No sales team. No investors. Twenty-odd years of Cloudmanic Labs paying for itself. That isn’t a virtue, it’s a starting position - but it’s why $99 works here and might not work somewhere else.

So: $48 to $72 a year for the machine. $99 to $2,040 a year for the service. We charge $99, both numbers are above, and we’re not going to draw the line between them for you.

We registered a .lol domain before we ran any of this. Running it didn’t change our minds.

The arithmetic is all reproducible - the pricing page has our side of it, the comparisons have theirs, and the benchmark is in the repo. If a number here is wrong, mail help@feasible.lol and we’ll fix the page.