Filament Metrics Matomo Laravel Package

Product Decisions This Supports

• Build vs. buy for in-app analytics: This package is a Filament plugin that drops an analytics surface directly into an existing admin panel. The build-vs-buy calculus shifts toward "buy/adopt" whenever your team already runs Filament — the integration cost is a plugin registration plus a config call rather than a bespoke dashboard. Evaluate against the cost of building and maintaining a custom analytics page (query layer, chart components, access control, i18n) before committing engineering time.
• Admin UX and information architecture: The 3.3.0 Plugin::make()->navigationGroup(string|Closure) addition is a real product decision enabler, not just a config nicety. It lets you place the analytics/settings page inside your panel's navigation groups (e.g. "Insights", "Operations", "Reporting") instead of surfacing it under a generic translated group. This directly affects discoverability, menu coherence, and how analytics is framed to internal users — closing a common objection from teams with carefully curated admin navigation.
• Roadmap sequencing for internal tooling: If analytics in the admin panel is on the roadmap, this package can compress the timeline by removing custom UI work. It also de-risks the "we'll build it later" backlog item — you can ship a usable analytics surface now and iterate on custom metrics separately.
• Localization and multi-market readiness: The default behavior retains the translated group, meaning existing non-English panels keep working unchanged; the new opt-in override gives you control without forcing a migration. That supports a phased rollout across locales/teams.
• Multi-tenant / multi-panel products: Because navigationGroup accepts a Closure, the group can be resolved dynamically per panel or per tenant — useful for SaaS products with distinct admin panels or white-labeled deployments where navigation labels differ by customer.
• Upgrade and dependency decisions: The feature requires filament-analytics-core 3.1+. This is a concrete input to your dependency-pinning and upgrade-window decisions — confirm the core version in your lockfile before promising the capability to stakeholders.

When to Consider This Package

Consider adoption when:

• You already run Filament for your admin/back-office and want analytics surfaced in-panel with minimal custom UI work.
• Your product needs a lightweight, embedded analytics view for internal operators, support, or account managers — not a customer-facing BI product.
• You value navigation coherence: the 3.3.0 navigationGroup() support (string or Closure) lets analytics live in a group that matches your panel's IA, and the Closure form supports per-panel/tenant variation.
• You operate in multiple locales and need the option to override the default translated group deliberately rather than by patching.
• You can absorb the filament-analytics-core 3.1+ requirement and are comfortable tracking a two-package version pairing (plugin + core).

Look elsewhere when:

• You are not on Filament — the value proposition is largely the bundled admin UI; outside Filament the integration cost rises sharply and a standalone charting/BFF approach may be cleaner.
• You need deep, custom analytics (cohort analysis, complex funnels, warehouse-native querying, embedded customer-facing dashboards) — this is a convenience surface, not a BI platform. Pair it with a real analytics backend rather than stretching it.
• You require strict control over data residency or query semantics that a prebuilt plugin can't expose.
• Your team pins dependencies conservatively and cannot yet move filament-analytics-core to 3.1+; defer until the upgrade window opens.
• Navigation customization is a hard requirement and you cannot upgrade — the pre-3.3.0 behavior (translated group only) may not satisfy your IA standards.

How to Pitch It (Stakeholders)

To executives: We can put an analytics view inside our existing admin panel without a bespoke build. The latest release (3.3.0) adds navigation-group control, meaning the feature fits our menu structure and branding rather than appearing as a bolted-on, generically labeled page. Cost is low — a plugin registration and a one-line configuration — and it addresses a known gap in our internal tooling roadmap. Decision needed: approve the dependency upgrade (filament-analytics-core 3.1+) and the small integration effort.

To engineering: This is a Filament plugin that registers an analytics/settings page in the panel. 3.3.0 introduces Plugin::make()->navigationGroup(string|Closure), which overrides the default translated navigation group; the Closure variant allows per-panel or per-tenant resolution. It is opt-in and non-breaking — existing behavior (translated group) is preserved if unused. Hard prerequisite: filament-analytics-core 3.1. Action items: verify the core version in composer.lock, confirm the target panel's navigation groups, and add the config call during plugin registration. No migration work expected for current panels.

To product/design: We gain control over where analytics appears in the admin IA, so we can align it with our own taxonomy instead of shipping an unfamiliar group label. Recommend deciding the group name (and whether it should be dynamic per tenant) before rollout, and validating discoverability with a short internal usability pass.