jeffersongoncalves/filament-gtag
A Filament plugin that adds Google Analytics gtag.js tracking to your admin panel, with configurable measurement IDs and simple setup for monitoring panel usage and visitor activity.
Architecture fit. The package is a thin Filament admin surface over three dependencies: filament-analytics-core (shared base plugin behaviour), spatie/laravel-settings for persistence, and jeffersongoncalves/laravel-gtag for the actual script injection. That is an appropriate decomposition for the problem — a settings page should not own rendering logic. The architectural value is not the analytics integration itself (a gtag snippet is a five-line Blade partial) but the relocation of the measurement ID from .env/config into a database-backed, admin-editable setting. That converts a deploy-gated change into a marketing-ops self-service action, which is the only defensible reason to adopt a package here.
Integration feasibility. Low effort for a team already on Filament. The plugin registers in a PanelProvider, requires the settings migrations to be published, and assumes a settings class is bound. The notable constraint is the transitive dependency chain: Filament version, filament-analytics-core (now floor-pinned at 3.1 by this release), spatie/laravel-settings version, and laravel-gtag v3 must all resolve together. The 1.3.0 release bumping laravel-gtag from ^2.0 to ^3.0 signalled that the underlying rendering contract is still moving, and 3.4.0 hard-requiring a specific filament-analytics-core minor confirms the coupling is tightening rather than settling. Pin deliberately, including the transitive core package.
Technical risk. Materially higher than the code volume suggests:
laravel-gtag major breaks rendering; a filament-analytics-core minor can now gate features (3.4.0's navigationGroup() silently no-ops without 3.1). All three are controlled by the same author with no deprecation policy visible. The feature-advertisement in the release note with an inline "(requires …)" caveat is itself a signal that the author treats cross-package version floors as release-note material rather than Composer-enforced constraints.Key questions. Does it support the Filament major we run? Does it support the filament-analytics-core version our other analytics plugins already pin — and if not, does the resolver downgrade us silently? Does the rendering path respect a consent gate, or can we intercept it? Is the settings read cached per-request, or does it hit the DB on every page render? Multi-panel and multi-tenant behaviour — one GA property per panel, or global; and does navigationGroup() accept a Closure for per-tenant resolution or only for lazy label evaluation? Does it emit the snippet server-side only, or does it also handle GTM containers? Are there tests, and what is the upgrade policy across Filament majors?
Stack fit. Clean for Laravel 10/11/12 + Filament 3/4 + spatie/laravel-settings. Teams not already on spatie/laravel-settings inherit an extra migration, cache driver dependency, and a settings-resolution concept to learn — that overhead likely exceeds the package's value for a single analytics ID. The 3.4.0 navigationGroup() addition is a genuine but small ergonomic win: it lets the settings page sit alongside other marketing/analytics pages instead of in the default translated group, which matters slightly more in a multi-panel install where ad-hoc groups become clutter. Do not treat it as a reason to upgrade on its own.
Migration path. Remove the hardcoded gtag snippet from the layout Blade, install laravel-gtag, publish and run the settings migrations, register the plugin on the target panel, then backfill the existing measurement ID through the admin UI. Keep the legacy snippet in place behind a feature flag until GA4 DebugView confirms exactly one tag is firing — double-firing is the most likely migration defect and it corrupts historical reporting rather than throwing an error. If adopting 3.4.0, add the navigationGroup() call in the same PanelProvider edit and verify the group renders — a no-op caused by a sub-3.1 core is invisible and easy to mistake for a broken closure.
Compatibility. Verify Composer constraints against our Filament, filament-analytics-core, and settings versions before committing. Run composer why-not for the core package specifically: if another analytics plugin in the panel already requires a different core minor, this release may create an unsolvable or silently downgraded resolution. Also audit CSP headers — a DB-driven script tag is easy to introduce and easy to forget when the script-src policy is next tightened.
Sequencing. (1) Spike in a staging branch, confirm tag fires and settings persist. (2) Resolve filament-analytics-core version constraints across all analytics plugins on the panel. (3) Add consent gating if the package does not provide it — treat this as a hard prerequisite, not a follow-up. (4) CSP allowlist for googletagmanager.com. (5) Cut over from the env-based ID with the old snippet disabled. (6) Hand the admin page to marketing with a one-page runbook including where the page now lives in navigation.
Maintenance. Budget for ownership we do not control. Realistic posture: track upstream releases, but assume we may need to fork or vendor the rendering component if the author stops. The dependency is small enough that a fork is a day of work — that is the mitigation, and it should be stated up front rather than discovered during an incident. Note that forking now means tracking three repos, not one; if we fork, fork the whole family or none of it.
Support. Community-only, no SLA, and a user base small enough that a filed issue may go unanswered for weeks. Internal documentation and a named owner matter more than usual here.
Scaling. Runtime cost is negligible — a cached settings read plus a script tag. Confirm spatie/laravel-settings caching is enabled so we are not adding a DB query to every page render; on a high-traffic marketing site that is the only scaling consideration and it is easily neutralised. The 3.4.0 navigation change is build-time only and has no runtime bearing.
Failure modes. Settings table absent after a deploy (migrations run out of order) → page errors or tag disappears silently. Stale settings cache → ID changes do not propagate. Missing or invalid measurement ID → zero data, no alert. CSP block → zero data, visible only in browser console. Duplicate tags from a leftover snippet → inflated sessions and broken attribution. Underspecced filament-analytics-core → navigationGroup() ignored, page lands in an unexpected group, and admins report the settings page as "missing" rather than "misfiled." Recommend a synthetic check asserting the tag renders with the expected ID on the production homepage.
Ramp-up. Roughly half a day for a Laravel developer familiar with Filament; the package itself is not the hard part. The real effort sits in dependency-resolution across the analytics package family, consent gating, CSP, and the verification step — plan for those explicitly, because they are the items most likely to be skipped and the ones that carry compliance and data-quality consequences.
How can I help you explore Laravel packages today?