If you ship a SaaS in 2026 and you instrument it with Google Analytics or with a hosted product analytics tool, roughly 30 to 45% of your users will block your tracking. Not because they hate you. Because their browser has uBlock, Brave's shields, or DNS-level blocking turned on. That is the new default. Your dashboards lie to you and you make decisions on a fictional sample. We moved to self-hosting analytics 2026 not because we are privacy zealots but because we wanted numbers we could trust. This is the case we make to other founders, including the parts where self-hosting is the wrong answer.
The ad-blocker problem nobody talks about
The single most underrated fact about analytics in 2026 is that the modern web has built-in ad-blockers. Browsers like Brave block third-party trackers by default. Safari Intelligent Tracking Prevention does the same. uBlock and similar extensions are installed on a substantial fraction of desktops.
What this means in practice: if your tracker is loaded from analytics.google.com or posthog.com or any well-known third-party tracker domain, a meaningful fraction of your traffic will not be counted. You cannot fix this with consent banners. You cannot fix this with cookies. You can only fix it by serving the tracker from your own domain.
We use insights.draftedby.com. Deliberately not analytics.draftedby.com. The pattern analytics.* triggers some ad-blocker filters by name. Picking a less-obvious subdomain is a small detail with a measurable impact on the percentage of traffic that gets counted.
Self-hosting solves this almost cleanly. The tracker comes from your domain. Ad-blockers see a same-origin script and most filter rules do not block it. The traffic numbers we get from our self-hosted analytics tend to match server-side log estimates within a few percent. Hosted analytics tools we tried earlier consistently undercounted by 30 to 40%.
If your analytics tool is a third-party tracker by domain, you are reading a partial sample of reality and pretending it is the truth.
The GDPR posture, briefly
For European founders this matters. Self-hosting analytics gives you more direct control over the data flow:
- The data does not leave your infrastructure.
- You can make a documented case for legitimate-interest processing of pseudonymous, low-risk data without a consent banner in many jurisdictions.
- You can answer "where is the data, who has access, how long is it retained?" with confidence.
We are not going to give legal advice. But the GDPR-compliance complexity of running a hosted tool with a US-based vendor is real, and the simplicity of running a self-hosted tool on your own EU-based hardware is also real. For our use case, with mostly EU customers, the self-hosted route is much less paperwork.
The catch: cookie consent law depends on jurisdiction. Some countries require consent for any analytics. Some allow exemption for strictly anonymous, non-identifying analytics. We always check the specific market. The lazy assumption "GDPR requires a consent banner for everything" is wrong; the laws are more nuanced than that.
The plugin pricing trap
The first time we evaluated analytics tools, we almost picked Matomo. Matomo is mature, has more features than Umami, and the core is open-source. We were ready to deploy it.
Then we read the plugin price list. Heatmaps and session recording, the two features we wanted most, are paid plugins. Together they cost around 290 EUR per year. Suddenly our "free open-source analytics" was 290 EUR per year with a model that could change next quarter.
We pivoted. We picked Umami for the core analytics (which is fully MIT and includes everything we need) and Microsoft Clarity for heatmaps and session recording (which is genuinely free and has no ad-blocker problem because it serves from clarity.ms with a relatively well-disguised pattern).
The principle generalizes: when you pick an open-source tool, read the plugin price list first. The features that matter to you are sometimes the ones the maintainers reserve for paid tiers. PostHog Scale licensing, for example, starts at thousands of euros per year for features that the Hobby tier locks out. We discussed this in detail in our PostHog vs Umami self-hosted breakdown, including why we still pay for PostHog Cloud free tier on Carriva.
The operational reality
Self-hosting is not free. The dollar cost is near-zero. The operational cost is real.
For us, Umami is a Coolify-managed deploy on the homelab Proxmox host. It runs in roughly 250 MB of RAM. It uses Postgres for storage. The total operational overhead is:
- Initial setup: 1 hour.
- Monthly maintenance: roughly zero (it runs).
- Backup overhead: included in our existing Postgres backup pipeline.
- Recovery time if it dies: 5 minutes (re-deploy from Coolify).
Compare that to the operational cost of running self-hosted PostHog Hobby that we lived with for 9 months: 12 GB of RAM, weekly babysitting of the ClickHouse component, recurring memory pressure alerts, and an upgrade path that required real planning. PostHog is a much more sophisticated tool. The operational complexity matched the sophistication.
The lesson is that "self-hosting" is not a single thing. Self-hosting Umami is trivial. Self-hosting PostHog is a real commitment. Pick the tool whose operational complexity matches your team size.
When hosted analytics is the right call
We are not religious about self-hosting. There are use cases where hosted is correct.
When you need product-analytics depth
Carriva is the most analytically rich product in our studio. Multi-step funnels, cohort retention, A/B testing potential, RAG-related event tracking. We use PostHog Cloud free tier for Carriva. The 1M-events-per-month cap is generous for our scale, the cost is zero, and we get the full PostHog feature set.
The reason we did not self-host PostHog for Carriva: the operational complexity is not justified by the cost savings at our current scale, and the 12 GB of RAM the self-hosted version eats is hardware we would rather use for other things.
When you need the team collaboration features
Hosted tools tend to have better multi-user collaboration features (commenting, dashboards shared via link, notification rules). For a team of 1 to 3, this matters less. For a team of 8, it matters a lot.
When your customer's compliance requires it
If you sell to a regulated buyer who insists on a SOC 2 attest from your analytics vendor, self-hosting puts the SOC 2 burden on you. That math rarely works out.
The architecture we landed on
For the studio in 2026:
- Most products on Umami self-hosted, served from
insights.draftedby.com. Simple page-view and event analytics. Coolify-managed deploy on the Proxmox host. Zero monthly cost beyond the homelab's existing electricity. - Carriva on PostHog Cloud free tier. Different product, different needs.
- Microsoft Clarity for heatmaps and session recording where we need them. Free, no ad-blocker problem, decent UI.
- Server-side log analysis as a periodic sanity check, comparing against the Umami numbers to make sure we are not undercounting.
That stack costs us nothing per month and gives us numbers we can trust. The infrastructure decisions feed into our broader solo dev DevOps Proxmox and Coolify homelab setup, which makes adding services like this nearly free.
The migration mechanics
If you are sitting on a hosted analytics tool today and you want to move:
- Pick the right replacement for your use case. Read the plugin price list. Match operational complexity to team size.
- Provision in parallel. Run both tools side by side for two weeks. Make sure the new tool captures everything you need.
- Pick a domain that does not look like analytics.
insights.*ormetrics.*orpulse.*instead ofanalytics.*. - Migrate the named events. Do not migrate page views (you will lose history but it is rarely valuable past 90 days). Do migrate event tracking for important conversions.
- Document the new dashboard locations. Otherwise the next time you go looking for a number, you will spend 20 minutes finding it.
We documented our migration in detail in the PostHog vs Umami self-hosted post.
The data ownership argument
There is a quieter benefit to self-hosting analytics that does not show up on a feature comparison: you own the data forever.
When a hosted analytics tool changes pricing, deprecates a feature, or shuts down, you lose access on their schedule. With self-hosted analytics, the schedule is yours. Six years from now, the data is still on your hardware (and your backups, which we discussed in our self-hosting Postgres in 2026 piece). You can query it, export it, replay it, whatever you need.
This matters less in week 1. It matters a lot in year 5. Founders who run a SaaS for the long term tend to value owning their own data. Founders building for a quick exit do not need to.
The mistakes other founders make
In conversations with other small-studio founders, three patterns stand out as mistakes:
- Over-instrumenting in week 1. They install three analytics tools. They never look at any of them. They add a consent banner that hurts conversion. The right move is one tool, well-configured, with a couple of named conversion events. Add depth as you grow.
- Trusting hosted dashboards over reality. If your hosted analytics says you got 2,400 visits and your server logs say you got 4,000, the server logs are right. Adjust accordingly.
- Picking analytics by feature list without considering ad-blockers. A tool with great funnels that is blocked by 35% of users is worse than a simpler tool that is blocked by 2%. Reach beats depth at small scale.
What is next for us
We will run the current setup through the rest of 2026. The two upgrades on the roadmap:
- Adding goal-based reporting in Umami so the dashboard surfaces conversion rates without a manual calculation.
- Cross-product analytics: a unified view across all four products with revenue, signups, and churn in one place. Probably built as a small custom dashboard reading from the underlying Postgres.
Self-hosting analytics 2026 is the right default for a small SaaS studio in our shape. It is not the right default for everyone. The decision tree is roughly: do you need product-analytics depth (PostHog), session recording (Clarity), or simple traffic-and-conversion truth (Umami)? Pick per use case. Do not pick per ideology.
We picked self-hosted as the default and exception-based hosted where it mattered. That mix has held up for over a year. We are not in a hurry to change it. The savings (in money, in trust in the numbers, in long-term ownership) compound. The cost (a few hours of operational learning) is paid once and then forgotten. That trade is the entire pitch.
