Filament Page Visits Laravel Package

Product Decisions This Supports

• Build vs. buy on observability. The new ResponseTimeTrendChart widget turns page-visit data we already collect into p50 / p95 / p99 response-time trends over 90 days. For a Laravel app with modest traffic, that is often "good enough" telemetry to defer or avoid an APM contract (New Relic, Datadog, Scout). A PM can use this to justify a "no new vendor spend this quarter" decision, or to scope a smaller APM tier.
• Roadmap prioritization and regression triage. Percentile trends let us correlate slow releases/features with measurable user impact and argue for investment in caching, query tuning, or infra work with numbers instead of anecdotes.
• SLO and SLA commitments. p95/p99 are the vocabulary of performance commitments. This supports defining internal SLOs, deciding which endpoints are customer-critical, and answering "are we fast enough to sell into this segment?"
• Dashboard scope and audience segmentation. Widgets are config-driven (metrics_page.widgets.response_time_trend), so we can decide per audience — engineering sees latency trends, execs see a summary — without forking the codebase.
• International expansion. Translations across all 19 locales reduce the cost of shipping the admin/analytics surface to new markets; localization stops being a blocking workstream for ops-facing tooling.
• Safe incremental rollout as a product property. The widget auto-hides when response_time_stats is absent. That means we can ship the dashboard upgrade and enable the performance narrative later, decoupled from the dependency migration — a sequencing decision, not an engineering blocker.

When to Consider This Package

Consider it when:

• You already run jeffersongoncalves/laravel-page-visits (or are willing to) and want its data surfaced in an admin/metrics page rather than building dashboards yourself.
• You are on Laravel with an existing panel/admin UI and want a low-effort, first-party analytics surface for an internal audience.
• You need a multi-locale admin experience out of the box (19 locales) with no extra i18n effort.
• Your performance questions are "how are we trending?" rather than "which span in this distributed trace caused the slowdown?" — i.e., aggregate latency trends are sufficient.

Look elsewhere when:

• You need distributed tracing, error tracking, log correlation, high-cardinality breakdowns, alerting/paging, or real-time streaming — this is a trend chart, not an observability platform.
• You require vendor SLAs, support contracts, or audited data retention beyond what the local aggregation/pruning job keeps.
• Your stack is not Laravel/PHP, or you have no admin panel to host the widget.
• You cannot run scheduled aggregation (page-visits:aggregate-and-prune); without it the chart has no data to show.
• Traffic volume or compliance constraints make app-local analytics storage inappropriate.

How to Pitch It (Stakeholders)

For executives: This is a small, additive release that gives us performance visibility from data we already collect — no new vendor, no new contract. It lets us talk about application speed in the same percentiles customers and procurement teams ask about (p95/p99), and it arrives translated for all 19 of our locales, so it doesn't add a localization backlog item. Cost is effectively an engineering afternoon, and the feature stays dark until we choose to turn it on.

For engineering: Purely additive minor release (3.2.0) — no breaking changes, no deprecations. One new widget, ResponseTimeTrendChart, backed by the response_time_stats column introduced in laravel-page-visits 1.3.0, and disabled via metrics_page.widgets.response_time_trend if we want it off. It self-disables when the column is missing, so upgrading this package alone is zero-risk. To light it up, sequence the work: bump laravel-page-visits, publish the page-visits-migrations tag, migrate, and confirm page-visits:aggregate-and-prune is scheduled — data appears only after the first aggregation run. Recommend shipping the upgrade now and enabling the widget once the aggregation job has produced a few days of history.