An official WordPress plugin

Tidemark Analytics is now in the WordPress.org plugin directory. Install it, activate it, open Settings → Tidemark Analytics, enter the address of your Tidemark Analytics and save.

• No cookies, and nothing stored in WordPress. The plugin keeps its settings and nothing else. Your statistics stay in Tidemark Analytics.
• It leaves you out. Signed-in administrators are not counted by default, you can choose other roles, and page previews are never counted.
• A separate script file. The script is a deferred file of its own, and the tag asks the common caching and speed plugins not to combine or delay it.
• The extras are one tick away. Outbound link clicks, file downloads, form submissions, and scroll depth and time on page.
• Custom events from your theme. Call plausible('Signup') from your theme or another plugin to record your own events.

The address is your own Tidemark Analytics install. The plugin is free and open source. The code is on GitHub.

An Install on menu

The snippet you copy from the dashboard, on the install page and in a site’s Settings → Tracking, now starts with an Install on menu: HTML, WordPress, Shopify, Next.js, Nuxt, Astro, SvelteKit and Laravel. Pick yours and it shows the file to open and the code to paste, already filled in with your site’s domain and script file. For WordPress it shows the address to enter in the plugin, with a link to the plugin page.

Tidemark Analytics remembers your choice, so the next site you add opens on the same one.

Smaller changes

• A site whose visits are all from today no longer looks empty in “Last 7/28/30/91 days”. Those periods end yesterday, so the overview now says so and offers a button to show today.
• The word “Tidemark” no longer shows up above the top bar now and then after signing in.

Upgrading

Self-hosted installs update from the dashboard as usual. There are no database changes in this release.

Two-factor sign-in, with more ways in

An authenticator app is still the default, and setting one up now shows a QR code to scan. You can also turn on e-mail codes (a one-time code sent to your account address, which needs outgoing e-mail on your install) and passkeys: your fingerprint, face, screen lock or a security key, as many as you like per account. At sign-in the page offers whichever methods you have set up.

Turning on the first method gives you ten recovery codes, shown once, for the day you lose your phone or key. You can make a new set from Settings → Security, which replaces the old one. Removing a method asks for your password.

Campaign links and tracking pixels

Site settings has a new Campaigns tab. The link builder adds UTM values to any page of your site and shows the result as you type, so visits from a campaign show up under Sources and Campaigns. Two things build on it:

• A short link (/l/abc) counts a click and forwards to the page with its UTM values.
• A tracking pixel (/p/abc.gif) counts a view when a newsletter loads it.

Both keep only a daily total per link: no cookies, no addresses, no visit. Opens are approximate, because mail apps may preload or block images. A short link can only point at a page on your own site.

Delete by filter

If something sensitive did get recorded, or a test run polluted the data, “reset all statistics” is too blunt. Site settings → Data now has Delete by filter. Choose conditions (a page, a country, a source or campaign, a browser, an event or an event property) and an optional date range, preview how many visits and events match, then confirm by typing the site’s domain.

A matching visit is deleted whole, with everything recorded during it, so your reports stay consistent. Imported history is not touched. Owners and admins can use it, and each deletion is logged with who ran it.

A tidier layout

A site’s settings sections now sit under Settings in the sidebar instead of a second list on the page. On phones the top bar is lighter: the menu, the site or page you are on, Find and your account. The organization switcher and the live visitor count moved to the top of the menu, and more controls are easy to tap.

Upgrading

Self-hosted installs update from the dashboard as usual, and the new tables are created automatically. E-mail codes need outgoing e-mail; everything else works on any install.

Organizations

Everyone now has a Personal organization, created with their sign-in. It holds the sites you add by default and it is just yours: no admins, no invitations, nothing to set up.

When you work with others, create an organization from the switcher in the top bar. It has one owner and any number of admins, who can see and change every site in it, add and delete sites and manage its teams, while billing, deletion and who else is an admin stay with the owner. The owner can hand the organization over to one of its admins; they accept, and the previous owner stays on as an admin. Give an organization a logo, and your photo shows on Personal, so a long list stays easy to tell apart.

Teams and invitations

A team is a named group in an organization. Share a site with it as Viewers or Admins and everyone in the team has access, now and as people join or leave. A person with access in several ways simply has the strongest role.

Adding someone who has no account yet now sends them an e-mail invitation: a single-use link, valid for 72 hours, where they choose a name and password. Nothing is created for them until they accept. On a self-hosted install this is off until you set TIDEMARK_INVITES=true (it needs working mail settings).

The site’s People with access section is one list now: the owner, organization admins, teams (open one to see who is in it), people added directly and pending invitations, each marked with how they got access, and one field to add a person by e-mail or a team by name.

Moving a site

A site can move to another organization from its Sharing and access settings. You see who gains and loses access before you confirm. You need to be an owner or admin of both organizations, and unless both have the same owner only the owner of the organization it is in can move it out. Statistics, goals, shared links and the people you added to the site directly come along; access that came from the old organization does not.

Scroll depth and time on page

An opt-in script variant (Site settings → Tracking) sends one extra event per page view with how far the visitor scrolled and how long they were active, as numbers you can use in goals, filters and funnels. It does not change your bounce rate, and it captures no element, text or position.

Upgrading

Updates are automatic. Everyone gets a Personal organization and the sites they own move into it; nothing else changes until you create an organization. The full list is in the changelog.

Hear about it without checking

Email reports. Each person can ask for a weekly or monthly summary of any site they belong to, under Account settings → Email reports. It covers visitors, pageviews, bounce rate and visit duration against the period before, the top pages, sources and countries, goals with revenue, and the notes on your graph. It arrives at 08:00 in the site’s timezone, has no tracking pixel and no tracked links, and every message has an unsubscribe link.

Alerts and webhooks. Under Site settings → Alerts, create rules for a traffic spike or drop against the usual for that weekday and time, a goal reaching a number of conversions, new conversions of a goal, or a traffic source that sent nothing in the last 28 days. Send each rule by email, to Slack or Discord, or to your own service as signed JSON. Rules have quiet hours and cooldowns, failed deliveries are retried, and every message carries totals only, never anything about a visitor.

