Filament Metrics Fathom Laravel Package

Product Decisions This Supports

• Admin information architecture (IA): the plugin exposes a single, explicit lever — Plugin::make()->navigationGroup(string|Closure) — for deciding where the analytics/settings surface lives inside a Filament panel's own navigation. That's a product/UX decision (where users find analytics), not just a technical one, and this release makes it a first-class configuration rather than a fork-or-patch.
• White-label and multi-tenant packaging: because the argument accepts a Closure, grouping can be resolved per-panel, per-tenant, or per-plan at runtime. This supports tiered products where analytics sits under "Insights" for enterprise tenants and under "Settings" for smaller accounts — a real differentiation lever without custom code.
• Consistency across panels: for products shipping multiple Filament panels (admin, tenant, reseller), this removes the last class of "one page lives in a translated default group while everything else follows our IA" inconsistency — a recurring source of polish complaints and support tickets.
• Build vs. buy: reinforces the "buy/adopt" side. The plugin now yields on the customization axis that most often forces teams to copy the settings page into their own codebase. Lower fork pressure means lower long-term maintenance cost and a smaller internal ownership burden.
• Reduced localization surface: the fallback keeps the existing translated group (filament-analytics::...), so teams that never call the method see no change. No forced copy changes, no re-translation work, no migration story.
• Not a roadmap driver: this is a configuration affordance, not a capability. It should not, on its own, change prioritization of an analytics feature area — it removes friction for teams already committed to the plugin.

When to Consider This Package

Adopt / upgrade when:

• You run one or more Filament panels and want a shipped analytics/settings surface without owning the UI code.
• Your panel already enforces a house navigation structure and you need third-party pages to conform to it — this release makes that a one-liner instead of a patch.
• You are multi-tenant or white-label and need navigation placement to vary by tenant, plan, or panel; the Closure form covers this without touching vendor code.
• You are already on filament-analytics-core 3.1+ (hard requirement for this method) and want the grouping API rather than an alternative mechanism.
• You value staying on the upstream release line: picking up 3.3.0 now keeps you current ahead of future breaking changes, and the change is additive.

Look elsewhere or defer when:

• You are pinned below filament-analytics-core 3.1. navigationGroup() will not be available; upgrading the core is a prerequisite and may carry its own review cost. Treat this as a coordinated upgrade, not a drop-in.
• You are not on Filament, or you need analytics UI well beyond a settings page (custom dashboards, embedded BI, warehouse-native tooling). This is a narrow surface.
• You need navigation behavior beyond grouping — ordering, badges, per-role visibility, icons. Not covered here; verify against your IA requirements before assuming parity with native Filament pages.
• Your team cannot accept an external dependency for a page that appears in your primary navigation. The blast radius of a breaking release in this package is user-visible; weigh that against the maintenance savings.
• You are mid-freeze: the default behavior is unchanged, so there is no urgency to ship this in the current cycle.

Evaluation checklist before adopting: confirm core 3.1 compatibility in your lock file, verify the closure receives enough context to key off tenant/panel, and confirm fallback translation still renders correctly for locales where you do not set a group.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-risk release from a package we use for the analytics settings screen in our admin panels. It lets us place that screen in our own navigation menu — including varying the placement by customer tier or tenant — instead of accepting a default label we can't control. That matters for two reasons: it removes a recurring "why is this page in the wrong place" polish gap in customer-facing admin areas, and it reduces the chance our engineers fork the package to get the layout they want, which is where maintenance cost quietly accumulates. It is additive, the default behavior is unchanged, and it introduces no migration or re-translation work.

For engineering: The change is one opt-in method — Plugin::make()->navigationGroup(string|Closure) — that overrides the translated default group. The Closure form is what makes it useful for us: grouping can be resolved at runtime per panel or tenant. The single hard requirement is filament-analytics-core 3.1, so confirm our constraint allows it before scoping; if the core bump is non-trivial, split it into its own ticket rather than bundling it with the adoption. No breaking changes, no deprecations, no config migration. Default behavior is fully preserved for anyone who does not call the method, so rollout risk is close to nil — the real work is deciding our target IA and encoding it, not the upgrade itself. Recommend we adopt when the core is already at 3.1 and we next touch panel navigation, and that we do not fork the page in the interim.