Eloquent Viewable Laravel Package

Product Decisions This Supports

• Popularity-driven discovery surfaces. The package ships query scopes (orderByViews, orderByUniqueViews) plus Period::pastDays(7)-style filtering, which directly powers "Most Read," "Trending This Week," and "Popular in Category" modules without a separate analytics pipeline or nightly ETL job. This is the highest-leverage use: it turns analytics from a reporting afterthought into a ranking input for the product itself.
• Editorial and content roadmap prioritization. Because each view is a row rather than an incremented counter, you can answer "which content earned attention in the last 30 days" and "which content is still being discovered long after publish" without asking a data team. This informs content investment, refresh-vs-retire calls, and homepage merchandising.
• Build vs. buy: buy (adopt) for view counting; do not build. Implementing per-model view tracking correctly means crawler filtering, DNT/IP exclusions, cooldowns, unique-visitor semantics, queueing to keep requests fast, cache invalidation, and indexes on a growing table. That is several weeks of engineering plus ongoing maintenance for a capability that is not your differentiator. A ~900-star MIT package with migrations and a one-trait integration collapses that to an afternoon.
• Reduced dependence on third-party analytics for product logic. GA4 and similar tools are built for marketing reporting, not for joining behavior to your Eloquent models or feeding a recommendation query. Keeping view data in your own database makes popularity a first-class, queryable domain concept you can combine with purchases, follows, or subscriptions ("most-viewed listings that converted").
• Privacy and compliance posture as a product decision. First-party, cookie-optional view records with built-in DNT and crawler filtering materially simplify consent flows and vendor review compared to shipping a third-party tag. That is a differentiator for audiences in regulated or privacy-sensitive segments (health, education, public sector, EU).
• Roadmap items this unlocks cheaply: per-author/per-category popularity dashboards for creators, "you might also like" based on view co-occurrence (once data exists), paywall or ranking experiments where views are the guardrail metric, and content lifecycle alerts. Each of these depends on having trustworthy, owned view data — this package is the cheapest path to that foundation.
• Segmentation hooks without scope creep. View "collections" let one model carry multiple counters (e.g., impressions vs. detail-views vs. preview-plays) without a second package or a custom table, which keeps experimentation cheap.

When to Consider This Package

Adopt when:

• The stack is Laravel and the things you want to measure are Eloquent models (posts, listings, products, docs, courses).
• View counts need to drive behavior — sorting, ranking, recommendations, dashboards shown to users or creators — not merely be reported to a marketing team.
• Traffic is application-scale (thousands to low millions of views per month) rather than event-stream scale, so a relational views table with proper indexes and count caching stays comfortable.
• You want data ownership, self-hosting, and a permissive MIT license with no per-event pricing.
• You need "good enough" unique-view semantics: cooldowns are session-based, so treat "unique" as deduplicated sessions, not authenticated people. If a stakeholder will read "unique views" as "unique users," align on the definition before shipping it on a dashboard.

Look elsewhere when:

• You need funnel, retention, cohort, attribution, or campaign/UTM analysis — that is product-analytics territory (PostHog, Amplitude, GA4), and forcing it into a per-model view table will produce the wrong shapes.
• Volume is genuinely large (hundreds of millions of events) or you need sub-second aggregation over long histories; a row-per-view table demands retention policy, partitioning, or a columnar/warehouse path, and the package offers no aggregation layer.
• The stack is not Laravel, or views must be emitted from mobile/edge clients rather than server-rendered requests.
• You require real-time streaming, cross-device identity resolution, or bot/fraud detection beyond basic crawler and IP filtering.
• You need vendor-backed SLAs or enterprise support — this is a single-maintainer open-source project, and the near-zero dependent count is a reminder to inspect the changelog and test suite yourself rather than assume broad third-party validation.

Adoption caveats to plan for: define a retention/archival policy up front, add the recommended composite indexes before launch, and enable queueing on any high-traffic route. If views are recorded from queued jobs, event listeners lose request context (session, auth user, IP) — capture what you need during the request.

How to Pitch It (Stakeholders)

For executives: This is a small, free, self-hosted component that gives us first-party visibility into what content and inventory people actually look at, and lets us use that signal to rank and recommend — the kind of capability we would otherwise either build ourselves or buy from an analytics vendor. It is MIT-licensed, lives inside our own application and data, and adds roughly a day of integration work with no recurring cost, no third-party tag, and a materially simpler privacy story. The trade-off is scale: it is designed for application-level traffic, so if view tracking ever becomes a high-volume, cross-channel analytics need, we would revisit with a dedicated analytics platform. Recommended as a low-cost, reversible bet.

For engineering: Add one trait and one interface to the models we care about, publish and review two migrations, and we get a fluent API: views($post)->record(), ->count(), ->unique(), ->period(Period::pastDays(7)), plus orderByViews / orderByUniqueViews scopes on the model. Writes can be deferred to a queue to keep request latency flat, and counts can be cached. Filtering for crawlers, DNT, ignored IPs, and cooldowns is handled for us and still runs before anything is queued. What we own: index the views table correctly, set a retention/archival policy, and watch that the view table does not become the largest thing in the database. It is MIT, actively released, and small enough to read end to end — so the integration risk is low, but we should not expect upstream to absorb our feature requests.