Notes on the graph. Add a short note to any date, such as “launched v2”, and it shows on the graph and in the table view. A note can be private, shared with everyone on the site, or shown on the public dashboard.

Collect less, and count what is real

Privacy controls. Each site can now respect Global Privacy Control and Do Not Track, keep only the country or the region instead of the city, keep only a referrer’s domain, and decide which URL query parameters may be stored at all.

Small groups. Set a minimum, and public dashboards and shared links leave out rows with fewer visitors than that. A filter cannot narrow a public view down below it.

Masking personal data. Email addresses, tokens, UUIDs and long numbers that a site sends by accident in a page address, referrer or event are replaced with a placeholder before they are stored. Only a count of how often it happened is kept. Self-hosted installs have it on by default.

Bot and spam filtering. On top of known crawlers, Tidemark Analytics now leaves out headless browsers, traffic from the address ranges of large cloud and hosting providers, referrer spam, and floods from a single visitor. It uses only what each request already carries, and keeps a daily count of what was filtered, by reason, which the site settings show. It is on by default and each site can turn it off, which helps when you are testing from a script or a server. A few people browse through VPNs hosted in those data centers, so the switch is there if you need it.

For scripts and assistants

MCP server. An AI assistant can read a site’s stats through a read-only MCP endpoint. Create an API key under Account settings → Security, choose Read-only, and paste the configuration it shows into your assistant. It can read totals, trends, top pages and sources, goals and funnels, and nothing else.

Read-only API keys. A read-only key can only read statistics through the Stats API and MCP. Full-access keys still have the same access as their owner.

Stats API and OpenAPI. The Stats API gains goals and funnels, and the whole API is described in an OpenAPI document at /api/v1/openapi.json, so you can generate a client in the language you use.

Which plan gets what

Self-hosted installs get all of it, including email reports, notes, bot filtering, the privacy controls, alerts and webhooks, the API and MCP.

Updating a self-hosted install needs nothing special: take the new release from the in-app updater or pull the new Docker image, and the migrations run on their own. The full list is in the changelog.

The snippet

<script defer data-domain="yourdomain.com" src="https://analytics.example.com/js/script.js"></script>

Replace the domain with your site’s, and the src with your own Tidemark Analytics address if you self-host. The script is about 2 KB, sets no cookies, and sends a pageview on load and on every history change.

Plain HTML

Paste the snippet inside <head> on each page, or in the shared include if you use one.

Astro

Put it in your base layout, for example src/layouts/Base.astro:

<head>
  <script is:inline defer data-domain="yourdomain.com" src="https://analytics.example.com/js/script.js"></script>
</head>

is:inline stops Astro from bundling or rewriting the tag. Astro’s view transitions change the page without a full reload, and the script’s history tracking picks that up.

Hugo

Add it to your theme’s layouts/partials/head.html (or a partial the head already includes):

<script defer data-domain="{{ .Site.Params.analyticsDomain }}" src="https://analytics.example.com/js/script.js"></script>

Setting the domain once in hugo.toml keeps staging builds from reporting under the wrong site.

Eleventy and Jekyll

Add the tag to the base layout’s <head>. In Jekyll you can wrap it in {% if jekyll.environment == "production" %} so local builds are not counted.

Next.js

In the App Router, add it to app/layout.tsx with the built-in script component:

import Script from 'next/script';

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Script defer data-domain="yourdomain.com" src="https://analytics.example.com/js/script.js" strategy="afterInteractive" />
      </body>
    </html>
  );
}

Client-side navigation is a history change, so every route gets a pageview without extra code.

Hash-based routers

If your app navigates with #/route URLs, use the hash variant: script.hash.js.

Keep development visits out

The script ignores localhost by default, so running your site locally does not add visits. Add the local variant only if you want to test there.

Test it

1. Deploy, then open the live site in a private window.
2. Watch current visitors in your dashboard.
3. Navigate between pages and confirm each one appears.

If you run a content security policy, allow the analytics address in script-src and connect-src.

Next steps

You can also count outbound links, downloads and form submissions by adding variants to the file name. This guide has the details.

This guide uses Tidemark Analytics, but the steps are the same for any tool that gives you a single script tag.

Before you start

You need a self-hosted Tidemark Analytics install and access to your WordPress admin. In Tidemark Analytics, add your domain under Add site and copy the snippet. It looks like this:

<script defer data-domain="yourdomain.com" src="https://analytics.example.com/js/script.js"></script>

If you self-host, the src points at your own Tidemark Analytics address instead.

Step 1: Add the script without touching theme files

Editing header.php is fragile, because a theme update can wipe your change. Use a header-and-footer snippet plugin instead. Plugins such as WPCode or Insert Headers and Footers are common choices.

1. Install and activate the plugin.
2. Open its settings and find the Header (or “Scripts in Header”) box.
3. Paste the Tidemark Analytics snippet and save.

Block themes and some page builders have their own “custom code” area that does the same job. If yours does, use it.

Step 2: Remove Google Analytics

Delete the old tag in whatever added it: the Google Analytics plugin, a “Site Kit” setup, or a snippet in your theme. Running both for a couple of weeks is useful for comparing numbers, but remove Google Analytics when you are done so you can drop the cookie banner if it only existed for analytics. Keep it if other tools on your site still set cookies.

Step 3: Check it works

1. Open your site in a private window.
2. Open the Tidemark Analytics dashboard and look at current visitors. You should see yourself within a few seconds.
3. Click around, and confirm the pages show up under Top pages.

If nothing appears, view the page source and search for data-domain. If it is missing, a caching plugin may still be serving the old page.

Caching and optimisation plugins

• Clear the cache after adding the script, so visitors get the new page.
• Do not defer or combine the script in a way that rewrites it. Most optimisation plugins can exclude a script by its address, so add your Tidemark Analytics address to the exclude list if you see missing visits.
• CDN and ad blockers: some blockers hide analytics scripts. You can reduce that by serving the script from your own domain through a proxy and setting data-api to match. The Tidemark Analytics docs explain the setup.

Track forms, downloads and outbound links

Tidemark Analytics can count outbound link clicks, file downloads and form submissions by changing the script file name, for example script.outbound-links.file-downloads.js. This guide covers the options.

