# Open Web Analytics: a GPL-2.0 PHP analytics server you host yourself

> Open Web Analytics is a self-hosted PHP analytics server and JavaScript tracker positioned as an open source alternative to Google Analytics. It is aimed at operators who want the visitor data on their own hardware, and the cookie options in the README show how much of the privacy story is left to the person writing the snippet.

**Open-Web-Analytics/Open-Web-Analytics** — Official repository for Open Web Analytics which is an open source alternative to commercial tools such as Google Analytics. Stay in control of the data you collect about the use of your website or app.  Please consider sponsoring this project.

- Repository: https://github.com/Open-Web-Analytics/Open-Web-Analytics
- Website: http://www.openwebanalytics.com
- Stars: 2,689 · Forks: 488
- Language: PHP
- License: GPL-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-web-analytics-open-web-analytics

## What Open Web Analytics solves, and for whom

Commercial analytics products answer questions about your traffic by keeping the raw data on their infrastructure. Open Web Analytics takes the opposite position: the README describes it as "an open source alternative to commercial web analytics tools such as Google Analytics" and says the point is to "stay in control of the data you collect about the user of your websites or applications." That framing tells you who the project is for. It is for the operator who can provision a PHP host and a database and would rather do that than accept a third party holding the visit log.

The feature list is broader than pageview counting. The README lists visitor and pageview tracking, e-commerce transactions, configurable actions, an unlimited number of websites on a single server instance, a first party JavaScript tracker, a reporting dashboard, customizable reports, heatmaps, "Domstream" session recordings, visitor geolocation, a REST API for administration and data access, a multi-user reporting interface, and an extensible module framework.

The multi-site point matters more than it looks. One OWA Server instance is meant to hold many websites, so a small agency or an internal platform team does not run one analytics install per property. The cost of that convenience is that the server becomes a shared dependency: if it is down, every tracked site loses collection at once.

## How the tracker, the server and the reports fit together

The repository ships two halves in one tree. The server side is PHP, with Core/, modules/, api/, conf/ and the install.php entry point visible at the top level. The client side is a JavaScript tracker built from the front end sources, and the README is explicit that the built public/ asset tree, including the JS tracker, is not tracked in git. So the tracker you deploy is a build artifact, not a file you copy out of the repository as-is.

Data flow is the conventional one for this class of tool. A page loads the first party tracker, the tracker writes cookies and sends events, the PHP server stores them, and the reporting dashboard reads them back. The README mentions queue.php and cli.php at the repository root, which suggests collection and background work are separable from the web request path, though the README does not document the queue's behaviour in detail.

The cookie layer is where the design is most legible, and it is worth reading closely. By default the visitor id cookie (owa_v) lives 364 days, the campaign store (owa_c) lives 60 days, and the session store lives 364 days. Each cookie is rewritten on every page view. That produces a rolling window rather than a fixed one: shortening a lifetime means the visitor's id expires that many days after their last visit, not their first, so a returning visitor is never forgotten. The README also notes that shortening a lifetime does not delete anything already collected. It limits how far back returning-visitor and days-since-first-visit reporting can reach for people who stop visiting. That is a real reporting consequence, and it is stated plainly rather than buried.

## Installing OWA Server and tracking your first pageview

The README does not put installation steps in the repository itself. It points to the technical requirements wiki page and a step by step installation guide, and it says to read the requirements before installing. The install.php file at the repository root is the entry point the guide walks through. Start there rather than guessing at a manual database setup.

If you are working from a clone rather than a release package, the README gives the build commands directly. It notes that vendor/ and the built public/ asset tree, including the JS tracker, are not tracked in git, so this step is not optional after cloning:

```bash
composer install
npm install && npm run build
```

Composer pulls the PHP dependencies and npm installs the JavaScript build toolchain, then npm run build produces the production front end assets. After that, the built public/ tree exists and contains the tracker you will serve.

Once the server is installed and a site is registered in the dashboard, tracking is a snippet on the page. The README's cookie example shows the shape of the command queue, and it is the clearest piece of client-side code in the repository. These lines go before trackPageView, because the queue is drained in push order and trackPageView is what writes the first cookie:

