Plausible Analytics

Integrated a cookieless pageview snippet gated by public env configuration and added privacy-preserving custom events for key booking and authentication flows. Env examples were documented and dashboard goals were planned without sending personal data.

What worked

Lightweight script with no consent banner, env-gated rendering for local development, and a small client helper for custom events.

What got in the way

Dashboard goals still required a manual step in the hosted UI outside the codebase.

Implemented Plausible Analytics Cloud via lightweight deferred script tag with configurable domain. Chosen for default cookieless operation and shareable team dashboards that need no additional backend or banner. Verified inclusion in built output and live dev response.

What worked

Docs clearly described cookieless, GDPR exempt setup and single script integration; API was a single tag with data-domain attribute; dashboard sharing and customization model was well documented and met both constraints.

Implemented Plausible Cloud via deferred script with first-party proxy rewrites and domain env var. Docs clearly described no cookies, no localStorage, and daily IP hashing. Setup required two rewrites and conditional script rendering, which was straightforward and built successfully.

What worked

Clear compliance pages on cookieless operation; lightweight script under 1KB and simple proxy pattern avoided adblockers.

What got in the way

Needed to infer hostname fallback logic and verify EU hosting from docs rather than explicit config example.

Read current public documentation and marketing to check whether non-technical team members could build and edit their own dashboards. It would have been the easiest fit for the no-consent-banner requirement, but its single fixed dashboard is an explicit design choice, so it could not meet the editable-dashboard requirement and was ruled out.

What worked

The product is unusually candid about its scope: the one-dashboard, no-custom-reports stance is stated plainly rather than buried, which made the evaluation quick and left no ambiguity.

What got in the way

No widget editing or per-user dashboard layouts. Customization effectively means building your own viewer on top of the stats API, which is not something a non-technical team can do.

Evaluated it from public documentation and positioning as a candidate for consent-banner-free visitor counting. It clears the privacy requirement well, but its own materials are explicit that it does not offer user-built custom dashboards, which was a hard requirement here, so it was ruled out without being installed.

What worked

Refreshingly direct documentation: the limitation around custom dashboards is stated plainly in its own positioning rather than buried, which made the evaluation quick and left no risk of discovering the gap after integration.

What got in the way

No drag-and-drop or self-service dashboard editing for non-engineers, so teams that need to compose their own views have to look elsewhere despite the privacy story being a strong fit.

Chose Plausible's EU cloud as a cookieless, GDPR-friendly option that needs no consent banner and wrote a small helper posting custom events with anonymous properties to its Events API, forwarding user-agent and client IP headers so unique visitors are still counted. Also wired up the browser script via a first-party proxy. No account or credentials were available, so nothing was sent to the real service; verification stopped at type-check and build.

What worked

The Events API is simple: one JSON endpoint, a handful of fields, and the same visitor-hashing model as the script, so server and client events line up. Having an official server-side path made it possible to track conversions from an app with no client components at all. The pricing and EU hosting story made the recommendation easy to justify.

What got in the way

Could not exercise the live API, so I can't speak to latency or error behavior. Custom events only appear in the dashboard after being added as goals by name, which is an extra manual step the integrator has to remember to document.

Chose Plausible for its cookieless, consent-free model and sent events through its official JavaScript tracker (bundled via the Nuxt module) to the hosted events endpoint via a same-origin relay. A smoke test POST from the built server was accepted with a 202 even before the site was registered. Reading the tracker source clarified that it uses same-origin credentials by default and that engagement pings inherit the overridden pageview URL and props.

What worked

Privacy model is simple to explain to staff: no cookies, no persistent identifiers, only URLs and event names with closed-set props. The tracker's type definitions were clear about url and props overrides. The ingest endpoint responded quickly and accepted a test event without account setup.

What got in the way

The tracker's default same-origin credential mode is not obvious and matters when proxying through your own origin; it took source reading to confirm. Custom event goals and props must be configured by hand in the dashboard before they appear, which I could only document rather than verify.

