Privacy-friendly web analytics in 2026: revisit Matomo, Plausible and Umami before you add another tracking script

Most teams do not choose their web analytics. Someone pastes a Google tag into the site header during launch week, marketing adds Google Tag Manager a few months later, and after that the analytics setup grows by one script at a time. Nobody owns it, and nobody can say with confidence what data leaves the visitor’s browser. In 2026 that habit is harder to defend. Customers ask about third-party trackers in security questionnaires, browsers and ad blockers drop a growing share of analytics requests, and in India the Digital Personal Data Protection Act, 2023 is moving through its phased start, with the main duties for businesses due in May 2027.

So when a team says “let us move off Google Analytics” or “let us add a privacy-friendly tool”, the real question is wider: what do you actually need to measure, where should that data live, and who will run the thing? This post compares the three open source tools that most engineering teams weigh for self-hosted, privacy-friendly web analytics in 2026: Matomo, Plausible Community Edition and Umami. We look at where each one stands on 27 October 2026, how they store and identify visits, what cookies and consent mean for each, what they cost to run, and we work through a plan for one invented team.

A few earlier posts sit next to this one. In real-time OLAP with ClickHouse, Apache Doris and StarRocks we looked at column stores for event data; Plausible uses ClickHouse underneath, so that post explains a good part of its behaviour. In MySQL-compatible databases with MySQL, MariaDB and Percona Server we covered the database family that Matomo runs on, including the version changes that Matomo 6 now depends on. In uptime monitoring with Uptime Kuma, Gatus and the Blackbox exporter we looked at checking a site from outside, which is a different job from counting visitors but is often confused with it. And file backups with restic, BorgBackup and Kopia covers where your analytics database dumps should finally live.

A note before we start: this post explains what the tools do and what the Indian law says in its published text. It is not legal advice. For your own site, decide the legal questions with your legal or privacy team.

A scenario to keep us honest

Take an invented Mysuru company that sells heritage tours, palace and museum tickets, and school educational trips across Karnataka. About 15 engineers. The product is a Next.js marketing site with tour pages in English and Kannada, a booking and payment application, a portal for travel agents, and a separate site where schools book trips for their students.

Their analytics estate looks like this:

• Google Analytics 4 runs on the marketing site and the school trips site through Google Tag Manager. The container has 31 tags, including two ad pixels and a chat widget.
• A cookie banner plugin was added in 2024. It shows a banner, but the tags fire before the visitor clicks anything.
• The travel agent portal has a self-hosted Matomo 4 installation on a small shared virtual machine, set up by a former engineer in 2021. It still works. Nobody has upgraded it, and its MariaDB database shares the machine with a staging database.
• The booking application has its own event table in PostgreSQL that records searches, cart steps and payments. Finance trusts this table. Marketing trusts GA4. The two rarely agree.

Two things set off the current discussion. First, a large school group sent a vendor questionnaire asking for every third-party script on the school trips site, where the data goes, and how the company handles children’s data under the DPDP Act. The honest answer was “we will check”. Second, after the cookie banner was finally fixed to wait for consent, GA4 sessions on the marketing site fell sharply, while bookings in the PostgreSQL table did not change. The marketing head asked whether the business had a traffic problem or a measurement problem.

After the meeting, one developer proposed Plausible (“no cookies, tiny script, done in a day”). Another proposed upgrading the old Matomo and using it everywhere (“we already run it, it does everything GA does”). A frontend engineer suggested Umami (“MIT licence, it is just Next.js and PostgreSQL, same as our stack”).

The question this post tries to answer: which tool should this team run, for which sites, and what has to change apart from the script tag?

The short version

