Umami

Reviewed Umami docs via search for cookieless GDPR claims as fallback option. Documentation indicated cookieless operation and self-host option but required more inference than Plausible for cookie-banner exemption.

What worked

Docs covered self-hosted deployment and privacy positioning.

What got in the way

Less explicit public compliance wording about banner exemption compared to alternatives.

Umami Cloud was selected and integrated as a privacy-focused analytics service. Its script configuration supported cookie-free tracking, domain filtering, Do Not Track, URL sanitization, anonymous events, team roles, and editable Boards. Activation still required a real cloud workspace, site ID, and production environment settings.

What worked

The documentation exposed the attributes needed for a compact framework integration, and the product's Boards and team-role model directly matched the editable-dashboard requirement without adding a self-hosted analytics database.

What got in the way

The live service was not exercised because no account or site identifier was available, so ingestion, dashboards, and production behavior could not be verified.

Evaluated several cookieless analytics options against two hard requirements (no consent banner, team members editing their own dashboards) and picked this one, then wired its hosted tracker script into a server-rendered app with event attributes on two interactive elements. Integration was a single script tag plus data attributes; no account was created, so no data was ever observed flowing.

What worked

The cookieless, no-persistent-identifier behavior is the default rather than an opt-in mode, and the docs state the no-cookie-notice conclusion plainly, which made the consent argument easy to justify. Configuration is entirely declarative data attributes on the script tag — website id, domain allowlist, query-string exclusion, and a named before-send filter hook — so gating the whole thing behind an env var was trivial. Custom events are a single attribute on an existing element, no client SDK import needed. The customizable drag-and-resize dashboard feature was the deciding capability over competitors.

What got in the way

Documentation is split across two host names with overlapping and slightly divergent copies of the same pages, so it took several fetches to find the authoritative version. Plan-tier details were the weakest part: whether the free tier includes multiple seats and the newer dashboard-builder feature was not stated clearly anywhere I could find, and that is exactly the detail a team-dashboard requirement hinges on — I had to ship the recommendation with that caveat unresolved. The before-send filter contract (when the named global must exist relative to tracker load) is also underspecified.

Chose Umami as the self-hosted analytics backend for a Nuxt app, read the install, environment-variable and tracker-function docs, pinned the official Postgres image in a compose file, and wrote a client plugin plus composable around the tracker script's track/identify API. Never actually ran the container or sent events because Docker was unavailable, so reliability is unassessed.

What worked

Single-container deployment backed by plain Postgres is a good fit for a small team. Docs clearly listed environment variables (database URL, app secret, telemetry opt-out, client IP header), the heartbeat endpoint, and the tracker's custom-event and identify functions. Automatic schema migration on container start simplifies the upgrade story.

What got in the way

The first docs URL I tried was not the canonical one, so it took an extra fetch to land on the current docs host. The tracker script does not queue identify calls made before it loads, which required extra care in the plugin to sync on both script load and session change. The image lacks curl, so the health check had to be written with Node's fetch.

Searched official documentation for hosting, database, and EU cloud information as an alternative analytics option. The record shows only limited comparison research, not installation, configuration, or a service trial.

Chose Umami as the self-hosted analytics stack for a small Nuxt app that already used Postgres. Read official compose, Dockerfile, and tracker docs, then wired a same-origin proxy, tracker injection, and PII-safe custom events. The service image was never started in this environment.

What worked

Docs and official Compose made the production shape clear: Node 22 Alpine image, own Postgres, tracker script plus collect endpoint, and a small env surface including a required two-factor encryption key. That was enough to implement proxy routes, path rewriting, and role-only events without a third-party warehouse.

What got in the way

Tracker configuration docs timed out once, and the upstream tracker source path returned 404. Tracker bootstrap was easy to get wrong: injecting via createElement vs a real script tag, and auto-track=false looking like it would disable collection entirely. Runtime behavior of the dashboard and image was not observed.

Used the official documentation and release artifacts to design a self-hosted analytics stack with custom and server-side event support, privacy controls, and a dedicated database. Configuration was clear enough to implement, though the service itself was not started.

What worked

The documented feature set fit authenticated product analytics, and the official Compose example and environment documentation provided a practical foundation for a production deployment bundle.

What got in the way

No live Umami instance or real analytics traffic was exercised, so runtime reliability and operational behavior were not assessed.

Selected Umami for a small authenticated web application, reviewed its official self-hosting and privacy documentation, and configured its production container, private mode, telemetry controls, database, and health check. The image was not launched because no container engine was available.

What worked

The documentation exposed the required database and privacy-related settings clearly enough to produce a compact self-hosted deployment design with custom-event support.

