Laravel Fathom Laravel Package

Product Decisions This Supports

• Build vs. buy (micro-scale): This package replaces roughly one Blade partial (a <script> tag plus a config value) with a Composer dependency. The honest framing is not "buy vs. build" but "vendor vs. inline." Decide whether one line of Blade in your layout is worth an external package boundary at all.
• Analytics vendor selection: It's a concrete commitment to Fathom as your web analytics provider. If Fathom is already chosen for privacy/GDPR reasons (cookieless, no consent banner required in most jurisdictions), this package is the last-mile wiring — not a decision driver. If Fathom is not yet chosen, this package should not be part of the evaluation; it carries no vendor-lock mitigation.
• Security posture / CSP compliance (new in 4.1.0): Rendered <script> tags now inherit Laravel's Vite CSP nonce when the app sets one, so nonce-based script-src policies work without 'unsafe-inline'. This converts a previously real objection ("our CSP forbids inline scripts") into a non-issue for the package path — but it does not change the underlying decision, since a hand-inlined snippet can equally call the same nonce helper. Treat it as removing a blocker, not creating a reason to adopt.
• Multi-site / multi-tenant instrumentation: The only genuinely defensible product use case. If you run several Laravel apps or tenant-specific domains, a config-driven, environment-aware injection point for the Fathom site ID is meaningfully better than copy-pasting snippets across layouts and forgetting one.
• Environment gating in the roadmap: Prevents dev/staging traffic polluting production analytics. Worth a line in your definition-of-done for analytics work, but it's a @production directive away.
• Feature-level tracking (out of scope): This package covers page views only. 4.1.0 adds no event, goal, funnel, or attribution capability. If the roadmap includes any of those, that work stays custom regardless of whether you adopt this. Do not count this package toward "analytics instrumentation" as an epic — it closes a checkbox, not a capability.
• Roadmap risk input: Still 2 stars, 0 dependents, single maintainer. The 4.1.0 release is mild evidence of an attentive maintainer (it's a security-hygiene fix, not a feature grab), but it does not change the classification: treat this as a snapshot dependency you are prepared to vendor or replace, not a strategic layer.

When to Consider This Package

Reasonable to adopt when:

• You have already committed to Fathom and need a Blade-only, server-rendered site instrumented in under 10 minutes.
• You run multiple Laravel properties and want one config-driven injection pattern instead of N copy-pasted snippets.
• You operate a strict, nonce-based CSP (e.g. laravel-security-headers or equivalent) and want the nonce handled for you rather than re-implemented in every layout. As of 4.1.0 this is no longer a reason to exclude the package — though it is also not a reason to prefer it over a one-line inline tag that calls the same nonce helper.
• Your team enforces a "config lives in config/, not in templates" convention and the snippet would otherwise be hardcoded.
• You accept the maintenance risk and can fork or inline the ~1 file if the maintainer disappears.

Look elsewhere (or skip entirely) when:

• You can paste the snippet yourself. For a single-site app, the dependency adds supply-chain surface and a version-constraint burden for functionality you can reproduce in one line. Default recommendation: inline it. (Caveat: if you inline, replicate the nonce attribute yourself — 4.1.0 sets the bar you should match.)
• Your frontend is Inertia, Livewire SPA-navigation, or a separate JS app. Client-side route changes won't fire page views through a Blade script tag alone; you need router hooks in your JS layer, which this package does not provide. Nonce propagation to dynamically injected scripts is likewise your problem.
• You need consent management integration (OneTrust, Cookiebot, custom CMP) — you need script-load orchestration, not a template include. Note that a CSP nonce and a consent decision are different gates; passing the first does not satisfy the second.
• You need server-side or event tracking (goals, conversions, outbound links, form submissions, e-commerce). Fathom's event API is a different integration, unchanged by this release.
• You need first-party proxying / ad-blocker resilience via a custom domain — that's a Fathom account + DNS + config change, with no package help here.
• Your procurement process requires SCA, active maintenance SLAs, or a security review trail. Better CSP behavior slightly improves the security story, but zero dependents and 2 stars will not clear that bar; expect to justify a vendored fork.

How to Pitch It (Stakeholders)

To executives (30 seconds): Fathom is our privacy-friendly, cookieless analytics option — no consent banner overhead, GDPR-simpler than GA4. This package is a small convenience wrapper that drops Fathom's tracking tag into Laravel templates via configuration rather than hardcoded snippets. The latest release (4.1.0) makes it compatible with our strict Content-Security-Policy, which is a nice hygiene win but doesn't change the shape of the decision. It is not a strategic dependency: it saves maybe an hour of setup and enforces consistency across our sites. Cost is the same as Fathom's subscription; the package itself is MIT and free. Recommendation: use Fathom if analytics vendor selection is the decision; treat this wrapper as optional plumbing we can replace in an afternoon if it goes stale.

To engineering: It's a Blade directive / config-backed include for the Fathom script. Release 4.1.0 adds CSP nonce support — rendered <script> tags pick up Laravel's Vite nonce, so nonce-based script-src works without 'unsafe-inline'. That's a legitimate reason the package cleared a bar it previously failed; credit it, but weigh it against the fact that the same one-line inline tag can call the nonce helper directly. Honest assessment otherwise unchanged: low community signal (2 stars, 0 dependents, single maintainer), though the 4.1.0 release is a mildly positive maintenance signal. Practical guidance: adopt only if we're multi-site or want a single instrumentation point; otherwise inline the snippet in our layout, nonce included, and skip the dependency. If we do adopt, pin the version, keep usage isolated to one layout partial, and be ready to fork — it's small enough that a fork is a non-event. Note limitations up front: page views only, no SPA route handling, no consent-manager integration, no event tracking, no nonce propagation into JS-injected scripts. Those remain our own work either way.

One-line decision ask: "Approve Fathom as the analytics vendor. Approve this package only as optional convenience — now CSP-compatible, still not a dependency we build a roadmap on."