• Matomo (GPLv3, developed by the Matomo team at InnoCraft) is the oldest and widest of the three. It started as Piwik in 2007 and was renamed in 2018. It is a PHP application on MySQL or MariaDB, with visitor logs, goals, ecommerce, segments, a tag manager, server log import and paid premium plugins. The current stable release is 5.14.2 (22 October 2026). Matomo 6.0.0 is in beta since 9 September 2026 and needs PHP 8.1 and MySQL 8.0 or MariaDB 10.6.
• Plausible Community Edition (AGPLv3, by Plausible Insights) is the self-hosted release of the Plausible cloud service. It is an Elixir application that keeps users and settings in PostgreSQL and events in ClickHouse. It uses no cookies and a daily rotating identifier. The current release is v3.2.1 (15 May 2026), a security fix that all v3.x installs should have. Some cloud features, such as funnels, ecommerce revenue goals and SSO, are not in Community Edition.
• Umami (MIT, by Umami Software) is a Next.js and TypeScript application on PostgreSQL. It uses no cookies, and by default its visitor identifier rotates every calendar month. Umami v3 removed MySQL support. The current release is v3.4.1 (23 October 2026), a security release that upgrades Next.js and all self-hosted users are asked to apply.
• None of the three is a full replacement for GA4’s advertising features, and none of them makes a site “compliant” just by being installed. Cookieless tracking changes the consent picture under some laws, but personal data can still enter through URLs, events and custom properties.
• For the Mysuru team, the plan in this post is: first remove what should not be there (ad pixels and tags on the school trips site), keep the booking table as the source of truth for money, use one lightweight cookieless tool for the public sites, decide Matomo’s future on the agent portal as an upgrade question, and run whatever they choose like any other production service.
• Neither trigger was caused by the choice of analytics tool. One was an unknown list of third-party scripts, and one was a measurement gap that nobody had explained.

Where things stand on 27 October 2026

All times below are converted to IST where they matter. Dates come from GitHub releases, official changelogs and documentation, and the Gazette of India.

Matomo

• Stable line. Matomo 5 has been the current major version since 5.0.0 on 19 December 2023. In 2026 it has had a minor release almost every month, from 5.7.0 (29 January) to 5.14.0 (21 September), followed by 5.14.1 (4 October) and 5.14.2 (22 October 2026).
• Matomo 6 beta. The 6.0.0 beta changelog is dated 9 September 2026, and new beta builds were still appearing on GitHub on 26 October. Matomo describes it as the first major release since December 2023. The notable changes: PHP 8.1 or newer, MySQL 8.0 or MariaDB 10.6 or newer, tracking spam and bot prevention built in and enabled by default (including filtering of headless browser traffic from AI tools), a new consent column on the log_visit table that is added with an ALTER TABLE during the upgrade, removal of the old SEO plugin, removal of the experimental TiDB schema, and a front end build moved to Vite.
• Matomo 4. The last 4.x release we found is 4.16.2 (20 November 2025). If you still run 4.x, check its support status on Matomo’s own pages.

Plausible

• Release model. Plausible’s own page describes Community Edition as a long term release published about twice a year, while the cloud service gets changes several times a week.
• Recent releases. v3.0.0 (11 April 2025), v3.1.0 (13 November 2025, new per-site tracking script and snippet, form submission tracking, an interactive flag for events), v3.2.0 (26 January 2026, segment-limited shared links, ClickHouse low-memory settings that were not applied before, fixed) and v3.2.1 (15 May 2026).
• The security fix. v3.2.1 removes an HTTP /storybook endpoint that, in Plausible’s words, could under certain conditions allow remote code execution with the privileges of the user running the application. It is tracked as CVE-2026-8467. Every Community Edition release from v3.0.0-rc.0 to v3.2.0 is listed as affected when that endpoint is reachable from an untrusted network.
• Stack in the official compose file for v3.2.1. postgres:16-alpine, clickhouse/clickhouse-server:24.12-alpine and ghcr.io/plausible/community-edition:v3.2.1. The README asks for a CPU with SSE 4.2 or NEON (a ClickHouse requirement) and recommends at least 2 GB of RAM.

Umami

• v3. Umami v3.0.0 came out on 7 November 2025 with a new interface, segments, cohorts, tracked links and pixels. It also dropped MySQL: v3 supports only PostgreSQL, and the project published a migration guide.
• 2026 releases. v3.1.0 (17 April), v3.2.0 (25 June), v3.3.0 (12 August, two-factor login, session identity stitching, property filters), v3.3.1 (21 August), v3.4.0 (17 September, chart annotations, an MCP endpoint that is off by default, API keys and a typed API client) and v3.4.1 (23 October 2026).
• The security release. v3.4.1 upgrades Next.js to 16.4.2, which the release notes say fixes a critical remote code execution issue in next/og along with other problems, pins the Docker base image to a patched Node.js 22 image, and raises several dependency versions. The notes ask all self-hosted users to upgrade.
• Requirements. The README asks for Node.js 18.18 or newer and PostgreSQL 12.14 or newer. The source also has an optional ClickHouse path that turns on only when CLICKHOUSE_URL is set; the self-hosting documentation describes PostgreSQL.

