Cairn Laravel Package

Product Decisions This Supports

• Prioritizing performance work with evidence. The new Slowest Routes panel separates server response time from Core Web Vitals, so product and engineering can decide whether a slow experience is an infrastructure problem, a frontend problem, or both. The minimum-five-pageview threshold keeps low-traffic noise out of prioritization.
• Fixing broken journeys and dead links. Broken Pages lists 4xx/5xx responses by status, URL, and referrer. This supports roadmap decisions around redirects, stale links, partner content, and bug triage, because a 404 with a referrer points to a dead link someone else hosts, while a 5xx identifies a page with a defect.
• Measuring unmatched URLs without corrupting traffic metrics. The new not_found entry type records 404s for URLs with no route, which were previously invisible, without starting sessions or counting visitors. This helps detect link rot, mistyped URLs, and scanner traffic without inflating pageviews or visitor figures.
• Adding error-rate reporting to product health. Metric::Errors, Dimension::Status, and Dimension::ErrorPage make errors a first-class dimension and metric. PMs can track error volume by route and page, set expectations for reliability, and compare error trends against releases or campaigns.
• Embedding analytics in internal tools and customer-facing reports. The JSON API fixes make grouped reports rank correctly before limits, respect dimension filters consistently, return the actual interval used, and return structured error-page keys. This supports dashboards, scheduled reports, and lightweight integrations rather than relying only on the built-in UI.
• Controlling report noise and relevance. Report::minimum() lets teams exclude rows below a metric floor before ordering and limiting, which is useful for ranked tables, “top N” summaries, and executive dashboards where sparse rows add noise.
• Build-vs-buy for Laravel analytics. Cairn remains attractive when the product needs first-party, Laravel-native analytics with privacy controls and operational reporting. This release strengthens the case for buying/using an existing package rather than building route performance, error tracking, and API reporting from scratch.

When to Consider This Package

Consider Cairn when:

• The product is a Laravel application and the team wants analytics integrated at the framework level rather than through a separate JavaScript-heavy analytics platform.
• The primary questions are operational and product-health oriented: pageviews, routes, response times, errors, broken pages, referrers, and basic dimensions such as country, channel, language, and screen class.
• Privacy and consent handling matter. The release reinforces existing privacy gates for Do Not Track, Global Privacy Control, opt-out, consent, bots, sampling, and ignored paths, and it scrubs unmatched URLs more aggressively because no route validates them.
• The team wants self-managed or package-managed analytics without introducing a large external vendor dependency.
• There is a need for a JSON API that can power internal dashboards or lightweight reporting workflows.
• The team can absorb small upgrade steps: backfilling rollups for Broken Pages and per-route errors, adding new widgets to a published config, clearing config:cache, and auditing API clients for parameters that are now rejected with 422.

Look elsewhere when:

• The product needs full behavioral analytics such as funnels, retention, cohorts, experimentation, attribution modeling, session replay, or advanced segmentation.
• The organization requires a warehouse-native analytics stack, real-time streaming, or cross-product identity resolution.
• Analytics must span multiple non-Laravel applications or heterogeneous services.
• The team cannot tolerate API contract tightening. This release makes unknown parameters and unrecognized values return 422 instead of being silently ignored, which is better behavior but can break careless clients.
• The team expects the dashboard default to remain “last 30 days.” The default is now Today, which is better for daily operational monitoring but may surprise users who rely on bookmarks without an explicit range.

How to Pitch It (Stakeholders)

For executives: Cairn v1.3.0 turns existing Laravel telemetry into clearer operational insight. We can now see which routes are slow on the server, which pages are failing, and which broken links are driving 404s, without counting those failures as normal traffic. The release also hardens the reporting API so dashboards and integrations get ranked, filtered, and validated results instead of silently incorrect answers. It is a low-migration upgrade with targeted backfill steps, and it reduces the case for building custom analytics plumbing.

For engineering: The package already recorded response times and status codes; this release exposes them through Slowest Routes and Broken Pages, adds not_found tracking for unrouted 404s, and introduces Metric::Errors plus Status and ErrorPage dimensions. Privacy controls and URL scrubbing are applied consistently, including stronger scrubbing for unmatched paths. The API now ranks grouped rows before limiting, honors dimension filters, returns the actual interval, and rejects unreadable parameters with 422. Upgrade work is mainly a rollup backfill for historical routed errors, adding the new widgets if the config publishes a widget list, clearing config cache, and checking API clients for unknown parameters.