Filament Gtag Laravel Package

Product Decisions This Supports

• Feature: self-service analytics configuration. The package puts a Google Analytics (gtag) settings screen inside the Filament admin panel, backed by spatie/laravel-settings. The product decision it unlocks is "should changing a tracking ID require a developer, a PR, a deploy, and a release window?" For most teams the answer is no — marketing should be able to swap a GA4 measurement ID on a Tuesday afternoon.
• Build vs. buy for a deliberately small surface area. This is not an analytics platform; it is a settings form plus a render hook. A competent Laravel dev reproduces it in roughly 1–2 days. The buy case is therefore timing and consistency, not capability: adopt it if you are already on Filament + spatie/laravel-settings and want the screen today; build or vendor it if you want to own the upgrade path.
• Roadmap sequencing. It is a cheap, high-visibility win for a "reduce marketing→engineering tickets" initiative. It slots naturally into an existing Filament admin epic and needs no new infrastructure — no queue workers, no external service, no schema migration beyond the settings table.
• Use cases where it actually moves the needle: agencies running many client Filament installs who need per-site GA IDs without code branches; SaaS products that want a different measurement property for staging vs. production, or per-tenant tracking; and internal admin panels where a non-technical owner manages tags.
• Admin-panel information architecture is now configurable (3.4.0). Plugin::make()->navigationGroup(string|Closure) lets the settings page join one of the panel's own navigation groups instead of the package's translated default group. This is a small but real product win: it removes one of the usual "third-party plugin clutters our nav" objections and lets you place analytics settings where admins already look — under Settings, Integrations, or Marketing, per panel. Use the Closure form when grouping varies per panel or tenant. If a coherent admin IA is part of your product quality bar, this materially lowers the cost of adoption.
• Multi-tenant / per-environment analytics is the interesting product question. Because the values live in spatie/laravel-settings rather than in config/, per-tenant or per-scope IDs are at least architecturally possible. Treat that as an evaluation item to verify, not a promised capability — the package docs do not scope this out.
• Explicitly out of scope for this decision: consent management (GDPR/ePrivacy/TCF), GTM container management, server-side tagging, ecommerce event mapping, and conversion schema design. If any of those are on the roadmap, this package is a fragment of the solution, not the solution — do not let adopting it create the impression that "analytics is handled."

When to Consider This Package

Adopt it (or vendor it) when all of the following hold:

• You are on Filament and already use spatie/laravel-settings; adding it is incremental, not a new paradigm.
• You need one GA4 measurement ID per install (or a small, well-defined set of scopes) and nothing more.
• The people editing the ID are trusted admins — the measurement ID is public by nature, so this is not a secrets-management feature.
• You accept that you are adopting a multi-package chain: this plugin, its jeffersongoncalves/laravel-gtag dependency that does the actual injection, and — as 3.4.0 makes explicit — filament-analytics-core ≥ 3.1 behind the newer features. Budget for tracking three version lines, not one. The navigationGroup() API is version-gated, so the triple is coupled: pinning the plugin's latest minor effectively pins the core package's minor too.
• You are comfortable pinning versions and, realistically, forking. At 5 stars, 0 dependents, and a single maintainer, this is an unproven dependency — the healthy posture is "vendor the code, keep the MIT license, own the maintenance."
• You care about admin UX consistency: as of 3.4.0 the page can live in your own navigation group, so you no longer trade panel IA for a free settings screen. That upgrade alone is a reasonable trigger to re-evaluate if you previously rejected it on polish grounds.

Look elsewhere (or build it) when:

• You need consent-aware firing. GA4 without Consent Mode is a legal exposure in the EU/UK. If your product needs a CMP integration, buy a package that owns that problem end-to-end.
• You need Google Tag Manager, not raw gtag — different product, different governance model, and a much better fit for marketing teams who change tags frequently.
• You need multi-property, server-side tagging, or ecommerce/event instrumentation. Those are design problems; a settings screen does not solve them.
• You are on a Filament major version the plugin has not caught up to, or you have a policy against single-maintainer dependencies in production. Filament's release cadence makes plugin lag a recurring tax — and the new filament-analytics-core ≥ 3.1 pin adds a second compatibility matrix to watch at every Filament bump.
• You need audit trails on who changed tracking config and when. Nothing here indicates that exists; if "who turned off analytics last quarter?" is a question you must answer, add logging or build the screen yourself.

Signal to weigh honestly: 3.4.0 is a small, additive, non-breaking configuration improvement — not a product pivot. There are no deprecations and no migration work, so the upgrade decision is cheap. Set against that, the release history is still dominated by dependency bumps, translation rollouts, changelog CI, and a sponsor link, and this release's headline feature is coupling to another package's minor version rather than new capability. The 17 locales remain a genuine nicety for international admin teams, but they do not offset the adoption risk. Score it as a convenience utility, not a platform bet.

How to Pitch It (Stakeholders)

To executives: "A small, MIT-licensed plugin that lets marketing change our Google Analytics ID from the admin panel instead of filing an engineering ticket. The latest release adds one useful thing: the settings screen can now sit in whichever admin menu section we choose, instead of a hard-coded one — so it fits our product rather than standing out as a third-party add-on. It removes a recurring low-value interrupt and costs us roughly a day to evaluate and integrate. It does not handle privacy consent or tag management, so it is one piece of the analytics picture, not the whole answer — we should not describe analytics as 'done' because of it."

To engineering: "It is a thin Filament settings page over spatie/laravel-settings, delegating injection to a companion laravel-gtag package, with 3.4.0 adding an opt-in navigationGroup(string|Closure) call that requires filament-analytics-core ≥ 3.1. Low code volume, low blast radius, permissive license, and this release is purely additive — no deprecations, no migration. The real cost remains ownership: one maintainer, negligible adoption, and a dependency chain that is now visibly three packages deep with a minor-version coupling between two of them, all of which will need attention at every Filament major. Recommendation — vendor the source into our codebase, keep the MIT attribution, and treat it as first-party code we control. That gives us the feature, including the new navigation-group placement, this sprint and removes the supply-chain question entirely. If we do install it live instead, pin the plugin and filament-analytics-core together."

Decision to record: approved as a reference implementation to be vendored, scoped to GA4 measurement-ID configuration only, now including navigationGroup() placement in the vendored surface; the pinning note is extended to filament-analytics-core ≥ 3.1; consent management and tag management remain open roadmap items.