Laravel Analytics Laravel Package

Product Decisions This Supports

• Build vs. buy on reporting surfaces. This package collapses the "we should show analytics in-app" decision from a scoped project (OAuth flow, Data API client, response normalization, caching, test doubles) into a few days of glue work. It makes "buy" cheap and "build custom" hard to justify for read-only reporting.
• Feature and content prioritization. fetchMostVisitedPages, fetchTopReferrers, fetchTopCountries, fetchTopBrowsers and fetchTopOperatingSystems produce the evidence needed to defend a roadmap: fund SEO, fix mobile web, localize, or prune dead sections — based on observed distribution rather than opinion. Low-traffic page lists are also a credible input to sunset/consolidation decisions.
• Customer-facing value, not just internal dashboards. For SaaS or agency products, per-client reporting embedded in the product is a monetizable, plan-gated feature — it converts "can you send me numbers?" support requests into retention surface.
• Replacing GA iframe embeds. This is the strongest single argument: embedded GA views are fragile (CSP, third-party cookie/ITP changes, mobile UX, no control over the vendor's UI changes). Server-side retrieval we render ourselves removes that maintenance liability.
• Reporting cadence and operating rhythm. Scheduled jobs can pull weekly KPIs into email or Slack without hiring a BI resource or buying seats.
• Report design can be iterated by PM without engineering re-architecture. The generic get(period, metrics, dimensions, maxResults, orderBy, offset, dimensionFilter, metricFilter) plus GA4's documented metric/dimension schema means new report cards are a config change, not a new endpoint. That is the real product leverage: cheap experimentation with what to show.
• Note the scores honestly: ~59 overall and opportunity ~29 signals a commodity capability, well executed. The package is not differentiated — the differentiation lives in the dashboards and decisions we build on top of it.

When to Consider This Package

Adopt when:

• The app is Laravel/PHP and GA4 is already the accepted source of truth for traffic. (This is GA4-only; Universal Analytics is out of scope.)
• Needs are read-only, pre-aggregated, and dashboard-shaped: visitors, page views, top pages, referrers, geography, device/browser, new vs. returning.
• Near-real-time freshness is not a product SLA — caching is built in and defaults to 24 hours, which is both a performance feature and a quota safeguard.
• A small team wants server-side service-account auth (Analyst role on the property, JSON key kept out of VCS) instead of per-user OAuth.
• You want the reporting layer under test: Analytics::fake() with an injected payload lets dashboards ship with deterministic CI rather than live API calls.

Look elsewhere when:

• You need raw event-level data, exploration/funnel analysis, custom channel grouping, or joins with product/CRM data. That is a BigQuery export plus a modeling layer — the Data API returns pre-aggregated rows with cardinality and sampling limits.
• You need real-time ("last five minutes") views, or very high report volume against tight per-property quotas.
• You need write access (audiences, config changes). This package is read-only.
• Data residency or consent posture is a blocker. GA data processing and this package's outbound calls are outside your perimeter; it solves neither consent nor GDPR positioning. Regulated or EU-only customers often push toward Plausible/Matomo/PostHog instead.
• You need a UI. There is none. Dashboard design and frontend budget are separate line items.
• Multi-tenant reporting per client/property is a hard requirement — property_id is a single config value, so per-tenant support means per-tenant configuration or instantiation, which needs a spike before we promise it.

Diligence items before betting a critical path: the listing shows 0 dependents, which is almost certainly a registry artifact given ~3.2k stars — verify on Packagist. Release date (Oct 2026), CHANGELOG, and MIT licensing suggest active, low-lock-in maintenance; because it is a thin wrapper, removal cost is low.

How to Pitch It (Stakeholders)

One line: We can ship an in-product analytics view in days instead of a quarter, at zero licence cost, on the GA4 data we already have.

For executives — cost and speed:

• MIT-licensed, no new vendor, no BI seats, no ETL pipeline to own. First dashboard is roughly 2–5 engineering days versus ~4–6 weeks to build equivalent retrieval ourselves.
• Maintained by Spatie with a documented changelog and regular releases; ~3.2k stars. Risk of abandonment is low and exit cost is minimal because it is a thin wrapper over Google's own client.
• Replaces fragile GA iframe embeds, removing a recurring source of breakage we don't control.

For engineering — what it actually is:

• A typed Laravel facade over the Google Analytics Data API (GA4). Typical call: Analytics::fetchVisitorsAndPageViews(Period::days(7)), returning Illuminate\Support\Collection.
• Config-driven property_id and service-account JSON credentials, with configurable response caching and cache store.
• Escape hatch for custom reports via Analytics::get(...) with metrics, dimensions, ordering, offset pagination, and GA4 filter expressions — no need to fork the package.
• Analytics::fake() for tests; dashboards can be developed and CI'd without live credentials.

Set expectations explicitly (non-goals): not a replacement for the GA UI or BigQuery, read-only, one property per config, freshness bounded by cache TTL, and no handling of consent or data-residency obligations.

What we own either way: secret storage and key rotation, dashboard UX and information hierarchy, caching strategy, and a stated plan B — BigQuery export — if reporting needs outgrow pre-aggregated API queries.