What about the old data?

Google Analytics history cannot be imported into Tidemark Analytics. Export the reports you want to keep, and treat the switch date as the start of the new data. Here is a longer migration checklist.

Before you start

• Add the site to Tidemark Analytics first, using the same domain you track in Plausible.
• Set the site’s reporting timezone to match Plausible’s (Site settings → Data). Dates in the export follow the timezone the site had in Plausible, so a mismatch shifts days.
• You need to be an owner or admin of the site.
• Make sure there is room for the data. A very large export (3.5 years from a busy site, a 215 MB zip) added roughly 330 MB to a SQLite database, while small sites add very little.

Step 1: Export from Plausible

In Plausible, open the site and go to Settings → Imports & exports. Under Export data, click Prepare download. For a site with a lot of history this can take up to about 20 minutes, and you can leave the page and come back. When it is ready, download the .zip. Plausible keeps it for seven days.

Step 2: Import into Tidemark Analytics

1. In Tidemark Analytics, open the site’s Site settings → Data and find Import from Plausible.
2. Click Choose the .zip file and pick the download.
3. Keep the tab open until it says the import has finished. A 200 MB export takes a few minutes.

You do not have to worry about upload limits. Your browser reads the zip and sends only the numbers Tidemark Analytics needs, in small batches, so the file is never uploaded as a whole.

What comes across

• Daily totals: visitors, visits, pageviews, bounce rate and visit duration.
• Sources: channels, sources, referrers and UTM campaign fields.
• Pages: top pages, entry pages and exit pages.
• Locations: countries and regions.
• Devices: device types, browsers and operating systems.
• Custom events: counted for goals that use the same event name, so create a goal with the event’s name to see them.

What does not

• Cities, because Plausible exports them as numeric ids.
• Custom properties, scroll depth and time on page.
• Goal definitions, funnels and shared links, which you set up again in Tidemark Analytics.
• Browser and operating-system versions. Tidemark Analytics reports each as a whole.

How imported data behaves

Imported numbers are daily totals, so they behave a little differently from data Tidemark Analytics collected itself:

• They appear in the top stats, the graph and the reports for periods made of whole days.
• They do not appear in hourly views such as Today.
• They are left out while a filter is active, because the export does not say how the numbers relate to each other. A note on the dashboard tells you when this happens.
• Visitors are added up day by day, the same way Plausible’s own numbers work across longer periods.

Overlap with Tidemark Analytics’s own data

Tidemark Analytics only imports days before the first day it recorded a visit for the site, so nothing is counted twice. If you ran Tidemark Analytics and Plausible side by side for a while, the days when both ran come from Tidemark Analytics.

Switching the script

The Tidemark Analytics script is Plausible-compatible, so the switch is usually a one-line change: replace the Plausible script address with your Tidemark Analytics one and keep the same data-domain. Run both for a week if you want to compare. If you are comparing the tools more broadly, see Tidemark Analytics vs Plausible.

What you need

• A machine with Docker and Docker Compose.
• A domain or subdomain for the dashboard, for example stats.example.com.
• A reverse proxy that handles HTTPS. Caddy, Traefik, nginx, Nginx Proxy Manager or a Cloudflare Tunnel all work.

The compose file

Save this as docker-compose.yml:

services:
  tidemark:
    image: ghcr.io/tidemark-apps/analytics:latest
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - tidemark-data:/data
    environment:
      APP_URL: https://stats.example.com

volumes:
  tidemark-data:

APP_URL is the address visitors and you will use. It appears in the tracking snippet and in links, so set it to your real domain.

Start it

docker compose up -d

Then open http://localhost:8080/install (or the server’s address) to create your admin account. Add your site, copy the tracking snippet into your site’s <head>, and the dashboard fills in as pageviews arrive.

HTTPS with a reverse proxy

The container speaks plain HTTP on port 8080, so put it behind the proxy you already use and forward your domain to that port. A minimal Caddy example:

stats.example.com {
  reverse_proxy tidemark:8080
}

Tidemark Analytics trusts the proxy’s forwarded headers, so it sees the visitor’s real address for counting and builds HTTPS links.

Visitor countries come from a CDN’s headers, such as Cloudflare’s. Without one, the dashboard shows visits but not where they came from.

Where your data lives

Everything that changes lives in the /data volume: the settings file, the SQLite database, logs and uploads. The container can be deleted and recreated at any time without losing anything. Back up that volume and you have backed up Tidemark Analytics.

Updating

The in-app updater is off in the image, because the container is meant to stay read-only. To update, pull a newer image:

docker compose pull && docker compose up -d

Database changes run on the first request after the update. Pin a version tag instead of latest if you prefer to choose when to update.

Using MariaDB or PostgreSQL

SQLite is the default and is fine for most sites. For a larger site, add a database container, then choose MySQL/MariaDB or PostgreSQL in the installer and enter the container’s host, database, user and password. The docs include a ready-made MariaDB compose file.

Running as a different user

Set PUID and PGID on the container to run as another user and group. Unraid, for example, uses 99 and 100. There is also a Community Apps template for Unraid users.

Why Docker (and why not)

Docker is a good fit when you already run containers and want updates to be a single command. If you only have shared hosting, you do not need Docker at all. Tidemark Analytics also installs as a PHP zip, and the software is the same either way.

The short version

• Pick Plausible if you want a mature, hosted product from a dedicated team with a long track record.
• Pick Tidemark Analytics if you want to run analytics yourself on ordinary PHP hosting or a small Docker container.

What they have in common

• No cookies and no personal data stored, so there is usually no consent banner to build for analytics alone (see do you need a cookie banner, which is not legal advice).
• One page with the numbers that matter: visitors, pageviews, bounce rate, visit duration, sources, pages, countries, devices and goals.
• A small tracking script and an Events API for custom events and goals.
• Open source.

Where they differ

Check Plausible’s current pricing and feature list before deciding, because the table is a snapshot.

Self-hosting is the biggest difference

