Weave Code
Laravel Tagmanager Laravel Package
label84/laravel-tagmanager
A lightweight Laravel package for Google Tag Manager integration. Configure your GTM container, inject the required scripts, and push data layer events from PHP or Blade with a clean, simple API - no manual snippet handling.
Easier way to add Google Tag Manager to your Laravel application. Including support for User-ID, E-commerce and Server Side Events (Measurement Protocol).
Frequently asked questions about Laravel Tagmanager
- How do I install and configure label84/laravel-tagmanager in a Laravel app?
- Install it with composer require label84/laravel-tagmanager, then publish the package config with php artisan vendor:publish and set your GTM container ID (typically via an environment variable) in the published config file. Finally, add the package's Blade directive to your base layout so the container snippet is rendered. The typical integration takes about half a day including verification against a staging GTM container. No database, queue, or cache setup is required.
- Which Laravel and PHP versions does laravel-tagmanager support?
- The authoritative answer is the require block in the package's composer.json, so check that matrix against your current runtime before committing. This is the single most likely blocker when evaluating the package, especially if you are on an older Laravel release or planning an upgrade. Because the package is a thin service provider plus facade and Blade directive, there is no infrastructure footprint to plan around once the version constraint is satisfied.
- Where do I put the Google Tag Manager Blade directive in my layout?
- Place the container snippet directive inside the head of your base Blade layout, following Google's standard GTM placement guidance, and add the noscript fallback immediately after the opening body tag if the package exposes one for that position. The package is designed for conventional server-rendered Blade layouts, so a single base template is usually enough. After changing layouts, run php artisan view:clear so compiled views pick up the change.
- How do I push dataLayer events from PHP or a Laravel controller?
- The package exposes a facade and helper API so you can push dataLayer payloads from controllers, view composers, or Blade rather than hand-writing JavaScript. You build the payload as a PHP array and push it; the package renders it into the page for GTM to consume. Keep payload keys stable across releases and add a test that asserts the rendered dataLayer shape, since that output is the main thing a version bump can change.
- Does laravel-tagmanager support Google Tag Manager User-ID tracking?
- Yes, User-ID support is one of the features the package explicitly covers, so you can pass your application's user identifier into the dataLayer from PHP. Typically you push it once per page for authenticated users and let GTM map it to your GA4 or Universal Analytics tags. Make sure you only send hashed or non-PII identifiers and confirm the value is gated correctly for logged-out visitors.
- Can I send e-commerce dataLayer events with this package?
- Yes, the package includes support for e-commerce dataLayer payloads, so you can push product and transaction arrays from your Laravel checkout or order confirmation flow instead of writing inline JavaScript. Because these payloads often contain nested arrays, they are exactly the kind of data affected by the merge() fix in v1.5.3. Validate item arrays, numeric keys, and currency and value fields in GTM Preview before releasing.
- How do server-side events work with the Measurement Protocol in this package?
- The package includes support for Server Side Events via Google's Measurement Protocol, letting you send event hits from your Laravel backend rather than relying solely on the browser tag. This is useful for events that must fire reliably, such as completed orders or post-payment confirmations. You still need a GA4 Measurement Protocol API secret and a valid client_id, so plan that configuration as part of your integration work.
- Is upgrading to laravel-tagmanager 1.5.3 safe, and what changed in merge()?
- Version 1.5.3 is a patch release containing a single fix to merge() on array input, so there is no public API removal, config schema change, or deprecation. The risk is behavioral rather than structural: if you depended on the previous merged output for array payloads, such as key ordering or overwrite versus append semantics on nested or numeric keys, your dataLayer payload may change after upgrading. Read the diff in PR #7, upgrade in a feature branch, and run any tests that assert dataLayer or rendered head output before promoting.
- Does this package handle GDPR or CCPA consent gating for Google Tag Manager?
- No, the package only injects the container snippet and pushes dataLayer payloads; consent gating remains your application's responsibility. If you use a consent management platform, make sure the GTM container does not load tags until consent is granted, for example by conditioning the directive or using GTM's built-in consent mode. Verify the ordering of the consent script versus the container snippet in your base layout, since getting that wrong is a common compliance failure.
- Is laravel-tagmanager suitable for an SPA or headless front-end, and what are the alternatives?
- Fit is high for conventional Laravel apps with server-rendered Blade layouts but low for SPAs, Inertia, or headless front-ends that manage GTM client-side, where the package adds little value. In those cases, you are usually better off injecting the GTM snippet directly in your front-end template or using a JavaScript-side analytics library. For standard Blade apps the alternatives are hand-written snippets or heavier analytics wrappers, so it is worth checking the package's release cadence and maintenance activity over the last twelve months before standardising on it.
Weaver
How can I help you explore Laravel packages today?