irazasyed/laravel-gamp
Laravel GAMP is a Laravel wrapper for Google Analytics Measurement Protocol, enabling server-side tracking of events, page views, and ecommerce transactions. It offers a simple, fluent API to send analytics hits from your backend without client-side JavaScript.
What changed in v1.10: A single PR (#42, "Update for Laravel 10") is the entire release. There are no new features, no deprecations, no documented bug fixes, and no security patches. Practically, this is a Composer constraint bump plus (presumably) a CI matrix update to run tests against Laravel 10. Treat it as a framework-compatibility release, not a functional one.
Architecture fit: irazasyed/laravel-gamp is a thin service-provider + facade wrapper around the Google Analytics Measurement Protocol. It fits cleanly into the standard Laravel package model (auto-discovered provider, config file, facade, queued/HTTP client calls out to Google's collect endpoint). It occupies a narrow seam — server-side event dispatch — and does not impose opinions on your domain layer. That is good for fit and bad for leverage: it is a replaceable convenience wrapper, and the underlying Measurement Protocol is callable with a handful of lines of Http::post().
Integration feasibility: Low effort. Install, publish config, set the tracking ID, dispatch hits. Laravel 10 support removes the main blocker for teams on modern Laravel. The realistic integration work is not the package — it is the surrounding decisions: which events are worth sending server-side, how you deduplicate against client-side gtag hits, and how you handle PII/consent.
Technical risk (ranked):
google-analytics.com/collect, v=1, tid=UA-...). UA stopped processing hits in July 2023 and the collect endpoint is dead. If v1.10 only bumps Laravel constraints without migrating to the GA4 endpoint (/mp/collect, api_secret, client_id required, engagement_time_msec required for session attribution), then the package is functionally a no-op against a live GA4 property regardless of Laravel version. A "Laravel 10 support" release that does not address this is a compatibility signal, not a viability signal.illuminate/support constraint was tightened to ^10.0 rather than widened to ^9.0|^10.0, this is a breaking change for anyone still on Laravel 9, despite the patch-level version number. Must be verified against composer.json, not inferred from the PR title.Key questions for the maintainer / to answer internally:
v=1? Show a working payload example.^9.0|^10.0) or replaced (^10.0)? Is this a breaking change disguised as a patch?api_secret handling story — config, env, rotation?Stack fit: Suitable for Laravel 9/10 monoliths or modular monoliths that already own their analytics instrumentation and want server-side conversion events (signups, subscription starts, server-only errors) alongside client-side gtag. It is not suitable as the primary analytics pipeline — it is a supplement to a client-side tag or a warehouse-based event stream.
Migration path:
composer.json and the service provider in the v1.10 tag. Confirm (a) the constraint semantics, (b) the endpoint being called, (c) whether api_secret/client_id are supported. This is a 30-minute spike and gates everything else.Http::post('https://www.google-analytics.com/mp/collect'). The wrapper is lower total cost than a dependency you must fork.composer.lock diff review — a patch bump that resolves to a different illuminate/support major is worth an explicit review.Compatibility: Confirm PHP 8.1+ across all target services and check for other packages pinning illuminate/support to ^9.0, which would make the upgrade unresolvable. Also verify the package's HTTP client usage is compatible with Guzzle 7 and any global HTTP middleware (retries, logging) you have registered.
Sequencing:
Maintenance: The package is small and the surface area is small, but the maintenance burden is deceptive — you are inheriting a dependency on an external API contract (Measurement Protocol) that changes on Google's schedule, mediated by a single-maintainer package that may not track those changes. Budget for periodic verification that hits are actually landing. Recommend an internal canary: a synthetic daily event with an alert if it stops arriving.
Support: No commercial support. Upstream responsiveness is unproven; the release record shows infrequent, single-PR cadence. Escalation path for a production issue is "fork it." Because the wrapper is thin, forking is cheap — factor that into the build-vs-buy call, and prefer the internal wrapper if the team has spare capacity.
Scaling: Hits are outbound HTTP calls to Google. At low-to-moderate volume this is fine. At high volume, inline dispatch adds latency to request paths and creates a fan-out dependency on an external endpoint. Mitigations: dispatch via queue, batch multiple events per request (Measurement Protocol supports up to 25 events per payload), and set aggressive connect/read timeouts with fire-and-forget semantics. Watch for connection-pool exhaustion under bursty traffic.
Failure modes:
composer update unresolvable across a multi-package app, surfacing as a CI failure far from the cause.Ramp-up: Low — an engineer familiar with Laravel can be productive in well under a day. The real ramp-up cost is analytics-domain knowledge: GA4 event schema, client_id propagation from the browser, session attribution via engagement_time_msec, and deduplication between client and server hits. Assign that to whoever owns analytics, not whoever owns the Composer file.
TPM recommendation: Adopt v1.10 conditionally — gated on written confirmation that it targets GA4 Measurement Protocol v2 and that the Laravel constraint was widened rather than replaced. If either is unconfirmed, treat v1.10 as a maintenance signal only and pursue the internal-wrapper path, which is roughly equivalent in effort and eliminates the single-maintainer and endpoint-drift risks simultaneously.
How can I help you explore Laravel packages today?