India: the DPDP Act and Rules

• The Act. The Digital Personal Data Protection Act, 2023 (Act 22 of 2023) was passed by Parliament in August 2023.
• The Rules and the timeline. MeitY notified the Digital Personal Data Protection Rules, 2025 in the Gazette on 13 November 2025, together with notification G.S.R. 843(E), which brings the Act into force in three steps. From 13 November 2025: definitions, the Data Protection Board and related provisions. One year from publication: the provisions on Consent Managers. Eighteen months from publication: the main duties, including notice and consent (sections 5 and 6), the obligations of Data Fiduciaries (section 8), children’s data (section 9), the rights of Data Principals and the penalty provisions. Counting from 13 November 2025, those dates come to 13 November 2026 and 13 May 2027. MeitY published a corrigendum to the Rules on 16 December 2025.
• A possible change. In January 2026 newspapers reported that MeitY had asked industry about shortening the 18 month window to 12 months for some obligations. We could not find any notification making that change as of 27 October 2026. Check the MeitY and Gazette pages yourself before you plan around either date.

First question: why do you want to change?

Before you compare tools, write down which problem you are solving. The answer changes the choice.

• “We need fewer third-party scripts and a clear answer for questionnaires.” This is mostly a clean-up job. Removing tags does more than adding a new tool.
• “Our numbers dropped after the consent banner started working.” This is a measurement question. Part of the drop is real behaviour, part is visitors who decline, and part was always there as ad blockers. A new tool will count some of these visitors and not others, and you need to know which.
• “We want the analytics data on our own servers.” Self-hosting fits, but you take on a database, upgrades, backups and security fixes. The Plausible and Umami releases of 2026 above are a reminder of what that means.
• “We need full product analytics: funnels, retention, user journeys, revenue.” Matomo, with paid plugins for some parts, or Umami’s newer reports may fit. Plausible Community Edition leaves funnels and ecommerce revenue to its cloud plans. A product analytics tool such as PostHog may fit better than any of the three.

The Mysuru team had all of the first three problems and a little of the fourth. That is common, and it is why “pick one tool for everything” is usually the wrong first move.

What each tool is

Matomo

Matomo is a full web analytics platform. The tracker (JavaScript, mobile SDKs, an HTTP tracking API, or server log import) sends hits to a PHP endpoint, which writes raw visits and actions into log tables in MySQL or MariaDB. A separate archiving process turns those raw logs into reports per site, per period and per segment, and stores the results in archive tables. The interface reads the archives. Around this core sit goals, ecommerce, custom dimensions, a visitor log and visitor profiles, a tag manager, a consent manager integration, a Google Analytics importer and a marketplace of plugins, some free and some paid, such as heatmaps and session recordings, funnels and A/B testing. There is also Matomo Cloud, the company’s hosted service. Matomo states on its site that more than 1,000,000 websites use it; that is the vendor’s own figure.

Plausible Community Edition

Plausible is a deliberately small analytics tool. The tracker is a short script that sends a page view or event to the Plausible server. The server is written in Elixir on the Phoenix framework. It stores accounts, sites and settings in PostgreSQL and every event and session in ClickHouse, which is why queries over large date ranges stay quick on modest hardware. The dashboard is one page with sources, pages, locations, devices, goals and custom properties. Plausible Insights, based in Estonia, sells the hosted service and funds Community Edition from that revenue. Community Edition is released under AGPLv3, and the official install guide uses Docker Compose.

Umami

Umami is a Next.js application written in TypeScript, using Prisma to talk to PostgreSQL. The tracker sends events to an /api/send endpoint, which stores sessions and events in PostgreSQL tables. The interface started small, like Plausible, but v3 added segments, cohorts, funnels, goals, journeys, retention, revenue, boards and tracked links and pixels. It is released under the MIT licence, the most permissive of the three. Umami Software also runs Umami Cloud. You can run Umami with Docker, or build it from source with Node.js as an ordinary Node application, which suits teams that already run Node services.

Side by side

Licence and ownership

