Filament Metrics Ga4 Laravel Package

Product Decisions This Supports

• Information architecture and admin UX: Teams can now control where the analytics settings page lives inside a Filament panel's navigation (e.g., grouping it under "Settings," "Insights," or a custom product area) instead of accepting a fixed, translated group. This turns a packaging detail into a UX decision that PMs can own rather than work around.
• Build vs. buy for embedded analytics: The package remains a thin Filament settings surface over filament-analytics-core. A navigation-group hook reduces the need for forked views or custom panel wiring, strengthening the case for buying/integrating rather than building an in-house settings UI.
• White-labeling and multi-tenant panels: Because navigationGroup() accepts a Closure, the group label can be resolved per-tenant, per-locale, or per-role at runtime. That directly supports reseller/OEM packaging, role-scoped admins, and localized deployments as roadmap items rather than custom engineering.
• Release sequencing risk is now explicit: The feature requires filament-analytics-core 3.1. Any roadmap that pins the core below 3.1 cannot use this and will retain the default translated group—an upgrade dependency to schedule, not a blocker.
• Not a scope expansion: This is a presentation-layer capability. It does not change data collection, retention, metrics definitions, or reporting, so it should not trigger privacy, billing, or analytics-contract reviews.

When to Consider This Package

Adopt when:

• Your admin surface is a Filament panel and you want analytics configuration to sit alongside your existing settings rather than as an orphaned or awkwardly named menu entry.
• You operate multiple panels, brands, tenants, or locales and need navigation labels to vary at runtime—this release is the first version where a Closure makes that practical without forking.
• You can move to filament-analytics-core 3.1 or later; the feature is inert on older core versions, and the package falls back to the translated default group.
• You are consolidating third-party admin plugins and want navigation grouping decided centrally by the host panel, not by each plugin.

Look elsewhere or defer when:

• You are not on Filament, or your panels intentionally use a fixed, framework-provided navigation structure that plugins should not influence.
• You are pinned to filament-analytics-core below 3.1 and have no near-term upgrade path—expect no benefit from 3.1.0.
• You need analytics capabilities rather than placement controls; this release adds no metrics, dashboards, or data features.
• You require a stable navigation contract across many plugins and would rather standardize grouping yourself than depend on per-plugin hooks.

How to Pitch It (Stakeholders)

For executives: A small, low-risk release. It lets us place the analytics settings screen wherever it belongs in the admin menu—including different labels for different brands, tenants, or languages—so the product looks native to each customer instead of carrying a generic plugin label. No change to data handling, pricing, or compliance surface. The only cost is an upgrade dependency: our analytics core must be on 3.1 or newer.

For engineering: Plugin::make()->navigationGroup(string|Closure) overrides the default translated navigation group for the settings page. A Closure is evaluated at render time, so tenant-, locale-, and role-aware grouping is supported without custom views. Behavior is backward compatible—omit the call and the existing translated group is preserved. Requires filament-analytics-core ^3.1; on earlier core versions the setting has no effect. Recommend pinning the core to at least 3.1 in composer constraints and adding a menu-placement test in the panel's acceptance suite.