```js
owa_cmds.push(['setOption', 'stateStoreExpirations', {"v": 90, "s": 7}]);
owa_cmds.push(['setOption', 'cookiePersistence', false]);
```

stateStoreExpirations is keyed by store: v for the visitor id, c for the campaign store, s for the session store. Stores you leave out keep their defaults. Values are whole days, one or more, and the README says anything else is ignored rather than guessed at. In the snippet above the visitor id would last 90 days and the session store 7. Setting cookiePersistence to false makes all of them session cookies instead: no expiry date, discarded when the browser closes, and a returning visitor counted as new. It overrides the lifetimes, so setting both means session cookies.

For WordPress sites the README points elsewhere: the OWA integration plugin, or the owa-wordpress-plugin repository. For other PHP applications there is the OWA PHP SDK. Neither is part of this repository.

## The cookie ceiling nobody can raise

Shortening the visitor cookie is the usual reason to touch these options, and the README gives the reason: several consent exemptions for analytics, the Dutch Telecommunicatiewet art. 11.7a(3) among them, turn on the tracking having a small privacy impact, and a year-long identifier is hard to argue as small. That is a fair statement of the problem. The project hands you the dial and leaves the legal judgement to you, which is the right boundary for a GPL-2.0 tool but also means nothing here is compliant by default.

The constraint that surprises people is the browser ceiling. The README states that Chrome caps cookie expiry at 400 days and Safari caps script-written cookies considerably lower. No value you set in stateStoreExpirations can exceed those limits. So a 364-day visitor cookie is already near the practical maximum in Chrome and may be truncated in Safari regardless of what the snippet asks for.

There is a subtler trap in the rolling window. Because each cookie is rewritten on every page view, a visitor who returns regularly keeps their identifier indefinitely, even with a 90-day setting. If your goal is that identifiers age out for everyone, a rolling window does not achieve it; only cookiePersistence: false does, at the cost of counting every returning visitor as new. Choose which of those two properties you actually need before you write the snippet.

The README also notes that cookie_persistence has governed server-set cookies since 2016 but was never read by the tracker until the tracker-side cookiePersistence option was added. If you configured the server setting years ago and assumed it covered the client, it did not.

## Where Open Web Analytics is the wrong tool

The deployment surface is the first limit. This is PHP plus a database plus a Node build step, and the README's development section assumes you have Composer and Node.js available. A team that does not already run PHP infrastructure is signing up to learn one, and the repository does not present a container image or a hosted option. The install path runs through install.php and a wiki guide, not a single command.

Source installs have an extra failure mode. Because vendor/ and the built public/ tree are not tracked in git, a clone that skips composer install and npm run build is incomplete. The README says this outright, but it is the kind of thing that produces a site with no tracker and no obvious error.

Upgrades are the other cost. UPGRADING.md exists specifically because interfaces get deprecated while remaining supported, and the README addresses it to anyone "upgrading, or maintaining a third-party module, local template override, or custom theme." If you have extended the module framework or overridden templates, treat every release as something to read the upgrade notes for, not something to pull blindly. The project has shipped 1.12.0, 1.13.0 and 1.14.0 within roughly a month of each other, so the release cadence is brisk enough that an unread upgrade note can accumulate.

Finally, the README does not document rollback, backup or data retention procedures. It also does not document the queue's operational behaviour, the REST API's surface, or how heatmaps and Domstream recordings are stored and pruned. Session recordings in particular deserve scrutiny before you enable them: the README lists the capability without describing what is captured or how long it is kept. If you need those answers before deploying, the repository is silent and the wiki is where you would have to look.

## Open Web Analytics against Matomo

Matomo is the obvious comparison, and the two differ less in purpose than in packaging. Both are PHP analytics platforms you host yourself, both track visitors and pageviews, and both exist because some operators will not send visit data to a third party. The difference is what you get out of the box.

