Skip to main content

How to Migrate from Google Analytics to Umami 2026

·OSSAlt Team
google-analyticsumamianalyticsprivacymigration
Share:

How to Migrate from Google Analytics to Umami 2026

Umami is a free, open source Google Analytics alternative. Self-host it for $0/month, get a clean single-page dashboard, and stop sending your users' data to Google. No cookies, no consent banners, full GDPR compliance. The migration is as simple as replacing a script tag.

TL;DR

Deploy Umami (Docker + PostgreSQL), create your website in the dashboard, replace the GA script tag with Umami's tracking script, and you're done. The entire switch takes under an hour. Custom events take another hour to migrate. No data import from GA — Umami starts collecting fresh from day one.

Key Takeaways

  • Umami requires no cookies and is GDPR/CCPA compliant out of the box — no consent banner needed
  • Self-hosted Umami has no usage limits — track unlimited websites and pageviews
  • The tracking script is a single <script> tag; Next.js, Nuxt, and other frameworks work the same way
  • Custom event syntax is simpler than GA4: umami.track('event-name', { key: 'value' })
  • Umami lacks funnels, user-level tracking, and advanced segments — consider Plausible or PostHog if you need those
  • Umami Cloud offers a free tier (10K pageviews/month) if you prefer managed hosting

Why Replace Google Analytics

Google Analytics 4 is technically free but comes with real costs: your users' behavioral data goes to Google, consent banners are required in the EU (reducing effective analytics coverage by 20-40% on many sites), and the GA4 interface is notoriously complex for the value it provides to most websites.

Umami tracks what most websites actually need — pageviews, unique visitors, referrers, UTM parameters, devices, browsers, and countries — without requiring consent, without cookies, and without sending data to any third party. For personal projects, portfolios, content sites, SaaS landing pages, and documentation sites, Umami covers 90% of what GA4 offers at zero privacy cost.

For a detailed look at costs at scale, see the real cost of Google Analytics 360 vs Plausible. For the broader landscape of open source analytics options, see best open source analytics tools 2026. If you want to compare Umami to Plausible specifically, see how to migrate from Google Analytics to Plausible.

Step 1: Deploy Umami

# Clone and deploy with Docker
git clone https://github.com/umami-software/umami.git
cd umami
cp .env.example .env

# Edit .env:
# DATABASE_URL=postgresql://umami:password@db:5432/umami
# APP_SECRET=generate-a-random-secret-here

docker compose up -d

Default login: admin / umami — change immediately after first login.

For production, put Umami behind nginx or Caddy with TLS:

server {
    server_name analytics.yourdomain.com;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Or use Umami Cloud (cloud.umami.is) — free tier available up to 10,000 pageviews/month. This removes hosting overhead for low-traffic sites.

Hardware requirements are minimal: Umami runs comfortably on a $6/month VPS alongside other services. The database grows slowly even for high-traffic sites because Umami stores aggregate data rather than individual user sessions or full clickstreams.

Step 2: Add Your Website

  1. Log in to your Umami dashboard
  2. SettingsWebsitesAdd website
  3. Enter your domain name (e.g., example.com)
  4. Copy the Tracking Code shown

Step 3: Replace the GA Snippet

Remove Google Analytics (the entire block):

<!-- DELETE this entire script block -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXX');
</script>

Add Umami:

<script
  defer
  src="https://analytics.yourdomain.com/script.js"
  data-website-id="your-website-id"
></script>

That's the entire tracking implementation for standard pageview tracking. No additional configuration needed. Umami automatically tracks page changes in single-page applications via the History API — React, Next.js, Vue, SvelteKit, and other SPAs work without any extra setup.

Next.js integration:

// app/layout.tsx
import Script from 'next/script';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <head>
        <Script
          defer
          src="https://analytics.yourdomain.com/script.js"
          data-website-id={process.env.NEXT_PUBLIC_UMAMI_WEBSITE_ID}
          strategy="afterInteractive"
        />
      </head>
      <body>{children}</body>
    </html>
  );
}

Step 4: Set Up Event Tracking

// Track custom events
umami.track('signup-click');

// Track with data
umami.track('purchase', { plan: 'pro', amount: 49 });

// Track via data attributes (no JS needed)
// <button data-umami-event="signup-click">Sign Up</button>

Data attributes are the easiest approach — just add data-umami-event to any HTML element. No JavaScript, no event listeners, no imports. The Umami tracking script picks up these attributes automatically.

Migrating from GA4 events:

// GA4
gtag('event', 'sign_up', { method: 'email' });

// Umami equivalent
umami.track('sign_up', { method: 'email' });

The structure is similar. The main difference is that GA4 has reserved event names with special meaning (like purchase for enhanced ecommerce). Umami treats all event names equally — there's no predefined event schema to learn.

