Google Analytics Laravel Package

Technical Evaluation

Architecture fit. widop/google-analytics is a narrow, framework-agnostic adapter that wraps Google's certificate-based (service account / JWT bearer) OAuth2 flow and the legacy Google Analytics Reporting API. It is not a Laravel package — there is no service provider, facade, config file, or migration to speak of — so its architectural fit is best described as a replaceable integration shim rather than an infrastructure component. For a Laravel codebase, the correct framing is: hide it behind an application-owned interface (e.g. AnalyticsReportingClient) and treat the package as one implementation of that interface.

Integration feasibility. Composer-installable under MIT, which is frictionless legally. The real cost is dependency resolution: it is built against the google/apiclient era of the late 1.x/2.0 client, which transitively pins Guzzle, psr/*, and google/auth versions. On a modern Laravel stack (Laravel 10/11, Guzzle 7, PHP 8.2+) this will almost certainly produce a dependency conflict with the framework's own HTTP stack. Integration is feasible only as an isolated, unconstrained dependency tree (separate process/queue worker) or by vendoring the ~hundreds of lines of auth logic directly.

Technical risk: high.

• Product risk (dominant). The package targets the Universal Analytics Core/Management Reporting API. UA stopped processing standard hits on 1 July 2023 and its reporting APIs were retired; a wrapper around that surface is functionally dead for new data regardless of code quality.
• Dependency risk. No releases, no dependents, 27 stars — effectively unmaintained. Transitive security patching must be our responsibility.
• Credential risk. Certificate-based auth means a private key on disk or in secrets storage; the library offers no opinion on key rotation, storage hygiene, or audience scoping.
• Version risk. Pre-PSR-4 conventions and PHP version constraints likely predate our platform baseline.

Key questions.

1. Do we need historical Universal Analytics data, or ongoing GA4 reporting? These have entirely different answers (one-off export vs. new integration).
2. Is anything in this package actually doing work that google/auth + google/analytics-data doesn't do in ~40 lines of code today?
3. What is the real motivating requirement — service-account auth (solved by google/auth), or a Laravel-shaped config/facade (solved by 60 lines of our own code)?
4. Who owns the private key lifecycle, and does our secrets management support rotation without redeploy?
5. Are we able to tolerate a dependency that will never receive a CVE patch?

Integration Approach

Stack fit. The package's idiom (construct a client from a key path, an issuer email, and a profile/view ID, call a reporting method) maps reasonably onto a Laravel service class bound in a provider and driven by config/services.php + env vars. That ergonomics argument is the package's only real value, and it is reproducible: google/auth's ServiceAccountCredentials with the analytics.readonly scope plus a thin HTTP call against the Data API is the modern equivalent.

Recommended migration path. Do not adopt as a runtime dependency. Instead:

1. Spike (1–2 days). Stand up google/analytics-data + google/auth in a throwaway branch, create a service account, grant it Viewer on a GA4 property, and prove a runReport round-trip. This validates the requirement without inheriting the package.
2. If UA historical data is genuinely required, treat it as a data extraction project (bulk export off the property or BigQuery export if it was linked), not an API integration. Do not build a cron around a retired API.
3. If the requirement is GA4, implement in-house behind an interface. Expected size: ~1 config entry, 1 provider binding, 1 client class, 1 DTO, 1 queued job. That is below the threshold where a 27-star dependency earns its keep.

Compatibility. Assume the package will not resolve cleanly against our composer.lock. Verify with composer why-not widop/google-analytics before any further investment; a conflict on guzzlehttp/guzzle or google/apiclient is a stop-work signal. If isolation is mandatory, run it in a separate service with its own lockfile and an internal HTTP boundary.

Sequencing. (a) Requirements clarification — UA vs GA4, historical vs ongoing. (b) Dependency/conflict probe. (c) Credential provisioning and IAM (service account, property-level Viewer grant). (d) Interface + in-house implementation with contract tests recording fixtures from a sandbox property. (e) Feature-flag rollout behind the interface so the backing implementation stays swappable. (f) Decommission any parallel legacy path.

Operational Impact

Maintenance. Effectively zero upstream velocity. We own the code the moment it ships, including any future PHP major-version compatibility work. Budget it as a fork, not a dependency. The MIT license at least permits vendoring.

Support. No maintainer responsiveness, no issue tracker signal (0 dependents means no crowd-sourced fixes), no Stack Overflow corpus specific to this package. Escalation path is "read Google's docs and the library source."

Scaling. Reporting calls are read-only and cacheable. The operational design must include: persisted access tokens (the JWT flow mints a token valid ~1 hour — do not re-sign per request), response caching keyed by (property, dimension set, date range), and batching/queueing to stay inside GA4 Data API quota (roughly 200k tokens per property per day, with per-request token cost driven by cardinality and date range). Unbounded dimension combinations will exhaust quota quickly; enforce an allowlist of report definitions.

Failure modes to instrument.

• 403 PERMISSION_DENIED — service account not added to the property, or the property ID is wrong; the single most common operational error.
• 401 / invalid_grant — expired, revoked, or rotated key; needs alerting distinct from generic HTTP 5xx.
• 404 / 400 on legacy endpoints — the UA retirement failure mode; will look like a broken integration rather than a dead API if not explicitly detected.
• 429 RESOURCE_EXHAUSTED / quota exhaustion — needs backoff with jitter and a circuit breaker.
• Dependency drift — a composer update silently resolving a different google/auth major and changing token behaviour.
• Key leakage — private key committed to a repo or logged in an exception trace; enforce .gitignore, secret manager injection, and redaction in the HTTP client's logging middleware.

Ramp-up. Low code surface, high domain surface. An engineer can read the package in an hour; getting productive on GA4 property permissions, service-account provisioning, dimension/metric naming, sampling, and quota semantics is a multi-day curve and is where the actual risk lives. Plan for a knowledge handoff doc covering the service account, its grants, and the report allowlist — that artefact matters far more than the library.