Which fits: Google Analytics or Umami for your site analytics
A team facing a GA4 renewal question, a consent review or a data residency requirement usually needs one answer first: does the site analytics job fit Umami, or does it depend on something GA4 still does better? Umami fits teams that need cookieless traffic, campaign and conversion views on infrastructure they operate themselves, specifically a Node.js application backed by PostgreSQL. Umami's documentation describes it as working without cookies, cross-site tracking or the automatic collection of personal data, which removes the consent banner question for many sites, though whether a banner is needed still depends on your jurisdiction and your own configuration, which your counsel should confirm.
GA4 fits teams that depend on Google Ads, Looker Studio or broad marketing reporting. If paid search optimization, audience sharing with Google campaigns or dashboards built on Google's connectors sit at the center of the work, moving off GA4 means rebuilding those workflows rather than swapping a tag. Confirm which of these integrations your marketing and paid media teams use today, and list the reports that get opened every week, before deciding. Umami's reporting is deliberately narrower, so the gap should be measured against your actual reports rather than the feature list.
The decision turns on three questions. First, reporting depth: does your team need segmentation, funnels and attribution beyond what Umami covers, or can it run on traffic, campaigns and conversions? Second, who operates the stack: someone must own the Node.js application, the PostgreSQL database, upgrades and backups, or pay a partner to do so. Third, event volume and retention: check whether your expected event count and history length fit a self-hosted model, where your own database capacity sets the limit. Umami Cloud pricing is a separate question, and the pricing page is the place to confirm current plan limits before comparing costs.
Which option fits which team
This table maps common team situations to Umami, Google Analytics 4 or Matomo, with the reason tied to each platform's licensing, data handling, and reporting depth. Read each row against your own traffic, consent obligations and reporting needs, then check the rows that match your situation most closely.
| Team situation | Best fit | Why |
|---|---|---|
| Small content site that wants a simple traffic dashboard | Umami | MIT licensed, cookieless by design, and self-hostable on Node.js with PostgreSQL 12.14 or newer, so setup stays light. |
| Regulated EU publisher seeking a consent-free setup | Matomo | CNIL's exemption conditions can apply to self-hosted Matomo configured to its rules, but Umami is not assessed against those conditions here, so confirm with your counsel or CNIL guidance. |
| Marketing team running Google Ads and needing GA4 audiences | Google Analytics 4 | Native Google Ads linkage and audience sharing have no direct equivalent in Umami, so confirm any replacement workflow before moving. |
| Agency managing many client properties | Matomo | Umami's self-hosted reporting is lighter, so agencies with multi-site reporting, segmentation and custom dashboards should confirm feature coverage against their client requirements. |
| Team with no ops capacity that wants managed hosting | Umami Cloud | Umami Cloud adds email reports and a streaming API that self-hosting lacks, with paid tiers listed on the pricing page, so confirm current limits there. |
| Team needing raw hits and long-term retention under its own control | Umami or Matomo, self-hosted | Self-hosting keeps data in your infrastructure, and retention depends on your own storage policy rather than vendor limits. |
How the Umami stack is built and what it needs
Platform engineers who already run containers will usually start from the prebuilt image, published at docker.umami.is/umami-software/umami, rather than compiling anything. Umami's Docker Compose file starts the application together with a bundled PostgreSQL database, which makes a single-host evaluation straightforward. For production, most teams replace the bundled database with a PostgreSQL instance they already back up, monitor and patch, and point the application at it through its database connection setting.
- Image source: Pull the prebuilt image from the Umami registry path and pin a specific tag so upgrades are deliberate.
- Bundled database: The Compose file includes PostgreSQL for convenience; treat it as a starting point, not a backup strategy.
- External database: Using a managed or existing PostgreSQL cluster moves backups, failover and patching to the team that already runs those services.
- Version floor: Umami supports PostgreSQL from version 12.14, so check the server version before you connect.
- Upgrades: Each release is listed on the GitHub releases page, so read release notes before changing the image tag.
Confirm with your own platform team which PostgreSQL service, backup schedule and secrets store the deployment must use before you adopt the Compose file as written.
Developers who want to audit the code, patch it or run a branch build install from source. The installation documentation requires Node.js 18.18 or newer for this path, so the build host and any CI runner need that runtime or a later one that the project supports. The source install still needs a reachable PostgreSQL database, and the same version floor applies because the application code, not the image, decides which database features it relies on.
- Runtime floor: Install Node.js 18.18 or newer before cloning the repository.
- Dependencies: Install packages and build from the tagged release you intend to run, not the default branch.
- Database setup: Create the database and role in PostgreSQL 12.14 or newer, then run the migration steps described in the installation documentation.
- Process management: A source install runs as a Node.js process, so the team must provide a service manager, restarts and log collection.
- Patch carrying: Local changes must be rebased onto each new release, which adds recurring engineering work.
Confirm the exact build and migration commands for the release you choose against the current installation guide, since those steps change between versions.
Whichever path you choose, Umami is one Node.js web application that receives tracking events from the site script and writes them to PostgreSQL. The database holds the event and session data that reports are built from, so its sizing, backups and access controls matter more to a compliance review than the application container itself. Keeping the application stateless and the data in one database makes recovery mostly a database task.
- Stateless application: The web process holds no event data, so it can be replaced or scaled without a restore.
- Data location: All events land in the PostgreSQL database you operate, which is the main asset to protect.
- Backups: Schedule backups and test restores against the same PostgreSQL version you run in production.
- Network placement: Keep the database off public networks and allow only the application to connect.
- Scaling: Confirm with the project documentation how the application behaves under your expected traffic before you size the database.
Before go-live, ask your team to document where the database runs, who can read it and how a restore would be tested.
Where data lives and what control means under each option
Google Analytics 4 and Umami differ mainly in where events are stored, who can read them, and what evidence your organization must produce itself. The cards below cover data location, transfer rules, consent limits and the compliance work that stays with your team, whichever option you choose.
Where GA4 data is stored
GA4 events are processed on Google's infrastructure under Google's terms, and you cannot choose the storage region for standard properties from the interface. Your own copy exists only if you configure exports, such as the BigQuery export, and that copy then sits in your Google Cloud project. Check which regions your properties and exports use, and who in your organization holds access to them.
Umami on your own infrastructure
Self-hosted Umami writes events to a PostgreSQL database that you run in your own cloud account or data center, so the database, backups and access logs are yours to govern. Your team also controls the Node.js application and its logs. Confirm where the database host, backups and any reverse proxy or CDN in front of the tracker are located, because these determine the actual data path.
EU-US transfer context
The European Commission adopted its adequacy decision for the EU-US Data Privacy Framework on July 10, 2023 (decision 2023/1795), which lets personal data flow to US companies that participate in the framework. That decision is context for GA4 transfers, not a substitute for your own assessment. Confirm whether your Google contract and the vendors in your stack are covered, and record the basis you rely on.
CNIL consent exemption limits
CNIL's sheet 16 sets conditions for analytics to run without consent, including a limit on purposes, a single publisher scope, no cross-checking with other processing, truncation of the last byte of the IP address and a tracker lifetime of at most 13 months. CNIL also states that most large audience measurement offerings do not qualify regardless of configuration. Check each condition against your Umami setup and your site's other trackers before you drop a consent banner.
Umami's cookieless design
Umami is documented as an analytics platform that works without cookies, cross-site tracking or automatic collection of personal data. That design reduces what the tracker stores on visitors' devices, but it does not by itself settle a consent question for your site. Review the events you send, custom data fields and any identifiers your own code adds, since those can reintroduce personal data.
Compliance evidence you produce
Records of processing, retention settings, the legal basis you rely on, transfer assessments, access reviews and backup test results must come from your organization. DeployOpen can plan, configure and document these controls and prepare the evidence, but it does not issue audit reports, attestations or certifications. Ask your auditor or data protection officer which artifacts they will request before implementation begins.
What Umami Cloud adds over self-hosting Umami
The self-hosted version of Umami is free to use, and Umami's pricing page says Umami Cloud adds features the self-hosted version lacks, such as email reports and a streaming API. The license cost is zero in both cases, so the decision is about who operates the stack. Umami Cloud is a paid, hosted service with three published plans: Hobby at $0 per month for up to 100K events with 6 months of retention, Pro at $20 per month for 1 million events with 2 years of retention, and Business at $200 per month for 10 million events with 5 years of retention. Enterprise pricing and retention are quoted individually. Confirm current plan details and the feature list on the Umami pricing page before budgeting, because the plans are the vendor's to change.
Usage beyond a plan's event allowance is billed as overage: the pricing page lists $0.00003 per extra event on Pro and $0.00002 on Business. Event volume is therefore the cost driver to model. Count your monthly tracked events, not visitors, and add a margin for campaign spikes. Self-hosting shifts the cost to infrastructure you already pay for: a Node.js application, a PostgreSQL database from version 12.14 or newer, backups, TLS, and the staff hours for upgrades. Your own cost depends on your hosting prices and team, so ask your platform team or implementation partner for a written estimate instead of relying on a generic figure.
Pay for Cloud when you need the vendor-run features and do not want to carry uptime, patching and database maintenance yourself. In that model, Umami operates the hosted service and its availability, while your team still owns tracker placement, consent wording and the data you send. Stay self-hosted when data must remain in your own infrastructure, when your reports depend on keeping raw data under your own retention rules, or when you already run the Docker Compose stack reliably. In self-hosting, your team or a partner such as DeployOpen owns backups, upgrades to each release, and restore testing, so write those duties into the runbook before go-live.
How a move from GA4 to Umami is structured
The sequence turns an undocumented GA4 setup into a tested Umami deployment, a verified tracking script and a dated cutover, with the historical data decisions made before the old property goes quiet. Each phase closes with a check the team can sign off.
Inventory GA4 events, reports and dependencies
Start by listing every event, custom dimension, conversion, audience and scheduled report in the GA4 property, and note which team uses each one. Include tags that fire through Google Tag Manager and any integration with Google Ads, Search Console or BigQuery, because those links do not move to Umami. The inventory is done when each item is marked as keep, rebuild as a custom event in Umami, or retire, and the business owner of each report has approved the list.
Deploy Umami with PostgreSQL
Set up Umami on infrastructure your organization controls, either from the prebuilt Docker image with the Docker Compose file that bundles PostgreSQL, or from a source install that requires Node.js 18.18 or newer. For production, confirm with Umami's installation documentation which PostgreSQL version your environment supports (from version 12.14 is the documented minimum) and plan for backups, TLS and access control. The step closes when the admin login works, the database backup has been restored successfully in a test, and the team has recorded the hosting owner and the upgrade process.
Create websites and replace the tracking script
In Umami, create a website entry for each domain or property, then replace the gtag snippet on each site with the Umami script, placing it where the GA4 tag sat, and remove the old tag so both do not fire on the same pages. Check that the script is not blocked by your content security policy and that your Tag Manager container no longer loads GA4 on pages where Umami is active. The step is done when a test visit appears in the Umami dashboard for every template type, such as the home page, product pages, forms and checkout.
Define custom events, goals and campaign tracking
Rebuild the conversions from the inventory as Umami custom events, using the data attributes or JavaScript call that Umami documents for each button, form or outcome. Confirm that UTM parameters are captured on landing pages and appear in the campaign reports, and document the naming convention so marketing and engineering use the same event names. Umami records what the script sends, so events that depended on GA4 features such as enhanced measurement or automatic event collection need explicit replacements. The step closes with a test checklist where each conversion has been triggered once and shows in the dashboard.
Run Umami and GA4 in parallel
Keep GA4 active while Umami collects data on the same pages, so the two tools can be compared over a period the owners agree on. Compare totals for visits, pageviews and the main conversions, and record where the numbers differ and why, since the tools count sessions, bots and consent state differently. Consent-related behavior is part of this check: confirm with your privacy team whether the Umami configuration needs a banner in each market you serve. The step is done when the differences are explained in writing and the reporting owners accept the variance.
Decide historical data and retention before cutover
Before turning GA4 off, decide which historical data must be kept. Our supplied facts do not establish that GA4 history imports into Umami as raw hits, so ask Umami and your team whether any import route exists for your data and confirm the answer in writing. Where history must survive, export reports or BigQuery data while the export is still available and store it in an approved location with a retention period set by your records policy. The step closes when the keep-or-discard decisions are signed off and the export files have been checked for completeness.
Cut over and retire the GA4 property
Switch dashboards, alerts and recurring reports to Umami, remove any remaining GA4 tags from the sites and Tag Manager, and update the privacy notice and cookie policy to describe the tool in use. Keep the GA4 property in read-only status for a period set by your data owner so late questions can be answered from it. The step is complete when no GA4 tag fires on production pages, the stakeholders confirm their reports are running in Umami, and the cutover record lists the date, the owner and the archived data locations.
Questions buyers ask before choosing Umami over GA4
How much work is it to self-host Umami, and who has to do it?
Self-hosting Umami is a small application deployment: it runs on Node.js (version 18.18 or newer for a source install) with a PostgreSQL database (version 12.14 or newer), and the project publishes a prebuilt Docker image and a Docker Compose file that starts Umami with a bundled PostgreSQL database. Someone on your team or a partner must still provision the server, set up HTTPS, back up the database, apply upgrades and monitor uptime. The effort depends mainly on how many sites you track, your traffic volume, and whether your platform team already runs containers and PostgreSQL. Confirm these details against the Umami installation documentation before you size the work.
Does Umami need cookies or a consent banner?
Umami is designed to work without cookies, cross-site tracking or automatic collection of personal data, so it does not set cookies for its basic measurement. Whether you still need a consent banner depends on the rules that apply to your site, your country, and how you configure and combine the tool with other trackers. The cookieless design helps, but it does not settle the legal question by itself. Ask your privacy counsel to review your deployment, your privacy notice and any other scripts on the page, including the Umami README for its stated design.
What does Umami Cloud cost, and when is it worth paying for?
Umami is free to self-host under the MIT license, so your costs are the server, storage, backups and the staff time to run them. Umami Cloud is a separate paid service. Its pricing page lists a Hobby plan at $0 per month for up to 100K events with 6 months of retention, Pro at $20 per month for 1 million events with 2 years of retention, and Business at $200 per month for 10 million events with 5 years of retention, with overage charges per extra event. Cloud also adds features the self-hosted version lacks, such as email reports and a streaming API. It is worth comparing when you need those features and would rather not operate the service yourself. Check current terms on the Umami pricing page.
Can I move my historical GA4 data into Umami?
Umami does not document a general importer that rebuilds GA4 history inside it, so plan to keep GA4 data where it is and start Umami collecting from the cutover date. If you need older numbers for year-over-year comparison, export what you need from GA4 before you switch off the tag, and store those exports with your analytics records. Confirm current import options with the Umami project before you promise stakeholders any historical series. Note that Universal Analytics history is no longer available: Google stated that UA data access ended the week of July 1, 2024, and unexported data was permanently deleted.
How long does a migration from GA4 to Umami take?
The duration depends on the number of sites and properties, the tags and events you rely on, how many people build reports, and how much you need to rebuild on the Umami side. A small marketing site with a few pageview goals is a much smaller job than a multi-brand estate with custom events feeding dashboards. Ask any implementation partner for a timeline in writing, based on your own inventory of tags, events and reports. You should confirm the duration in scope, because no fixed timeline applies to every environment.
Which event tracking and reporting gaps should my marketing team expect?
Umami covers pageviews, campaigns, conversions and custom events for lightweight site analytics, but it is a narrower tool than GA4. Teams that depend on Google Ads audiences, advanced attribution models, or deep explorations built on raw event sequences often find the gap large. Before you switch, list every report and integration your marketing team uses today, then test each one in a staging environment. If those needs remain central, Matomo is another self-hosted option to evaluate alongside Umami.
Can our in-house team do this, or do we need a partner?
A capable platform team can deploy Umami alone, especially with the Docker image, but the harder part is the operating work: patching, backups, access control, monitoring and documentation for auditors or privacy reviewers. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. A fixed-scope engagement needs an inventory of sites, tags and reports, named technical owners on your side, access to your cloud or data center accounts, and a decision on who receives ongoing operations. Ongoing support is available as a retainer. DeployOpen does not publish prices, and a quote follows from the written scope.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Google Analytics vs Umami, that means starting from a written scope that decides whether Umami fits your sites and reporting needs, then building it in your environment.
How we scope
- Inventory the sites, pages and events you measure today, and which GA4 reports your marketing team relies on.
- Confirm the Umami deployment target, including Node.js and PostgreSQL hosting inside your own infrastructure.
- Agree in writing which reporting gaps need Matomo or another tool, so scope stays fixed.
How we build
- Deploy Umami from the published Docker image or a source install, with PostgreSQL configured and backed up.
- Implement the tracking script, custom event tracking and any tag manager changes across your sites.
- Test event collection, data retention settings and access controls, then document the results for your reviewers.
How we hand over
- Deliver runbooks covering installation, upgrades to new Umami releases, database backups and restore steps.
- Walk your team through the dashboards, event naming conventions and what Umami does not report.
- Provide a documented record of the setup that your compliance or privacy reviewers can assess with their auditors.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover version upgrades, patching of the host and database, and periodic restore tests.
- Ask for the support scope, response expectations and upgrade approach in writing before you sign.