Data attributes with properties:

<button 
  data-umami-event="plan-selected"
  data-umami-event-plan="pro"
  data-umami-event-price="49">
  Choose Pro Plan
</button>

Event properties are tracked as key-value pairs and appear in your Umami dashboard under the event name. You can filter and view them in the Events section.

Step 5: Share Dashboards

  1. SettingsWebsites → click your site → Share URL
  2. Enable sharing → copy the public link
  3. Share with clients, stakeholders, or embed in internal tools

Shared dashboards are public, read-only views of your analytics. No account needed to view them — a simple URL is enough. This is commonly used by agencies sharing client analytics, open source projects showing their traffic transparently, or teams embedding analytics in internal documentation.

Feature Mapping

GA4 FeatureUmami Equivalent
Pageviews
Visitors
Bounce rate
Visit duration
Traffic sources✅ (referrers)
UTM parameters
Countries
Devices/Browsers
Custom events
Realtime
API
Multi-site
Team access
Data export❌ (API access)
Funnels
User tracking❌ (privacy-first)
Revenue analytics

GDPR and Privacy Compliance

Umami's privacy approach is architectural, not a configuration option. It does not set cookies, does not collect or store IP addresses, does not build user profiles, and does not share any data with third parties. Each pageview is an anonymous aggregated measurement.

This means: no cookie consent banner required in the EU, no GDPR data processor agreements needed for the analytics system, and no privacy policy sections covering individual-level tracking. For sites where cookie consent has noticeably reduced effective analytics coverage, Umami restores accurate measurement.

The tracking script can be served from your own domain (analytics.yourdomain.com), bypassing many ad blockers that specifically block third-party analytics domains. Because Umami runs on your subdomain rather than a Google domain, it passes through most browser privacy filters — giving you more accurate pageview counts than GA4 in privacy-conscious user segments.

Self-Hosting vs Umami Cloud

FactorSelf-HostedUmami Cloud
Cost$6-10/month VPSFree (10K events) → $9+/month
MaintenanceHandle updates, backupsFully managed
Data control100% on your serverUmami's infrastructure
LimitsNonePlan-based
Setup time30 minutesUnder 5 minutes

For most small-to-medium sites, self-hosting on a shared VPS alongside other services is the most cost-effective option. The Umami database grows slowly and compute requirements are minimal.

Server Requirements and Self-Hosting

Umami's resource requirements are modest. A basic single-site deployment runs comfortably on a $5-6/month VPS with 1GB of RAM and 1 vCPU. For multi-site deployments with significant traffic, a 2GB RAM instance handles several hundred thousand pageviews per month without strain. Umami uses a standard Node.js application stack, so you're not dealing with unusual infrastructure requirements.

Umami supports both PostgreSQL and MySQL for the database. PostgreSQL is generally recommended because it offers better performance for analytical queries and is more commonly available on managed database platforms. If you're already running a PostgreSQL instance for another application, you can add Umami's database to the same server or managed service.

The Docker Compose setup is the most common self-hosting approach. The official repository includes a docker-compose.yml that brings up the Umami application and a PostgreSQL container together. Behind the app, you'll want a reverse proxy — Nginx or Caddy both work well — to terminate TLS and proxy requests to the Node application on port 3000.

Upgrading Umami involves pulling the latest Docker image and running database migrations. The project uses Prisma for migrations, and the application runs them automatically on startup if new ones are detected. Most upgrades are seamless, but it's worth checking the release notes before upgrading across major versions, as schema changes occasionally require attention.

Common Pitfalls

One of the most common surprises when switching from GA to Umami is that historical data does not carry over. Umami starts collecting from the day you install it. If you need to preserve historical GA data for comparison or reporting, export it before switching — GA4 allows data exports to Google Sheets or BigQuery, but there's no way to import that data into Umami.

Bounce rate definitions differ between GA and Umami. Google's original bounce rate measured sessions with a single pageview. GA4 replaced it with engagement rate, defining a "bounced" session as one that lasted less than 10 seconds, had no conversions, and had only one pageview. Umami calculates bounce rate as sessions with a single pageview. These different definitions mean your Umami bounce rate will not match your GA4 engagement rate, and direct comparisons are misleading.

Session definitions also differ. GA4 uses a 30-minute inactivity timeout by default and resets sessions at midnight. Umami's session model is simpler — a session ends after 30 minutes of inactivity. For most practical purposes this is close enough, but if your team has been reporting on specific session-based metrics, the numbers will shift slightly after the migration.

