Filament Metrics Plausible Laravel Package

Product Decisions This Supports

• Panel IA / navigation architecture: Teams can now control where the analytics settings page surfaces in a Filament panel (Plugin::make()->navigationGroup(...)), instead of inheriting the package's translated default group. This turns a fixed packaging decision into a configurable product decision.
• Multi-panel and multi-tenant rollouts: Because navigationGroup accepts a Closure, the destination can be resolved at runtime — per panel, per tenant, or per role — which matters when the same codebase ships an admin panel, a client panel, and a partner portal with different information architectures.
• Localization and UX polish: The fallback (keeping the translated group) means non-English panels are not regressed by adopting this. Teams can localize the group label through their own translation keys rather than accepting the vendor's string.
• Upgrade sequencing / dependency management: The feature is gated on filament-analytics-core 3.1. That's a concrete, checkable constraint for the roadmap — the plugin bump is only useful once core is at 3.1, so plan the two upgrades together rather than in separate sprints.
• Build vs. buy signal: Upstream is actively closing small integration-friction gaps rather than only shipping headline features. That's a mild positive for staying on the package instead of forking or hand-rolling a settings page.
• Not a decision-driver: This is configuration surface, not new analytical capability. It should not move the needle on whether the product's analytics offering is competitive.

When to Consider This Package

Adopt or keep it when:

• You are already on Filament and filament-analytics-core 3.1 or later — the new option is inert or unavailable otherwise.
• Your panel has a deliberate navigation taxonomy (e.g., "Insights", "Reporting", "Configuration") and you do not want a vendor-owned settings page appearing under a group you didn't choose.
• You run more than one panel or need runtime-conditional placement — the Closure form is the reason to care about this release specifically.
• You want translated defaults preserved for locales you don't maintain, while overriding only where your IA demands it.

Look elsewhere or defer when:

• You are pinned below filament-analytics-core 3.1 — this release delivers nothing until that constraint clears, so don't let it anchor an upgrade story.
• Your settings page placement is genuinely fine as shipped. This is optional polish; it is not worth a dedicated migration window or a QA cycle on its own.
• You need fine-grained control beyond group placement — ordering, sort, icon, or conditional visibility of the page itself. This release covers grouping only; confirm the rest is reachable through Filament's own page registration before assuming parity.
• You are not on Filament at all, or you are evaluating analytics backends on data-model and query capability. Navigation grouping is irrelevant to that comparison.

How to Pitch It (Stakeholders)

For executives (one line): A small configuration addition that lets the analytics settings screen sit where it belongs in our admin navigation — low effort, no user-facing risk, and it removes a recurring "why is this menu item here?" complaint.

For engineering: Release 3.1.0 adds Plugin::make()->navigationGroup(string|Closure) to the analytics plugin, letting us assign the settings page to one of our own panel navigation groups. Default behaviour is unchanged — omitting the call preserves the package's translated group, so this is purely additive and safe to adopt incrementally. The Closure variant supports runtime resolution, which covers our multi-panel and per-tenant cases without separate plugin registrations.

Sequencing and risk: Hard dependency on filament-analytics-core 3.1 — bundle the two upgrades. No breaking changes, no deprecations, no migration required. Recommend slotting this into the next routine dependency pass rather than a standalone release, and validating navigation rendering across each panel we ship.

What we are not claiming: This does not change analytics capability, performance, or data coverage. Position it as UX hygiene and integration maturity, not as a feature win.