• Matomo is GPLv3, as the LICENSE file in the 5.14.2 release shows. The core is free to self-host. Premium plugins carry commercial licences and are paid for separately. The company behind it is InnoCraft, based in New Zealand.
• Plausible Community Edition is AGPLv3 or later. If you modify it and let users interact with it over a network, the AGPL asks you to offer them your modified source. For internal use this rarely matters, but legal teams in some companies have rules about AGPL software, so check early. Plausible switched from MIT to AGPL in October 2020, and from version 2.1 in May 2024 the self-hosted release has been called Community Edition. Funnels, user journeys, ecommerce revenue goals, SSO and the sites API are cloud-only.
• Umami is MIT. You can modify and embed it with very few conditions.
• All three companies sell a hosted version. That is how the open source work is paid for, and it means some features will always appear in the paid product first, or only there. Plausible is the most open about this; read the comparison page before you assume a feature exists.

Architecture and storage

• Matomo: PHP application server plus MySQL or MariaDB. Raw data lands in log tables (log_visit, log_link_visit_action and others), and reports come from archive tables built by core:archive. By default archiving can be triggered from the browser; for anything beyond a small site, Matomo recommends running core:archive from cron and turning browser-triggered archiving off. For heavy tracking load there is a QueuedTracking plugin that buffers hits in Redis or MySQL. Matomo’s own FAQ notes that it does not work behind a MySQL load balancer such as ProxySQL unless every query in one connection goes to the same server.
• Plausible: Elixir application plus PostgreSQL for metadata plus ClickHouse for events. You run three containers. ClickHouse is the part that needs care: memory settings, disk space and upgrades. The v3.2.0 release fixed low-memory settings for ClickHouse that had not actually been applied.
• Umami: Node.js application plus PostgreSQL. Two processes, both familiar to most web teams. Events and sessions live in normal PostgreSQL tables, so heavy traffic means a growing database and slower large queries, and you deal with that the PostgreSQL way: indexes, partitioning, retention and hardware.

Cookies and visitor identifiers

This is where the three differ most, and where marketing pages say the least.

• Matomo sets first-party cookies by default: _pk_id holds a visitor ID for 13 months, _pk_ses covers the 30 minute visit, and _pk_ref keeps the referrer for 6 months, according to Matomo’s cookie FAQ. You can call disableCookies to stop that, and use requireConsent or requireCookieConsent to hold tracking until a visitor agrees. Without cookies, Matomo builds a visit hash (the config_id) that it says is changed regularly so that long-term profiles cannot be built. Matomo’s documentation says plainly that without cookies the unique visitor counts become less accurate.
• Plausible sets no cookies and uses no local storage for tracking. Its data policy describes the daily identifier as a hash of a daily salt, the site domain, the IP address and the user agent, and says the salt is rotated and deleted every 24 hours and raw IP addresses and user agents are not stored. The result: the same person on two different days counts as two visitors.
• Umami sets no cookies either. In the v3.4.1 source, the session ID is a UUID derived from the website ID, IP address, user agent, a salt and an optional distinct ID, hashed together with the app secret. The salt is derived from the start of the current period, and the default period is a month; the SALT_ROTATION setting can change it to a week or a day. So by default Umami can recognise the same browser for the rest of the calendar month. That is not wrong, but it is a different privacy choice from Plausible’s 24 hours, and it is worth writing down. Since v3.3, a site can also identify a visitor on purpose and stitch sessions together; once you do that, you are clearly handling personal data.

Consent and the law

• In the EU and UK, ePrivacy rules cover storing or reading anything on the visitor’s device, not only personal data, so the answer differs by country. Matomo’s FAQ walks through this and, for Germany, suggests treating JavaScript tracking as needing consent.
• India has no separate cookie law. The DPDP Act applies to digital personal data, which it defines as data about an individual who is identifiable by or in relation to that data. Whether a hashed or truncated IP, a visit hash or a monthly session ID counts as personal data in your setup is a question for your legal team, not for a vendor’s marketing page.
• Section 9 of the Act deserves attention from anyone whose site serves children. Section 9(1) asks for verifiable consent of a parent before processing a child’s personal data. Section 9(3) says a Data Fiduciary shall not undertake tracking or behavioural monitoring of children or targeted advertising directed at children. Rule 12 and the Fourth Schedule list limited exemptions, for example for educational institutions in some situations. For the Mysuru school trips site, this matters more than any choice between analytics tools: ad pixels and retargeting tags on pages that students may use are the first thing to question.
• Whatever tool you choose, the risky data usually comes from your own configuration: email addresses or phone numbers in URLs, order IDs in events, names in custom properties, user IDs sent “just for debugging”.

Features

