Tracker Laravel Package

Product Decisions This Supports

• Audience and engagement analysis — visitor sessions, page views, devices, browsers, operating systems, referrers, and geolocation land in your own database. That supports decisions like "which pages actually get used," "where do new users enter," and "is our traffic mobile-first enough to justify a mobile investment."
• Roadmap prioritization — raw view/session counts by route or section give a cheap sanity check on what to build next, kill, or invest in, especially pre-product-market-fit when you don't yet have a product analytics stack.
• Build vs. buy for analytics — this is the "build" or "self-host" option in an analytics buy-vs-build debate. It's a concrete answer to "do we add a third-party script, pay for Plausible/Fathom/Matomo, or keep first-party data in our own DB?"
• Privacy and data-ownership decisions — storing IPs, user agents, and geodata yourself forces an explicit decision about PII retention, anonymization, and GDPR/CCPA posture. That's a product/policy decision, not just a technical one.
• Browser/device support policy — aggregated user-agent data is enough signal to decide which browsers and viewports are worth supporting.
• Internal tooling and support — visitor context (sessions, IP, referrer) is useful inside admin/support screens and as a lightweight signal for abuse or fraud investigations.
• What it does not support — there are no funnels, cohorts, retention curves, experiments, or event-based product analytics out of the box. Don't scope decisions that require those on this package alone.

When to Consider This Package

Consider it when:

• You're on a Laravel app with MySQL and want visitor data inside your existing admin, with no external SaaS and no client-side script. v4.0.0 explicitly targets PHP >= 7 and Laravel 7 — that is the ceiling of what's claimed, not a floor you can assume past.
• You need low-fidelity traffic visibility (views, sessions, referrers, devices, geo) fast, and are comfortable owning the schema and models.
• Data residency, privacy, or procurement rules make third-party analytics hard to approve.
• You have PHP capacity to fork, pin, and maintain — ~2.9k stars and MIT licensing make it a readable, forkable starting point.
• You want raw data to build your own reporting on, rather than a vendor's opinionated dashboard.

Look elsewhere when:

• You need product analytics — funnels, retention, cohorts, A/B tests, event tracking, warehouse sync. Use PostHog, Amplitude, Mixpanel, or an event pipeline you own.
• You want a maintained dependency on a modern stack — v4.0.0 is a compatibility re-tag, not a feature or hardening release: it restates PHP >= 7 / Laravel 7 support and bumps the major version to signal the change. There is no commitment to PHP 8.x or Laravel 8–11, no security fixes called out, and no upstream bug-fix activity described. On Laravel 10–11, still assume it breaks and that you're adopting a fork, not a package.
• Compliance or security review is strict — a dependency handling IP addresses and user agents whose most recent release is a version-constraint re-tag remains a hard sell in regulated environments (SBOM, vulnerability scanning, DPA requirements).
• Traffic is high — synchronous per-request DB writes for page views, sessions, and geo lookups can become a write-path tax. If you're above modest traffic, plan for queued writes or a separate store.
• You only need a dashboard number — spatie/laravel-analytics against GA4, or Matomo/Plausible, gets you further with less maintenance.

Practical guidance: treat this as a reference implementation to fork, not a dependency to composer require. The v4.0.0 tag is a mildly encouraging sign of life, but it moves the supported range to "PHP 7 / Laravel 7" rather than forward to current Laravel — so it doesn't change the fork calculus. Time-box a spike, verify migrations and middleware against your Laravel/PHP version, and wrap it behind your own interface so it can be swapped later.

How to Pitch It (Stakeholders)

For executives: This gives us first-party visitor analytics inside the product we already run — no per-seat SaaS fee, no third-party tracking script, and visitor data stays in our own infrastructure, which simplifies privacy conversations. The tradeoff is maturity. The project went a long stretch without releases, and the newest version (v4.0.0) is a version tag that restates support for PHP 7 and Laravel 7 — it doesn't add capability or bring it current with our stack. So we'd be adopting a piece of code we maintain ourselves, not a supported vendor product. Recommended path: a short, time-boxed spike to confirm it works on our stack, then a fork we own — not a long-term dependency commitment. If we need funnels, cohorts, or experimentation, this doesn't replace a real analytics tool, and we should plan for a paid or open-source product analytics platform separately.

For engineering: Small MIT-licensed Laravel package — service provider, migrations, Eloquent models, and tracking middleware that records visits, sessions, page views, user agents, referrers, and geo into MySQL. Positives: readable surface area, our schema, easy to extend, no external calls at runtime if geo is local. The new v4.0.0 tag declares PHP >= 7 / Laravel 7 compatibility — note that's the top of the supported range, not a forward-compat commitment, and it carries no stated security or bug fixes; a major-version bump for a compatibility-only change is itself a signal about maintenance cadence. Risks: framework and PHP drift beyond Laravel 7, no upstream security fixes, and per-request write volume at higher traffic. Recommendation: vendor or fork it under our namespace, pin and audit it, put the writes behind a queue if traffic warrants, and keep a thin internal interface so swapping to Plausible or Matomo later is a config change rather than a rewrite.