The practical recommendation is to run both GA and Umami for 4-6 weeks before removing GA. This gives you enough data to compare the two systems on the same traffic, validate that event tracking is firing correctly, and let stakeholders get comfortable with Umami's reporting interface before GA disappears. Document any metric differences you find during the parallel run — bounce rate divergence, session count differences, referrer attribution gaps — so you can explain them confidently when stakeholders ask why the numbers changed.

The Bottom Line

Umami is the simplest GA replacement — deploy, add a script tag, and you have privacy-friendly analytics with no consent banner overhead. No cost, no cookies, no complexity. Self-host on a $6 VPS and track unlimited websites.

If you need more advanced features — funnels, revenue tracking, historical import, or user-level behavioral analysis — consider Plausible for privacy-first analytics or PostHog for a full product analytics suite. For the simplest, zero-cost, zero-privacy-compromise option, Umami is the right choice for the majority of websites.


Compare analytics tools on OSSAlt — privacy, features, and self-hosting options side by side.

See open source alternatives to Google Analytics on OSSAlt.

Why Replace Google Analytics?

The most immediate reason to move away from Google Analytics is the legal and UX overhead it creates. Under GDPR and similar regulations, dropping third-party tracking cookies without consent is not legal in the EU. This means every site running GA4 needs a cookie consent banner — and those banners are increasingly triggering user frustration. Studies consistently show that a significant portion of users either click "reject all" or close the banner without engaging, which means your analytics data is incomplete by design. When consent-based analytics gives you a distorted picture, you're making product and marketing decisions based on a sample of your audience, not the whole.

GA4 also introduced a level of complexity that many small teams find disproportionate to their actual needs. The shift from Universal Analytics to GA4 was not a minor UI refresh — it was a fundamental change in the data model. Events replaced sessions as the primary unit. The interface buried the most common views behind multiple navigation steps. Basic questions like "how many people visited my homepage this week" require building custom explorations or writing queries in BigQuery. Teams that just want to know which pages are popular and where traffic comes from do not need this complexity.

Beyond GDPR, Google's use of Analytics data in its advertising business is a legitimate concern. Google's privacy policy allows it to use data collected through its products to improve its own services, which includes ad targeting. Even if your users never interact with Google ads, the data about their behavior on your site flows into Google's ecosystem. For privacy-conscious products and for companies whose users care about data ethics, this is a reputational and trust issue.

Data sampling is another limitation that affects growing sites. GA4 applies sampling when reports cover large date ranges or complex segments. This means the numbers you see in the dashboard may not reflect actual traffic — Google is estimating based on a subset of your data. Self-hosted analytics processes every event without sampling, giving you exact numbers every time.

Umami vs Plausible vs Matomo

The three main self-hosted analytics options each occupy a different point in the simplicity-to-power spectrum, and knowing which to choose can save significant time.

Umami is the simplest. Setup takes about 20 minutes, the dashboard is minimal, and the resource requirements are low. It's the right choice when you want a quick replacement for the core GA use cases — pageviews, sessions, referrers, countries, devices — and want to avoid cookies entirely. The trade-off is that Umami lacks advanced segmentation, funnel analysis, and detailed event properties.

Plausible occupies the middle ground. It's also cookieless and privacy-first, and it offers slightly more polished reporting than Umami with built-in goal tracking, custom properties on events, and a better-developed public dashboard experience. Plausible is available as a paid cloud service or self-hosted. The self-hosted version requires more maintenance than Umami because it depends on ClickHouse for storage, which adds operational complexity. Choose Plausible when you want a more polished product and are willing to either pay for the cloud version or maintain a ClickHouse instance.

Matomo is the most powerful and the most complex. It's the closest to a full GA replacement, with funnels, heatmaps, session recordings, and A/B testing available as plugins. The trade-off is substantial operational overhead. Choose Matomo when you have specific advanced analytics requirements and the engineering capacity to run it properly.

Common Pitfalls

One of the most common surprises when switching from GA to Umami is that historical data does not carry over. Umami starts collecting from the day you install it. If you need to preserve historical GA data for comparison or reporting, export it before switching — but there's no way to import that historical data into Umami.

Bounce rate definitions differ between GA and Umami. Google's original bounce rate measured sessions with a single pageview. GA4 replaced it with engagement rate, defining a "bounced" session as one that lasted less than 10 seconds with no conversions and only one pageview. Umami calculates bounce rate as sessions with a single pageview. These different definitions mean your Umami bounce rate will not match your GA4 engagement rate, and direct comparisons are misleading. Document the differences during your parallel run period so you can explain them to stakeholders when the numbers shift.

The SaaS-to-Self-Hosted Migration Guide (Free PDF)

Step-by-step: infrastructure setup, data migration, backups, and security for 15+ common SaaS replacements. Used by 300+ developers.

Join 300+ self-hosters. Unsubscribe in one click.