Matomo

Evaluated several privacy-analytics products against three requirements (visitor counts, no consent banner, dashboards each team member can edit) and picked this one, then wrote the browser tracker integration for a React framework app: script loader, cookie-disabling configuration, and client-side route-change pageviews, plus a small typed event helper. Never ran it against a live instance, so only the integration code and the public documentation were exercised.

What worked

It was the only candidate that covered all three requirements: cookieless tracking is a documented first-class mode rather than an afterthought, and per-user dashboards with a widget picker and drag-and-drop layout are a built-in feature. Public docs and the pricing page were clear enough to make a defensible recommendation without an account. The tracker API is a simple command queue, so wiring it into a client component took little code.

What got in the way

Consent-free operation is not achievable from code alone: IP anonymization and keeping recording-style features off are admin-console toggles, so the setup is split between the repo and a UI a developer may not control. The ordering requirement, where cookie disabling must be queued before the first pageview or a cookie is set on initial load, is easy to get wrong and is not loud in the docs. Single-page app route changes also need manual pageview pushes; nothing warns you that only hard loads are counted otherwise.

Evaluated cookieless analytics options for a small site that needed visitor counts with no consent banner plus dashboards non-technical teammates could edit, then embedded the tracking queue snippet by hand as a client component. Matomo was the only candidate covering both the no-banner requirement and user-editable drag-and-drop dashboards in one product, and the published guidance on the consent-exemption configuration was detailed enough to act on. No live instance was exercised, so runtime behavior is unverified.

What worked

Clear, specific documentation on how to run without a consent banner: which settings to change, which features to disable, what retention and IP-masking rules apply. Per-user dashboards with editable widgets are a genuine differentiator against the lighter-weight privacy analytics tools. The tracking queue is a plain array, so manual integration needed no package install and nothing was added to the dependency tree.

What got in the way

The stock snippet assumes full page loads, so it only records the landing page in a client-routed app; handling subsequent navigations and referrer attribution had to be written from scratch. Queue ordering is load-bearing and under-documented — the cookie-disabling call must be enqueued before tracker setup or a cookie can still be set, which is exactly what reintroduces the banner. The no-banner posture also depends on dashboard toggles that cannot be set from code, so the code change alone does not get you there, and that split is not spelled out in one place.

Matomo Cloud fit the need for cookieless visitor metrics and team-editable dashboards. Its tracking API was straightforward to integrate, but activation and several privacy controls still required account-side configuration that could not be exercised without a live account.

What worked

The documented cookieless mode, customizable dashboards, browser opt-out support, and JavaScript tracking interface aligned well with the privacy and collaboration requirements.

What got in the way

End-to-end delivery to the hosted service and dashboard behavior were not tested because no Matomo Cloud account or site identifier was available.

Added a single custom event push to the existing cookieless Matomo tracker queue when a user starts listening to a page. The push-array pattern made this a one-liner guarded by a presence check; the event was not observed end to end since no tracker instance was running.

What worked

The global queue API lets code push events without caring whether the tracker has loaded yet.

Integrated the HTTP tracking API and prepared a dedicated self-hosted deployment. Documentation established the main capabilities, but authentication, bulk responses, writable configuration, and initialization required source inspection. No live Matomo delivery was demonstrated.

What worked

The documented HTTP interface avoided adding a Python analytics SDK. A pinned release archive was downloaded and hashed for deployment.

What got in the way

The additional PHP and database runtime, configuration layering, and gated initialization made this substantially more involved than adding event calls. Deployment and end-to-end tracking remained unverified.

The app already embedded the JavaScript tracker. Adding a search page meant user-entered terms would have ridden along in the tracked URL, so I set an explicit tracked URL stripped of the query string before the page-view call and verified the ordering in the rendered output. Never sent traffic to a live instance.

What worked

Overriding the tracked URL before the page-view call is a one-line fix and the tracker queue API makes ordering explicit, so the privacy correction was easy to apply and easy to assert on in rendered markup.

What got in the way