Plausible’s self-hosted edition is designed for a server you control, and it relies on ClickHouse, which is excellent for large volumes but heavier to run. Tidemark Analytics makes the opposite trade-off. It stores events in a regular database, runs on the PHP hosting many sites already pay for, and ships as a Docker image if you prefer containers. The cost of that simplicity is scale: Tidemark Analytics is built for the traffic of typical sites and small businesses, not for tens of millions of events a month on one box.

Features Tidemark Analytics does not have yet

We would rather say it plainly. Tidemark Analytics has goal funnels, revenue reporting, segments and journeys, but Plausible goes further in places we do not match yet. From what its public demo shows, that includes browser and operating-system version breakdowns. Neither tool does session replay. If those extras matter to how you work, Plausible (or a product analytics tool such as PostHog) is the better fit right now, and it is worth checking Plausible’s own feature list for the current picture.

Moving between them

If you already use Plausible, you do not have to start from zero. Tidemark Analytics can import Plausible’s CSV export, and because the script is compatible you can usually switch by changing the script address and keeping your goals. Here is how the import works.

Which one should you choose?

Choose by who you want to look after the server. If you want someone else to run it and need the extra reporting, a hosted Plausible plan is a safe choice. If you would rather own your data on hosting you already have, try Tidemark Analytics. You can run both side by side for a couple of weeks and compare, which is the best test either way.

This guide lists ten alternatives, what each is good at, and who should pick it. They are in no particular order, and we put ourselves last. Features and prices change often, so treat this as a map and check each tool’s own site before you decide. We last reviewed it in October 2026.

What to look for

Before the list, five questions that separate these tools more than any feature table does:

• How does it count visitors? Some tools use cookies and long-lived identifiers. Others use a short-lived hash that changes every day, which means no cookie and no profile of a person across days.
• Where does the data live? On the vendor’s servers, on your own server, or both?
• How deep do you need to go? A single dashboard of traffic, or funnels, session replay, experiments and feature flags?
• Can you leave? Can you export your data, and is the software open source?
• What does it cost at your traffic? Many tools price by pageviews or events, so a spike matters.

Quick picks

1. Plausible

Plausible is the tool most people mean when they say “privacy-friendly analytics”. It has a single-page dashboard, a tiny script and no cookies. It is available as a paid hosted service priced by monthly pageviews, and as an open-source Community Edition (AGPL) you can host yourself. Self-hosting means running a ClickHouse and a Postgres database, usually with Docker, so it suits people comfortable with containers.

Good for: a mature, simple, hosted dashboard. Watch for: the self-hosted edition is not identical to the hosted one, and pricing grows with traffic.

2. Fathom

Fathom is a hosted, paid, privacy-first service with a clean dashboard and a focus on simplicity. As far as we know it is hosted only, so there is no self-hosting option.

Good for: people who want a polished hosted tool and no servers to think about. Watch for: no self-hosting or open-source edition.

3. Simple Analytics

Simple Analytics is another hosted, paid, privacy-focused service with an easy dashboard and readable reports. Like Fathom, it is a hosted product rather than something you run yourself.

Good for: teams who want plain reports without setup. Watch for: hosted only, so your data lives with the vendor.

4. Umami

Umami is open source (MIT) and can be self-hosted or used as a hosted service, which includes a free tier for small sites. It is cookieless, popular with developers, and has events and more detailed reports than the simplest tools.

Good for: developers who want open source with a hosted option. Watch for: self-hosting needs Node.js and a database, so it is a step up from a shared host.

5. Matomo

Matomo is the most complete open-source answer to Google Analytics. It can be self-hosted on a typical PHP and MySQL host or used as a paid hosted service, and it covers funnels, goals, ecommerce, and heatmaps and session recordings through its own features and plugins. It can be configured to run without cookies, but it ships with more options on by default than the minimalist tools, so how privacy-friendly it is depends on how you set it up.

Good for: teams that need depth and want to own their data. Watch for: more to configure, and a bigger interface to learn.

6. GoatCounter

GoatCounter is a small, open-source, cookieless analytics tool. It is free to use as a hosted service for non-commercial sites and can be self-hosted as a single program. It is deliberately minimal.

Good for: personal sites, blogs and small projects. Watch for: a basic feature set, and the free hosted plan is for non-commercial use.

7. Pirsch

Pirsch is a cookie-free, privacy-focused analytics service, hosted and paid. It sits in the same space as Plausible and Fathom, with a simple dashboard and an API.

Good for: a hosted alternative if the better-known options do not fit. Watch for: check the current pricing and hosting details on their site.

8. Cloudflare Web Analytics

If your site already runs through Cloudflare, Cloudflare Web Analytics is free, cookieless and takes almost no setup, because it can measure traffic at the edge without a script. It is proprietary and cannot be self-hosted, and it is far more basic than the tools above: you get the headline numbers, not custom events or goals.

Good for: a free baseline if you are on Cloudflare. Watch for: limited depth, and it only exists inside Cloudflare.

9. PostHog

PostHog is a product analytics platform, not just web analytics. It offers funnels, retention, session replay, feature flags and experiments, and it is open source with both cloud and self-hosted options. That depth comes with weight: it collects more by default, and self-hosting it is a bigger job.

Good for: product teams who need to understand what users do inside an app. Watch for: overkill if you only want traffic numbers.

10. Tidemark Analytics

Tidemark Analytics is ours. It counts visitors without cookies or stored IP addresses, using a hash that changes every day, and shows everything on one page: visitors, pageviews, bounce rate, visit duration, sources, pages, locations, devices, goals and custom events. You run it yourself, as a self-hosted install on ordinary PHP shared hosting or in Docker, under the MIT license. The tracking script and events API follow Plausible’s conventions, and it can import a Plausible export.

Good for: a calm one-page dashboard you can host anywhere, including cheap shared hosting. Watch for: it is young, and it does not have session replay, retention or imports from tools other than Plausible. If you need those, Matomo or PostHog are the better fit, and we say so on our compare page.

How to choose

A short way through the list:

1. Want zero maintenance? Pick a hosted tool: Plausible, Fathom, Simple Analytics, Pirsch or Umami Cloud.
2. Want to own the server and the data? Pick open source: Matomo, Umami, GoatCounter, Plausible Community Edition or Tidemark Analytics.
3. Only have shared hosting? Matomo and Tidemark Analytics are built for PHP hosts.
4. Need replay, retention or experiments? Matomo or PostHog.
5. Just need a free baseline? Cloudflare Web Analytics if you use Cloudflare, otherwise GoatCounter or a free tier.