• Matomo: the widest set. Visits log and visitor profiles, goals, ecommerce, campaigns, custom dimensions, segments, annotations, scheduled email reports, a tag manager, a GA importer, server log import, a full reporting API, and premium plugins for heatmaps, session recording, funnels, A/B testing, form and media analytics.
• Plausible Community Edition: core traffic reports, goals, custom events and custom properties, outbound link, file download and form submission tracking, UTM campaigns, a stats API, shared links, segments, GA4 and CSV import (since v2.1), and Google Search Console integration. No funnels, journeys or ecommerce revenue in Community Edition.
• Umami: traffic reports, custom events with properties, segments and cohorts, funnels, goals, journeys, retention, attribution, revenue, UTM, boards, tracked links and pixels, annotations, an API with API keys, two-factor login, and a read-only MCP endpoint for AI assistants that is disabled by default.

Tracker script weight

In our drill (below), the Plausible and Umami scripts were a few kilobytes each and the Matomo 5.14.2 matomo.js about 68 KB before compression. For most sites, one script of that size is not the problem. Thirty tags in a tag manager are.

Performance and scale

• Matomo publishes sizing guidance, for example one server with 2 CPUs, 2 GB RAM and 50 GB SSD for up to 100,000 page views a month, and separate database and application servers from about 1 million actions a month. It also says a clustered setup can handle more than a billion page views a month. Both are the vendor’s own guidance and claims. In practice, archiving, the number of segments and database tuning matter more than the tracking endpoint.
• Plausible gets its query speed from ClickHouse. We found no official scale figures for Community Edition; Plausible itself says capacity and dashboard speed become your job when you self-host.
• Umami on PostgreSQL is comfortable for small and medium sites. Its ClickHouse option is not described in the self-hosting docs, so treat it as something to test, not a supported path.
• None of this is a benchmark. If volume matters, replay a week of your own traffic into a test instance.

Bots and blocked scripts

• Matomo 6 builds tracking spam prevention in and enables it by default; in Matomo 5 it is a plugin.
• Plausible’s comparison page says its cloud filters about 32,000 data centre IP ranges, while Community Edition has only basic user agent and referrer spam filtering. That is Plausible’s own description.
• Umami checks for bots by default (DISABLE_BOT_CHECK turns it off).
• All three scripts are on common ad blocker lists. Serving the script and endpoint from your own domain reduces the loss (Umami has TRACKER_SCRIPT_NAME, Plausible documents proxy setups). Do it to measure your own site, not to get around a visitor’s clear choice.

Upgrades and operations

• Matomo: web updater or console, with database migrations. Major upgrades can include long ALTER TABLE steps on large log tables, as Matomo 6 does with its consent column. Plan a window.
• Plausible: change the image tag and restart. Some releases, such as v3.2.0, also need the matching branch of the community-edition repository because ClickHouse settings changed.
• Umami: pull a new image or tag, build and restart; database migrations run as part of the build or start.

Data ownership and retention

• Matomo has settings to delete old raw logs while keeping reports, to anonymise IP addresses (Matomo suggests masking at least 2 bytes), to anonymise referrers, and tools to find and delete data for one visitor.
• Plausible stores events without IP addresses or user agents. Community Edition has CSV export and import to and from the cloud.
• Umami keeps self-hosted data indefinitely unless you delete it, according to its FAQ. Plan a retention job yourself.

What actually happens when you replace GA4 with one of these

A few things surprise teams in the first month.

• The numbers will not match. GA4 models some data, filters in its own way and loses visitors who decline consent. Plausible and Umami count without cookies and lose some visitors to ad blockers. Matomo depends on how you configure it. Run both tools side by side for four to six weeks and compare trends, not totals.
• Unique visitors mean different things. Plausible’s daily identifier, Umami’s monthly one and Matomo’s cookie or visit hash give three different “unique visitor” numbers for the same traffic. Pick one definition and write it on the dashboard.
• Conversions should come from your own database. Bookings, payments and sign ups are facts in your application. Analytics tools are good at “where did people come from” and “which pages did they see”, and weak at money. Send a goal event to the analytics tool, but report revenue from the booking table.
• Ad platform integration goes away. None of these tools feeds Google Ads or Meta the way GA4 and their own pixels do. If marketing depends on that, the decision is a business one, not an engineering one.
• Historical data stays where it was. Plausible and Matomo can import Google Analytics data, but imported data never looks exactly like native data. Export what you need from GA4.

A worked plan for the Mysuru team

