Open Web Analytics

Open Web Analytics (OWA) is a self-hosted web analytics platform built as a fully open source alternative to commercial services like Google Analytics. Running entirely on your own infrastructure, it gives you complete ownership and control of the visitor data collected from your websites and applications, with no data ever leaving your servers.

OWA tracks visitors, pageviews, e-commerce transactions, and custom configurable actions across an unlimited number of websites from a single server installation. Beyond standard traffic metrics, it includes first-party JavaScript tracking, visual heatmap generation, and Domstream session recording — all without depending on any third-party analytics services.

Built in PHP and deployable on standard LAMP stacks or Docker, OWA integrates with WordPress via an official plugin and with any PHP application through the OWA PHP SDK. A REST API provides programmatic access to reports and administration, while the extensible module system allows custom functionality to be added without modifying core code.

OWA is designed for privacy-conscious organizations, developers building analytics into their own applications, and web agencies that need to run analytics infrastructure for multiple clients from a single installation.

What You Get

• First-party JavaScript tracker - A self-hosted tracking script that collects visitor data using first-party cookies, eliminating dependence on third-party tracking infrastructure.
• Heatmap generation - Click and scroll heatmaps overlaid directly on your web pages so you can visualize where users interact and optimize your layouts.
• Domstream session recordings - Record full user sessions as DOM stream replays and watch exactly how visitors navigate your pages, including clicks, scrolls, and form interactions.
• E-commerce transaction tracking - Track purchases, revenue, cart abandonment, and conversion funnels with built-in commerce event support.
• REST API for data access and administration - Retrieve analytics data, configure sites, and manage users programmatically through a documented RESTful API with token-based authentication.
• Multi-website tracking from one instance - Add unlimited websites to a single OWA server and manage them from a shared admin dashboard with per-site data isolation.
• Geolocation of visitors - Map visitors to countries and regions using the optional MaxMind GeoIP module bundled with the analytics platform.
• Extensible module system - Add custom event types, new reports, and additional tracking capabilities by registering modules without touching the core codebase.

Common Use Cases

• Privacy-compliant publishing - A news organization deploys OWA to track article readership and user engagement without sending any reader data to Google or external analytics providers, satisfying GDPR and data sovereignty requirements.
• Agency analytics infrastructure - A web agency installs one OWA instance to monitor traffic across dozens of client websites, with each client accessing only their own site’s dashboard through the multi-user interface.
• E-commerce without data leakage - An online retailer instruments their checkout flow with OWA’s transaction tracking to measure conversion rates and average order value while keeping all customer purchase data on-premises.
• UX research via session replay - A product team enables Domstream recording to watch how users navigate a new checkout flow, identifying where users hesitate or abandon before completing a form.
• Embedded analytics in SaaS products - A developer uses the OWA PHP SDK to embed behavioral tracking directly into their own PHP application, surfacing feature usage data without building a custom analytics backend.
• Self-hosted alternative for regulated industries - A healthcare company deploys OWA on their own HIPAA-compliant infrastructure to track portal usage metrics without exposing patient-adjacent behavioral data to third-party analytics vendors.

Under The Hood

Architecture Open Web Analytics follows a centralized monolithic pattern built around a singleton owa class that delegates through a deep inheritance chain of caller and base classes. Modules in the modules directory provide nominal separation — each module registers entities, handlers, controllers, and templates — but inter-component communication relies on static singleton accessors scattered throughout the codebase rather than explicit dependency injection. The most architecturally coherent subsystem is the event dispatch pipeline, which uses an observer pattern to route incoming analytics events through registered handlers. Report controllers follow a dispatch pattern based on a report_name parameter, giving the system extensibility without modifying routing. Web, CLI, and REST API entry points each bootstrap the system independently rather than sharing a unified initialization abstraction, resulting in initialization logic spread across multiple files.

Tech Stack The server is written in PHP with Composer managing module-level dependencies through the Wikimedia merge plugin, which aggregates per-module composer.json files into a unified dependency tree. Database access is abstracted through a custom PHP class built on PDO, targeting MySQL as the primary storage engine. The reporting UI and JavaScript tracker rely on jQuery 3.6 and jQuery UI, bundled by Webpack 5 with custom concatenation plugins that stitch together legacy script files into combined minified assets. Geolocation is handled by the optional MaxMind GeoIP module. Server-side templating uses a Smarty-style PHP template system, and the REST API produces JSON responses through the existing view layer rather than a dedicated API framework. Session recording (Domstream) ships as a separately activated module.

Code Quality Automated test coverage is effectively absent — the single test file in the repository contains only a class skeleton with no test assertions or test framework integration. PHP type hints are missing throughout the codebase, and no static analysis tools (PHPStan, Psalm) or code style enforcement (PHP-CS-Fixer, PHPCS) are configured. Error handling routes through a global error singleton rather than typed exceptions, making it difficult to distinguish recoverable errors from fatal ones. The codebase mixes procedural and object-oriented styles, with global singleton accessors functioning as an implicit service locator that obscures dependencies and makes individual components difficult to test or replace in isolation. Inline comments are present but inconsistent across modules.

What Makes It Unique OWA’s most distinctive feature is its built-in Domstream session recording module, which captures DOM state changes during a user’s visit and allows full session replay directly in the analytics dashboard — a capability that predates commercial session recording tools and remains uncommon in open source analytics platforms. The resultSetManager class provides a flexible ad-hoc analytical query engine where callers declare metrics, dimensions, time periods, and constraints as parameters, enabling new report types without pre-defined database queries. The observer-based event dispatch system allows custom analytics events to be registered and processed by the module system without modifying core routing code, making OWA genuinely extensible for embedding in custom PHP applications.

Self-Hosting

Open Web Analytics is licensed under the GNU General Public License version 2 (GPL-2.0). This is a strong copyleft license: you can use, modify, and redistribute OWA freely, including for commercial purposes, but if you distribute modified versions of the software itself, you must release those modifications under the same GPL-2.0 terms. For most self-hosting scenarios — running OWA on your own server to track your own websites — the GPL imposes no restrictions on how you use the analytics data or the insights you derive from it. The copyleft obligation only applies if you distribute the OWA software itself to others.

Self-hosting OWA requires a LAMP-compatible environment: PHP (8.x compatible as of recent releases), MySQL, and a web server such as Apache or Nginx. You are responsible for provisioning and maintaining the server, managing MySQL backups, applying OWA updates manually by pulling new releases from GitHub, and handling uptime and security patching of the underlying OS and PHP runtime. The Domstream session recording module generates additional disk I/O and storage requirements proportional to traffic volume. There is no built-in high-availability or horizontal scaling mechanism — scaling requires manual infrastructure work outside the OWA codebase itself.

There is no hosted or managed cloud version of Open Web Analytics; the project is entirely community-supported with no paid tier, enterprise license, or commercial support offering from the maintainer. Support is limited to the GitHub issue tracker and community forums, and response times depend on volunteer availability. You give up SLA guarantees, managed upgrades, automatic backups, and dedicated support channels that commercial analytics services provide. The project has a small, single-maintainer team, so the pace of bug fixes and new features is slower than commercial alternatives — a meaningful operational consideration when evaluating OWA for production use in larger organizations.