Whichever you choose, run it next to Google Analytics for a few weeks before you switch off the old tag, so you can compare the numbers and recreate your goals. Our guide to switching from Google Analytics walks through it.

This is a general overview to help you ask better questions. It is not legal advice, the rules differ by country and change over time, and a banner is often driven by other things on your site besides analytics. If the stakes matter, ask a qualified adviser.

Why analytics usually triggers a banner

Two sets of rules matter in Europe and the UK:

• The ePrivacy rules (the “cookie law”) require consent before storing or reading information on a visitor’s device, such as a cookie, unless it is strictly necessary to provide the service they asked for.
• Data protection law (the GDPR and the UK GDPR) governs personal data: identifiers like cookie IDs and IP addresses count, and processing them needs a legal basis.

A tool that sets a long-lived cookie, builds a profile of a person across visits, or shares the data with the vendor for its own purposes is hard to justify without consent. That is the case for many default analytics setups, which is why the banner appeared.

Can analytics ever be exempt?

Some regulators have said yes, under conditions. France’s data protection authority, the CNIL, publishes guidance on analytics saying that audience measurement can be exempt from consent if, among other conditions:

• visitors are informed and can object,
• the data is used only to produce anonymous statistics for the site itself, and is not combined with other processing,
• the tracker is limited to a single site or app,
• identifiers have a limited lifetime and the data is not kept longer than needed, and
• the vendor does not reuse the data for its own purposes.

The older EU working-party guidance reached a similar position for strictly first-party, aggregated statistics. Other countries have their own views, some stricter, and the EU’s rules are under review, so a tool that is fine in one country is not automatically fine in another.

What makes a tool “banner-friendly”

Regardless of the exact rules, these design choices make exemption easier to argue and the privacy risk lower:

• No cookies and no local storage on the visitor’s device for analytics.
• No persistent identifier. A visitor id that is a hash which changes every day cannot be followed from one day to the next, so there is no profile to build.
• No raw IP addresses or user agents stored. They can be used briefly to compute the hash and then discarded.
• Data stays with you, not sent to a vendor that can use it for advertising or its own purposes.
• Aggregate reporting only. You see counts, not individual people.

Tidemark Analytics is built this way: it sets no cookies, uses no local storage for visitors, stores no IP addresses, and uses a daily-rotating salted hash for the visitor id. We still do not tell you that you do not need a banner, because that depends on your jurisdiction and everything else your site does. We tell you what the tool does so you or your adviser can decide.

The banner often has other causes

Removing analytics from the consent banner rarely removes the banner itself. Check what else sets or reads data on a visitor’s device:

• advertising and remarketing tags,
• embedded video, maps and social widgets,
• chat widgets and A/B testing tools,
• fonts or scripts loaded from third parties that receive the visitor’s IP address.

If you keep any of those, you probably still need a banner for them, even if analytics no longer asks for consent.

A practical way to decide

1. List everything that runs on your pages that stores or reads something on a visitor’s device, or sends data to a third party.
2. Check how your analytics tool counts visitors: cookies? local storage? raw IPs? a persistent id?
3. Read your regulator’s guidance for the countries where your visitors are, or ask an adviser.
4. Be transparent either way. Say what you measure in your privacy notice, even if you do not need consent.
5. Revisit it when you add or remove a tool, or when the rules change.

What we promise and what we do not

We make no promise that using any tool, including ours, makes you “compliant”. We do promise a short, checkable description of what Tidemark Analytics does and does not collect: see how privacy works. If you are moving off Google Analytics, our switching guide includes a step for updating your banner and privacy policy.

This guide compares six self-hosted options by what they need to run, how they upgrade, and who they suit. We build one of them, so we put ourselves in the list and try to be straight about the trade-offs. Details change between releases, so check each project’s documentation before you commit.

What to compare

• Runtime requirements. PHP hosting, Docker, Node.js, or a single compiled program.
• Database. SQLite (nothing to run), MySQL or MariaDB (common on shared hosts), PostgreSQL, or heavier analytical databases.
• Upgrades. One click, a command, or pulling a new container image.
• Footprint. How much memory and disk it needs as traffic grows.
• Privacy defaults. Whether it uses cookies and what it stores about visitors out of the box.

At a glance

Matomo

Matomo is the long-standing open-source alternative to Google Analytics. It runs on an ordinary PHP and MySQL or MariaDB host, which is why it has been the default choice for shared hosting for years. It is the deepest tool here: goals, funnels, ecommerce and optional heatmaps and session recordings. The cost of that depth is a large interface and plenty of settings, and its privacy posture depends on how you configure it.

Choose it if you need broad features and want to stay on PHP hosting. Skip it if you want a single quiet dashboard.

Plausible Community Edition

Plausible publishes an open-source (AGPL) Community Edition that you can self-host with Docker. It keeps the same one-page, cookieless approach as the hosted service. It stores events in ClickHouse alongside PostgreSQL, so you need a server with enough memory and comfort running containers, and the self-hosted edition can lag behind the hosted one on features.

Choose it if you have a VPS and like Docker. Skip it if you only have shared hosting.

Umami

Umami is open source (MIT), cookieless and aimed at developers. You run it as a Node.js application against a SQL database, commonly in Docker. It offers events and a friendly dashboard, and there is a hosted version if you would rather not run it.

Choose it if you are comfortable with Node and containers. Skip it if your host only supports PHP.

GoatCounter

GoatCounter is a small open-source analytics program that ships as a single binary and stores data in SQLite or PostgreSQL. It is minimal on purpose: simple counts, no cookies, very light on resources.

Choose it if you want something tiny on a VPS you control. Skip it if you want goals, filtering depth or a PHP install.

PostHog

PostHog is a product analytics platform with funnels, retention, session replay, feature flags and experiments. It can be self-hosted, but it is a multi-service deployment and its scale is meant for products, not brochure sites. It also collects far more than a traffic counter does.

Choose it if you are building an app and need product analytics. Skip it if you just want to know how many people read your blog.

