Laravel Statistics Laravel Package

Product Decisions This Supports

• Build vs. buy for product analytics. This package is a "buy the pattern, own the code" option: first-party visit tracking inside your own Laravel database for $0 in vendor spend, versus a GA4/PostHog/Segment contract or a sprint of custom instrumentation. The decision it enables is not "which analytics tool" but "do we need a tool at all yet."
• Baseline engagement metrics without a third-party tag. Supports decisions that only need directional numbers — DAU/WAU, returning vs. new visitors, route/page popularity, feature adoption by user segment — where raw visit rows can be joined against your own users table instead of reconciling a SaaS export. This is enough to answer "are trial accounts logging in and hitting the activation path?" and not much more.
• Privacy and data-residency posture as a sales lever. Because events never leave your infrastructure, it unblocks roadmap items in regulated or EU-sensitive accounts where a client-side tag triggers a DPA, cookie-consent work, or a security review. Useful in enterprise deal cycles where "no third-party scripts" is a procurement checkbox.
• Instrumentation cost tradeoff. The one-insert-per-request write plus scheduled rollup is the core product argument: a defensible analytics baseline that does not measurably degrade page latency and does not require an event pipeline or a data team. This is the argument you make when engineering pushes back on "yet another tracking call."
• Roadmap scoping for an internal usage dashboard. If a roadmap item is "give CS and leadership a view of who is actually using the product," this is a credible two-table foundation (raw visits + your own aggregated rollups) rather than a data-warehouse project. It can ship in a sprint, not a quarter.
• De-prioritizing analytics as a differentiator. Adopting it is an explicit statement that analytics is table stakes, not a product surface worth investing in — which frees roadmap capacity for core features. Make that call consciously and write it down.
• Framing the fork budget. It forces an honest accounting: the value isn't the dependency, it's a validated schema and query pattern. The PM decision is "2–5 engineer-days to vendor and own this" vs. "a contract" vs. "do nothing and keep guessing."

When to Consider This Package

Consider it (as a fork you own) when:

• You run a Laravel monolith and need visit/pageview/visitor counts, not behavioral analytics.
• Your questions are answerable in SQL against tables you already have — "which accounts logged in last week," "which routes do trial users hit before converting," "which pages do churned accounts stop visiting."
• You want zero JS tag, zero consent-banner surface, and data that never leaves your DB.
• Traffic is modest enough that a row-per-request insert plus a nightly aggregation job is comfortably within budget and your table-growth math is boring.
• You have engineering capacity for a small, well-scoped fork. The repository is archived — treat it as a code sample and pattern to internalize, not a dependency to composer require. Budget roughly 2–5 engineer-days to vendor it, pin the schema, strip sensitive columns, add indexes and tests before production.

Look elsewhere when:

• You need funnels, cohort retention curves, session replay, experiment attribution, or a self-serve exploration UI. This package records visits; it does not model behavior. Use PostHog, Amplitude, or a warehouse.
• You need real-time dashboards or sub-minute freshness — the cron rollup is inherently batch.
• You have high write volume, or multi-tenant isolation requirements that a shared visits table won't satisfy cleanly (tenant IDs mean editing the migration before first run).
• You cannot own a fork. An archived repo with 0 dependents means no upstream security patches, no Laravel major-version guarantees, and nobody to escalate to.
• You need a vendor SLA, support contract, or named maintainer to clear a compliance review. MIT gives you rights, not accountability.
• The whole decision hinges on one dashboard. Spatie's analytics package, Plausible, or Matomo may cover it with less ownership burden; a two-table hand-rolled equivalent is also legitimate — and honestly close to what you'd get here anyway.

Assessment: the low opportunity score is the signal that matters — the package is essentially complete and abandoned, so there is no ecosystem momentum to ride and no community to inherit. Its value to you is as a validated design (cheap write path, scheduled rollup, SQL-native reporting) and as a head start on a fork. Adopt the pattern; don't adopt the dependency.

How to Pitch It (Stakeholders)

To executives: We can answer basic product-usage questions — are accounts active, which features actually get used, are trials engaging before they convert — without signing a new analytics vendor, without adding a tracking script to the app, and without customer behavioral data leaving our infrastructure. That removes a recurring SaaS line item, shortens privacy and security review for regulated accounts, and costs a few engineer-days rather than a quarter. The caveat, stated plainly: the open-source project is no longer maintained, so we would adopt it as code we own and support, not as a supported product. It gets us a credible baseline, not a competitive analytics capability — if we later need funnels, experimentation, or self-serve dashboards, we will still buy a platform, and this decision doesn't block that.

To engineering: A minimal footprint — one insert per tracked request, one migration, one middleware, and a scheduled aggregation job. We'd vendor it rather than depend on it: pin the version, publish and edit the migration for our UUID users and any tenant column, drop the request-body/header/cookie fields we don't need on privacy grounds, add indexes on created_at, user_id, is_bot, and request_path, and set an explicit retention window from day one. Scope tracking to public route groups only — no admin, health checks, webhooks, or assets — and register the middleware after session/auth so attribution isn't empty. Keep the raw table as an append-only event log and write our own daily rollups for dashboards so reports never couple to the package schema. Test with the middleware disabled plus a small integration test asserting a row is written. Deliverable is roughly 2–5 engineer-days including the fork; the risk we're accepting is that Laravel major upgrades are on us, and the mitigation is that the code surface is deliberately tiny.