Google Analytics Bundle Laravel Package

Product Decisions This Supports

• Server-side measurement strategy: whether to capture conversion and engagement events (signups, checkouts, trial starts, offline/back-office actions) from the backend rather than relying solely on the browser, where ad blockers, ITP/ETP, and consent banners routinely swallow 15–40% of client-side hits. This package is one implementation option for that decision, not the decision itself.
• Build vs. buy vs. wire-it-directly: it represents the "buy/borrow" branch — a prebuilt Symfony service that wraps the Google Analytics hit endpoint behind a configurable service, versus a ~100-line in-house HTTP client against the GA Measurement Protocol. For most teams the in-house client wins on control and longevity.
• Roadmap hygiene / dependency triage: with 49 stars, zero dependents, a last release of September 2020, and a low opportunity score (11.94), this is a candidate for an explicit "do not adopt / plan to remove" entry on the dependency register rather than a silent drift into the codebase.
• Analytics vendor lock-in and migration planning: the package targets Universal Analytics-era payloads. If your roadmap assumes GA4 (Measurement Protocol v2 with api_secret and client_id), this package does not cover the target state and adopting it creates rework in the same quarter.
• Consent and data-governance scoping: server-side tracking changes the privacy story — you now decide what is sent, when, and with what identifiers, which touches GDPR/CCPA review, DPA scope, and IP-anonymisation defaults. Any adoption decision here is a joint product/legal call, not just an engineering one.
• Framework-fit decision: this is a Symfony bundle, not a Laravel package. For a Laravel codebase it implies either a Symfony service container shim or a rewrite — a real cost line that shifts the recommendation toward "build small, in-house."

When to Consider This Package

Consider it only if all of the following hold:

• The application is Symfony (not Laravel) and already pins Symfony 3.x/4.x-era component versions that this bundle's constraints satisfy.
• You are still contractually or technically bound to Universal Analytics properties — realistically only legacy reporting pipelines or archived-data reconciliation, since UA stopped processing hits in mid-2023.
• You need a small, well-scoped set of server-side hits (event tracking, e-commerce transactions) and want to avoid writing the HTTP call yourself.
• You have accepted the maintenance burden: you are prepared to fork and own it, because the upstream is effectively dormant.

Look elsewhere — or build — if any of these are true:

• You need GA4. Use the Measurement Protocol v2 directly, or a maintained client (e.g. a GA4-specific SDK or a thin in-house client). This bundle will not get you there.
• You are on Laravel. There is no Laravel service provider, facade, or config publish here. The integration cost exceeds the code it saves.
• You require active maintenance, security patching, or vendor support. Last release 2020, no dependents, low opportunity score — treat it as unmaintained.
• You need queueing, retries, batching, sampling control, or offline conversion imports at volume. Those are the requirements that justify a real client, not a convenience wrapper.
• You are consolidating on a warehouse-first stack (e.g. sending events to your own pipeline and forwarding to GA from there). A direct-to-Google bundle is the wrong shape.

If you must ship server-side tracking soon and are on Symfony with UA legacy needs, the pragmatic path is: fork the bundle, pin it, and budget an exit.

How to Pitch It (Stakeholders)

For executives: This is a small, dormant Symfony add-on for sending analytics events from our server instead of the user's browser. It solves a real and measurable problem — client-side tracking loses a meaningful share of conversions to ad blockers and privacy restrictions, which makes our funnel data and paid-channel attribution look worse than reality. However, the package itself is effectively abandoned: last released in 2020, negligible adoption, and built for the previous generation of Google Analytics. Recommendation: do not adopt as-is. Fund a small in-house server-side event client targeting GA4's Measurement Protocol — an estimated one-to-two engineer-weeks — rather than taking on a dependency we would immediately have to fork and maintain. The strategic value is in the capability, not this package.

For engineering: Treat happyr/google-analytics-bundle as reference material, not a dependency. It confirms the pattern (a container-managed HTTP client posting hits to Google's collection endpoint) and nothing more. It is Symfony-only, targets UA-era payloads, has zero dependents, and has not shipped since September 2020 — no security posture, no GA4 support, no PHP 8+ guarantees we can rely on. Build a thin, tested client behind an interface (AnalyticsTracker::track(Event $event)), put it on a queue with retries and idempotency keys, and keep the dispatch site vendor-agnostic so GA4, a warehouse sink, or a second vendor can be added without touching product code. That also gives us consent gating and PII scrubbing in one place.