Analytics Google Filament Laravel Package

Product Decisions This Supports

• Admin-surface consolidation vs. context switching. The core decision this enables is whether a PM keeps operators/analysts bouncing to the GA4 console or surfaces a read-only traffic summary inside the tool they already live in (the Filament admin panel). This package is a candidate answer to "how cheaply can we get a GA tile into our existing back office?"
• Build vs. buy for a presentation layer only. This is not an analytics engine — it's a Filament adapter. It informs the decision "do we spend engineering days wiring GA4 API + chart components ourselves, or adopt an adapter?" The honest comparison is a few days of internal work against the cost of owning a near-zero-adoption dependency (see below).
• Internal-tooling roadmap sequencing. Useful as a low-effort, low-blast-radius item to slot into an admin-panel iteration when the team has spare capacity, rather than a headline feature. Good candidate for a spike, not a committed roadmap line.
• Ecosystem lock-in assessment. Because it belongs to a named module suite (liberusoftware/module-*), adopting it is really a decision about standardizing on that suite. That's a platform-architecture decision worth making explicitly, not by accident via one widget.
• Metrics-ownership decisions. Whether product metrics belong in the admin panel (engineer/ops-visible, low ceremony) or in a BI tool (governed, historical, shareable). If the answer is BI, this package is out of scope entirely.

When to Consider This Package

Consider it only when all of the following hold:

• You are already running Filament and already committed to (or actively evaluating) the liberusoftware module suite — this is an adapter, so the value is composition, not standalone function.
• The audience is internal and authenticated: ops, support, or engineering checking traffic at a glance. Not customer-facing, not a reporting surface of record.
• You need read-only, low-fidelity GA4 metrics (sessions, users, page views, top pages) and nothing requiring transformation, joins, or historical retention.
• You can treat it as vendored/forkable code — you're willing to read the source, pin a commit, and accept maintenance yourself. With 0 stars, 0 dependents, and a single publisher, that is the realistic operating model.
• You can resolve the license question before shipping. NOASSERTION means GitHub could not identify a recognized license. For a commercial product this is a blocking legal review item, not a footnote.

Look elsewhere — or build the widget in-house — when:

• License clarity is non-negotiable. NOASSERTION plus zero dependents is a genuine legal/procurement risk. Default position: do not ship in a commercial or client-delivered product without written clarification from the publisher.
• You need support, SLAs, or a security-response path. There is no community, no dependents, and no evidence of a maintainer team. A single-maintainer package in the auth-adjacent admin panel is a supply-chain consideration, not just a quality one.
• The release metadata doesn't reconcile. The listed last release (2026-10-27) is in the future relative to normal package-consumption assumptions. Treat that as a signal to verify the registry, tags, and changelog by hand before trusting the version you'd pin.
• You need multi-source analytics (GA4 + Plausible + Matomo + product events) or any analytics beyond Google. This is single-vendor by construction.
• You need metrics to be a system of record. Anything audited, billed against, or shared externally belongs in a governed BI layer with defined semantics, not a thin presentation adapter.
• You're not on Filament, or you're on a Filament major version the package hasn't declared support for. Compatibility surface is unverified at this adoption level.

How to Pitch It (Stakeholders)

One line for executives: A small, free adapter that can put a Google Analytics summary inside our existing admin panel — worth a short, time-boxed evaluation, but not something to build a reporting strategy on.

For engineering: This is a Filament presentation adapter over Google Analytics, part of the liberusoftware module family. Scope is narrow — it renders GA data in the admin panel; it does not collect, model, or retain analytics data. It carries no meaningful adoption signal (0 stars, 0 dependents) and an unresolved license (NOASSERTION), so the proposal is a two-day spike on a branch, evaluating three things: (1) does it install and render cleanly against our Filament version, (2) what does it actually depend on and how much of it would we end up rewriting, (3) can we get license clarification. If any of the three disappoints, we write the widget ourselves — the surface area is small enough that "build" is a credible fallback, which is precisely what keeps this a low-risk decision.

Risk framing for the room: The cost is near zero and the reversibility is high, so the downside is contained to evaluation time. The upside is a saved sprint of dashboard plumbing. What we should not do is let one convenient widget quietly make a platform decision — if we adopt it, we adopt it as vendored code with a named internal owner, and we resolve the license before anything reaches a client environment.