Do you also want Analytics for your site without paying Google? Then Umami is the choice for you.
Your site loses 30–50% of traffic in Google Analytics reports, you risk GDPR fines, and you’re handing your visitors’ data to an ad company. There’s an alternative: it’s called Umami, it installs with a 20-line file and gives you 80% of the info you actually need.
The number they lie to you about
Open GA4. Look at this week’s visits.
Now multiply by 1.5–1.7.
That’s the real number.
Three filters overlap without you knowing:
- Cookie consent: in the EU 40–60% refuse → not counted
- Ad-blockers: block 25–45% of GA requests
- Sampling: above certain thresholds, GA4 stops counting every event and estimates
No warning. No error bar. Just numbers that look right but aren’t.
The “free” cost
GA4 is free. The price is:
- Your data → fuels Google’s ad targeting
- Your compliance → banners, DPA, DPIA, assessments: $5,000–18,000/year
- Your performance → 45 KB + dependencies that slow Core Web Vitals
- Your freedom → data on US servers, subject to the CLOUD Act
In 2022 the Italian DPA declared GA4 non-compliant. You’re not alone: 8 EU countries did the same.
The alternative: 2 KB, zero cookies, your data
Umami is open-source (MIT) analytics that runs on your server.
| Umami | GA4 | |
| Cookies | None | Yes |
| Script | ~2 KB | ~45 KB + deps |
| GDPR | Compliant out of the box | Banner + DPA + DPIA |
| Data | On your server | On Google servers |
| Sampling | Never | Yes |
| Real cost | ~$5/month (VPS) | $5,000+/year (compliance) |
| Lost traffic | ~0% | 30–50% |
What it gives you: visits, pageviews, bounce rate, referrals, country, device, custom events, session replay, heatmaps, REST API, multi-site.
What it doesn’t give you: Google Ads remarketing, enterprise attribution. If you need those, GA4 stays the option. For 90% of sites, it’s more than enough.
Installation
Got a VPS with Docker? Perfect.
Installation is described step by step in the official documentation — basically:
- Clone the repo (or use the pre-built Docker image)
- Create a .env with password and secret
- docker compose up -d
- Log in at http://localhost:3000 with admin / umami
- Change the password immediately
For HTTPS, put a reverse proxy (Caddy, Nginx, Cloudflare Tunnel) in front of port 3000. Caddy does it in 3 lines with an automatic certificate.
If you want the easiest route: Railway, Render or Northflank have one-click deploy with a free tier.
The official docker-compose.yml is already in the GitHub repo — you don’t have to write it.
Configure your sites (2 minutes)
This is the part that makes GA4 feel dumb.
1. In the dashboard: Settings → Websites → Add Website
- Name: My blog
- URL: https://yoursite.com
- Click Create
2. Copy the snippet it shows you:
<script defer src="https://analytics.tuosito.com/script.js" data-website-id="abc123"></script>
3. Paste it before </head> on your site.
4. Done.
Within 30 seconds you’ll see the first visit (yours).
Custom event?
<button onclick="umami.track('download_pdf')">Download</button>
No “event parameter mapping”, no 47-minute wizard.
Backup (one line)
docker compose exec -T umami-db pg_dump -U umami umami | gzip > backup-$(date +%F).sql.gz
In crontab, once a week. It weighs a few MB.
The test that changes your perspective
Don’t “migrate”. Add the Umami snippet next to GA4 for a week.
Compare the numbers.
The difference isn’t that Umami is more accurate. It’s that GA4 was hiding half your visitors and you didn’t know.
Your site already has the data. You’re looking at it through fogged glass.
docker compose up -d and remove the glass.
Why Umami is GDPR-compliant (and GA4 isn’t)
It’s not a matter of “settings” or “configuration”. It’s architecture.
What Umami technically does
What Umami technically does | How | Why it matters for GDPR |
| No cookies, no persistent ID in the browser | Session ID computed server-side (hash of IP + UA + monthly salt) | No “information storage” on the device → ePrivacy doesn’t apply |
| IP never stored | Used in memory for geolocation, then discarded | IP is personal data (Art. 4.1). You don’t keep it → you don’t “process” it |
| Rotating salt | Monthly (sessions), hourly (visits) | You can’t link “yesterday’s user” to “today’s” → not a persistent identifier |
| No cross-site tracking | The hash is scoped to your website ID | You don’t build profiles, you don’t chase the user |
| Self-hosted | No extra-EEA transfer | Removes the Schrems II / CLOUD Act issue |
| Respects DNT (opt-in) | data-do-not-track="true" | Best practices |
Why GA4 can’t do the same
GA4 by design must:
- Set persistence cookies (for multi-day sessions)
- Store a unique, permanent Client ID
- Transfer data to Google servers in the USA
- Share data with its advertising ecosystem
None of these things is optional. It’s the business model.
The technical point lawyers ignore
Umami’s sessionKey is technically a pseudonymous identifier (hash of IP + UA + salt). In theory, under Art. 4(3) GDPR, any “identifier” that can be linked to an individual is personal data.
But in practice:
- The salt changes every day → it isn’t persistent
- It isn’t globally unique → two visitors from the same IP + UA on the same day share the key
The caveat (intellectual honesty)
If you enable Session Replay or send PII data in custom events (e.g. names, emails), compliance vanishes. With the default setup (pageview + anonymous events), you’re fine.
What you need in the privacy policy: one line. "This site uses a self-hosted analytics system that does not collect personal data and does not use cookies." Done. No banner, no DPA, no DPIA.
