Laravisit Laravel Package

Product Decisions This Supports

• Custom analytics vs. buy/adopt: Laravisit gives you first-party, in-database visit tracking on top of a standard Laravel model trait. It supports the decision to keep lightweight usage metrics inside your own app rather than shipping a third-party analytics script or a full warehouse/BI contract.
• View counters and popularity ranking: Because visits are Eloquent records, "most viewed," "trending," and "recently popular" sorts are ordinary queries against your own models — informing roadmap choices about list ordering, recommendations, and content surfacing.
• Traffic-driven feature investment: With per-model visit history you can answer "does anyone actually use this page?" questions that justify or kill roadmap items (e.g., expanding a section, retiring an underperforming one).
• Build-vs-buy for analytics plumbing: This is the adopt-and-ship-a-week option in the middle of the spectrum between "log visits ourselves" (cheap to start, expensive to get right with IP handling, pruning, and queryable aggregates) and "add Segment/GA/Plausible" (fast, but data lives outside your app and can't be joined to your users).
• Roadmap timing: The v2.2.0 release means tracking stays viable if the platform roadmap includes Laravel 13 and PHP 8.4 upgrades — no need to schedule a replacement project at the same time as the framework upgrade.
• Use cases to evaluate it against: product/content detail page counters, admin dashboards showing engagement by resource, "viewed by X people" social proof, and simple per-model engagement reporting for stakeholder updates.

When to Consider This Package

Consider adopting when:

• You need per-model view/visit counts and history in your own database, not aggregate pageviews in an external tool.
• Your product needs engagement data joins — e.g., "show views alongside conversion rate for the same resource."
• You're on Laravel 10–13 and PHP 8.1–8.4; v2.2.0 explicitly covers that matrix, so the same dependency works through your next framework upgrade cycle.
• The team is small and the alternative is writing bespoke tracking code (schema, trait, pruning, IP handling) that no one owns.
• You want something you can read and modify in an afternoon — this is a small, single-purpose package, not a platform.

Look elsewhere when:

• You need funnels, attribution, session stitching, or cohort analysis — that's an analytics product, not a visit-counter package.
• You need high-volume, write-heavy ingestion (millions of pageviews/day); a package that writes a row per visit to your primary database will compete with your application traffic.
• You require strict privacy/compliance guarantees (consent management, regional data residency, formal DPAs). A self-hosted package can help, but you own the compliance work — IP storage and retention policy are your responsibility.
• The team wants zero maintenance surface for analytics. Every Laravel major bump requires the upstream maintainer to release compatibility (as v2.2.0 shows), and that's a dependency you now track.
• A product analytics tool is already mandated by marketing/leadership and the data needs to be shared outside engineering.

Maintenance signal from this release: v2.2.0 is a compatibility release only — Laravel 13, PHP 8.4, updated coderflexx/laravel-presenter ^2.2, illuminate/contracts ^13.0, testbench/collision bumps, and a CI matrix across Laravel 10–13 / PHP 8.1–8.4. No new features, no deprecations, no breaking changes. Healthy maintenance, but treat the package as stable-and-small rather than actively expanding.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add first-party page-view and engagement tracking to our existing Laravel application without a new vendor contract, a JavaScript tag, or a data-sharing agreement. coderflexx/laravisit is a small, focused open-source package that stores visits as records in our own database, which means the numbers live next to our product data and can be reported on directly. The v2.2.0 release keeps it compatible with Laravel 13 and PHP 8.4, so adopting it now doesn't create a migration obligation during our next platform upgrade. Cost is engineering time only; the trade-off is that it answers "how many people viewed this?" not "why did they convert?" — the latter stays with our analytics tooling.

For engineering leads (talking points):

• Low-risk dependency: single-purpose, Eloquent-native, no external services, no queue/worker infrastructure required.
• Compatible across our supported matrix (Laravel 10–13, PHP 8.1–8.4) per the v2.2.0 CI configuration, so it survives the framework upgrade we've already scoped.
• Implementation is trait-based on the models we choose to track — no schema redesign, opt-in per resource.
• Clear boundaries: we own retention/pruning policy and IP handling; the package owns recording and querying. We should decide up front whether IPs are stored at all.
• v2.2.0 contains no breaking changes or deprecations — it's purely a compatibility bump, so there is no re-qualification work if it's already in a spike branch.
• Watch item: it is a small maintainer-led project. Pin the version, and keep the visit-recording path behind our own interface so a replacement is a contained change rather than a refactor.