Step 1: Write down every script you run

Open the Tag Manager container and the page source of every site. List each script, who added it, what it sends, where it sends it, and whether anyone still uses its data. For the school trips site, mark every tag that sets cookies or sends data to an advertising platform. This list is the answer to the school group’s questionnaire, and it usually shrinks by half once people see it.

Step 2: Remove before you add

Remove the ad pixels and the chat widget from the school trips site first. Remove tags that nobody uses. Make the consent banner hold every remaining non-essential tag until the visitor agrees, and test it in a fresh browser profile. Only then add anything new. This step alone answers most of the questionnaire, and it costs nothing.

Step 3: Agree on what you measure, and where the truth lives

Write a one page measurement plan: page views, a few goals (tour page viewed, booking started, booking paid), campaign sources, and nothing that names a person. Bookings and revenue come from the PostgreSQL booking table. The analytics tool answers “where from” and “what pages”. Agree on this with marketing and finance before the tool is installed, or the arguments about numbers will continue with a new tool.

Step 4: Choose a cookieless tool for the public sites

For the marketing site and the school trips site, the team needs simple traffic reports, a few goals, campaigns and a dashboard marketing can read. Plausible Community Edition and Umami both fit. In this case:

• Plausible’s 24 hour identifier and the absence of stored IP addresses make the answer to the school group simpler. The cost is one more stateful system (ClickHouse) and an AGPL licence check.
• Umami fits the team’s existing Node.js and PostgreSQL skills and has an MIT licence. The cost is a monthly identifier by default (set SALT_ROTATION to day if you want behaviour closer to Plausible), a larger feature set to keep away from children’s pages, and growing PostgreSQL tables.

The Mysuru team chose Umami with SALT_ROTATION=day, no identified users on the school trips site, no custom properties on pages that students use, and a retention job. Another team with ClickHouse experience could fairly choose Plausible. Both are reasonable; the configuration matters more than the brand.

Step 5: Decide Matomo’s future on the agent portal as an upgrade

The agent portal is used by logged-in business users, and the team uses Matomo’s visitor log and goals there. That is a different job from public site analytics. Treat it as an upgrade: move Matomo 4 to the current 5.14 line on its own machine, give it its own database (not shared with staging), turn on cron archiving, set raw log deletion, anonymise IPs, and plan for Matomo 6 once it is stable, after checking that PHP 8.1 and MySQL 8.0 or MariaDB 10.6 are in place. If, after a month, nobody uses the visitor log, fold the portal into the same tool as the public sites.

Step 6: Run it like production

Put the analytics server behind your normal reverse proxy with TLS. Expose only the tracker script and the collection endpoint publicly; keep the dashboard behind the VPN or SSO. Subscribe to the GitHub releases of the tool. Add the endpoint to uptime checks. Back up the database every night and test a restore. A self-hosted analytics tool with a public endpoint and an unpatched framework is a security risk, as both the Plausible /storybook issue and the Umami Next.js upgrade in 2026 show.

Step 7: Run side by side, then switch

Run GA4, with consent working, and the new tool together for four to six weeks. Compare daily trends against the booking table. Explain the gaps in a short note for marketing. Then remove GA4 from the school trips site. Whether GA4 stays on the marketing site, behind consent, for ad campaigns is a marketing decision, now made with clear numbers.

Step 8: Prepare for May 2027 with the rest of the company

Analytics is one item in the DPDP work, not the whole of it. Add the analytics tools to the company’s data inventory: what is collected, the purpose, where it is stored, how long it is kept and who can see it. Update the privacy notice. Let the legal team decide whether any analytics data on the school trips site is personal data of children and what follows from that.

When Matomo is the better choice

• You need ecommerce analytics, a visitor log, custom dimensions, heatmaps or A/B testing in one self-hosted tool.
• You need to analyse server logs without any JavaScript, for example for documentation sites or for strict consent setups. Matomo’s log analytics import does this.
• You run many sites and need detailed user permissions and scheduled email reports.
• You have PHP and MySQL skills and an existing Matomo installation with years of history.
• You want a tag manager that runs on your own server.

When not to change at all

• GA4 behind working consent meets your needs and your legal team is comfortable with it. Fix the banner and the tag list, and stop there.
• You only need uptime and response times. That is monitoring, not analytics.
• Your real need is product analytics with user identity and session replay. That is a different category of tool.
• Nobody will run it. Use a hosted plan from one of these vendors, or nothing. An abandoned analytics server on the public internet is worse than no analytics.

