Weave Code
Laravel Statistics Laravel Package
rinvex/laravel-statistics
Rinvex Laravel Statistics adds lightweight, model-based analytics to Laravel apps. Attach a trait to any Eloquent model to record and query daily, monthly, and yearly hits, views, and custom metrics via polymorphic relations, with caching and configurable tracking built in.
Rinvex Laravel Statistics gives any Eloquent model a flexible, polymorphic statistics layer. Attach counts, totals, or custom numeric metrics to users, posts, products—whatever your app needs—and query them with an expressive, fluent API.
Add the HasStatistics trait to a model and start recording typed statistics with amounts and optional metadata, then retrieve or aggregate them by type, model, or time range.
- Polymorphic statistics for any Eloquent model
- Track counts, amounts, and custom types with metadata
- Fluent querying and aggregation by type or date range
- Configurable statistic model and database table
- Ships with migrations, service provider, and config
Frequently asked questions about Laravel Statistics
- How do I install rinvex/laravel-statistics in a Laravel app?
- Install it with Composer, then publish the package's config and migrations using vendor:publish and run migrate. You also need to register the TrackStatistics middleware on the route groups you want to track. Before running the stock migration in production, publish it and review the columns, indexes, and foreign keys rather than executing it blindly.
- Does rinvex/laravel-statistics support Laravel 11 or newer?
- The package is built around Laravel 8–10-era conventions, and because the repository is archived there will be no Laravel major-version compatibility work. Confirm its supported Laravel and PHP range against your composer.lock in a throwaway branch before committing. Expect friction on newer major versions rather than guaranteed support.
- How do I attach statistics to an Eloquent model with HasStatistics?
- Add the HasStatistics trait to any Eloquent model, such as User, Post, or Product, to give it a polymorphic statistics relation. You can then record typed statistics with amounts and optional metadata through that relation. The package stores the records in a configurable statistics table and exposes a fluent query API for retrieving them.
- How do I query or aggregate statistics by type or date range?
- The package provides a fluent querying API for retrieving statistics by type, related model, or time range, and for aggregating counts and amounts. For dashboards, consider building your own derived summary table so reporting queries do not scan raw rows directly. That approach also keeps reporting stable if you later fork or replace the package.
- What does the statistics:crush command do and should I schedule it?
- The statistics:crush command is intended as a scheduled rollup job for raw statistics rows, but you should read its source before enabling it because it is not clear whether it aggregates, prunes, or both. If it prunes raw data, that deletion may be irreversible. If you schedule it, use withoutOverlapping()->onOneServer() and test it against a copy of production data first.
- Is rinvex/laravel-statistics abandoned or still maintained?
- The repository is archived, has zero dependents, and carries an explicit abandoned flag, so there will be no security patches, Laravel upgrade work, or escalation path. The MIT license gives you legal rights to fork and modify it, but not vendor accountability. Treat it as a design pattern to adopt under first-party ownership rather than a maintained dependency.
- What are the performance implications of tracking every request synchronously?
- The middleware performs a synchronous INSERT for each tracked request, which is cheap at low volume but becomes a latency and table-growth problem at scale. Add indexes on created_at, user_id, request_path, and is_bot, define a retention policy, and exclude health checks, admin routes, and webhooks. Keep reporting on a separate summary table rather than querying raw rows live.
- Can I use UUID or ULID keys and custom user tables with this package?
- The published migration likely assumes auto-incrementing users.id keys, so plan to edit it if you use UUIDs, ULIDs, non-default user tables, or multiple database connections. Do not run the stock migration unchanged in those setups. Publish the migration, convert the foreign key to your key type, and verify the schema before migrating.
- What privacy concerns should I review before deploying the tracking middleware?
- Default data collection may capture tokens or personally identifiable information in headers, referrers, or IP-derived fields, creating GDPR or CCPA exposure if deployed before schema review. Audit the published migration and trim unused columns, add a retention policy, and apply consent gating where required. Privacy review is one of the larger parts of the integration effort, not the install itself.
- Are there better alternatives to rinvex/laravel-statistics for product analytics?
- If you need funnels, cohorts, or attribution, this package is the wrong tool and you should evaluate PostHog or Amplitude instead. For simple directional usage metrics, a hand-rolled two-table equivalent using middleware plus a page_views table is often cheaper than adopting and adapting this package. If you keep rinvex/laravel-statistics, fork it into packages/ under first-party ownership and pin the reference commit.
Weaver
How can I help you explore Laravel packages today?