Livewire Google Analytics Laravel Package

Product Decisions This Supports

• Feature instrumentation for Livewire UI. The package attaches GA4 events to Livewire component behaviour via a trait, so the events worth measuring — multi-step form progression, validation failures, submit success, modal and panel opens, wire:navigate transitions — become declarations in PHP rather than tag-manager configuration. This is the main use case: intent-level analytics on an app where page views under-report what users actually did.
• Build vs buy on the dispatch layer only. Adopt it as a small Composer dependency for "send this event from this component," and build (or already own) everything around it. v1.3.2 makes that split explicit: the package does not load gtag.js, has no measurement ID setting, does no consent handling, and sends nothing from the server. Evaluate it against GTM dataLayer pushes (more flexible, decoupled from PHP), hand-rolled $wire/Alpine dispatches (zero dependency, more boilerplate), or a full analytics SDK (heavier, more lock-in).
• Roadmap scoping. Treat the stated non-goals as stable product boundaries, not backlog gaps. Do not plan features that assume the package will grow a measurement-ID config, server-side dispatch, or consent gating. If the roadmap needs server-side or offline events (purchase confirmations, webhooks, refunds), budget a second mechanism — GA4 Measurement Protocol — as a separate workstream.
• Privacy and legal sign-off as a product decision. Two documented facts force this: (1) since 1.3.0, the event payload of an …AfterRedirect() method is written into the next page's listener script as escaped JSON; (2) the package knows nothing about consent — it sends a waiting event once window.gtag exists, and ['queue' => false] turns that off. Whether event params may carry user identifiers or free text is therefore a PM/compliance call made before rollout, not an implementation detail discovered in review.
• Adoption cost and support load. The new quickstart ships one complete contact form — layout, component, view and route, each with file name and imports — plus a "check that it works" path with console checks, a pasteable test event, and where to look in GA4 DebugView. That shortens time-to-first-event, which is the difference between scheduling this in a sprint and parking it as a spike. The corrected troubleshooting entries (No hint path defined for [livewire-google-analytics] vs View [script] not found) reduce the debugging tax that usually lands on the PM as "why is this not working."

When to Consider This Package

Consider it when:

• You are on Laravel + Livewire and want analytics events driven by component behaviour rather than by DOM selectors or tag-manager rules.
• You already have, or are willing to own, gtag.js loading, the measurement ID, and consent gating. The package is designed to sit on top of an existing GA4 setup, not to install one.
• You value a small, reviewable surface: one trait, eight protected methods (dispatch and …AfterRedirect() variants), event declarations that appear in code review and diffs.
• You need SPA-style navigation support — the listener is not re-registered under wire:navigate, but carried events from the new page are sent.
• You want a documented debugging path: debug_mode on the tag or per-event via 'debug_mode' => true, Tag Assistant, and GA4 DebugView under Admin → Data display.

Look elsewhere when:

• You need server-side, offline, or webhook-triggered events, or a measurement ID configured in Laravel config. Out of scope by design.
• You need built-in consent mode or GDPR/ePrivacy gating. The package is explicitly consent-agnostic; that obligation stays with you and likely means a consent management platform alongside it.
• You need a tag manager, non-Livewire front ends, or events originating outside Livewire components.
• You need vendor support, an SLA, or a bus-factor above one. This is a single-maintainer package.
• You cannot accept event parameters appearing in serialized page HTML. If params carry identifiers or free text, the …AfterRedirect() behaviour is a blocker until you have reviewed the data you send.

How to Pitch It (Stakeholders)

For executives. A narrowly scoped, low-cost way to get real product analytics out of a Livewire application: it records the behaviours we care about — form steps, submissions, validation failures, navigation — as code-reviewed event declarations. It adds no tracking script, no measurement ID setting, and no vendor lock-in, so it composes with whatever analytics and consent stack we already run rather than replacing it. The trade-off is explicit and now documented on the index page: we own consent and GA configuration ourselves, which means a short legal/analytics-ops sign-off before launch, not an engineering surprise. This release is documentation only — no code change, no breaking change, no migration.

For engineering. v1.3.2 is docs-only; upgrading touches nothing in src/. What changed is that the documentation now matches the code and stops over-claiming. Three corrections matter for anyone already instrumented: (1) …AfterRedirect() events are serialized into the next page's listener script as escaped JSON — the "values are never written into a script" claim was true only before 1.3.0; (2) Google's consent mode does not "do the rest" for queued events — the package just waits for window.gtag and ['queue' => false] disables that; (3) the listener does listen a second time under wire:navigate, but it does send the new page's carried events, and all eight trait methods are protected, not four. The new quickstart (complete contact form) and the install-page verification steps — console checks, a pasteable test event, what DebugView looks like on success and what it means when you see something else — are the fastest path to a first confirmed event in a fresh environment. Treat the "what this package does not do" list as the integration contract: bring your own gtag.js, measurement ID, consent handling, and a separate mechanism if you need anything server-side.