Filament Metrics Posthog Laravel Package

Getting Started

The plugin adds an analytics settings page to a Filament panel. Registration happens in your panel provider, not in a service provider:

use Vendor\Analytics\AnalyticsPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugin(AnalyticsPlugin::make());
}

First use case: after installing, load /admin and confirm the settings page appears. Out of the box it sits in the package's own translated navigation group — you don't need to configure anything to get a working screen.

As of 3.1.0, you can move it into a group you already use:

AnalyticsPlugin::make()
    ->navigationGroup('Reports'),

Check composer show for filament-analytics-core — 3.1.0 requires core 3.1+. On older core the method will be ignored or error, so bump the constraint before adopting the new call.

Where to look first: the plugin class (src/*Plugin.php) for the fluent surface, and your panel's navigationGroups([...]) array, which is the source of truth for group names and order.

Implementation Patterns

Match an existing panel group. If you declared groups explicitly, the string you pass must match exactly:

$panel->navigationGroups([
    NavigationGroup::make('Reports'),
]);

$panel->plugin(
    AnalyticsPlugin::make()->navigationGroup('Reports')
);

Conditional grouping via Closure. Pass a closure when the group depends on runtime state (tenant, role, feature flag):

AnalyticsPlugin::make()
    ->navigationGroup(fn () => auth()->user()?->isAdmin()
        ? 'Reports'
        : 'Settings');

The closure is resolved lazily when Filament builds navigation, so it re-evaluates per request rather than being frozen at registration.

Returning null from the closure is the natural way to keep the default translated group for some users while overriding it for others.

Multi-panel setups. Configure the plugin per panel — call navigationGroup() inside each panel() method rather than sharing one plugin instance, so a "Reports" group in the admin panel doesn't leak into a customer-facing panel that has no such group.

Pair with sort/ordering. Grouping usually goes alongside ->navigationSort() (if exposed) so the settings page lands predictably within the group rather than at the end.

Gotchas and Tips

• Version coupling. The navigationGroup() method is new in 3.1.0 and depends on filament-analytics-core 3.1. Pin both, or a composer update on the core alone can leave you calling a method the installed code doesn't have.
• Silent fallback. Without the call the translated group is kept — good for backwards compatibility, but it means a typo'd group name in an array you did register won't throw. The page just quietly becomes its own group. Inspect the rendered sidebar, don't assume.
• String matching is exact, including case and translation. If your panel groups use __('nav.reports'), you must pass the same translated value — a raw 'Reports' will not match.
• Closures must be cheap. Navigation is built on most authenticated requests. Avoid queries inside the closure; read from the already-resolved user or cached flags.
• Clear caches after changing groups. Filament caches navigation/component metadata in optimized deployments:

  php artisan filament:optimize-clear
  

  A "my group change did nothing" report is usually this.
• Extension point. If you need more than grouping (custom heading, icon, ordering), look at the package's page class and Filament's navigationGroup/navigationLabel/navigationSort page hooks rather than post-processing the navigation in a view.
• Testing. Assert the group via Filament's navigation testing helpers, or simply getPages() on the panel — cheaper and less brittle than snapshotting rendered HTML.