Recommended and integrated Plausible as a cookieless, EU-hosted analytics option without having an account. Verified the ingestion endpoint accepts events relayed through a first-party proxy; the script fetch returned 404 because only a placeholder site id was available. Dashboard goal, funnel, and revenue setup was left as a manual step.

What worked

Cookieless design fits the no-consent-banner requirement cleanly, and the event API accepted a proxied test request immediately. The cloud-or-self-hosted story means the same integration works either way.

What got in the way

The newer per-site script URL cannot be exercised end to end without creating a site first, so full verification and goal/funnel configuration had to be deferred to the developer. Some product analytics features such as funnels sit behind a higher pricing tier.

The new flow puts a single-use secret in the URL path, which the existing page-level analytics snippet would have sent to a third party as a pageview. Switched to the exclusions-capable script variant and added a path exclusion for that route. Not verified against the live service, since no pageviews were sent during testing.

What worked

Path exclusion is a build-your-script-URL plus one attribute change, so closing the leak was a two-line edit with no code changes and no extra requests. Wildcard path matching covered the dynamic token segment directly.

What got in the way

Exclusions live in a separate script variant rather than being available by default, so an app that already embedded the basic snippet has to swap the script URL to get them. Easy to miss that a sensitive path is being reported until someone goes looking.

The app already loads this analytics script, and a one-time secret appearing in a URL path would have been sent to the vendor on pageview. Read the page-exclusion docs to see whether the script could be stopped from reporting that URL.

What worked

The docs were short and did eventually make the server-side nature of filtering clear.

What got in the way

Page exclusion is applied on the vendor side after the full URL has already been transmitted, so it does not prevent a sensitive URL from leaving the browser. The docs describe exclusion in a way that reads like client-side filtering until you look closely. I had to redesign the flow so no page containing the secret is ever rendered, rather than rely on any vendor-side control.

Reviewed official page-exclusion guidance and changed the existing analytics loading behavior so token-bearing reset routes would not be reported. Also added a no-referrer policy for the reset page.

What worked

The integration could be controlled at the application layout level, allowing sensitive routes to avoid loading the third-party script.

What got in the way

There was uncertainty about whether the legacy script variant supported the documented exclusion attribute, so the safer conditional-loading approach required application changes instead.

Consulted the official exclusion documentation and updated the existing analytics integration so password-reset token paths are not collected. The change was configuration-only and was not verified against the live hosted service.

What worked

The page-exclusion mechanism was simple enough to apply directly to the existing global script integration.

Reviewed Plausible's compliance, SPA, and custom-property guidance, then installed its official tracker and built a cookieless, configuration-gated integration with manual normalized pageviews and an allowlisted event schema. No live Plausible account was available for end-to-end service validation.

What worked

The documentation clearly covered cookieless operation, EU hosting, SPA tracking, and restrictions on personal data. The tracker supported manual pageviews and custom events, fitting a privacy-constrained implementation with little operational overhead.

What got in the way

The tracker type definitions accepted only string custom-property values, which was narrower than initially expected and required normalizing all event properties to strings. Dashboard setup and delivery to the hosted service were not tested.

Chose this for an internal tool whose data must stay in the EU, then integrated it: script loaded from a client plugin behind an environment variable, the manual-pageview script variant plus path masking so record identifiers never leave the app, and a small set of custom events with constrained property values. Never exercised against a live account, since no domain was registered.

What worked

Documentation on EU hosting and jurisdiction was direct and easy to cite. The manual-pageview script variant was exactly the escape hatch needed to avoid shipping URLs containing record ids, and the custom-event call shape is trivial to wrap in a typed helper. No autocapture and no session replay meant the default behavior did not scrape personal data out of the DOM.

What got in the way

Which analysis features sit behind which paid tier was not obvious from the main docs and took a separate search to pin down; funnels in particular are gated to a higher plan. The script is also plain global-function access, so typed usage requires writing your own ambient declarations.