Tidemark Analytics

Tidemark Analytics is ours. It is built to run where other tools cannot: on ordinary PHP shared hosting with nothing but a file upload, or in a single Docker container for servers and home labs. You upload a zip, open /install, choose SQLite, MySQL, MariaDB or PostgreSQL, and create an account. It needs PHP 8.3 or newer, no Node, no Docker and no SSH on shared hosting. Updates are one click in the dashboard, or a newer image in Docker. It uses no cookies and stores no IP addresses, and it is MIT licensed.

Choose it if you want a calm one-page dashboard on cheap hosting. Skip it if you need session replay, retention or experiments: it does not have them, and Matomo or PostHog do. It does have goal funnels and revenue reporting.

How to choose

1. Only have shared hosting? Matomo or Tidemark Analytics. They are the two built for PHP.
2. Have a VPS and like Docker? Plausible Community Edition, Umami or Tidemark Analytics all work.
3. Want the smallest possible footprint? GoatCounter or Tidemark Analytics with SQLite.
4. Need deep reporting? Matomo, or PostHog for product analytics.
5. Not sure you want to run it yourself? Most of these have hosted versions you can try first. Moving between hosted and self-hosted is usually an export and an import, so the choice is not permanent.

Whatever you pick, plan for backups and updates from day one. Self-hosting trades a monthly bill for a small, regular amount of attention, and the tool that needs the least of it is usually the one you will still be running in two years.

The problem cookies solve

A cookie lets a site tell that two requests came from the same browser. Analytics tools used that to separate “100 visits from 80 people” from “100 visits from 1 person”, and to recognize returning visitors across days and weeks. The same ability is what makes cookies a privacy concern, because a stable identifier can be combined with other data to build a profile.

Counting without a stored identifier

A cookieless tool needs a way to say “this request and that request are probably the same visitor today” without leaving anything on the visitor’s device. The usual approach is a hash:

1. A visitor loads a page. A small script sends the page address, the referrer and the screen width to the analytics server.
2. The server already sees the visitor’s IP address and browser string (user agent) as part of any web request.
3. It combines the site, the IP address and the user agent with a secret value called a salt, and runs them through a one-way hash function. The result is a short string, the visitor id.
4. It stores the visitor id with the page view, and throws away the IP address and user agent.

Two requests from the same browser on the same day produce the same hash, so they count as one visitor. Nothing was written to the visitor’s device, and the stored id cannot be turned back into an IP address.

Why the salt changes every day

If the salt were fixed, the same person would get the same id every day, and you would have rebuilt a persistent identifier with extra steps. So the salt is combined with the date and rotates daily. Tomorrow the same person produces a completely different id.

That is the privacy property: the tool can say how many people visited today, but it cannot say that today’s visitor 4F2A is the same person as last Tuesday’s visitor 9C71. In Tidemark Analytics, the visitor id is an HMAC of the site, IP address and user agent, keyed by a salt that includes the current date, and the raw IP address and user agent never reach the database.

How visits are stitched together

Within a day, the tool also groups page views into visits. Tidemark Analytics ends a visit after 30 minutes of inactivity, which is a common convention. A visit that has only one page view or event counts as a bounce, and the visit duration is the time between its first and last event. Because the id is the same all day, “unique visitors” for a week is the number of distinct daily ids, which counts someone who came on three days as three visitors.

What you give up

Be clear about the trade-offs before you rely on the numbers:

• No returning-visitor tracking across days. You cannot measure loyalty, cohorts or “users who came back next week”.
• Shared networks can merge people. Two visitors behind the same IP address with the same browser look identical for that day. For most sites this is a small effect.
• One person on two devices counts twice, and a visitor whose IP address changes mid-day (moving from Wi-Fi to mobile data) can count twice.
• Multi-day visitor counts add up daily visitors, so they run a bit higher than a count of distinct people.
• No user-level journeys. You see which pages are popular and where traffic comes from, not the path of an individual.

For content sites, documentation, marketing pages and most small businesses, these limits cost very little, because the questions you ask are about volume and sources, not individuals. For products where you need to follow users through a funnel over weeks, you need a different kind of tool.

What gets stored

For each page view a cookieless tool like Tidemark Analytics keeps aggregate-friendly fields: the page, the referrer and its source category, the country (and region or city when your CDN provides them), the browser, the operating system, the device type and the day-rotating id. It does not store the IP address, the raw user agent, or anything it could use to recognise a person later. You can read the exact list on our privacy by design page.

Does “cookieless” mean “consent-free”?

Not automatically. Whether you need a consent banner depends on the rules in your country and on everything else your site does. We cover that in Do you need a cookie banner for analytics?. What cookieless counting does is make the analytics part easy to describe and low risk.

Want to see it?

Read how the metrics are defined.

This guide walks through a typical setup with Tidemark Analytics, which is designed for PHP shared hosting, but the checklist applies to any PHP-based analytics tool.

What you need

• PHP 8.3 or newer on the hosting account. Most hosts let you pick the PHP version in the control panel.
• A few common PHP extensions: mbstring, openssl, PDO with one database driver, fileinfo, ctype, tokenizer and XML. These are enabled by default almost everywhere.
• A place for the database. SQLite needs nothing at all (it is a file). Otherwise a MySQL, MariaDB or PostgreSQL database from your host works too.
• A domain or subdomain for the dashboard, for example stats.yourdomain.com.
• HTTPS, which most hosts provide for free with Let’s Encrypt.

You do not need SSH, Node.js, Docker or Composer.

Step 1: Create a subdomain

In your hosting control panel, add a subdomain such as stats.yourdomain.com and note its document root folder. If your host lets you, point the document root at the public folder of the app after you upload it. If it does not, the release includes a root .htaccess that forwards requests to public/ and blocks the internal folders, so uploading to the web root as-is still works.

Step 2: Upload the release

Download the latest tidemark-x.y.z.zip from the releases page (dependencies are already bundled), upload it with the file manager or FTP, and unzip it in the subdomain’s folder.

Step 3: Run the installer

Open https://stats.yourdomain.com/install. The installer checks your server, connects a database (choose SQLite if you want zero setup), runs the migrations and creates your admin account. When it finishes you are signed in.

