Laravel Fathom Laravel Package

Product Decisions This Supports

• Analytics vendor selection (the real decision). The package itself is not the decision; it's the cost-of-switching lever. Because it reduces Laravel-side integration to a config file and a Blade component, the effort comparison between Fathom and GA4/Plausible/PostHog shifts from "a sprint" to "an afternoon." Frame the evaluation on price, compliance posture, and data ownership — not integration cost.
• Consent and compliance roadmap. Fathom is cookieless, which is the single highest-leverage property here: it can defer, shrink, or eliminate a consent-management build for analytics. That's a sprint of engineering and ongoing legal review you may not have to spend — quantify it before the build-vs-buy conversation.
• Build vs. buy for instrumentation. Reinforces "buy commodity, build differentiation." Don't build an event pipeline; pay for Fathom and keep the glue thin.
• Roadmap prioritization inputs. Server-side API access lets you pull site stats into an admin panel or internal dashboard without standing up a separate BI tool — enough to answer "is anyone using the feature we shipped?"
• Data quality as a product decision. Config-driven site IDs per environment mean staging and preview traffic don't pollute production metrics. Every downstream metric depends on getting this right once.
• Lock-in posture. The abstraction is thin by design — a public HTTP API and a script tag. That makes the exit cost roughly a day, which should lower the evidence bar for trying it.

When to Consider This Package

Adopt when:

• The application is Laravel and Fathom is already the chosen or shortlisted vendor.
• You want script-tag handling (custom domain, excluded paths, environment gating) expressed in config rather than hardcoded into layouts.
• You need both the client snippet and server-side API reads from one codebase.
• You're a small team with a privacy-sensitive audience and no appetite for a cookie banner.

Look elsewhere or validate first:

• If you only need the script tag, be honest that this is convenience, not capability — a six-line Blade partial gets you most of the way. Justify the dependency on config/env hygiene, not features.
• Not Laravel, or a multi-framework monorepo where a language-agnostic snippet is simpler.
• SPA/Inertia/Livewire route changes — verify whether Fathom's automatic pageview tracking covers your navigation model before committing.
• You need funnels, cohorts, retention, session replay, or experimentation. Fathom is aggregate web analytics; this is PostHog/Mixpanel/Amplitude territory. Don't let a cheap wrapper pull you into the wrong category.
• Self-hosting is a hard requirement — Plausible or Umami.
• Critical conversion events (signup, trial start, payment) need guaranteed delivery with retries and auditability. Treat Fathom as a reporting layer, keep the source of truth in your own queue or warehouse.
• Dependency provenance policy. Twenty stars and a single maintainer is a real signal. Mitigate by pinning the version and vendoring the source — the code surface is small enough that a fork is cheap. Confirm Laravel version support and release cadence before adoption, not after.

How to Pitch It (Stakeholders)

For executives: One day of integration to replace our analytics snippet with a privacy-first, cookieless product. That likely removes the need for a consent banner covering analytics — a measurable savings in engineering and legal review — and improves our GDPR posture without reducing what we can measure. If Fathom disappoints, removal costs about a day, so the downside is bounded.

For engineering: A small MIT-licensed wrapper: a service provider, a config file, an API facade, and a Blade component. Low surface area, no runtime magic, no database changes. We'll pin and vendor it rather than track upstream, given the maintainer footprint — a fork or inline replacement is a day's work if it's ever abandoned. The only diligence items are Laravel version compatibility and script behavior under our front-end routing model.