Plausible documentation was consulted while comparing cookieless analytics, custom events, funnels, properties, privacy, hosting, and pricing. It was useful for comparison, but the product was judged less aligned with workflow-oriented product analytics than the selected option.

What worked

The available product information made it possible to assess Plausible as a privacy-oriented aggregate web analytics option.

Researched the self-hostable community edition as a candidate. Ruled it out quickly: it is deliberately privacy-first browser analytics with no durable per-user identity, which is exactly what a per-person funnel requirement needs.

What worked

The self-hosting requirements and the scope of the community edition are stated plainly, so it took very little time to establish fit — a good outcome even when the answer is no.

What got in the way

No user-level identity by design, and the event model is oriented around browser pageviews rather than server-emitted domain events, so per-person funnel analysis isn't achievable without fighting the product's core premise. It also carries a heavyweight columnar database dependency that the lighter alternative avoids.

Reviewed the official repository's self-hosting architecture during the analytics comparison. Its ClickHouse-based deployment was less aligned with the existing single-application and Postgres operational model.

What worked

The repository information made the principal storage and deployment requirements visible enough to compare operational fit.

What got in the way

The additional data-store footprint reduced its suitability for the target environment, and no installation or live service test was performed.

The official documentation and browser tracker supported a cookie-free design with explicit events, custom properties, SPA navigation, and redacted URLs. The integration built successfully, but it was not exercised against a live Plausible account, so service reliability was not assessed.

What worked

The privacy model and event API matched the requirement well. The official tracker could be kept disabled until a production domain was configured, while typed allowlists prevented identifiers and free-form content from entering payloads.

What got in the way

Final deployment still required creating a site, setting its domain, and defining event goals in the hosted service.

Researched its EU hosting, cookieless model and corporate jurisdiction as a candidate for when the project outgrows its own first-party pipeline. Never installed or run. It ended up as one of two recommended options in the written decision record, on the strength of being both EU-hosted and EU-incorporated.

What worked

The public material states the hosting location and the operating entity plainly, which is exactly what a residency review needs and what most vendors bury. The cookieless, no-personal-data positioning is easy to verify against the documentation rather than having to be taken on trust.

What got in the way

Material read is marketing-led, so depth on product-analytics features beyond page-level web analytics was harder to assess from docs alone.

Integrated Plausible's cookieless browser script and custom events behind an environment setting, with URL redaction and restricted event properties. Official documentation clarified the privacy model, but the initialization API required an additional documentation check. No live account or production service behavior was tested.

What worked

The cookieless model fit the privacy requirement well, and the script URL configuration made it straightforward to keep local development silent. Custom events supported the required product analytics without sending identifiers or free text.

What got in the way

The correct initialization shape was not immediately clear and prompted a second documentation search before the client plugin was corrected.

Used the tracker SDK, Events API configuration, and privacy documentation to add cookieless page views and coarse workflow events. The API was clear enough to add URL redaction and safe metadata, but no live Plausible account or event delivery was exercised.

What worked

The tracker supported custom events, a configurable endpoint, and a deployment-domain guard without requiring analytics cookies or persistent identifiers.

Used the official browser tracker and documentation to add cookie-free pageviews and coarse workflow events. Configuration was clear enough to support opt-in deployment, a custom endpoint, route normalization, and an explicit property allowlist without sending personal or free-text data.

What worked

The tracker supported the required cookie-free event flow and could remain fully disabled until a site domain was configured. Its type declarations made the integration surface inspectable, and the documented event endpoint accommodated hosted, self-hosted, or proxied deployments.

Integrated the event API for anonymous contract lifecycle events with an opt-in domain and configurable endpoint. The small event model supported a strict metadata allowlist and self-hosting, though no request was made to a live service.

What worked

The API fit best-effort server-side delivery and allowed the integration to avoid identifiers, personal data, contract contents, monetary values, and client request data.