Laravel Page Visits Laravel Package

Product Decisions This Supports

• Prioritising performance work: 1.3.0 turns this from a traffic-counter into a lightweight performance signal. Daily count / avg / min / max / p50 / p95 / p99 (ms) on page_visit_daily_stats lets you answer "is the product getting slower?" and "which days did we breach our latency target?" without standing up APM.
• Build vs. buy for observability: tail latencies (p95/p99) are the numbers that justify or retire a RUM/APM contract (Datadog, New Relic, Sentry Performance). If server-side daily percentiles answer the question you actually ask, you can defer or downgrade that spend; if you need per-route, per-segment, or real-user browser metrics, this package won't get you there.
• Roadmap sequencing and release retro: correlate a latency regression with the day a release shipped. avg vs. p95 divergence on a given day is a cheap, credible "something changed" flag for a postmortem or a rollback decision.
• SLO / SLA definition: p95 and p99 give you the vocabulary to state an internal target ("p95 under 400ms") in a form engineering already tracks, and to check it against history rather than anecdote.
• Sales and support conversations: when an enterprise prospect or a complaining customer asks about reliability, daily percentile history is defensible evidence rather than a promise.
• Deliberately not supported: real-time alerting, per-page or per-tenant latency breakdowns, and browser-side (Core Web Vitals) measurement. Don't let this release be sold internally as an APM replacement.

When to Consider This Package

Adopt when:

• You're on Laravel, already want first-party page-visit analytics, and would rather keep that data in your own database than ship it to a third party (privacy/GDPR posture, data residency).
• You need trend-level performance visibility — daily percentiles, flat memory on high-traffic days thanks to SQL-side aggregation — not per-request tracing.
• You're willing to own the upgrade mechanics: 1.3.0 requires publishing the new migration and running php artisan migrate. No breaking changes from 1.2.x, but it is a deploy-coupled schema change, so schedule it rather than letting it ride a routine release.
• You can live with daily granularity and a single aggregate row per day.

Look elsewhere when:

• You need sub-daily alerting, per-route/per-tenant segmentation, or raw distributions you can re-slice later — daily pre-aggregated percentiles are lossy by design and cannot be recomputed into new dimensions.
• You need real user monitoring (Core Web Vitals, browser render timing). This is server-side response time, a different and narrower question.
• Latency coverage matters: response_time_stats is null when no visit was timed, so the value of this feature is entirely dependent on how consistently your visit instrumentation records timings. Validate coverage on a sample of days before anyone builds a dashboard on it.
• You already have APM with alerting and dashboards — this becomes a redundant second source of truth with weaker resolution.

Open questions to resolve before committing: is p95 over the day's full visit population or sampled? What's the retention story once page-visits:aggregate-and-prune prunes raw visits? And what's the query cost of the dashboard reading this column on your largest table?

How to Pitch It (Stakeholders)

To executives: the analytics package we already run now keeps daily latency percentiles — average, p95, p99 — alongside traffic, in our own database, at no additional vendor cost and with flat memory on peak days. It gives us a defensible answer to "is the product getting slower, and when did it start?" and a data-backed input to any APM renewal. It is decision support, not incident response: it won't page anyone at 3am, and it won't replace real-user monitoring if that need is real.

To engineering: 1.3.0 adds a nullable response_time_stats column to page_visit_daily_stats, populated by page-visits:aggregate-and-prune using SQL aggregates (count, avg, min, max, p50, p95, p99, all in ms) — so aggregation cost stays off the PHP heap on busy days. Upgrade is a published migration plus php artisan migrate; nothing breaks from 1.2.x. Two caveats to design around: stats are null for days with no timed visits, so timing coverage is a prerequisite for trusting the numbers, and the percentiles are daily server-side aggregates — treat them as trend signal, not a tracing or alerting substrate.