A short history, so the choices make sense

• 2005 to 2007: Google buys Urchin and launches Google Analytics in 2005. Piwik starts in 2007, growing out of the earlier phpMyVisites.
• 2010 to 2018: Piwik 1.0 (August 2010), 2.0 (December 2013) and 3.0 (December 2016). Piwik is renamed Matomo in January 2018, the year the EU’s GDPR starts to apply.
• 2019 to 2020: Plausible starts in 2019 under MIT, reaches v1.0.0 in October 2020 and moves to AGPL the same month. Umami appears on GitHub in July 2020. Matomo 4.0 arrives in November 2020.
• 2023: Universal Analytics stops processing data for standard properties on 1 July, leaving GA4. India’s DPDP Act is passed in August. Umami v2.0.0 (April), Plausible v2.0.0 (July) and Matomo 5.0.0 (December).
• 2024 to 2025: Plausible v2.1 (May 2024) introduces Community Edition and GA4 import; Plausible v3.0 (April 2025); Umami v3.0 drops MySQL (November 2025); DPDP Rules notified on 13 November 2025.
• 2026: Plausible v3.2.1 security fix (May), Umami v3.3 and v3.4 with v3.4.1 patching Next.js (October), Matomo 5.7 to 5.14 and the 6.0 beta (September).

Operational costs to plan for

• Servers. Umami: one small application server plus PostgreSQL. Plausible: application, PostgreSQL and ClickHouse, with at least 2 GB RAM recommended. Matomo: PHP server plus MySQL or MariaDB, with Matomo’s sizing guidance growing to separate database servers at around a million actions a month.
• Disk. Raw events grow every day. Decide retention on day one. Matomo can delete old raw logs and keep reports; for Umami you write the job; for Plausible, check the ClickHouse disk and the data retention options in your version.
• Patching. Two of the three tools had serious security releases in 2026. Budget time each month to read release notes and apply them within days, not quarters.
• Backups. Use the database’s own tools (pg_dump, mariadb-dump or a physical backup, ClickHouse backups) and send the files to your normal backup store. Test a restore.
• People time. Someone has to own the measurement plan and keep personal data out of events. This is usually more work than the servers.
• Licences and plugins. Matomo premium plugins are paid for separately. Plausible’s funnels and revenue features need the cloud. Umami’s features are in the open source release today.
• Legal review. AGPL acceptance for Plausible, the privacy notice, and the DPDP inventory all take time from people outside engineering.

A decision guide

• Small public sites, minimum data, simple dashboard, comfortable with ClickHouse: Plausible Community Edition, or Plausible Cloud if you do not want to run it.
• Small to medium sites, Node.js and PostgreSQL team, want MIT and more reports: Umami, with a shorter salt rotation if your privacy stance needs it.
• Ecommerce, many sites, detailed reports, log analytics, PHP and MySQL skills: Matomo 5.14 now, Matomo 6 after it is stable.
• Heavy volume and a team that already runs ClickHouse: Plausible, or test Umami’s ClickHouse path carefully; for raw event pipelines, see the OLAP post linked above.
• Advertising-led marketing that depends on Google Ads and Meta: GA4 with working consent, and a cookieless tool alongside it for an honest baseline.
• Product analytics with identified users: look at a product analytics tool such as PostHog, and do the consent work properly.

Checklist before you add another tracking script

• Every current script and tag is listed with an owner and a purpose.
• Unused tags and ad pixels on children’s or school pages are removed.
• The consent banner blocks non-essential tags until the visitor agrees, tested in a fresh browser.
• A one page measurement plan exists, agreed by marketing and finance.
• Revenue and bookings are reported from the application database.
• The visitor identifier and its rotation period are written down.
• No email addresses, phone numbers, names or order IDs go into URLs, events or properties.
• IP handling, retention and deletion are configured, not left at defaults.
• The dashboard is behind VPN or SSO; only the tracker and collect endpoint are public.
• The server is on the latest release (Matomo 5.14.2, Plausible CE v3.2.1, Umami v3.4.1 as of 27 October 2026).
• Releases are watched, backups run nightly and a restore has been tested.
• The tool is in the company’s data inventory and privacy notice.
• Both tools ran side by side for at least four weeks before the old one was removed.

Common mistakes

