Google Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (and this is a "build"): The package’s surface area is small — an Analytics snippet, an AdWords conversion snippet, and Static Maps image URLs. Each is a few lines of server-side rendering plus a config value. At a score of 0, zero stars, and zero dependents, there is no community to amortize maintenance against, so the "buy" side of the ledger is empty.
• Feature scoping: Useful mainly as a checklist of what "Google integration" tends to mean in practice — analytics page tracking, conversion attribution, and static map rendering. That framing is more valuable than the code itself when writing a ticket or spec.
• Roadmap de-risking: This bundle wraps an older generation of Google’s client code (Universal Analytics-era tracking and the AdWords brand). Any roadmap item that assumes "we already have Google integration handled" should be re-examined — adopting this would likely ship deprecated tags.
• Framework fit: Despite the framing as a Laravel/PHP package, this is a fork of a Symfony bundle (antimattr/GoogleBundle). It relies on Symfony’s DI container and bundle registration, not Laravel service providers, facades, or php artisan vendor:publish. That is a structural mismatch, not a configuration detail.
• Vendor-risk register entry: A single-maintainer fork with no downstream consumers is a textbook "bus factor of one" dependency. If it were ever proposed, it belongs in the dependency risk log rather than the architecture diagram.

When to Consider This Package

Consider it only in narrow circumstances:

• You are maintaining a legacy Symfony 2/3 application that already depends on antimattr/GoogleBundle, and this fork contains a specific patch you need to keep that app running while you plan removal.
• You want to read it as reference material for how the original bundle structured its Google service wrappers — not to install it.
• You need a quick inventory of which Google surfaces a PHP app typically touches, to sanity-check your own integration list.

Look elsewhere — or build — in essentially every other case:

• Laravel or any non-Symfony framework. There is no adapter layer here; you would be fighting the container, not using it.
• GA4 / current Google Ads. Modern analytics requires gtag.js and Consent Mode; a bundle emitting older tracking calls will produce inaccurate or silently dropped data.
• Consent and privacy requirements. GDPR/CCPA consent gating, script blocking, and data-processing disclosures are product requirements, not snippet details. A thin vendor package will not model them, and retrofitting consent into someone else’s template output is worse than owning twenty lines yourself.
• Any dependency with a support expectation. No stars, no dependents, and a fork-of-a-fork lineage means no security patching, no CVE response, and no upgrade path.
• Server-side measurement needs. If you want Measurement Protocol, server-side tagging, or offline conversion uploads, this is not the shape of the solution.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Build the equivalent in-house, or use the officially supported first-party tooling.

For executives, the short version: this is a near-zero-adoption fork of an abandoned Symfony bundle that emits an outdated generation of Google tracking code. Putting it in a revenue path — analytics and conversion attribution — means our reporting could be quietly wrong, which is worse than obviously broken. The functionality it provides is small enough that replicating it costs less than a day of engineering and carries no third-party risk.

For engineering, the specifics: it is a Symfony bundle, not a Laravel package, so it brings container and bundle-registration assumptions that don't map to our service providers. It has no stars, no dependents, and one maintainer, so we own any bug we hit. And the payload — an analytics snippet, a conversion snippet, and a Static Maps URL builder — is trivially reproducible with current gtag.js, an explicit consent gate, and a signed Static Maps URL.

Proposed alternative: a small internal module with three responsibilities — render the current Google tag behind a consent check, expose a static map URL helper, and centralize the measurement IDs in config. We keep control of the privacy surface, we stay on supported APIs, and we remove a dependency instead of adding one.