Plausible Analytics

What is Plausible Analytics?

Plausible gives you visitors, pages, sources and goals on one screen, with a script small enough to barely register. It stores no cookies and no personal data, which means most sites do not need a consent banner.

Best for

Knowing how many people read a page without privacy overhead

Why choose Plausible Analytics

Plausible is the analytics tool for people who found Google Analytics exhausting. It shows visitors, page views, sources, top pages, entry and exit pages, and conversions on a single scrollable screen, with no property setup maze and no sampling. It sets no cookies and stores no personal data, which in most jurisdictions means no consent banner is required — a compliance simplification worth more than any individual chart. The script is small enough not to measurably affect page load, and because it aggregates rather than tracking individuals, exporting the numbers does not mean exporting a privacy problem. For anyone who just wants to know whether a page is being read, it is the right amount of tool.

Replaces

• Google Analytics
• Umami
• Fathom Analytics

Key features

• Cookieless, no personal data stored
• Single-page dashboard
• Goals, funnels and custom events
• Team accounts and shared dashboards

What to watch out for

Simplification is the product, so teams coming from enterprise analytics will miss funnels, cohort analysis, granular attribution and deep segmentation. Data collected before you configure a goal is gone, because there is no backfill and no reprocessing — decide your events before launch. Retention and query performance depend on the database behind it, and a busy site on a small instance will need tuning. Self-hosting means you own uptime of the tracking endpoint, and if it goes down quietly you lose data without noticing. Some advanced features exist only in the paid cloud product, so check the community edition's actual feature set before committing.

How to deploy

• Docker Compose with Postgres and ClickHouse
• Add the tracking script to your site
• Configure goals before launch

Getting started

Deploy it with an external database and create the site entry before touching any page. Add the tracking script directly in your site's template rather than through a tag manager, so a third-party failure cannot silently kill analytics. Configure your goals and custom events before launch, since retroactive reporting is not available. Enable bot filtering and check the dashboard after a day of real traffic rather than trusting the first hour. Add a simple uptime check on the script URL so you learn about an outage from a monitor rather than from a gap in the data.

Typical setup

One container plus a PostgreSQL database, with the tracking script installed directly in the site template rather than through a tag manager. Goals and custom events are defined before launch, because there is no backfill. Bot filtering is enabled, the instance is reachable only over HTTPS, and the database is backed up on the normal schedule. A simple external check watches the script URL, so an outage of the analytics endpoint is discovered by a monitor rather than inferred from a sudden flat line in the reports.

Who should look elsewhere

Not a replacement for a full analytics platform — there are no deep funnels, no user journeys and no audience segmentation, and events configured after the fact cannot be reported on historically. Anyone whose business depends on granular attribution should run it alongside a heavier tool rather than instead of one. And if no one will ever look at the dashboard, no analytics tool will help; the problem is not the software.

Project health

• GitHub stars: 29,275
• Last code push: 2026-10-01
• Open issues: 69
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.