Google Analytics Bundle Laravel Package

Getting Started

Before anything else: confirm the target. Despite the name pattern, hamaryuginh/google-analytics-bundle is a Symfony2 bundle, not a Laravel package. It ships a bundle class, a DI extension, and (typically) a Twig extension that injects the Google Analytics tracking snippet. There is no ServiceProvider, no facade, and no Laravel auto-discovery. Treat it as a reference implementation, not a dependency.

Minimal investigation order:

1. Read composer.json — check the symfony/symfony constraint and the PHP requirement. Anything ~2.3–~2.8 with PHP 5.x means it will not install alongside a modern Laravel app without --ignore-platform-reqs and dependency hell.
2. Read Resources/config/services.xml (or .yml) and the bundle's DependencyInjection/Configuration.php — this tells you the exact config keys (usually an account/tracking ID) and the service ID.
3. Look for Twig/ — that is the part you actually care about; it's the snippet-rendering logic you'd port.

If you are in a genuine legacy Symfony2 app, the minimal wire-up is: register the bundle in AppKernel.php, set the tracking ID in config.yml under the bundle's root key, then call the Twig function/block once in your base layout template.

For a Laravel app, the first use case is trivial to satisfy natively: put the measurement ID in config/services.php, then render the snippet in resources/views/layouts/app.blade.php. Copy the markup shape from the bundle's Twig template and skip the package entirely.

Implementation Patterns

Render once, in the master layout. The dominant failure mode with any analytics snippet is double-firing because it was included in both a layout and a partial. The bundle's Twig extension exists precisely to centralize this — mirror that discipline with a single Blade include.

Config-driven, environment-aware. Read the ID from config, never hardcode it:

// config/services.php
'google_analytics' => ['id' => env('GOOGLE_ANALYTICS_ID')],

Then guard rendering so local/testing environments don't pollute production data:

@if(config('services.google_analytics.id') && app()->isProduction())
    @include('partials.analytics')
@endif

Wrap it as a Blade component or directive if you include it in more than one layout — this mirrors the bundle's Twig-function ergonomics and gives you one place to add consent gating later.

Porting from the bundle: if you want its exact output (older ga.js vs analytics.js vs gtag.js — check which the template emits), copy the template verbatim first, then migrate to gtag.js manually. Do not assume the bundle emits current GA4 markup; it almost certainly predates GA4.

If you genuinely must run it (mixed Symfony2/Laravel monorepo), isolate it behind a Symfony kernel boundary. Do not attempt to boot a Symfony bundle inside Laravel's container.

Gotchas and Tips

• Symfony2 is EOL. The last Symfony 2.x release was 2018. Any bundle targeting it carries unpatched transitive dependencies. Composer will fight you on symfony/* and twig/twig version constraints.
• Zero dependents / 4 stars is a signal. No downstream usage means no one has stress-tested the edge cases, and there is no community to answer questions. Read the source — it's small — rather than trusting the README.
• Abandonware risk. Verify the last commit date and whether the repo is archived. If you adopt it, fork it into your own VCS so a deletion or force-push doesn't break your build.
• Naming trap. The -bundle suffix plus a Google Analytics description leads people to assume Laravel compatibility. It does not have a service provider; composer require alone will do nothing in Laravel.
• Duplicate tracking with SPAs / Turbo. The snippet fires on full page load. If you have client-side navigation, you need manual pageview calls — the bundle has no opinion here.
• Consent and GDPR. The vanilla snippet sets cookies before consent in most of these old bundles. Gate the include behind your consent mechanism; retrofitting is painful.
• Extension points to look at if forking: the DI Configuration tree (where the ID lives) and the Twig extension (where the markup lives). Those two files are ~90% of the value; everything else is Symfony2 ceremony you don't need in Laravel.