Filament Plausible Laravel Package

Product Decisions This Supports

• Build vs. buy vs. assemble for admin analytics. The package bundles three decisions into one cheap adoption: the Plausible Stats API client, the Filament widgets (visitors, pageviews, traffic sources), and a settings surface with credential management and response caching. The alternative — a custom API client plus dashboard views plus a settings page — is days of engineering for a capability that is not a differentiator. The real buy decision sits above the package: Plausible's paid subscription (or self-hosted) versus a "free" GA4 setup whose true cost shows up as consent-banner friction, legal review, and data-processing paperwork.
• Privacy and consent posture as a product requirement. Choosing a cookieless, privacy-friendly analytics backend is a compliance decision with a measurable product consequence: no consent banner gating the funnel, so no drop-off at the consent step and no consent-mode modelling distorting your numbers. For EU/UK-facing products this is often the deciding factor, and framing it as "analytics that doesn't tax conversion" lands well with both legal and growth.
• Analytics adjacency to the operator's workflow. Embedding insights inside the Filament panel means ops, support, and account managers read traffic data where they already work, instead of context-switching into a separate console. That supports decisions about whether metrics belong in the admin surface at all, or whether the panel should deep-link out to the analytics vendor instead.
• Admin information architecture and navigation taxonomy. Release 3.4.0's Plugin::make()->navigationGroup(string|Closure) is a genuine, if small, IA decision: put analytics settings under an existing domain group (e.g. "Insights", "Operations") rather than a plugin-defined translated group. This affects discoverability, permission grouping, and how multi-panel or white-labeled products present related tools. The Closure form lets you compute the group per tenant or role without forking the plugin.
• Tooling consolidation on the roadmap. Each panel-native integration is one fewer standalone SaaS console to provision, SSO, and offboard. This is an argument for consolidating analytics into the admin surface — and a reason to sequence it deliberately rather than bolting it on per team.
• Self-hosting and data-residency choices. Configurable site ID, API token, and host URL mean the same plugin serves Plausible Cloud or a self-hosted instance. That turns "where does our analytics data live" from an architectural fork into a configuration value.
• Script-only adoption. Disabling the settings page for script injection only means the plugin can be used purely for tracking instrumentation without exposing a configuration UI — useful when credentials are managed by platform/DevOps rather than panel operators.
• Upgrade sequencing as a planning item. The 3.4.0 feature requires filament-analytics-core 3.1+. Treat it as a bundled upgrade window, not a standalone bump. It is backwards compatible (omit the call and the translated group is retained), so it should not block or reshape a roadmap.

When to Consider This Package

Consider it when:

• Your admin surface is Filament and you already use, or are willing to pay for, Plausible. The plugin is a presentation layer over the Plausible Stats API; it does not replace the analytics product or its subscription.
• Privacy-friendly analytics is a stated requirement — EU/UK user base, no-consent-banner goals, or a data-protection review that makes GA4 unattractive.
• The analytics settings page needs to match your panel's navigation taxonomy, which is the specific thing 3.4.0 improved, and matters most for multi-panel or white-labeled deployments.
• You can satisfy filament-analytics-core 3.1+ and are comfortable upgrading the plugin and the core package in the same window.
• The scope matches: read-only traffic metrics in an admin panel. Visitors, pageviews, sources, date ranges, period comparisons. If you need funnels, retention cohorts, revenue attribution, or warehouse-native reporting, this is the wrong tool.
• You accept the maturity trade-off and have a mitigation — see below. The package is early-stage: a handful of stars, zero dependents, and a single maintainer. That is fine for a low-blast-radius admin convenience and unacceptable for anything load-bearing without a plan (version pinning, wrapping the plugin registration so it can be swapped, or vendoring the small surface into your own codebase if it becomes critical).
• You are willing to do diligence on release cadence and provenance. The published release metadata is thin; confirm the maintainer's responsiveness, the Composer constraint on the core package, and whether it is enforced as a hard requirement or a soft one.

Look elsewhere when:

• You are not on Filament, or your admin stack is custom or another framework.
• You need standalone BI, warehouse-native reporting, or advanced analytics beyond an in-panel widget set.
• You cannot or will not upgrade filament-analytics-core to 3.1+, which makes the headline 3.4.0 feature unavailable.
• Your bus-factor or procurement policy rules out single-maintainer, low-adoption dependencies. In that case the honest options are building the thin integration yourself or forking; the API surface is small enough that either is tractable.
• Strict data-residency, query-load, or security review requirements rule out an in-panel analytics plugin without additional controls (token scoping, caching policy review, network egress rules).
• You need deep navigation or widget customisation beyond grouping and configuration — at which point a custom page is a better investment than bending a plugin configuration API.
• The whole point is granular product analytics. Plausible is deliberately a lightweight, aggregate tool; if your roadmap depends on event-level behavioural analysis, this integration will frustrate the team that needs it.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk integration that puts privacy-friendly traffic analytics inside our existing Filament admin panel. The strategic value is twofold. First, it avoids building a bespoke dashboard and API client — we get widgets, caching, and a settings page off the shelf for the cost of an afternoon of configuration. Second, it lets us keep a cookieless analytics backend, which removes the consent-banner step from our funnel and materially reduces legal and consent-management overhead. Total cost of ownership is a Plausible subscription (or self-hosted instance) plus a bundled dependency upgrade — not engineering headcount. The one caveat I want on record is dependency maturity: this is an early-stage package with a single maintainer, so I recommend pinning the version and treating it as an admin convenience rather than critical infrastructure until adoption proves out.

To engineering: The package is a thin Filament plugin over the Plausible Stats API: configurable site ID, API token, and host URL; widgets for visitors, pageviews, and traffic sources; date-range and period comparison support; cached API responses. Release 3.4.0 adds Plugin::make()->navigationGroup(string|Closure), gated on filament-analytics-core 3.1 and backwards compatible — omit the call and the translated group is preserved. Integration is a one-line change in the PanelProvider, with no migrations, no config publishing, and no front-end assets. Two asks: land the core and plugin bumps in a single PR so there is no window where the plugin is present and the core is not, and be defensive with the Closure form — it is evaluated during panel navigation assembly, so a non-deterministic or expensive resolver costs you on every panel page load, not just the settings page. Register custom groups via Panel::navigationGroups() so ordering is deterministic, and verify placement per panel in multi-tenant setups.

To product and design: The 3.4.0 release gives us control over where analytics settings live in the admin information architecture. We can place them inside an existing group so related tools stay together, reduce navigation sprawl, and let a Closure route the page per tenant or role for white-labeled deployments. Default behaviour is unchanged, so there is no forced UX migration — we can adopt panel by panel, check discoverability with the operators who actually use it, and roll out broadly only once we are satisfied. The broader product argument is that traffic metrics belong where the work happens; embedding them in the panel removes a tool switch for support and account teams. What it will not do is give us event-level behavioural analytics — if a team needs cohorts or funnels, that is a separate conversation about the analytics vendor, not about this plugin.