Filament Laravel Analytics Laravel Package

Technical Evaluation

Architecture fit. The package is a thin presentation layer: a Filament plugin that registers dashboard widgets and a page, backed entirely by spatie/laravel-analytics and, beneath that, the Google Analytics Data API (GA4). There is no data persistence, no proprietary query engine, and no custom auth model — it renders metrics the underlying Spatie package already knows how to fetch. Architecturally that is a good fit only if we are already a Filament shop and already treat Google Analytics as the source of truth for traffic. It composes into a panel via ->plugin(...), exposes navigation/label/page configuration, and supports the standard Filament customization patterns (publishable config and views). It is a convenience surface, not infrastructure, and should be evaluated on that basis.

Integration feasibility. Low-to-moderate engineering effort, but the bulk of the effort is not code. The real cost is Google-side provisioning: create a Cloud project, enable the Analytics Data API, generate a service-account JSON key, add the service-account email as a Viewer on the GA4 property, and capture the numeric GA4 property ID (not a legacy UA- ID). The code path is short — composer require, publish config, register the plugin in the panel provider — and the README/plugin class namespace changed shape across early releases, so pinning the exact version and reading its README matters. Verifying the pipe outside Filament (Analytics::fetchTotalVisitorsAndPageViews(...)) before debugging any UI is the single most useful feasibility step.

Technical risk. Elevated and concentrated in three areas. Bus factor: a single maintainer, ~6 stars, and no release since 2022-12-28. The last release (v1.1.0) added filters and consolidated multiple Blade partials into one file, which silently breaks any published view overrides — a concrete upgrade hazard. Dependency drift: the plugin transitively depends on spatie/laravel-analytics and a Filament major version; either can move underneath it with no corresponding release here, and Filament's plugin/registration ergonomics have evolved. Credential/API fragility: GA4 service-account permissions, API enablement, property ID type, and credential path resolution are the dominant production failure sources, and Filament's error surface hides the underlying Google client message. The package also has no native model for multi-tenant/per-customer property isolation, and it does not provide first-party event data (funnels, cohorts, retention).

Key questions.

• Which Filament major version and PHP version are we standardizing on, and does the package's composer.json constrain to it? Has anyone verified against our installed stack, not the README?
• Who owns the Google Cloud project, service-account key rotation, and Viewer access on the GA4 property — and is there a runbook?
• Is our property genuinely GA4 with a numeric ID, and what is its configured timezone relative to the app timezone?
• Single internal panel, or multi-panel/multi-tenant? If the latter, are we prepared to keep the property static per panel and accept the service account needs access to every property?
• What is our cache store on every web node, and is it shared/persistent?
• Are we willing to vendor or fork this if it goes unmaintained, and who signs off on that contingency?

Integration Approach

Stack fit. Appropriate if and only if the target is a Laravel application with a Filament v3-era admin panel and Google Analytics is an accepted source of truth. If we are not on Filament, or need framework-agnostic reporting, or need first-party event analytics, this is the wrong tool — stop here. The intended first use case is a stakeholder-facing traffic page (visitors/page views over 30 days plus top pages), which is realistically ~90% of the value.

Migration path. Treat this as an additive, panel-scoped pilot rather than a replacement for anything. Register the plugin only on the panel that should see analytics; keep the property ID in config/env rather than making it dynamic per tenant. Gate registration to non-local environments (calls in local either fail or burn quota) and put the page behind a policy or gate so it is not visible to every panel user by default. For anything bespoke — funnels, per-post views, conversion widgets — write our own Filament widget calling spatie/laravel-analytics directly instead of forking vendor views. Mixing the canned page with custom widgets is the supported, low-regret pattern.

Compatibility. Verify before adoption: Filament major version, PHP version, and the resolved spatie/laravel-analytics version (require it explicitly if the transitive resolution looks pinned oddly). Use storage_path(...) for the credentials JSON — relative paths break under queue workers, Octane, or a different deploy root. Set ANALYTICS_CACHE_STORE=array in tests, redis/database in production, and never file on a multi-node deploy. Pin the package version in composer.json and re-check any published views on every bump, because v1.1.0's single-Blade consolidation is exactly the kind of change that silently orphans overrides.

Sequencing.

1. Provision Google side: Cloud project, enable Analytics Data API, service-account key, Viewer on the GA4 property, record the numeric property ID. Confirm the property timezone deliberately.
2. Prove the pipe outside Filament with a direct Analytics::fetch... call in tinker or a test; log the raw exception.
3. Publish config, point at the property and credentials path, set a meaningful cache lifetime (a day or so).
4. Register the plugin on a single internal panel, gated by environment and authorization.
5. Configure a shared cache store before exposing filters — each filter state is a distinct query, so cache keys fan out.
6. Set UI copy expectations for GA4's ~24–48h data freshness lag; do not build a "today so far" view.
7. Add custom widgets only where the canned page falls short.
8. Document the runbook: credential rotation, quota triage, timezone, and the upgrade/view-override checklist.

Operational Impact

Maintenance. This is the dominant operational risk. Single maintainer, thin release cadence, no release since December 2022, and a small star count means we should assume we may end up owning the code. Budget for a vendored or forked copy as a contingency, pin the version, and read the changelog before every minor bump. Any published view overrides become a per-upgrade liability — prefer custom widgets over editing vendor Blade.

Support. No SLA, no paid support, community-only. Internally we need a named owner for the Google Cloud project, service-account key rotation, and GA4 property permissions, because the most common incidents are credential/permission issues rather than code defects. Filament's error surface hides the underlying Google client message, so the support runbook must include "reproduce outside Filament and log the exception."

Scaling. The scaling constraint is the GA4 API quota, not our infrastructure. Filters multiply distinct queries, so a shared, persistent cache store is the cheapest insurance against quota errors and the number-one production incident with this stack. Keep cache_lifetime_in_minutes meaningful and ensure the store is shared across web nodes. Data freshness lag (roughly 24–48h for standard GA4 properties) is a permanent characteristic — set expectations in the UI rather than fighting it. Multi-tenant/per-customer isolation is not natively modeled; if that becomes a requirement, it is a design change, not a config change.

Failure modes. Watch for: 403 User does not have sufficient permissions for this property (service-account email not added as Viewer, or a UA ID used instead of a numeric GA4 ID); 403 PERMISSION_DENIED with SERVICE_DISABLED (Analytics Data API not enabled in the Cloud project); credential path breakage under Octane/queue/deploy roots; silent loss of published view overrides after upgrade; phantom "my change didn't apply" bugs from cached responses in non-production; app-vs-property timezone drift producing totals that disagree with the GA UI; quota exhaustion under filter fan-out; and the absence of a "today so far" view being misread as a bug.

Ramp-up. Low for a developer comfortable with Filament — registration is a few lines and the config is publishable. The real ramp-up cost is Google-side: service accounts, API enablement, property permissions, and the numeric GA4 ID. Non-technical stakeholders need a short orientation on what the page cannot answer (funnels, retention, cohorts, first-party events) and why intra-day numbers look stale. Recommended posture: pilot in an internal-only panel, pin the version, gate by environment and authorization, keep a fork contingency, and position the package explicitly as a convenience reporting layer — not a system of record.