Matomo is widely deployed as a PHP application with a large plugin ecosystem and a long history of third-party integrations. Open Web Analytics keeps heatmaps and Domstream session recordings inside the core feature list rather than leaving them to plugins, and its module framework is the documented extension point. If you want session replay and heatmaps without assembling them from separate components, that is a genuine reason to look at OWA specifically.

The trade-off runs the other way on ecosystem breadth. Matomo's plugin catalogue and the volume of documentation written about it by people outside the project are larger, which matters when you hit an unusual configuration. With OWA you are more dependent on the project's own wiki, and the README is candid that issue tickets without the necessary debug info are closed automatically, with the troubleshooting guide as the required first stop.

The cookie model is where OWA is arguably more explicit. The README documents per-store expirations, a session-cookie override, and the rolling-window consequence in one place. That is a level of detail about the tracking mechanism that many analytics projects leave to the reader.

## Licence, maintenance and upgrade cost

Open Web Analytics is licensed under the GNU GPL, version 2 or later, as stated in the README and in the LICENCE file at the repository root. The package.json records the license field as GPL-2.0-only. Those two statements are not identical, and the README's "version 2 or later" is the broader of the two. If the distinction matters for how you redistribute or embed the code, read the LICENCE file and, if necessary, take advice; this is a description of what the repository says, not legal advice.

The practical implication of a copyleft licence is that modifications you distribute carry the same licence obligations. Running OWA as a service for your own sites is a different situation from shipping it inside a product, and the two should be thought about separately before you build on the module framework.

Maintenance looks healthy by the only measures available here. The repository is not archived, and the last push was on 2026-09-24. Releases 1.12.0, 1.13.0 and 1.14.0 landed on 2026-08-21, 2026-09-12 and 2026-09-21 respectively. That is a project shipping changes, not one coasting.

Upgrade cost is where that cadence has a price. Three releases in about a month means upgrade notes are worth reading each time, particularly if you have local template overrides or custom themes. UPGRADING.md is the file to check, and it exists precisely because deprecated interfaces are kept working for a while rather than removed cleanly. The README also asks for donations to fund support, which suggests the project does not have a commercial support contract behind it. Budget for reading release notes yourself.

## Conclusion

Open Web Analytics fits teams with a PHP host, a database, and a reason to keep visitor data off someone else's servers, especially if they need heatmaps or session recordings in the same install. It is the wrong pick if nobody on the team wants to run PHP, a database and a build step from source, or if a managed analytics product is acceptable. Before committing, verify the technical requirements page against your PHP and database versions, decide whether the visitor cookie lifetime should be shortened from its 364-day default, and check UPGRADING.md if you already run third-party modules, local template overrides or a custom theme.

## FAQ

### What is Open Web Analytics?

It is an open source web analytics server written in PHP, described in its README as an alternative to commercial tools such as Google Analytics, with the goal of keeping control of the data collected about visitors. It ships a server plus a first party JavaScript tracking client.

### Is Matomo free to use?

The Open Web Analytics README does not state Matomo's licensing or pricing, so that question cannot be answered from this repository. What it does state is that Open Web Analytics itself is licensed under the GNU GPL, version 2 or later.

### What does web analytics do?

In Open Web Analytics the README describes tracking visitors, pageviews, e-commerce transactions and configurable actions, then reporting on them through a dashboard with customizable reports, heatmaps and session recordings. Geolocation of visitors and a REST API for data access are also listed.

### Is Google web analytics free?

The repository does not describe Google Analytics pricing or terms. It only positions Open Web Analytics as an open source alternative to commercial tools such as Google Analytics, licensed under the GNU GPL, version 2 or later.

## Sources

- [License: GPL-2.0](https://github.com/Open-Web-Analytics/Open-Web-Analytics/blob/master/LICENSE)
- [Open-Web-Analytics/Open-Web-Analytics on GitHub](https://github.com/Open-Web-Analytics/Open-Web-Analytics)
- [Project website](http://www.openwebanalytics.com)
- [README](https://github.com/Open-Web-Analytics/Open-Web-Analytics/blob/master/README.md)
- [Releases](https://github.com/Open-Web-Analytics/Open-Web-Analytics/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-web-analytics-open-web-analytics