Filament Mixpanel Laravel Package

Product Decisions This Supports

• Surfacing product usage where the team already works. This is a Filament panel plugin that puts analytics/settings into the admin panel your team uses daily — it supports the "instrument internal tooling, review adoption weekly" loop without standing up a separate BI tool.
• Build vs buy, resolved toward buy (small). The differentiator is the underlying filament-analytics-core package; this plugin is the panel integration and UI-config layer. You are buying integration work, not analytics IP — cheap to adopt, cheap to drop.
• Admin IA / settings consolidation. 3.3.0 adds Plugin::make()->navigationGroup(string|Closure), letting the settings page sit in your own navigation group instead of the plugin's translated default. This is adoption polish: fewer "where did that go?" moments, settings discoverable next to the rest of your panel config. Opt-in, default behavior unchanged, no migration.
• Not a roadmap driver. Nothing in this release changes capability, data model, or pricing. Treat it as maintenance-grade polish and keep roadmap decisions anchored to the core package's roadmap (note the hard coupling: this release requires filament-analytics-core 3.1+).

When to Consider This Package

Consider it when:

• You already run Filament v3+ and have at least one panel your team or customers use regularly — the value is zero if the panel isn't a daily destination.
• You need lightweight, in-context usage visibility (what's being clicked/visited) rather than warehouse-grade analytics.
• You're willing to track the filament-analytics-core version in lockstep — 3.3.0 explicitly requires core 3.1, so upgrades are coupled, and a lagging core blocks plugin upgrades.
• Your admin chrome is opinionated and branded — the new navigationGroup() setter (string or Closure, so you can resolve a translated/lazy group name) means the plugin no longer fights your navigation structure. Small, but it's the kind of friction that decides whether an internal tool gets used.
• You have a small team that will actually read the numbers; dashboards nobody opens are negative value.

Look elsewhere when:

• You need funnels, retention cohorts, revenue attribution, or SQL access — use a dedicated analytics/BI product.
• You need multiple non-Filament surfaces (marketing site, mobile app, API clients) in one view.
• You require a vendor SLA, SOC2-style assurances, or contractual support.
• You cannot absorb third-party dependency risk or a coordinated two-package upgrade cadence.
• Your panel is a single-admin back office where the sample size makes analytics noise.

How to Pitch It (Stakeholders)

Executives: A low-cost, low-risk addition that shows how our admin panel is actually used, inside the tool the team already opens every day. No new infrastructure, no new vendor contract. The 3.3.0 release is a config-level convenience — it lets us file the analytics settings under our own navigation group rather than the plugin's default — which is exactly the kind of small fit-and-finish that determines whether an internal tool gets adopted or ignored. Cost is hours, not weeks.

Engineering: Integration is a plugin registration on an existing Filament panel; 3.3.0 is additive and opt-in — Plugin::make()->navigationGroup(string|Closure) accepts a literal group name or a Closure for lazy/translated resolution. If you don't call it, you keep the current translated group, so there is no breaking change and no migration. The one real constraint to flag: this release pins us to filament-analytics-core 3.1+, so plan upgrades as a pair and watch the core's release notes before bumping.

Recommendation: Adopt for internal/admin-facing dashboards behind a feature flag; do not position it as customer-facing analytics, and do not let it become the source of truth for revenue or growth metrics. Re-evaluate if our reporting needs move beyond in-panel usage counts.