darvis/livewire-google-analytics
Easily add Google Analytics to your Livewire apps with a simple component. Track page views, events, and user interactions without writing JavaScript, keeping analytics setup clean and configurable in Laravel.
What this package is (baseline, since no prior assessment existed): livewire-google-analytics is a thin Livewire-side wrapper around window.gtag for the browser. Its job is to let you emit GA4 events from a Livewire component via a trait rather than hand-writing $this->dispatch('...') and <script> blocks. v1.3.2 is a documentation-only release; no code, config, or public API surface changed. The package has no prior assessment in this register, so this entry establishes the baseline.
Architecture fit. The package is deliberately narrow and sits at the presentation boundary: it emits client-side events from Livewire lifecycle methods. It explicitly does not load gtag.js, does not own a measurement ID, does not perform consent handling, and sends nothing server-side. That is a defensible design — it keeps the package out of the compliance and configuration surface — but it means the package is not an analytics integration. It is a dispatch ergonomic layer over an integration you already own. Any architecture decision that assumes this package handles measurement IDs, consent gating, or server-side/non-browser event capture is a misread, and the docs now say so plainly on the index page.
Integration feasibility. High for a shop already running Livewire plus GA4 via gtag.js. The contract is essentially: your layout loads gtag.js, and the trait's eight methods (including the …AfterRedirect() family) push events. Two mechanics matter for feasibility:
window.gtag exists and flushes it once available; ['queue' => false] turns this off. This makes it tolerant of script load order, at the cost of events that silently never send if gtag never appears.wire:navigate behaviour. On a repeat script run under wire:navigate the listener does not attach a second time, but it does send the carried events of the new page. This is the correct behaviour and was previously mis-documented; getting it wrong in a SPA-style Livewire app would have produced either duplicate or dropped events.Technical risk. Low code risk, moderate interpretation risk. The package has no build, no server components, and no data path except the browser. The real risks are:
window.gtag exists" behaviour is not a consent gate and must not be treated as one. This is the single largest risk and it is a design risk, not a defect.gtag means no event and no error surfaced to Laravel. Observability lives entirely in GA4 DebugView.…AfterRedirect() method is written into the next page's listener script as escaped JSON. That is a data-in-markup exposure that needs to be in your threat model if any event params can carry user-derived values.Documentation churn of this size on a patch release (v1.3.2) is itself a mild risk signal: corrections span the concepts, usage, testing, troubleshooting, and installation pages, plus the README and the Laravel Boost guideline. The corrections are honest and specific — the troubleshooting page now distinguishes No hint path defined for [livewire-google-analytics]. (service provider not loaded) from View [script] not found. (wrong view name) — but the volume suggests the docs had drifted from the code across several releases.
Key questions. What is the package's stated position on consent mode, and is that position acceptable to our legal review? Who owns gtag.js loading and the measurement ID in our stack — this package or our layout? Do we rely on queueing, or do we set ['queue' => false] and guarantee script order ourselves? Are any …AfterRedirect() event params user-derived, and if so are they safe to appear escaped in page markup? Is the package's GA4 event naming/content compatible with what our reporting already assumes?
Stack fit. Fits a Laravel + Livewire + GA4-via-gtag stack with no adapter work. It does not fit — and should not be forced into — a server-side tagging, GTM server container, or Measurement Protocol architecture, because the package sends nothing from the server.
Migration path. Nothing to migrate. There is no schema, no config file of consequence, no persisted state. Adoption is: add the package, add the trait to the components that should emit, and confirm gtag.js is on the page. Removal is equally cheap — delete the trait use and the dependency. Treat it as a leaf dependency in the architecture, which is exactly how it behaves.
Compatibility. The relevant compatibility axis is Livewire's lifecycle and wire:navigate, not Laravel's version. v1.3.2's doc fixes assert the wire:navigate semantics precisely: no second listener, carried events still sent. Confirm that against our pinned Livewire minor before rollout, because that is the one place where behaviour is subtle and a Livewire upgrade could change it without a package release. The Laravel Boost guideline (eight protected trait methods, not four) matters if we drive codegen or AI-assisted scaffolding from it — an agent following the old guideline would emit wrong overrides.
Sequencing.
gtag.js loading, measurement ID configuration, and consent gating are already handled by our layout and a consent tool — not by this package.'debug_mode' => true in event params. Retire any internal guidance referencing the "Google Analytics Debugger extension" — the package's own testing page has corrected this, and our runbooks should follow.Maintenance. Near-zero on our side; the package has a small surface and no server footprint. The maintenance burden that does exist is documentation-shaped: the package's own docs were wrong in several places as recently as v1.3.0–1.3.1, and v1.3.2 is largely a correction pass. Pin the version and re-read the concepts and usage pages on minor bumps rather than assuming doc stability.
Support. Support load will concentrate in one place: "the event didn't show up." The escalation path is DebugView, not application logs, because failures are invisible to Laravel. Publish an internal runbook that starts with the two console checks and the two distinct error messages the troubleshooting page now separates — No hint path defined for [livewire-google-analytics]. means the service provider isn't loaded; View [script] not found. means the view name is wrong. These are different fixes and were conflated before.
Scaling. No scaling concern in the conventional sense — the package adds no server work, no queues, no storage. The scaling question is entirely GA4's: browser-side events are subject to client-side blocking, ad blockers, and consent denial, so absolute event counts will under-report versus server-truth. If any downstream metric requires completeness (billing, funnel attribution, compliance evidence), it cannot come from this package and must be sourced server-side via Measurement Protocol or another channel.
Failure modes.
gtag absent → queued event waits, then is lost. No error. Mitigate by verifying script presence in staging.No hint path defined for [livewire-google-analytics].View [script] not found.wire:navigate → should not occur; the listener does not re-attach. If duplicate events appear, look at our own gtag initialisation, not the package.…AfterRedirect() payloads → visible as escaped JSON in the next page's markup.Ramp-up. Low and shortening. The new Quick start page — one complete contact form with layout, component, view, and route, each with filenames and imports — collapses the usual "assemble a working example from scattered snippets" phase into a single read. The installation page's "Check that it works" section (two console checks, a pasteable test event, where to look in DebugView, and what a non-appearance means) gives a new engineer a self-verifying path. Estimate well under a day for a developer already fluent in Livewire; the residual learning is GA4 vocabulary, not this package. The index page's explicit "what this package does not do" list is the most valuable onboarding artifact here, because it prevents the single most likely misconception before it forms.
Recommendation. Adopt for what it is: a convenience layer for emitting browser-side GA4 events from Livewire components. Do not adopt it as an analytics integration, a consent mechanism, or a source of record. Version v1.3.2 is a safe update — documentation only, no breaking changes, no deprecations, no new features — and its corrected descriptions of queueing, wire:navigate, and …AfterRedirect() payload handling should be read as the accurate baseline for any design decision, superseding anything written against 1.3.0 or earlier.
How can I help you explore Laravel packages today?