Laravel First Party Analytics Laravel Package

Product Decisions This Supports

• Build vs. buy for product analytics. This package shifts the default from "add GA4/PostHog/Amplitude and accept vendor cost, DPA review, and cookie consent" to "instrument the Laravel app directly and keep events in the database you already operate." For a PM, that is a roadmap-level decision about where product data lives and who can query it.
• Funnel and conversion definition. Config-driven conversions and ordered funnels mean PMs can define signup → activation → paid as product artifacts rather than as dashboard widgets built by an analyst in a third-party tool. Changes to funnel definitions become code review, not vendor config drift.
• Privacy posture as a feature, not a cost center. No-cookie mode by default, IP hashing with a daily salt, UA never stored, DNT/GPC honored, and bot filtering out of the box. This directly supports decisions like "can we ship to EU customers without a consent banner?" and "can we avoid a cookie-consent CMP purchase this quarter?"
• Instrumentation scope decisions. The package deliberately skips JSON, AJAX, Livewire updates, redirects, errors, and prefetches. That constrains analytics to meaningful pageviews — which is usually what a PM wants for content/marketing funnels, but means SPA-ish or Livewire-heavy flows need Analytics::track() calls to be designed into the feature spec.
• Identity and attribution modeling. User linking on Login/Registered, Analytics::identify(), and cookie-mode retroactive linking of anonymous visits determines whether you can answer "which channel produced this paying user?" That is a decision with product consequences and a config flag (ANALYTICS_COOKIES), not an implementation detail.
• Retention policy. analytics:prune with retention_days forces an explicit answer to "how long do we keep behavioral data?" — a question legal and product should co-own, and one most teams defer until an audit.
• Roadmap prioritization input. Top/entry pages, channels, referrers, UTM, countries, devices, browsers, OS, event property breakdowns, and preset/custom ranges are enough to run quarterly roadmap reviews and launch retrospectives without a BI ticket.
• Cost/ownership trade-off. No per-event pricing and no data egress means analytics stops scaling in cost with product success — relevant when modeling infrastructure spend against growth.

When to Consider This Package

Adopt when most of the following hold:

• The product is a Laravel 12 or 13 app serving server-rendered web routes. This is a hard gate — the pageview layer is middleware on the web group.
• Privacy, data residency, or procurement friction is blocking or slowing a third-party analytics rollout (EU customers, healthcare/fintech, enterprise security review, DPA redlines).
• You want analytics queryable in your own database — joining pageviews to your users and orders tables is the actual value, and it's something hosted tools make awkward.
• You need funnels and conversions defined by the product team and versioned with the code.
• Modest, product-level volume on the order of a normal Laravel web app, not high-cardinality event streams from mobile SDKs or edge services.
• You have engineering capacity to own a v0.1.x dependency — read the source, pin the version, and absorb breaking changes before 1.0.

Look elsewhere when:

• The app is not Laravel, or is Laravel but primarily an API/SPA/Livewire-driven UI where server-rendered pageviews don't represent user journeys.
• You need behavioral depth beyond pageviews and custom events: session replay, heatmaps, scroll depth, A/B testing, feature flags, in-app messaging, cohort/retention explorers, or a SQL-free analyst UI.
• You need warehouse/ETL, reverse ETL, or ad-platform activation (Google Ads, Meta CAPI, Klaviyo). This package does not send data anywhere.
• You need mobile app or multi-service tracking via SDKs.
• You need vendor-backed SLAs, SOC 2, or a support contract. This is a single-maintainer, first-release package.
• You need raw-IP-level or granular geolocation — the IP is hashed and country comes from a CDN header, which many setups won't populate.
• You are high-volume enough that per-request writes matter and you can't tolerate the write-mode trade-offs (batched-after-response by default, one queued job per request in queue mode).

How to Pitch It (Stakeholders)

For executives: We can answer core product questions — what pages people land on, where they come from, what they do, and where they convert — without adding a third-party analytics vendor. That means no per-event bill that grows with traffic, no data leaving our infrastructure, and a materially simpler privacy story: no cookies by default, IPs hashed and never stored raw, Do-Not-Track and Global Privacy Control honored out of the box. It installs in two commands on a Laravel app. The honest caveat is maturity: this is a v0.1.0 first release from a single maintainer, so treat it as a low-risk experiment on an internal or non-critical property before making it the source of truth for revenue reporting. Ask for a two-sprint pilot with a defined success criterion, not a permanent platform commitment.

For engineering: It is a well-scoped Laravel package rather than a platform — middleware on the web group (or the analytics.track alias), three write modes (batched after the response by default, one queued job per request, or sync) with write failures reported and never thrown, so analytics cannot take down a request. It respects the framework's extension points: a swappable DetectsBots contract, Analytics::ignoreUsing(), config-driven exclude_paths, ignore_referrers, conversions, and funnels, plus a gated Blade dashboard that is local-only by default. Data model is visits plus events with property breakdowns, pruned in chunks via analytics:prune. The release notes are unusually candid about test coverage: queue write mode was verified in the suite (job dispatched and applied) but not against a real queue worker, and the browser test ran on SQLite while MySQL 8.4 and PostgreSQL 17 coverage came from CI integration runs. Local CI was green across PHP 8.3/8.4/8.5 × Laravel 12/13 with Pint and PHPStan level 6.

What to ask before adopting: Pin the version and expect breaking changes pre-1.0; validate queue mode on your actual worker and driver; run the dashboard against your production database engine rather than SQLite; confirm whether your CDN sets the header the country field depends on; and get a written answer from legal on whether no-cookie mode plus hashed IPs changes your consent-banner obligation in each market you ship to. Decide ANALYTICS_COOKIES and retention_days explicitly at kickoff — they change what questions the data can answer later, and retroactive attribution is only possible in cookie mode.