Step 4: Add your site and paste the snippet

Add the domain you want to measure and copy the snippet into the <head> of every page:

<script defer data-domain="yourdomain.com"
  src="https://stats.yourdomain.com/js/script.js"></script>

The dashboard waits for the first page view and then opens by itself. If you use a CDN or proxy, real visitor addresses and countries are read from its headers.

Step 5: Add the cron job (optional)

Two features need a scheduled task: buffering events through a queue, and automatic deletion of old data. In your host’s cron settings add one entry that runs every minute:

* * * * * php /home/you/stats/artisan schedule:run >> /dev/null 2>&1

If you do not use those features, you can skip it. The cron guide has the details.

Step 6: Set up email (optional)

Password resets and invitations need working outgoing mail. Add your host’s SMTP settings as described in the email guide. Without it the app still works, it just cannot send emails.

Updating

Administrators can update from Account settings, which downloads the release, makes a backup of the current files, applies it and runs the database migrations the first time you open the dashboard afterwards. If your host blocks the updater from writing files, upload the new release over FTP instead. See the updating guide.

Backups

With SQLite, your whole database is one file, so backing up is a copy. Back up the .env file as well, because it holds the app key. With MySQL, MariaDB or PostgreSQL, use your host’s backup tool or a database dump. The backups guide lists exactly what to keep.

A few tips for shared hosting

• Pick SQLite for small sites. It is usually fast enough for small and medium sites and removes a moving part. Move to MySQL or MariaDB if traffic grows a lot.
• Keep PHP updated. Choose a supported PHP version in your control panel.
• Use a subdomain, not the main site’s folder, so analytics files never mix with your site.
• Check the file permissions if the installer says storage is not writable. The storage and bootstrap/cache folders must be writable by PHP.

If you would rather not run it

Self-hosting is one option, not the only one. The self-hosted tools guide compares the alternatives if you want to look at other options first.

1. Audit what you really use

Open Google Analytics and write down the reports and numbers you looked at in the last three months. For most small sites that is a short list: visitors, top pages, where traffic comes from, countries and devices. Also note anything configured on top:

• Conversions or key events you track (signups, purchases, downloads).
• Audiences or remarketing that feed ads. Privacy-friendly tools do not do this, so if you depend on it, plan for that separately.
• Integrations with Search Console, Google Ads or a dashboard tool.
• Who else looks at the reports, so they are not surprised.

If your list is “traffic, sources, pages, a couple of goals”, almost any alternative will do. If it includes funnels and audiences, read our comparison of alternatives first, because the lightest tools will not cover that.

2. Save the history you need

Most alternatives cannot import Google Analytics data, and Google keeps detailed event-level data for a limited time (up to 14 months, depending on your property’s retention setting). Before you switch, export what you will want later:

• The yearly and monthly totals you quote (visitors, pageviews, top pages and sources).
• Any report you build reports from, saved as CSV or PDF.
• If you use BigQuery, the raw export tables.

Keep these somewhere you will find them. A year-over-year comparison later is far easier with a spreadsheet of last year’s numbers than with nothing.

3. Pick the tool

Decide between hosted and self-hosted, and how much depth you need. Hosted tools (Plausible, Fathom, Simple Analytics and others) need no server. Self-hosted tools (Matomo, Umami, Plausible Community Edition, Tidemark Analytics) keep the data on your own hosting. The alternatives guide and the self-hosting guide will narrow it down.

4. Install it next to Google Analytics

Do not remove Google Analytics yet. Add the new tool’s script to the same pages. With Tidemark Analytics, for example, it is one line in your <head>:

<script defer data-domain="yourdomain.com"
  src="https://analytics.example.com/js/script.js"></script>

Run both for at least two to four weeks, long enough to cover a full cycle of your traffic. The numbers will not match exactly, and that is normal: tools define visitors, sessions and bounce rate differently, filter bots differently, and are affected differently by ad blockers. Compare trends over time, not exact totals.

5. Recreate your goals and events

List the conversions you tracked and recreate them. In most privacy-friendly tools a goal is either a page visit (for example /thank-you) or a custom event you send from your code. Tools that follow Plausible’s conventions, including Tidemark Analytics, share the same pattern:

window.plausible('Signup')

Add the matching goal in the new tool’s settings. Outbound link clicks, file downloads and form submissions can usually be turned on with a script option instead of code. See our guide to tracking links and downloads without cookies.

6. Bring over history where you can

If you are moving between privacy-friendly tools, imports are often possible. Tidemark Analytics can import a Plausible export, for example. Google Analytics history cannot generally be imported, which is why step 2 matters.

7. Check your cookie banner and privacy policy

Once Google Analytics is gone, your site may no longer need the analytics part of its consent banner, but that depends on what else you run (ads, embedded video, chat widgets) and on the rules where you operate. Read our note on cookie banners, then update your privacy policy to describe what you use now. Ask a qualified adviser if you are unsure.

8. Remove the Google Analytics tag

When the new numbers look right and your goals are firing:

1. Remove the Google Analytics script or tag manager tag from your pages.
2. Remove it from any plugin or theme setting that also adds it.
3. Disconnect it from Search Console and Google Ads if you linked them.
4. Keep the Google Analytics property for a while without collecting, so you can still open the old reports.

9. Tell the people who read the reports

Send teammates a short note: where the dashboard is, which numbers will look different, and that history before the switch lives in the exports you saved. Set a calendar reminder for a month out to review whether the new tool answers the questions you actually ask.

A quick checklist

• Listed the reports and goals you use
• Exported the history you will want later
• Chosen hosted or self-hosted
• Installed the new script alongside Google Analytics
• Compared trends for two to four weeks
• Recreated goals and events
• Updated the cookie banner and privacy policy
• Removed the Google Analytics tag

Most people finish in a weekend and spend the following month mostly checking that nothing is missing.

This guide shows the three ways to do it, using Tidemark Analytics’s script as the example. The same pattern works with Plausible and other tools that follow its conventions.

Option 1: Turn on the built-in extras

The simplest route is to ask the script to watch for common actions automatically. The tracking script comes in variants selected by its file name:

