Filament Fathom Dashboard Widget Laravel Package

Product Decisions This Supports

• Surfacing traffic KPIs where the team already works. The widget drops Fathom Analytics stats (visitors, pageviews, top pages/referrers, live counts) into a Filament dashboard, so product, marketing, and ops don't need a separate analytics login or a hand-rolled reporting pipeline to answer "is anyone using the thing we shipped?"
• Build vs. buy, resolved on the buy side. The alternative is a bespoke integration: Fathom API client, caching layer, chart rendering, auth, and ongoing maintenance. For a widget-scale need, that's weeks of engineering to reach parity with a Composer install. Reserve build effort for metrics Fathom's aggregate API can't express.
• Privacy-first analytics posture. Fathom is cookieless and GDPR-friendly. Choosing this package is an implicit endorsement of that vendor choice — it makes the compliance-friendly stack the convenient one, which matters more than any policy document for adoption.
• Roadmap and prioritization inputs. Date-range and site-level traffic views feed content/landing-page iteration, launch retrospection, and "did the campaign do anything?" questions. Useful for deciding what to double down on; explicitly not a substitute for funnel, cohort, or attribution tooling.
• Panel consolidation. Each analytics surface pulled into the admin panel is one fewer tab, one fewer credential to distribute, and one fewer place access needs auditing.
• Agency/portfolio use cases. Multi-site setups (client sites, docs vs. marketing vs. app) map naturally onto widget-per-site configurations.

When to Consider This Package

Adopt when most of these hold:

• You're already running Filament (v3+) on Laravel and are comfortable registering a panel widget — this is not a standalone dashboard library.
• You already pay for (or self-host) Fathom and can issue an API key; the widget is worthless without an account, and there's no offline/demo data path.
• Your need is at-a-glance, aggregate metrics. Fathom's API exposes totals and breakdowns, not user-level journeys.
• You want one or two dashboards for internal stakeholders, not a customer-facing analytics product.
• You can tolerate early-stage package risk: this is the 1.0.0 release, the changelog is a bare commit link, and the project is a single-maintainer effort with limited public adoption signal. Pin the version and read the source before shipping.

Look elsewhere when:

• You're on GA4, Plausible, Umami, Matomo, or PostHog — use the provider-specific package or write a thin adapter; don't fork this one.
• You need deep reporting: funnels, retention cohorts, revenue attribution, exports, scheduled reports. Fathom's API won't give it to you and neither will the widget.
• You need per-tenant keys, row-level access control, or role-scoped metric visibility. Treat multi-tenancy as a custom build until the package documents support for it.
• You require vendor SLA, security review artifacts, or guaranteed maintenance — 1.0.0 with no substantive release notes doesn't provide those signals.
• You're not on Filament, or you need these charts in a customer-facing Blade/Livewire/Inertia view.

How to Pitch It (Stakeholders)

For executives: A small, low-cost integration that puts our core traffic numbers inside the admin panel the team already uses daily. It leans on Fathom, our privacy-friendly analytics provider, so we get visibility without cookie banners or a new data-processing agreement. Cost is a few hours of engineering plus the Fathom subscription we already carry; the payoff is faster, better-informed content and launch decisions without adding another tool to the stack.

For engineering: One Composer dependency and a standard Filament widget registration — no schema changes, no migrations, no new services. Configuration is an API token and a site ID, ideally sourced from env/secret storage. The real caveats are maturity and bus factor: this just hit 1.0.0 with a minimal changelog, so pin the exact version, wrap the data fetch in a small cached service class, and keep the widget behind a feature flag. That gives us a clean seam to swap providers or replace it with an in-house widget if the package stalls, without touching the rest of the panel.

Recommendation: Approve as a scoped, reversible experiment — one dashboard, one site, version-pinned. Revisit at the next release or in one quarter, whichever comes first, and only expand to multi-site or multi-tenant use if upstream shows sustained maintenance.