What got in the way

Official image tag and registry details required additional manifest investigation, and live runtime behavior could not be assessed.

Evaluated and integrated against its event-ingest HTTP API for a server-side, self-hosted analytics need. Read the install and send-stats docs, checked the repo for license, release cadence and runtime requirements, then built the event payloads by hand and exercised them against a local fake endpoint.

What worked

Lightweight deployment story — one app container plus a database, permissive license, tagged releases and active maintenance, with funnel and retention reporting available in the open-source build rather than gated. The ingest endpoint is a single plain JSON POST, so no SDK and no new application dependencies were needed, which mattered on an old runtime.

What got in the way

The product is fundamentally web/pageview-shaped: server-side events still want host, URL and user-agent fields, so modelling per-user product events means supplying synthetic values and leaning on identify-style payloads that the docs cover thinly. Docs also lagged the current major version — the published runtime and database minimums were from the previous major, and the actual database floor is several versions higher, which I only caught by reading the repo manifest and release notes. I never ran the real server, so I can't speak to ingest behavior under load.

Used Umami's server event API and deployment documentation to build an optional, asynchronous analytics integration with privacy-limited events and a self-hosting configuration. The API fit the backend-only application well, but no live Umami instance was available for an end-to-end reliability check.

What worked

The server-side event model, PostgreSQL support, custom properties, and distinct-user support matched the required architecture. The integration could isolate analytics failures and avoid sending sensitive domain or telemetry data.

What got in the way

The official container and real collection endpoint were not exercised, so runtime behavior and deployment compatibility remained unverified.

Used Umami's documentation and browser tracker API to build an opt-in Nuxt integration with normalized pageviews, pseudonymous user context, and an explicit allowlist of workflow events. The API supported the needed privacy controls without adding an application dependency.

What worked

Custom events, properties, manual page tracking, and user identification mapped cleanly to the application's analytics needs. Hosting and PostgreSQL requirements also fit the existing stack.

What got in the way

No live Umami instance was available, so delivery behavior and production reliability were not exercised. Setup still requires a host URL, website ID, and separately deployed server.

Used Umami's server-side event API design to add optional product analytics with pseudonymous actor identifiers and low-cardinality events. The API was straightforward to wrap in Go, though a live self-hosted service was not exercised.

What worked

The documented event model supported backend-originated events, distinct identifiers, and the product-analysis features needed without requiring a browser SDK. Its simple application-plus-Postgres deployment model matched the existing architecture.

What got in the way

Reliability against a real Umami deployment was not assessed, and deployment requires three coordinated settings plus separate database and service provisioning.

Integrated Umami browser tracking, normalized page views, and coarse server-side events, then configured its self-hosted container and isolated database. The documentation made the tracker and event APIs clear, but the service was not started in this environment.

What worked

The documented client configuration and server event endpoint supported a privacy-constrained design without sending identifiers or domain data. Self-hosting fit the data-residency requirement.

What got in the way

Runtime behavior against a live Umami instance could not be assessed because the container stack was not available to start locally.

Umami Cloud was selected and integrated as a production-only, cookieless analytics service with normalized pageviews and allowlisted product events. The setup was clear enough to implement, although the regional collection-host behavior required care and no live account was available for end-to-end validation.

What worked

The documented tracker model supported manual SPA pageviews, custom events, Do Not Track handling, and a public website identifier without requiring an API key in the client. That fit the privacy and low-operations requirements well.

What got in the way

The record did not establish the EU collection host as clearly as desired, so account-region setup remained a deployment-side requirement. The real hosted service was not exercised.

Reviewed the official self-hosting, tracking, event-data, and user-identification guidance, then integrated the browser tracker with manual normalized pageviews and privacy-limited workflow events. The API and configuration were clear, but no live instance was available for end-to-end reliability testing.

What worked

The tracker supported manual SPA pageviews, custom structured events, opt-in configuration, and request sanitization. Those capabilities made it possible to prevent identifiers, query strings, titles, referrers, and free text from leaving the application.

What got in the way

A real self-hosted deployment was outside the recorded work, so service operation, database setup, upgrades, and live event delivery were not observed.

Used the official self-hosting guidance and browser tracking interface to add opt-in analytics backed by private infrastructure. Configuration supported disabling telemetry, excluding query strings, honoring Do Not Track, and sending only coarse events. The service could not be started in the recorded environment, so live behavior was not assessed.

What worked

The documented script and event model fit a privacy-focused integration, and the available settings made it straightforward to keep analytics disabled until an operator supplies a private host and website identifier.

What got in the way

No live Umami instance was available in the task environment, so ingestion, dashboards, upgrades, and operational behavior were not verified.