• script.outbound-links.js counts clicks on links that leave your site.
• script.file-downloads.js counts clicks on links to files such as PDFs, archives and installers.
• script.form-submissions.js counts submitted forms.

You can combine them in one file name:

<script defer data-domain="yourdomain.com"
  src="https://analytics.example.com/js/script.outbound-links.file-downloads.form-submissions.js"></script>

In Tidemark Analytics you do not have to edit the file name by hand: in a site’s settings, under the tracking extras, switch on outbound link clicks, file downloads and form submissions, and the snippet it shows you updates. Each one also creates a matching goal so the events show up in your dashboard.

Outbound clicks appear as an event named Outbound Link: Click, with the destination address stored with it, so you can see which links people actually follow. Downloads appear as File Download (with the file’s address) and form submissions as Form: Submission (with the page the form was on).

Option 2: Send a custom event from your code

For anything specific to your product, send an event yourself with one line of JavaScript:

window.plausible('Signup')

Call it where the action happens: after a successful signup, when someone adds an item to a cart, when a calculator is used. You can attach properties so one event can be broken down later:

window.plausible('Download', { props: { file: 'whitepaper.pdf' } })

Properties let you ask questions like “which file gets downloaded most?” without creating a separate event for each.

Option 3: Use a page as a goal

If the action ends on its own page, you do not need code at all. Create a goal for that page, such as /thank-you or /order-complete, and every visit to it counts as a conversion. Page goals support wildcards, so /blog/* covers every post.

Create the goal

Events show up in the dashboard’s goals section once a goal with the same name exists. In Tidemark Analytics, open the site’s settings, choose Goals, and add either a custom event (type the exact event name, such as Signup) or a page goal (type the path).

Read the results

Open the Goals report to see unique conversions, total conversions and the conversion rate. Click a goal to switch the whole dashboard into conversion mode: every report then shows which sources, pages, countries and devices produced the conversions, so you can see not just that people signed up but where they came from.

Do these need cookies?

No. The events use the same cookieless, daily-rotating visitor id as page views, so a “unique conversion” means one visitor completing the action in the period. Nothing is stored on the visitor’s device. If you care about what is collected, read our notes on how cookieless analytics works.

Tips

• Name events consistently. Signup and signup are different events.
• Keep the list short. Track the handful of actions you will actually look at.
• Test it. Open your site, perform the action, and watch the realtime view or the goal count to confirm it fires once.
• Single-page apps are covered automatically, because the script records a page view on every route change.

The tracking docs go into more detail on custom events, and the script variants guide lists every option.

Different tools define these slightly differently, so never compare an exact number between two tools. Compare each tool with itself over time.

Unique visitors

What it is: the number of distinct people who came to your site in the period you are looking at.

How it is counted: tools use an identifier to tell visitors apart. Cookie-based tools use a cookie. Cookieless tools like Tidemark Analytics use a hash of the visitor’s IP address and browser details that changes every day, so a visitor is “one browser, one day”. Over a longer period the daily counts are added up, which means someone who visited on three different days counts three times in a 28-day view.

Good for: the size of your audience and its trend. Watch for: two people sharing a network and browser can look like one, and one person on two devices counts twice.

Total visits (sessions)

What it is: the number of separate trips to your site. One visitor can make several visits.

How it is counted: page views are grouped into a visit. A common rule, used by Tidemark Analytics, is that a visit ends after 30 minutes of inactivity, so a return after lunch starts a new visit.

Good for: how often people come, compared with how many people there are. If visits are much higher than visitors, people are coming back.

Total pageviews

What it is: how many times pages were loaded.

How it is counted: every page load counts once, including repeat views of the same page. Single-page apps count a view when the route changes, which Tidemark Analytics’s script does automatically.

Good for: overall activity and which content is popular. Watch for: refreshes inflate it, and it says nothing about attention.

Views per visit

What it is: pageviews divided by visits: the average number of pages someone looks at in a visit.

Good for: whether people explore or leave after one page. A guide site wants it higher than a landing page does.

Bounce rate

What it is: the share of visits that ended after a single page view or event.

How it is counted: visits with one page view and nothing else, divided by all visits. In Tidemark Analytics, a visit with a single event is a bounce.

What it does not mean: a bounce is not a failure. Someone who finds a recipe, reads it and leaves has bounced and was perfectly served. It is most useful when you compare pages with the same purpose, or watch one page over time. Watch for: it differs between tools, because some count short engaged visits as non-bounces.

Visit duration

What it is: how long a visit lasted on average.

How it is counted: the time between the first and the last event in a visit. A visit with a single page view has a duration of zero, because there is no second event to measure against, which is why average duration looks shorter than you might expect on content-heavy sites with many one-page visits.

Good for: a rough sense of engagement, best read together with bounce rate.

Traffic sources and channels

What it is: where visitors came from. A source is a specific site or campaign (Google, Reddit, a newsletter). A channel is a group of sources (Organic Search, Social, Email, Referral, Direct).

How it is counted: from the page that sent the visitor (the referrer) and any campaign tags (UTM parameters) on the link. Visits with neither are “Direct”, which includes typed addresses, bookmarks and links from apps that do not send a referrer.

Good for: knowing which channels are worth your time. Watch for: “Direct” is a catch-all, so tag your own links with UTM parameters if you want them classified.

Goals and conversions

What it is: a count of visitors doing something you care about: signing up, downloading, buying, submitting a form.

How it is counted: a goal is either a visit to a particular page (for example a thank-you page) or a custom event your site sends. The conversion rate is the visitors who completed the goal divided by all visitors. See how to track links and downloads.

Which numbers to trust

• Trust trends over exact values. Whether this month beats last month matters more than the absolute count.
• Read metrics in pairs. Bounce rate with duration, visits with visitors, pageviews with views per visit.
• Segment before you conclude. A site-wide bounce rate hides that your blog and your pricing page behave very differently.
• Remember what is not measured. Visitors who block scripts, and traffic that never loads your page, do not appear in any script-based tool.

Seeing them together

The point of a one-page dashboard is that you can read these numbers side by side without hunting through reports. In Tidemark Analytics you can click a metric to see it on the graph, and click any row to filter the whole page by it.