Ga4 Analytics Data Bundle Laravel Package

Product Decisions This Supports

• Multi-client / multi-tenant reporting. 1.1.2 fixes a defect where every client wrote to the same cache key, so whichever GA4 property asked first served its numbers to all other clients for 24 hours. Any feature that surfaces more than one property in the same app — client portals, agency dashboards, white-label reports, per-brand KPI widgets — was silently returning wrong data before this release. This is the gating bug for that whole roadmap lane; treat 1.1.2 as the minimum version for any multi-property surface.
• Conversion and entitlement gating. A failed isTransactionInAnalytics() check was cached as false for the cache lifetime, meaning a transient API failure could read as "customer did not purchase" for up to 24 hours. If we ever gate paywalled content, upsells, or onboarding on a purchase check, this defect is the difference between an inconvenience and a support-ticket generator.
• Cache and data-freshness decisions. Keys now include the client's property and honour the configured cache.prefix; AnalyticsCache::clear() now clears one client's entries instead of flushing the entire cache.app pool. That makes "refresh this client's analytics" a safe, product-facing action rather than a maintenance-window operation that quietly evicts unrelated cached data.
• Build vs buy. The value here is not the GA4 API call — it's the years of accumulated edge cases in auth, property scoping, caching and prefix handling. Adoption buys those, but only from 1.1.2 onward; earlier versions carry known correctness defects.
• Roadmap candidates that become viable: scheduled report exports, quota-aware dashboard refreshes, per-client cache invalidation in admin tooling, and any pricing/commerce analytics feature.

When to Consider This Package

Adopt when:

• One application reads a small-to-moderate number of GA4 properties, read-only (reports, KPIs, transaction verification).
• We want framework-native configuration for credentials and caching instead of maintaining a bespoke Google Data API client.
• We are on PHP 8.1–8.5 and Symfony 5.4 / 6.4 / 7.4 — exactly the matrix CI now covers, including PHP 8.5 forward-compatibility.
• Pin >=1.1.2. No code changes are required to upgrade, but cache keys change, so plan for a cold start: first calls per report and period go back to the API, which has quota implications on a high-traffic deploy.

Look elsewhere when:

• We need write access, admin APIs, real-time streaming, or the full Data API surface — verify method coverage against what we actually need to report on.
• We need low-latency, high-cardinality, per-request querying. A 24-hour cache model is a poor fit; we would be building our own cache layer on top anyway.
• The app is Laravel-first. This ships as a Symfony bundle with Flex-oriented configuration; wiring it into Laravel is extra plumbing, and a plain Google client or a native Laravel package is simpler.
• Compliance or SBOM review requires vendor-shipped tests. 1.1.2 removes tests and tooling from the Composer package, so we would test against the repository, not the distributed tarball.
• Longevity is the dominant criterion. This is a single-maintainer package; wrap it behind our own interface so replacement is a swap, not a rewrite.

How to Pitch It (Stakeholders)

For executives: This release fixes a defect where one client's Google Analytics numbers could be served to a different client for up to 24 hours. For any multi-client or per-tenant reporting we intend to ship, that makes 1.1.2 the minimum acceptable version — it is the difference between "usable" and "not shippable." It also fixes a data-freshness bug where a failed purchase lookup was cached as "no purchase," and stops our analytics cache-clear from wiping unrelated cached data. Upgrade effort is close to zero: no code changes, a version bump and a cache warm-up. Strategic risk is moderate — small maintainer base — which we mitigate by keeping our own thin abstraction over it.

For engineering: Bump the constraint to >=1.1.2 and deploy outside peak traffic; the first call per report and per client re-hits the GA4 API because old cache entries are not read. Verify we are setting cache.prefix and that our runbooks reflect the new per-client AnalyticsCache::clear() semantics — any admin "refresh data" tool built against the old flush-everything behaviour should be reviewed. The release also drops the PHP 8.5-deprecated setAccessible() and the obsolete Guzzle choose_handler() fallback, and CI now covers PHP 8.1–8.5 against Symfony 5.4, 6.4 and 7.4, so we are clear on the upgrade path. Distribution no longer ships tests or tooling; run our checks against the upstream repo, and keep the package behind our own interface so an eventual swap stays cheap.