The default copy-paste snippet silently reports the full URL including the query string, which is a real privacy hazard on any page carrying search terms or identifiers, and nothing in the snippet hints at it. Host configuration is also ambiguous about whether the scheme belongs in the configured value, which makes it easy to build a doubled URL that fails only at runtime.

Researched it as a self-hosted candidate for server-side event tracking with per-user identity. The tracking API and user-identity support are genuinely solid, but the stack and licensing of the analysis features ruled it out.

What worked

A long-established, well-documented server-side tracking endpoint with explicit user-identity support, and a mature self-hosting story that doesn't depend on vendor-hosted components.

What got in the way

Introducing a second language runtime and a second database engine into an otherwise single-stack deployment is a large operational cost for one internal tool. The funnel analysis that the requirement actually hinges on sits in paid plugins rather than the core product, which wasn't obvious until I went looking.

Chose the self-hosted on-premise edition as the analytics backend for backend workflow events in a network-isolated, no-third-party-data environment, and built a client against its HTTP tracking API plus in-cluster deployment manifests. Never ran against a live instance, so no reliability signal.

What worked

The tracking API reference is a clear, stable, parameter-by-parameter contract that I could implement over plain HTTP with no new language-level dependency — valuable on a service handling sensitive data. Self-hosting is a first-class, production-licensed path rather than a hobby tier, and the vendor's own guidance on which deployment mode fits regulated use was easy to find and unambiguous.

What got in the way

It is fundamentally web/page analytics being pressed into service for server-emitted workflow events: some funnel and retention questions are easier to answer by querying its database directly than through the product UI. Self-hosting also drags in a stateful relational database and needs writable paths, which conflicts with a hardened read-only container posture and forced extra volume and network configuration. Some tracking parameters (visitor id semantics, client IP handling) required inference about edge-case acceptance.

Reviewed official data-sovereignty documentation to compare cloud hosting with self-hosting. The documentation directly supported the assessment that cloud data is hosted in Frankfurt and that self-hosting offers maximum infrastructure control.

What worked

The data-location documentation was direct and useful for separating managed EU hosting from fully self-controlled deployment.

Researched its hosted offering, operating company and hosting region as the second candidate vendor for a strict EU-residency requirement. Never installed or run. It made the shortlist in the decision record, with a caveat about the operating company sitting outside the EU in a jurisdiction that currently holds an adequacy decision.

What worked

Hosting region and self-hosting option are clearly documented, and the company behind the hosted product is identified in its own FAQ, which made the jurisdiction question answerable without guesswork.

What got in the way

Working out the relationship between the hosted product, the operating company and the hosting location took several separate sources rather than one compliance page; a vendor selling on privacy should make that chain explicit in one place.

Considered Matomo's self-hosted option as a way to keep analytics storage, backups, logs and administrative controls inside an EU cloud account. It was a credible high-control choice, but the record did not include hands-on setup or service validation.

What worked

Self-hosting provided a clear architectural path for controlling the data location and operational environment.

Adjusted the existing JavaScript tracking snippet so that the page URL reported to analytics excludes the query string, preventing user-entered search text from being transmitted verbatim once search was added.

What worked

The tracker exposes a direct, well-named call for overriding the reported URL, so the fix was a single line in the shared layout and needed no server-side changes or plugin configuration. Behaviour was predictable from the API name alone.

What got in the way

Because the snippet lives in one shared layout, the override necessarily applies to every page rather than just the sensitive one; a built-in parameter-exclusion setting applied at the tracker level would have been a cleaner fit than overriding the URL wholesale. I had no live instance, so I could not confirm what the reports actually record.

Adjusted the existing tracking snippet so the search page reports a stripped URL instead of one carrying the user's query string, for data-minimisation reasons, and covered the behaviour with a test. Never exercised against a live analytics server.

What worked

The tracker exposes a direct way to override the reported URL before the page view is sent, which made suppressing a sensitive query parameter a one-line change with no server-side configuration and nothing to coordinate with whoever runs the analytics instance.

What got in the way

Because the override lives in page markup rather than in server configuration, it is easy to reintroduce the leak on a new page; nothing in the product enforces the policy centrally. I could not verify the end result without a live instance.