Laravel Client Laravel Package

Product Decisions This Supports

• Static caching strategy ("full measure" vs "half measure"). The headline decision this release unlocks: teams can adopt full-page static caching (Statamic full measure, nginx/Varnish, Cloudflare "Cache Everything") — the biggest lever on TTFB and origin cost — without accepting a hole in the analytics data. Previously that trade-off was explicit: faster pages, zero recorded visits. That trade-off is now a config flag, so the performance roadmap no longer collides with the reporting roadmap.
• Analytics build vs buy vs bolt-on. This is a bolt-on: a Laravel middleware plus an optional pixel endpoint that forwards to a hosted API. The PM question is whether the remaining gap (client-side interactions, SPA route changes, external referrer capture) justifies migrating to a JavaScript-first product — this release does not close that gap, it just makes the existing server-side model survive caching.
• Attribution parity across delivery modes. With the beacon enabled, entry page and all utm_* parameters are derived server-side from the Referer of the pixel request, so campaign reporting stays consistent whether a page was served from cache or from PHP. Without it, cached traffic contributes nothing to acquisition reporting — a silent skew that misleads channel-level decisions.
• Privacy and consent posture. No JavaScript required, no cookies mentioned, visitor hashing and bot filtering applied uniformly to beacon traffic. Keeps you in a lower-friction consent position than a client-side analytics tag, which matters if you sell into the EU or to privacy-sensitive customers.
• Measurement integrity as a product requirement. Foreign-domain referers are dropped (mirrored/scraped copies can't inflate numbers), and tracking codes are restricted to scalars so malformed input like ?utm_source[]=x can't poison the pipeline. This is the kind of thing you normally only learn about after a board deck shows a fake traffic spike.
• Scoping the rollout. Beacon is off by default and inert without the config key, so this is a per-site, per-environment decision (e.g. enable on CDN-fronted marketing sites, skip on apps where PHP already runs). No forced migration.

When to Consider This Package

Adopt or keep it when:

• You are on Laravel or Statamic and want server-side, no-JS pageview analytics that you control at the middleware layer rather than via a vendor snippet.
• Your pages are, or are about to be, served from a cache that bypasses PHP — this is the specific case v5.1.0 exists to solve. Note the release's own guidance: if PHP still runs on cached pages (Statamic "half measure"), you do not need the beacon, and staying fully server-side is the better trade-off.
• You need entry-page and UTM attribution to survive caching, and can tolerate external referrer being the one value that still requires JavaScript.
• You want low integration surface: one config block, one layout snippet, and a default-off posture that doesn't disturb existing installs.

Look elsewhere, or at least de-scope, when:

• You need client-side event tracking — clicks, scroll depth, form abandonment, SPA route changes, e-commerce funnels. The beacon is a pageview pixel, not an event pipeline.
• You serve a non-Laravel stack or a mostly mobile-app audience where a server-rendered layout doesn't exist.
• You enforce a strict Referrer-Policy (the release explicitly flags caveats here) — the beacon degrades, and you may end up with pageviews but no attribution.
• Your audience is ad-blocker-heavy: the docs warn that paths containing track, stats, analytics, beacon, collect or pixel are blocked by common lists. You can pick a neutral path, but you cannot guarantee delivery.
• You depend on real-time dashboards, session replay, or audience segmentation — out of scope by design.

One adoption gate worth putting in the ticket: this is a soft breaking change for extenders. CheckTracking::getPage() and CheckTracking::doTracking() gained an optional parameter, and any subclass overriding them will fatal on an incompatible declaration. If your codebase has custom middleware extending this, budget a signature update alongside the version bump.

How to Pitch It (Stakeholders)

To executives: We can make the site significantly faster by serving pages from cache, and still count every visit. Until now, any page served from a static cache was invisible to our analytics — we were effectively choosing between speed and knowing our traffic. This release removes that choice for the cost of one config flag and a small snippet. It also keeps our analytics first-party and JavaScript-light, which is cheaper to defend under privacy review than a marketing tag. No new vendor, no new contract.

To engineering: Upgrade is low-risk. The beacon is off by default; installs with an older published config register no new route and behave identically. Enabling it adds one GET endpoint that runs through the existing middleware stack, so bot filtering, visitor hashing and deduplication are unchanged — a cache miss plus its beacon counts as one visit, not two. Two things to get right: choose a beacon path that doesn't look like an analytics endpoint and doesn't carry a file extension (CDNs will cache it before it reaches the app), and if anything in our codebase subclasses CheckTracking, update the getPage()/doTracking() signatures.

To the product/analytics owner: Numbers should stop under-reporting on cached pages. Watch for two known boundaries in the first weeks: external referrer still needs JavaScript, and a strict Referrer-Policy will cost us attribution. Verify campaign reporting against source-of-truth for one cycle before we make any decisions off the new data.

Bottom line: ship it as an opt-in for CDN-fronted, PHP-bypassing sites; leave it off where PHP still runs. Re-evaluate a JavaScript-first analytics product only if client-side interaction data becomes a real requirement.