• Adding a privacy-friendly tool and leaving all the old tags in place. Now you have one more script, not fewer.
• Saying “no cookies, so no personal data”. Personal data can still arrive through URLs, events and properties, and the legal meaning of identifiers depends on the law and your setup.
• Assuming all cookieless tools work the same way. Plausible rotates daily, Umami monthly by default, Matomo depends on configuration.
• Comparing totals between GA4 and the new tool. Compare trends, and explain the gaps.
• Using analytics as the source of revenue numbers.
• Exposing the whole dashboard and admin pages to the internet.
• Installing once and never upgrading. The 2026 security releases of Plausible and Umami were for the exact versions most teams installed.
• Leaving Matomo on browser-triggered archiving for a busy site. Use cron.
• Treating the DPDP timeline as a far-off date. May 2027 is close, and the work is mostly about inventory and notices, which take time.

A small hands-on drill

We ran a small local drill on 27 October 2026, between about 6:19 PM and 6:35 PM IST, on a Linux x86_64 test machine, as a normal user in a throwaway folder. We did not run any of the three servers: PostgreSQL, ClickHouse and PHP were not installed on the machine, and we kept the drill short. Instead we downloaded the tracker scripts and the Umami source and looked at what the browser side and the identifier code actually do.

What we saw:

• Script size. Plausible’s generic script was 2,841 bytes (1,305 bytes with gzip -9). Umami’s cloud script was 4,810 bytes (2,349 bytes compressed). The matomo.js from the 5.14.2 release zip was 68,294 bytes (22,142 bytes compressed). Real transfer sizes depend on server compression and on the features you enable.
• Browser storage. Neither the Plausible nor the Umami script touches document.cookie. Each reads one local storage key, plausible_ignore or umami.disabled, which is the opt-out flag for site owners who want to exclude their own visits. The Matomo script contains the _pk_ cookie prefix and the disableCookies, requireConsent and requireCookieConsent options.
• Umami’s identifier. In the v3.4.1 source, SALT_ROTATION defaults to month, the salt is a hash of the start of the current day, week or month, and the session ID is a UUID from a hash of the website ID, IP address, user agent, that salt, an optional distinct ID and the app secret. So the default identifier is stable for a calendar month and is not built from a random salt that is thrown away.
• Umami’s stack. The v3.4.1 package.json lists Next.js 16.4.2 and Prisma 7, and the ClickHouse code path is enabled only when CLICKHOUSE_URL is set.
• Licence. The LICENSE file in the Matomo 5.14.2 release is the GNU GPL version 3.

This is a tiny inspection, not a benchmark or a legal test. It does show that “cookieless” covers different designs, so read the identifier code or documentation of whatever tool you choose.

Unlearn, re-learn

Unlearn the idea that analytics is a script you paste once. Unlearn, too, the idea that a privacy-friendly label does the privacy work for you. Re-learn analytics as a small production system with a purpose: a short list of scripts, a written measurement plan, an identifier you understand, data that stays free of names and phone numbers, a database you back up, a release feed you watch and numbers you can explain to finance. Matomo, Plausible and Umami are all good tools in 2026, each with a different balance of depth, simplicity and cost of running. Pick the one that fits the questions you need to answer and the team that will look after it. The tracking scripts will keep changing; a short, owned list of them will not go out of date.

Sources

• Matomo: Matomo changelog, Matomo 6.0.0 beta changelog, Matomo 5.14.2 changelog, GitHub releases, requirements and sizing FAQ, cookies created by the Matomo tracker, using Matomo without consent and the licence file
• Plausible: GitHub releases (v3.1.0, v3.2.0 and v3.2.1 notes), Community Edition repository and README, Community Edition compared with Plausible Cloud, data policy and the licence commit history
• Umami: GitHub releases (v3.0.0, v3.3.0, v3.4.0 and v3.4.1 notes), README and source, Umami FAQ and the MySQL to PostgreSQL migration guide
• India: Digital Personal Data Protection Act, 2023 (MeitY PDF), DPDP Rules, 2025 and the enforcement timeline on the MeitY site, Gazette notification G.S.R. 843(E) of 13 November 2025, the PIB release of 14 November 2025 and the Lok Sabha answer of 12 August 2026 on the phased timeline
• Reporting on the proposed shorter timeline: The Economic Times
• Google Analytics: Universal Analytics sunset notice
• Nearby options: PostHog, Matomo Cloud, Plausible Cloud and Umami Cloud